Driver model at UEFI runtime

[Michael Walle]

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

[..]

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

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

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

-michael