Driver model at UEFI runtime

Thu Sep 30 17:47:17 CEST 2021

On Thu, 30 Sept 2021 at 17:12, Michael Walle <michael at walle.cc> wrote:

> [adding Vladimir, because he showed interest in this, too]
>
> Am 2021-09-30 15:56, schrieb François Ozog:
> > On Thu, 30 Sept 2021 at 14:07, Michael Walle <michael at walle.cc> 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?
> >>
> >> 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.
> >
> > With SystemReady, DT from distros are ignored.
>
> Err? Is this really true, I know about some incompatible changes
> to the device tree which prevents you from using usb (or even a
> kernel panic) with the imx8mm and I know that on the ls1028a
> flexspi wont work if the devicetree doesn't match the kernel.
> I.e. if you have a device tree from kernel 5.14 you cannot
> use it on 5.10. If you have one from 5.10 you cannot use it on
> a later kernel.
>
> What you describe is the situation we want to avoid and that comes from
years of tinkering.
https://developer.arm.com/architectures/system-architectures/arm-systemready/ir
lists a number of certified boards and the list is going to grow
significantly.
On those boards, you will be able to boot any kernel.
The image I have in mind with OS provided DT is:
as a French driver, my DT says that the steering wheel is on the left hand
side of the car.
Shall I whine about the cars in England that do not comply to my DT? or
accept to use the car provided DT?
The situation is comfortable for tinkerers, but not sustainable. It is a
matter of organization and not technology to solve the problems you
describe.

> So, IMHO this is alreay a non-starter for SystemReady if it
> should work beyond having a serial console and some storage :(
>
> > With SecureBoot on, dtb=<file> on the command line is disabled.
> > UEFI can have multiple boot options. Each boot option comes with:
> > - a list of "device paths" --> dp[n]
> > - a command line
> > The "device paths" are not your typical file path in operating system.
> > They can include configuration information (line speed for a UART
> > along with terminal emulation parameters). Each dp can be given a
> > specific class. An initrd "vendor media" class was created.
> > At present, dp[0] is loaded as the UEFI command and dp[1..n] are
> > ignored.
> > Linux kernel EFI_STUB can ask "load the "initrd vendor media here";
> > the EFI subsystem with browse through dp[1-n] for that element and
> > load it.
> > If measured boot is on, the initrd will be measured by the UEFI
> > subsystem.
> > So by having multiple BootXXX variables, one can achieve multiple
> > kernel selections.
> >
> >> 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.
> >
> > That was practical when the "user" is also a developer. Things have to
> > mature to a different model, yet offering same flexibility.
> > For example some NXP layerscape processors can define the function of
> > pins by configuring a SerDes. A pin can thus be a PCI lane or an
> > ethernet MII lane. A board is built with either PCI or Ethernet
> > connectors or devices. It has nothing to do with a "user" choice: the
> > DT passed to the OS need to reflect the hardware configuration. U-Boot
> > need the SerDes device DT to be able to configure the SoC to match the
> > board hardware. The RichOS shall not see the SerDes, just the PCI or
> > Ethernet things. Those are known in advance and associated with the
> > board itself.
>
> Thats understood and clear. But there are also different things to
> consider, where the user might actually change something not related
> to hardware but which is also contained in the devicetree. The
> internal switch connection (and configuration) on the LS1028A comes
> to mind (maybe Vladimir can be more specific here). In general, there
> might be more than just a description of the hardware in the devicetree.
>
> Indeed and DPAA2 configuration also comes to mind. But then where shall
the use configuration be described?
DT shall describe the hardware, and not its configuration which tends to be
OS dependent or more precisely, driver dependent.
U-Boot is probably the best placed to do some of the work. It can have ways
to describe the desired configuration in auxiliary persistent configuration
data.
That auxiliary information can be stored in various places under various
formats. One possible way is to have overlays.
Another one is to have U-Boot use DT format as way to stored some
configuration (U-Boot private bindings). This method is actually used by
TF-A, for instance to describe the static secure partitions.

> Could you describe the use case for multiple device trees for one
> > board?
>
> The board is actually a plug-in module which you can put into
> different carriers. The module comes in different variants (1
> to 4). This is detected by the bootloader and the correct variant
> device tree is loaded, but OTOH the carrier is not detected. This
> is something the user has to provide (by now, they have to set
> the fdtfile variable to match their carrier).
>
> You can also have a look at
> linux/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28*dts
> for actual devicetrees.
>
> For hats, capes, SoMs, carrier boards and others, we need to better
organize.
The EEPROM based approach by RPI and Beagle shall give us hints on how to
deal with this at scale in an industrial manner.
We have EEPROM SPDs for DIMMs: it feels so natural to leverage the same
concept to bring enumeration to those hot/cold pluggable elements.
It is my intent to sit down with RPI, Beagle and 96Boards to agree on
something around those lines.
In the meantime, manual composition is a nuisance with have to deal with.
But for sure, that should be entirely transparent to the OS.

Side note to read in a positive mindset even if it does not look positive:
If we keep things like they are, what may end up happening is that business
leaders will direct their teams to use ACPI to avoid DT related pains.
One would say ACPI does not support everything and it comes with EDK2...
Well, let's just be patient and we will witness that business guys have a
different view of what is a solution to a problem.

-michael
>

-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog