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

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 3268 bytes --]

On 2021-06-19, Stefan wrote:
>>> 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.
...
>> 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.
...
>> 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...
...
> 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.

Yes, standardizing on UEFI in general would be a good thing, especially
because u-boot can increasingly fill that role for boards that don't
have a tianocore/edkII implementation.

My heart is more with u-boot, but i also value standardization. :)


> 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.

Yeah, I like that idea! Das U-boot functionally is both kind of boot
firmware as well as a bootloader rolled into one; I could see treating
it more as a firmware which may not actually even need a separate
bootloader (other than maybe generating a boot script or extlinux.conf),
or a firmware implments EFI (and thus can load grub-efi).


> 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.)

Mixed feelings on that; it puts you in the situation of not knowing when
the current guix bootloader/firmware is broken if you don't reinstall it
(although maybe it could be made smarter and only reinstall
bootloader/firmware when it actually changes).

It's already possible to pass an empty bootloader that just generates
the configuration files for grub or extlinux which doesn't re-install(to
my knowledge). Extending that to the proposed firmware idea would make
some sense...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]