[TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Alexander Graf]

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