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