Hi Rob et al, First of all, for clarity I have been a supporter of the firmware provided devicetree as you can see from my recent talk [1] at EOSS24. But I also do recognise the current DT ABI stability challenges faced by the embedded community leading to this OS provided DT proposal. This proposal may allow embedded systems to just work but won't solve the DT fragmentation problem in the longer run. Maybe as a side effect it can give people a reason to not care about DT ABI stability issues? Or maybe I am a bit too optimistic about the possibility of improving DT ABI stability?
DT ABI stability is also important to the other DT consumers as well like U-Boot, barebox, other OSes etc. So we should keep them under consideration too. On Wed, 8 May 2024 at 04:13, Rob Herring <robherri...@gmail.com> wrote: <snip> > > >> Linux's device tree source is maintained with the kernel source, and > > >> kernel builds > > >> include building the device trees too. This ensures that the device tree > > >> matching the kernel's usage is always kept in sync. Often, embedded > > >> distros will > > >> include the matching device tree blobs. > > >> > > >> The EBBR mandates that the device tree blob is provided by the firmware. > > >> > > >> Thus it is likely that the device tree provided by the firmware and > > >> given to the > > >> operating system is not the matching device tree blob for that kernel. > > >> This can > > >> cause hardware to be missing, buggy, or non-functional. > > > > Yes. My first experience with EBBR was AFAIR a system that didn't boot, > > because an > > up-to-date Debian kernel failed to handle the old device tree provided by > > the > > firmware. At least updating the EFI firmware with a USB stick worked well. > > Was that SystemReady IR compliant too? Unfortunately, IR 1.x doesn't > do much for DT checking, but 2.x does and should help a bit. It's > testing with schemas from relatively recent kernel trees and OS > kernels of various versions have to boot. So there's at least some > implicit mismatching. > Current DT checking as you have highlighted above seems like a cumbersome effort to me. Testing against DT bindings/schemas coming from mainline kernel and other OS kernels can be difficult especially if those schema versions regress each other. Also, I suppose this DT checking happens for a single firmware version supporting the current DTS at that point. But what happens if we want to do firmware updates with a newer DTS version (new features)? Do we still have some DT checking mechanism for those? Also, what if the list of supported OS kernels expands in future? IMHO, the DT checking should be part of the firmware build process. And having a single canonical set of requirements to check against would greatly simplify DT checking. IOW, if we can have only a single version of DT bindings/schemas which is supported by all DT consumers. Currently we do have core DT schemas maintained here [2] and on similar grounds we should be able to decouple device specific bindings/schema files from the Linux kernel to the DT schema [2] repo. Although this is something that has been discussed in the past here [3], I still think it can be a good step for DT ABI checking tools to be effective and incorporated into the firmware build process which in turn will improve confidence in firmware provided DTB. [1] https://youtu.be/0Rw58lP3zPA [2] https://github.com/devicetree-org/dt-schema/tree/main/dtschema/schemas [3] https://lore.kernel.org/all/CAFA6WYPYfKU9hHh5CCbgcb6FEDX7ivGO=tgv4n2dax6_gag...@mail.gmail.com/ -Sumit _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
