On 10.06.24 15:52, Simon Glass wrote:
Hi Heinrich,
On Thu, 6 Jun 2024 at 10:03, Heinrich Schuchardt heinrich.schuchardt@canonical.com 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.
I was considering grub to be a bootloader, though. The OS doesn't find the file itself, right?
The Linux kernel does not scan for device-trees. It requires that the correct device-tree or ACPI tables are installed as EFI configuration table. This can be done by firmware or by the bootloader provided by the OS.
Best regards
Heinrich
Systemd-boot also provides device-trees and uses the EFI_DT_FIXUP_PROTOCOL.
OK.
Regards, SImon