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