Driver model at UEFI runtime

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

Best regards

Heinrich

>
>-michael