efibootmgr’s job is to manage and setup EFI configuration variables to define boot entries and order.
It doesn’t work on my Pinebook Pro, that’s the reason why I had to copy /boot/efi/EFI/manjaro/grubaa64.efi to /boot/efi/EFI/BOOT/BOOTAA64.EFI.
After some digging I found out that u-boot (tow-boot) is supposed to store the EFI environment variables in the UEFI partition, as a /ubootefi.var file.
However it doesn’t work and I cannot find proper documentation telling how this is supposed to work or if the file should be previously created and how.
I found a post stating that because of some bug it might not be able to write to FAT16 and would need FAT32, so I converted my EFI partition to FAT32, still to no avail.
u-boot can’t write EFI variables once the kernel takes over. The linux kernel takes ‘ownership’ of the eMMC and if the boot firmware tries to write to the EFI system partition there would be a conflict.
The only way to write EFI variables is before the linux kernel takes over. I used the EFI shell and set boot entries with bcfg
I downloaded shell.efi from some website that I don’t remember. The aarch64/Shell.efi in this package should work: Arch Linux - edk2-shell 202208-1 (any)
In the long term, I hope someone can teach uboot to store EFI vars in the SPI flash. Then we could remove it from the device tree, to make sure the linux kernel does not interfere.
Yes
I think that the perfect way to make a boot firmware on the PBP would be as follows:
u-boot (or coreboot/tianoCore/petitBoot) on SPI
assign SPI flash into the TrustZone, so the OS has no direct access
have a BL32 payload in the TrustZone that handles EFI variable access and firmware upgrades
This way, SecureBoot and secure firmware updates could be done. The linux OS wouldn’t need direct access to the SPI, since the boot firmware would handle that.
I don’t have any experience with bare-metal programming. If I had unlimited time, I’d teach myself and then work on this.
Well I would strongly disagree with the idea of removing the kernel’s ability to acccess the SPI flash, it’s very useful to have and could be used for different purposes.
It’s not in Linux and Free Software usages to purposely cripple anything.
Furthermore I do agree with tow-boot author’s opinion that a distribution should definitely not mess up with the firmware because the machine’s owner may want to use the machine with different OSes and no OS should make the assumption that it’s OK for it to mess up with the system’s firmware.
So while we might have tools that allow setting the firmware in whatnot way, and even upgrade it or install another make/version, that should be and remain an admin’s informed decision and never some “automatic installation stuff“, nor be required for the distro being installed or usable.
