Jeremy Linton

Yes, I've been cleaning up this and a few other commits in that repo for upstreaming last month, but got stalled debugging a shim/etc problem. Once that is cleared up...

@dimpase: You use an SD card to boot, write an updated RPI_EFI.fd (where the variables are stored when using SD/etc) then copy the resulting updated RPI_EFI.fd to your target boot...

You are not "building" anything. UEFI is designed around having an exclusive persistent place to store settings, and the rpi out of the box doesn't support such a concept, so...

I guess it depends on what you mean by "sane". You can both build disk images with this firmware or just put it on SD and pretend it's a normal...

I have a pi5 as well, but I also need to upstream a pile of pi4 patches before I get serious about working on the pi5.

I suspect I just ran headlong into this with a recent rebase of my edk2 branch. Try dropping to the shell and running grub directly rather than the default shim->grub...

Right, so confirmation that it looks like rpm firmware that supports the EFI memory attributes protocol blows up with: ``` SOpen: Open '\EFI\BOOT\fbaa64.efi' Success SetMemoryAttributes: BaseAddress == 0x33797000, Length ==...

This is a known bug, and has several downstream bugs associated with it, the upstream bug is: https://github.com/rhboot/shim/issues/614

Although the immediate crash can be fixed (at least in my testing) with https://src.fedoraproject.org/rpms/shim-unsigned-aarch64/pull-request/2 which is already merged to mainline shim. That doesn't mean the alignments are correct, only that...

Presumably, your just using the GPIO fan? In Linux? This is an issue for the older ACPI on/off methods in linux, where the ACPI expectation is that the OS has...