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

[François Ozog]

Le lun. 21 juin 2021 à 12:32, Alexander Graf <agraf at 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:
>
> 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 for making that crisply. Option 2 is addressing nicely backward and
forward compatibility.

>
>
> Thanks,
>
> Alex
>
> _______________________________________________
> boot-architecture mailing list
> boot-architecture at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
>
-- 
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog