[bug#48314] Patches to install guix system on Raspberry Pi

[Stefan via Guix-patches via <guix-patches@gnu.org>]

Hi Vagrant!

>> +(define-public %u-boot-rpi-efi-configs
>> +  '("CONFIG_OF_EMBED="
>> +    "CONFIG_OF_BOARD=y"
>> +    "CONFIG_BOOTDELAY=0"))
> 
> This is surely a matter of opinion, but CONFIG_BOOTDELAY=0 is kind of
> nasty; it makes it nearly impossible to debug from a u-boot prompt if
> needed. The default is probably "2" ... long enough to actually
> interrupt it, but short enough that it shouldn't cause huge delays in
> the boot process...
> 
> I know grub-efi will add it's own delay, so in a working environment,
> this just seems like an additional two seconds, but u-boot's EFI
> implementation is changing often enough that I wouldn't be surprised if
> you need to occasionally debug something.

During all the months of work to get Guix System booting over network with U-Boot and GRUB, there was no need for me to play around on the U-Boot prompt. I was even affected by a bug¹ preventing U-Boot to detect my keyboard at all. The actual problem with that bug was not that the U-Boot prompt was unusable, but that GRUB relies on the keyboard functionality of U-Boot, so I couldn’t debug boot problems e.g. due to kernel argument problems in GRUB.

Well, in this constellation U-Boot just needs to find and load the efi/boot/bootaa64.efi file. It doesn’t need to load device-tree files or care for overlays. It doesn’t need to load other stuff like SPL or other images. Its only purpose is to impose an EFI interface and to load GRUB. So the benefit of the U-Boot prompt is quite limited.

Also other distributions like openSUSE use U-Boot as EFI firmware, so I think the basic EFI functionality is tested quite well. My preference is to not bother pure users with a delayed boot time. However, I changed it to CONFIG_BOOTDELAY=1.


Bye

Stefan


¹ <https://en.opensuse.org/HCL:Raspberry_Pi3#I_cannot_use_keyboard_in_U-Boot_and_Grub_but_it_works_in_Linux>