Andrew Davis afd@ti.com schrieb am Do., 6. Juni 2024, 18:39:
On 6/6/24 11:03 AM, Heinrich Schuchardt wrote:
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com
wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com
wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote: > On Mon, 20 May 2024 at 18:27, Elliot Berman <
quic_eberman@quicinc.com> wrote:
>> On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: >>> I believe the compatible string is still the best approach. It
has a
>>> number of benefits: >>> >>> 1. It is in fact the purpose of compatible strings to match
hardware
>>> with a driver >> >> Agreed. Compatible string matching works great for the rest of the >> device tree, but I think matching the root node compatible has
different
>> challenges that the rest of DT doesn't have. >> >> I'm open to use compatible strings, but we (EBBR) should describe
how
>> OSes should pick the DTB based on the compatible strings given by >> firmware so that there is consistency. > > Yes, agreed. Do you have a proposal for this? >
AMD did some work based off regex strings, maybe this could be
expanded
and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and
the
OS provides its own. Firmware has to provide enough information that
OS
can pick the DTB and also OS need to be able to detect that it
doesn't
have a DTB for the platform and should fallback to the
firmware-provided
DT.
Maybe the scenario I think about isn't valid -- in that case, we
should
make sure that the spec says something about how "if OS wants to
provide
own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the
device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
The thing is the "devicetree" command still needs the DTB name hard-coded which makes the OS image *not* perfectly generic (and building a menu entry for each possible board is a bit nonsensical).
The current solution is as follows:
On the installer image put all device-trees of the installer kernel into directory /dtb of the ESP.
U-Boot installs the device-tree matching the board as EFI configuration table.
After booting the compatible and model properties are available in /proc/device-tree
Now update-grub can write the correct devicetree commands for each installed kernel based on these properties into grub.cfg.
The top level solution proposed here *was* to pass that name in from firmware instead (or find the top level compatible string in the firmware provided DT and then search for an OS provided DT with the same compatible). But Elliot's ID system seems like it could allow for an even better way.
That ID system seems to add complexity and is not needed for the solution described above.
What we would need extra is to have a file similar to the modalias file for modules, but for DT. A lookup table generated from DT IDs that maps from a provided ID to a set (as in a base DT plus overlays) of DT files to load for the given ID.
Have a look at all.db in Debian's package flash-kernel. It maps the model property to the device-tree file name.
A similar lookup table could be integrated into grub.cfg if grub could write a property of the installed device-tree into a variable.
Best regards
Heinrich
Firmware provides a base DT with enough info to run the bootloader, then the bootloader uses the ID to quickly find and load the OS provided DT if available (falling back to just passing the simple firmware provided DT on to the OS if needed).
Is that a fair summary?
Andrew
Systemd-boot also provides device-trees and uses the
EFI_DT_FIXUP_PROTOCOL.
Best regards
Heinrich _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org