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

[Jose Marinho]

Hi All,

> -----Original Message-----
> From: Simon Glass <sjg at chromium.org>
> Sent: 06 July 2022 09:34
> To: Rob Herring <robh at kernel.org>
> Cc: Jose Marinho <Jose.Marinho at arm.com>; tf-a at lists.trustedfirmware.org;
> u-boot at lists.denx.de; boot-architecture at lists.linaro.org; François Ozog
> <francois.ozog at linaro.org>; Manish Pandey2 <Manish.Pandey2 at arm.com>;
> Joanna Farley <Joanna.Farley at arm.com>; Ilias Apalodimas
> <ilias.apalodimas at linaro.org>; Matteo Carlini <Matteo.Carlini at arm.com>;
> Dan Handley <Dan.Handley at arm.com>; Harb Abdulhamid
> (harb at amperecomputing.com) <harb at amperecomputing.com>; Samer El-
> Haj-Mahmoud <Samer.El-Haj-Mahmoud at arm.com>; nd <nd at arm.com>
> Subject: Re: [RFC] Proposed location to host the firmware handoff
> specification.
> 
> 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.

The default working plan is for the source format to be sphinx.
Other alternatives/suggestions are welcome.

The output generated should be html (pdf can be supported too for 0/negligible effort).
This generation process can and will most likely evolve over time, depending on community direction/desire and the tools we have at our disposal.
The process should be as automated as possible given any practical constraints 😊 .

Regards,
Jose

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