Driver model at UEFI runtime

[Michael Walle]

Am 2021-10-01 00:20, schrieb 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.

Mh, I can't really comment on this as I am not familiar with ACPI.
But judging by all the linux acpi fixups and bios incompatiblies,
my gut tells me that it doesn't work _that_ well ;)

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

And here I am, trying to find a solution to a real problem I'm facing
with my board and the systemready cerification. But all I'm hearing is
that it should work the way linaro/ARM have in mind, but it clearly
doesn't.

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

Mh, it seems we are just repeating our own arguments and this doesn't
really lead to anything more of value.

-michael