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

[Simon Glass]

Hi Rob,

On Tue, 5 Jul 2022 at 11:27, Rob Herring <robh at kernel.org> wrote:
>
> 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?).

Yes it is a stretch. I'm just making the case.

>
> > 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.

Yes the DT spec works well and I hope the same thing can be used.

>
> 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.

I do hope that this can become a standard beyond ARM, e.g. with Intel
and another i can think of. Intel is essentially trying to create a
different thing independently, although has apparently adjusted to use
device tree due to its self-describing properties. I suspect that
having this spec in an ARM site would be a barrier to that.

I am OK with ARM TF being the means to get this into the open, but not
with it being the final destination.

If we cannot agree on anything better, I am happy with creating a new
project on github. We'll need to pick someone to own it and make final
calls when there is disagreement.

Regards,
Simon