Re: Supporting *multiple* bootloaders for arm64 on a single install?

[Stefan <stefan-guix@vodafonemail.de>]

Hi!

>> But as I understand it, guix only supports a single bootloader entry. 
> 
> That is correct.
> 
>> To support all of the above, I would need three separate bootloader
>> instances... one for Pinebook, one for Pinebook Pro, and lastly a
>> grub-efi bootloader.
> 
> Stefan wrote a Guix chain bootloader that is in master--but it's meant
> to be only used for bootloaders where there is a primary "bare-metal-loaded"
> bootloader and the others are chain-loaded one-after-another from ONE filesystem
> (for example Raspberry Pi and/or EFI bootloaders).
> 
> (It's currently used in order to use an EFI bootloader hosted on NFS--which
> is an awesome way to manage embedded boards)
> 
> The chain bootloader itself is one Guix bootloader.
> 
> I advise you to search for mails by Stefan on the guix-devel mailing list--those
> are very illuminating.

By the way, there is <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48314> since a month meanwhile, which now makes the support for the Raspberry Pi complete. The same bootloader can be used for an NFS root installation and an installation on micro SD card or an USB drive by just changing the mount point of the root file-system.

Danny, I’d appreciate your review very much. This time you can apply the patches and just use the gnu/system/examples/raspberry-pi-64.tmpl with guix system init. :-) 

>> And somewhere along the way I've lost track of how we get to
>> install-pinebook-pro-rk3399-u-boot…

The same happened to me. I’ll first wait for the patch #48314 to be accepted, before I’ll look again into creating a disk image for the Raspberry Pi.

> If you do want to chainload grub-efi eventually, that's supported in Guix master,
> see "efi-bootloader-chain".  It's meant for the end user to be able to use.

Referring to the patch #48314, the efi-bootloader-chain got simplified. It basically prepares a profile with all files to be copied as is, no special “collection” folder any more. And the installer of the grub-efi-netboot-(removable-)bootloader is now merely a simple “(copy-recursively bootloader-profile)“ procedure.

>> A related idea would be to generate an EFI bootable image with
>> sufficient emtpy space before the first partition (16MB) and then one
>> could manually install the appropriate u-boot, maybe with some helper
>> scripts to avoid having to do it completely manually...
> 
> Yeah, that's possible right now.  After all, you don't have to load the generated
> guix system disk image on bare metal.  Just boot it in qemu and install u-boot
> there for example.  Or even edit the image manually by using dd.  (unfortunately,
> on almost every ARM system I set up Guix on so far, one or both of those were
> necessary)

I believe that the ARM future is UEFI, like on PCs. A lot of distributions already chainload U-Boot and GRUB an arm systems. There is a specification for ARM servers which demands UEFI¹. And there is even the choice between U-Boot and TianoCore/EDK II.

I think meanwhile that it would be beneficial, if, beside a bootloader field, Guix would accept an optional firmware field. Then the U-Boot or TianoCore/EDK II (or coreboot) could become some board specific firmware, and the actual bootloader would be grub-efi installed on an EFI System Partition. For systems like the Raspberry, which require their firmware on a FAT partition, there is the already working efi-bootloader-chain solution.

The firmware could only be installed on explicit request. It's not expected to see frequent changes – every re-installation is a risk to brick the system. (For my taste the bootloader is re-installed too often already.)


Bye

Stefan


¹ <https://documentation-service.arm.com/static/5fb7e415d77dd807b9a80c80>