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

From: Alexander Graf <agraf@csgraf.de>
To: Simon Glass <sjg@chromium.org>, Julian Hall <Julian.Hall@arm.com>
Cc: Ed Stuber <edstuber@amperecomputing.com>,
	Boot Architecture Mailman List
	<boot-architecture@lists.linaro.org>,
	Okash Khawaja <okash.khawaja@gmail.com>,
	Harb Abdulhamid OS <abdulhamid@os.amperecomputing.com>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	Joanna Farley <Joanna.Farley@arm.com>,
	Arjun Khare <akhare@amperecomputing.com>,
	Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>,
	Paul Isaac's <paul.isaacs@linaro.org>,
	Ron Minnich <rminnich@google.com>,
	Moe Ammar <moe@amperecomputing.com>,
	Loic Pallardy <loic.pallardy@st.com>
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages
Date: Mon, 21 Jun 2021 12:32:48 +0200	[thread overview]
Message-ID: <1e947a09-e149-a746-cc6a-f6bd83cde80c@csgraf.de> (raw)
In-Reply-To: <CAPnjgZ0KqvasagMKg6gYwF4W+a3oEhn6mHz+N7Q6L6LZJKh+3A@mail.gmail.com>

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