Am 2021-10-01 00:20, schrieb François Ozog:
Le ven. 1 oct. 2021 à 00:00, Michael Walle <mich...@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
