Hi,
To the folks on this mailing-list attending the Linaro Connect in Madrid,
it was suggested we could seize the opportunity to meet in person.
If you like the idea, let's meet on the terrace were we took the group picture,
on Thursday 18:30, before the social evening.
See you there!
Best regards,
Vincent.
On Wed, May 8, 2024 at 7:19 PM Elliot Berman <quic_eberman(a)quicinc.com> wrote:
>
> On Thu, May 02, 2024 at 09:00:47AM -0500, Rob Herring wrote:
> > On Wed, May 1, 2024 at 4:18 PM Humphreys, Jonathan <j-humphreys(a)ti.com> wrote:
> > > [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.
>
> I think firmware-provided compatible string can cause headaches for both
> firmware and OS developers. I gave a talk about this at EOSS [1,2] and
> we've been posting some proposals [3,4] to introduce a board-id, which
> allows DTBs to have varying degrees of precision about describing what
> hardware they are applicable to.
>
> Compatible strings should be a mapping of some identifier
> registers/storage into a string. Today, bootloader has to figure out
> that mapping and I understood Jon's proposal as wanting to get firmware
> to provide the compatible string. However, the compatible string for a
> DTB could need to describe only a subset of those identifiers
> (compatible string) to get a DTB that works. This would be especially
> true for DT overlays, although there are other real and hypothetical
> situations where a DTB shouldn't/can't describe the complete set of
> identifiers. Firmware either needs to provide every possible combination
> of compatible string or knowledge needs to be baked into the OS about
> interpreting the compatible string. In simple terms, the proposal is to
> split out the identifers that are baked into the compatible string into
> separate "board-id" properties.
I don't think there is any way the OS (or OS loader) would be able
handle these properties and the logic to parse them. It all looks to
be platform specific. This could only work if the OS says to the
firmware "here's the 1000 DTB files, which one should I use? That's
quite different from the current proposals of how this would work.
Rob
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
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.
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. 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.
[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.
