Rob Herring <robherri...@gmail.com> writes: > On Wed, May 1, 2024 at 4:18 PM Humphreys, Jonathan <j-humphr...@ti.com> wrote: >> >> >> >> Hi all. Several EBBR meetings ago, I introduced the need for allowing OS >> provided device trees [1]. Please find below the proposal I am delinquent >> on sending. >> >> >> Hopefully, we can discuss this in the next meeting. >> >> >> Thanks >> >> Jon >> >> >> [1] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.02.12 >> >> >> >> Problem statement: >> ================== >> >> Device trees are in theory a pure description of the hardware, and since the >> hardware >> doesn't change, the device tree describing the hardware likewise never >> changes. >> With this, a device tree could then be burned into the hardware's ROM to be >> queried by software for hardware discovery. In practice, though, device trees >> evolve over time. They evolve for many reasons, including >> - support for previously unsupported hardware >> - device driver improvements that require additional hardware information >> - bug fixes > > I really would like specific cases of these where compatibility is > broken highlighted. The tooling and reviewing to identify these cases > has gotten much better. I've been prototyping a tool which will > compare 2 versions of binding schemas and spit out incompatible > changes for example. Those aren't the only types of changes as you > point out, but if we can eliminate a whole class of issues I think the > situation would be much better. > > >> 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. >> >> Proposal: >> ========= >> >> A key goal of the EBBR is to define the contract between the firmware and >> the OS >> so that the OS doesn't need to be built specifically for the hardware, and >> the >> firmware can boot any compliant OS. Thus, any solution that requires the OS >> to >> know specifics about the hardware beyond the EBBR contract would violate the >> EBBR goals. This precludes any solution where the OS, having the matching >> DTBs, >> would pick the DTB, because this requires the OS to know what hardware it is >> being run on. Likewise, any solution where the firmware is aware of the OS >> matching DTBs would require the firmware to be aware of the particular OS it >> is >> booting. > > Nothing prevents an OS from using its own DTB already. The OS does > know what hardware it runs on because we tell it with the DTB. > >> What can be known: >> - The firmware knows what board it is running on, and thus knows what device >> tree to use. But it doesn't know what version of the device tree to use, >> because it doesn't know what OS is being booted. >> - The OS knows what version of DTBs matches it's kernel, but does not know >> which >> specific device tree to use. >> >> This proposal then has the firmware choose the device tree by name, or some >> other identifier that can be used to match the device tree for the board >> [1]. It >> has the OS-provided OS loader select the location of the matching versions of >> DTBs for it. >> >> The firmware would pass the device tree filename/id to the OS loader, >> instead of >> the DTB itself. > > If the firmware can't know which version of DTB, how can it know > whether to pass a DTB vs. an identifier? The OS might be perfectly > fine with firmware's DTB. > >> The OS loader would determine the location of the matching DTBs >> based on the chosen OS to boot, load the matching DTB from that location, and >> pass to the kernel. >> >> Considerations: >> - often a DTB requires fixups. The EFI_DT_FIXUP_PROTOCOL could be utilized. >> - device tree overlays could be indicated with a scheme using the device >> tree ID >> passed to the OS loader >> - authenticating the DTB would be the responsibility of the OS distribution >> and >> handled in the same way as the kernel itself is authenticated. The OS is >> the >> entity responsible for signing the DTB, as it should be. >> >> This proposal should be in addition to supporting the standard way of >> passing in >> a firmware-provided DT, in cases where the OS doesn't provide or have a need >> to >> provide a matching DT. > > Agreed, but that contradicts what you said above unless you mean we > define 2 ways to operate with some platforms working one standard way > and other platforms working the other standard way.
yes, we would allow either way. I think Daniel's suggestion would address this and the above points. > >> [1] Rather than using the device tree source filename, to have more >> flexibility, >> one can conceive an ID or compatible string that the OS could then scan the >> DTBs >> to find a match. > > I agree with Daniel that we should use the root node compatible for > this. We discussed this a while back on this list (or u-boot?). To > summarize, both using the filename or root node compatible were > proposed. Several folks (myself included) don't like making the > filename an ABI. However, there are some cases where the filename is > more unique than the root node compatible. We should fix those root > node compatibles in that case IMO. > > Rob > _______________________________________________ > boot-architecture mailing list -- boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture-le...@lists.linaro.org _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
