Driver model at UEFI runtime

[Michael Walle]

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