Am 30. September 2021 11:53:47 MESZ schrieb Michael Walle <mich...@walle.cc>: >Am 2021-09-30 08:56, schrieb Heinrich Schuchardt: >> On 9/30/21 8:23 AM, François Ozog wrote: >[..] >>> Is U-Boot's UEFI loader implementation supposed to be the >>> recommended >>> UEFI firmware on ARM and RISC-V on a production / deployment >>> system? >>> >>> For Arm: yes, that is SystemReady spec. >> >> For RISC-V it is required by the RISC-V platform specification. >> >>> >>> >>> Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do >>> we >>> expect to load grub.efi which chain-loads a kernel without >>> CONFIG_EFI_STUB? >>> >>> all paths should be possible , and the shim.efi is to be supported >>> too. >>> With UEFI, I always see that UEFI is kept down to OS for SecureBoot. >>> In >>> other words I don’t see grub.efi booting a non config_efi_stub. >>> >>> What do distributions normally do? >>> >>> At least Red Hat made it clear at multiple Linaro Connect that they >>> want >>> standards, and SystemReady is one that makes the life of embedded >>> distros easy. >>> Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi >>> SecureBoot. >> >> For Fedora see >> https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description >> >> SUSE started the UEFI implementation to boot on all architectures in >> the >> same way. The current ARM and RISC-V images uses UEFI. >> >> Debian and Ubuntu install for booting via GRUB if the installer is >> invoked via UEFI. A fallback solution using the legacy Linux entry >> point >> exists. >> >> For BSD the only way to boot on ARM is via UEFI. >> >>> >>> What's our >>> position when compared to EDK II? >> >> U-Boot implements only a subset of UEFI defined in the EBBR >> specification. >> >> For servers you need a larger scope which is offered by EDK II. This is >> required both by the RISC-V platform specification as well as the ARM >> SystemReady ServerReady profile. >> >> The number of boards supported by upstream EDK II is very low. But >> proprietary firmware based on EDK II exists. >> >>> >>> the typical distro boot flow is not the most efficient and drags >>> concept >>> dating where the Microsoft certs had to be part of the picture. A >>> direct >>> U-Boot Linux.efi is my preferred; avoids yet another OS in the boot >>> path >>> (grub), avoids convoluted platform cert management (shim) and just >> >> This is why U-Boot supports UEFI boot options specifying both a binary >> as well as an initial RAM disk. > >I might be late to this, but where does the devicetree come from? As far >as I understand it right now, for most (all) the SytemReady IR certified >boards, the compiled-in one from u-boot is passed to linux. This won't >work >in the long run, because the devicetrees keep getting incompatible >changes. >So while it work for one kernel version it might not work on the next >version.
It would make sense to add the fdt devicepath to the bootoption like we did it for the initrd. Best regards Heinrich > >-michael