Driver model at UEFI runtime

Michael Walle michael at walle.cc
Thu Sep 30 14:07:26 CEST 2021


Am 2021-09-30 12:50, schrieb Heinrich Schuchardt:
> Am 30. September 2021 11:53:47 MESZ schrieb Michael Walle 
> <michael at 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.

I haven't followed the much of the recent development, are there any
commits/files I can look at?

And I'm not just talking about the use case where the EFI stub of linux
is booted directy, but also when there is grub in between.

The distribution would supply a bunch of devicetrees along with
the kernel (and initrd). Possibly also different versions of these.
In grub you would choose the desired kernel/initrd/devicetree
combination.

But this means grub would need to (1) know the filename of the
devicetree, or (2) it is hardcoded in the grub config which is
generated by the distribution.

For (1) you'd need to convey the information from u-boot to grub.
(2) would mean the distribution will have to figure out the suitable
devicetree.

To make things worse, there are boards which have several
different devicetrees or there might even be overlays. Eg. my
board has different devicetrees which are expected to be chosen
by the user by setting the fdtfile variable.

-michael


More information about the U-Boot mailing list