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:
1) 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.
2) 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,
Alex
