[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#48314] Patches to install guix system on Raspberry Pi
From: |
Stefan |
Subject: |
[bug#48314] Patches to install guix system on Raspberry Pi |
Date: |
Sun, 17 Jul 2022 18:47:52 +0200 |
Hi Vagrant!
> u-boot-file appears to be hard-coded; there may be other boards which use a
> different u-boot artifact.
If you build U-Boot, there is also u-boot-nodtb.bin. Therefore the u-boot-file
is a function argument to the public make-preinstalled-u-boot-package to allow
a selection.
> Also, why return a single file, rather than just building a package and then
> allowing other functions to pick the appropriate file out of the resulting
> package?
The reason is in the patch set 1: There is (already in master) a
bootloader-profile which is able to collect a chain of bootloaders. The version
in master allows a collection of files from packages, but requires a special
installer. I figured out that the usage of the bootloader-profile gets much
easier if the packages to chain only contain preselected files. From a user
perspective the content of a complete bootloader-package is kind of a blackbox.
When writing an operating-system configuration it is easy to figure out the
right U-Boot package name, but no one expects to be required to install U-Boot
in his profile to figure out that the u-boot.bin is below the libexec directory
and that he is even required to care about moving the file around in directory
hierarchies.
However, you are right that the make-preinstalled-u-boot-package could take
another U-Boot package as argument, being that other function to pick the
appropriate file. Then it might be useful for other boards, too. The only
trouble to solve then is a proper package name. Currently using
make-preinstalled-u-boot-package the result of make-u-boot-package is only an
intermediate package prefixed with “-complete”. Then a preinstalled package
needs a suffix like “-bin”. I think this makes sense, I will change it.
> I wondered "why does it have to be cross-compiled" but then realized that
> came from the existing make-u-boot-package function.
Yes, that’s right, it is a copy from the other function. It will be gone with
the re-work.
> I've mostly been building u-boot natively these days. :)
Me too, exclusively. :-)
Bye
Stefan