guix-patches
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]