[RFC] Proposed location to host the firmware handoff specification.

[Rob Herring]

On Tue, Jul 5, 2022 at 10:37 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Rob,
>
> On Tue, 5 Jul 2022 at 09:24, Rob Herring <robh at kernel.org> wrote:
> >
> > On Thu, Jun 30, 2022 at 3:24 AM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Jose,
> > >
> > > I don't think this is correct. TF-A is a project that aims to replace
> > > U-Boot SPL (and perhaps other components) with more closed firmware,
> > > e.g. the permissive license.
> > >
> > > This spec needs to be in a neutral place, not captive of one project.
> > >
> > > Given its close relationship to device tree, I suggest github.com/devicetree-org
> >
> > The only relationship to DT I see is DT is a payload as is ACPI. So I
> > don't think dt.org is the right place.
>
> Actually I was about to email you about this. Here's how I see it.
>
> DT is a base structure to allow self-describing data to be stored.
> This is in contrast with ACPI where there is just a header, but it is
> not possible to read the data without specific parsing code for the
> particular table types. Let's ignore ACPI for this discussion.
>
> Unfortunately DT has an overhead and is too expensive for early
> firmware use. It takes 3-4KB of code for libfdt as well as extra code
> and data to read properties, etc.
>
> Transfer List aims to bridge the gap, allowing simple C structures to
> be put into a tagged data structure. The intention is that anything
> more complex than that would use DT.
>
> So there is at least some relationship: simple stuff = Transfer list,
> complex stuff = DT.

That's a stretch IMO. Perhaps if this was a new output (DTB) format
for easier parsing, I'd agree. It's related to DT only as much as any
other data passed between 2 boot components (remember ATAGS?).

> The Transfer List spec specifies the data format for each entry type
> (the analog to the schema). The DT provides the format and schema for
> more complicated stuff.
>
> We could perhaps put it in an entirely separate repo, but to me there
> is a relationship with DT.

It seems to me that TF is the main driver and user of this, so I don't
see the issue with them hosting it at least to start as long as
there's not barriers to contributions. It's just a namespace like
devicetree-org. Personally, I'd be more concerned on what the source
format is (I assume the plan is not to commit PDFs) and what the
output generation is. GH has a lot of nice features to support that
which we've used for the DT spec and EBBR.

I'm not saying no to devicetree-org either. If the consensus is to put
it there, I really don't care so much as it takes less time to create
a new repo there than to write this email.

Rob