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

[Stefan]

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>