Driver model at UEFI runtime

[Heinrich Schuchardt]

On 9/30/21 14:07, Michael Walle wrote:
> 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?

For FDT, not yet.

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

The best way to handle this would be the devicetree command in GRUB. In
U-Boot we have implemented a protocol to fixup devicetrees:
https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL
This is already used by systemd-boot.

I prepared some patches for GRUB:
https://lists.gnu.org/archive/html/grub-devel/2021-02/msg00012.html

Unfortunately GRUB maintainers have decided to disable the devicetree
command when secure boot is enabled.

Best regards

Heinrich

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