Le lun. 21 juin 2021 à 12:32, Alexander Graf agraf@csgraf.de a écrit :
On 20.05.21 18:42, Simon Glass wrote:
Hi,
Re Jeremy's comment:
Using DT to pass platform info at this level is sort of crazy on an ACPI machine which won't have native DTs. Meaning there is an additional level of unnecessary indirection that needs to be converted back into a format which can be utilized by AML and other parts of the ACPI stack.
U-Boot has to generate part of the ACPI tables programmatically, using
info
from the DT to do so. In other words, U-Boot supports DT but must also support generating AML, etc. I don't see a particular problem with that.
I don't think it makes any sense to use ACPI tables to pass data between boot phases, but if that is being proposed, I'd like to understand the reason. I also wonder why people are using UEFI on rpi, but that's a different topic.
Reading the conversation, I believe the main confusion is about what "use DT to pass data" means.
There are fundamentally two ways to think of this:
- Take a standard Linux device tree as input. Use exactly that to pass
data between stages. Go through the LKML to define pre-Linux bindings. Implement a full DT parser to enumerate hardware.
- Use DT purely as opaque data transfer mechanism and reuse simple
parts (directories, compatible strings, etc) but leave out the complicated ones (recursive #address-cells, interrupt-map, etc). Use it to pass data privately between components. Be self-consistent, self-documenting and self-backwards-compatible.
Which one of them do you mean Simon? I'd be super happy to see option 2. DT as a data container is so much nicer than opaque binary blobs. At the same time, I can see how people feel like option 1 would tie them into an ecosystem dependency they don't want to be in.
thanks for making that crisply. Option 2 is addressing nicely backward and forward compatibility.
Thanks,
Alex
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture