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. 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.o...@linaro.org | Skype: ffozog