Driver model at UEFI runtime

[François Ozog]

Le ven. 1 oct. 2021 à 00:00, Michael Walle <michael at walle.cc> a écrit :

> >>>>> 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.
> >>
> >> how is that tinkering? That means once you have a device tree, it is
> >> set in stone. which isn't reality, sorry.
> >>
> >> Consider the ls1028a and the flexspi "bug". For the 5.10 kernel/dtb
> >> there was a wrong clock connected to the flexspi device. There
> >> wasn't
> >> even a driver for the correct clock.
> >
> > The clock could have been described even though there was no Linux
> > driver.
> > DT is there to describe HW, not the capacity of a particular OS or
> > boot firmware to deal with it.
>
> You're missing my point. It's not about what would be the perfect
> scenario. But what actually happens in reality. And unfortunately,
> it happens, so you have to deal with devicetree incompatibilies.
> Just ignoring this and keeping just one devicetree in the firmware
> is doomed to fail sooner or later.

We have an example of firmware provided hardware description that works
well (Ok: 99% of the time): ACPI.
We also are 100% sure that the current situation is messy, hairy, buggy but
familiar.

>
>
> [..]
>
> >> Regarding the imx8mm usb error, apparently the node was renamed. If
> >> you're
> >> using older kernels with newer dtbs, the kernel oopes. If you're
> >> using a
> >> newer kernel with older dtbs, USB doesn't get probed. (Although I
> >> was
> >> told that there is a "fix" for this, that is, both node names are
> >> tried.)
> >
> > I keep seeing those issues about node renames or compatible string
> > changes.
> > That's the tinkering I am talking about.
> > There is no in-kernel ABI but Linus bang heads if anyone touches
> > userland-kernel ABI inappropriately.
> >
> > As DT is mostly handled in-kernel, people treat DT as no-ABI.
> > But it is part of firmware-kernel ABI.
> > Until we properly organize this firmware-kernel ABI, the problem you
> > describe and more will continue.
>
> Sure, but until you reaches that point (I predict it wont happen soon
> or at all) you'll have to deal with per kernel devicetrees. Just
> saying, we are just providing one devicetree supplied by the firmware
> just doesn't work with the current situation. So IMHO if SystemReady is
> really "it just works", then you have to consider this. And so far,
> it seems all SystemReady certified boards just throw the u-boot
> devicetree at linux and hope for the best.

SystemReady is not meant to be all boards, starting now and mandatory. It
is a selected of boards for which everyone in the value chain is willing to
spend the energy to solve the problem as if we were living in a perfect
world.

>
>
> > Now the DT lifecycle before the firmware-kernel ABI also needs to be
> > specified so that we properly handle hats, capes, SoMs, carrier
> > boards...
> >
> >>>
> >>
> >
> https://developer.arm.com/architectures/system-architectures/arm-systemready/ir
> >>> lists a number of certified boards and the list is going to grow
> >>> significantly.
> >>
> >> And the sl28 board will likely be there soon, too.
> >>
> >>> On those boards, you will be able to boot any kernel.
> >>
> >> Actually I don't think so, because you might hit the imx8mm bug,
> >> too.
> >> May
> >> just be lucky by the devicetree/kernel combination.
> >>
> >>> 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.
> >>
> >> Mh, I'm not sure I understand what you're trying to tell me. The
> >> distribution also provides you the kernel, why shouldn't it provide
> >> devicetree which exactly matches this kernel and was also tested
> >> against.
> >
> > Because the kernel has no clue which hats, capes has been added for
> > instance.
>
> And the same might be true for the firmware as pointed out before.
>
> > The kernel provided DTB works fine when the firmware builder and OS
> > builders are the same.
>
> Ehh? It is just the other way around. The distro supplies the kernel
> and thus it also have the corresponding devicetrees for this particular
> kernel. The firmware can remain the same. Now Mark might disagree here,
> because OpenBSD doesn't provide devicetrees (I really don't know).
>
> I agree, that in a perfect world, there would be just one (or a set of)
> stable devicetree(s) which can be used by any OS/Distribution/Kernel.
> But this simply isn't the case.

Agreed: this is not the case today. But some vendors have decided that for
some boards it will work this way following EBBR for Arm and RISC-V.
Based on the current maturity of the DT, we are at a pivot moment when we
can do this for many boards without too much issues.


>
> > This traditional model is evolving and the team that deals with OS may
> > not even be in the same company as the one providing the firmware.
> > Ask the Fedora IoT architect what he thinks about the distro provided
> > DTs ;-)
>
> I don't even know who "the fedora iot architect" is, nor what her/his
> arguments are.
>
> > There is a need to deal with DT bugs. OS provided DT is a bad solution
> > to a real problem.
> > U-Boot patches look a possibility for those bugs.
>
> And then you always have to update the firmware and duplicate the
> "code".
> I.e. theres an incompatible change, the devicetree is update in linux
> and you have to replicate just this as a fixup in u-boot. And you have
> to detect when and if it should be applied.

DT should not change based on driver change. DT has been used as a driver
parameter facility and that created issues. DT is not meant for that. Linux
has driver load options and /etc/modules.d/*.conf for that as well as many
other facilities such as ethtool for example. If drivers stop using DT as a
parameter/config store you avoid most of the problems. And then you can
really share DT between OSes (*BSD…).

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