Hi,
Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback.
This activity followed the request of some members of the Arm ecosystem [2].
The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot.
The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden.
The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data.
New types are meant to be added, following the needs and use-cases of the different communities.
Thus, these communities should be empowered to request new types!
To enable community contributions, the specification must be hosted in a location that is friendly to change requests.
We propose to host the spec in trustedfirmware.org (tf.org).
Tf.org hosts several open-source projects and already has an open governance model.
TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date.
Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.).
We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed!
If anyone has objections, we are happy to consider alternatives and associated trade-offs.
Regards
[1] https://developer.arm.com/documentation/den0135/latest
[2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>
Hi Varun,
The intent is for the proposed location (a new repository hosted in tf.org) to be used to review proposed changes to this spec.
The details of the contribution and review process will be debated in the ML once we reach consensus on the hosting location.
Regards,
Jose
> -----Original Message-----
> From: Varun Wadekar <vwadekar(a)nvidia.com>
> Sent: 06 July 2022 12:58
> To: Jose Marinho <Jose.Marinho(a)arm.com>; Simon Glass
> <sjg(a)chromium.org>; Rob Herring <robh(a)kernel.org>
> Cc: tf-a(a)lists.trustedfirmware.org; u-boot(a)lists.denx.de; boot-
> architecture(a)lists.linaro.org; François Ozog <francois.ozog(a)linaro.org>;
> Manish Pandey2 <Manish.Pandey2(a)arm.com>; Joanna Farley
> <Joanna.Farley(a)arm.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org>;
> Matteo Carlini <Matteo.Carlini(a)arm.com>; Dan Handley
> <Dan.Handley(a)arm.com>; Harb Abdulhamid
> (harb(a)amperecomputing.com) <harb(a)amperecomputing.com>; Samer El-
> Haj-Mahmoud <Samer.El-Haj-Mahmoud(a)arm.com>; nd <nd(a)arm.com>
> Subject: RE: [RFC] Proposed location to host the firmware handoff
> specification.
>
> Hi,
>
> My concern with a standalone gitlab project is that it might be treated as an
> experiment by the wider community and be neglected. Do we have any
> gitlab projects (tf.org or otherwise) that have some "official" value?
>
> @Jose, do you see the location getting used for all future spec reviews? If
> yes, then the gitlab project will acquire some legitimacy over time and we can
> start with it now. But if we see this as a one off, then I would prefer the spec
> being hosted on tf.org.
>
> For the actual mechanics, I prefer reviewing docs and later updates as
> fragments instead of looking at the file and a separate changelog. So a
> platform (gerrit, gitlab, etc) that facilitates the approach would be helpful
> IMO.
>
> -Varun
>
> -----Original Message-----
> From: Jose Marinho via TF-A <tf-a(a)lists.trustedfirmware.org>
> Sent: Wednesday, 6 July 2022 11:50 AM
> To: Simon Glass <sjg(a)chromium.org>; Rob Herring <robh(a)kernel.org>
> Cc: tf-a(a)lists.trustedfirmware.org; u-boot(a)lists.denx.de; boot-
> architecture(a)lists.linaro.org; François Ozog <francois.ozog(a)linaro.org>;
> Manish Pandey2 <Manish.Pandey2(a)arm.com>; Joanna Farley
> <Joanna.Farley(a)arm.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org>;
> Matteo Carlini <Matteo.Carlini(a)arm.com>; Dan Handley
> <Dan.Handley(a)arm.com>; Harb Abdulhamid
> (harb(a)amperecomputing.com) <harb(a)amperecomputing.com>; Samer El-
> Haj-Mahmoud <Samer.El-Haj-Mahmoud(a)arm.com>; nd <nd(a)arm.com>
> Subject: [TF-A] Re: [RFC] Proposed location to host the firmware handoff
> specification.
>
> External email: Use caution opening links or attachments
>
>
> Hi All,
>
> > -----Original Message-----
> > From: Simon Glass <sjg(a)chromium.org>
> > Sent: 06 July 2022 09:34
> > To: Rob Herring <robh(a)kernel.org>
> > Cc: Jose Marinho <Jose.Marinho(a)arm.com>;
> > tf-a(a)lists.trustedfirmware.org; u-boot(a)lists.denx.de;
> > boot-architecture(a)lists.linaro.org; François Ozog
> > <francois.ozog(a)linaro.org>; Manish Pandey2
> <Manish.Pandey2(a)arm.com>;
> > Joanna Farley <Joanna.Farley(a)arm.com>; Ilias Apalodimas
> > <ilias.apalodimas(a)linaro.org>; Matteo Carlini
> > <Matteo.Carlini(a)arm.com>; Dan Handley <Dan.Handley(a)arm.com>; Harb
> > Abdulhamid
> > (harb(a)amperecomputing.com) <harb(a)amperecomputing.com>; Samer
> El-
> > Haj-Mahmoud <Samer.El-Haj-Mahmoud(a)arm.com>; nd <nd(a)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(a)kernel.org> wrote:
> > >
> > > On Tue, Jul 5, 2022 at 10:37 AM Simon Glass <sjg(a)chromium.org> wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Tue, 5 Jul 2022 at 09:24, Rob Herring <robh(a)kernel.org> wrote:
> > > > >
> > > > > On Thu, Jun 30, 2022 at 3:24 AM Simon Glass <sjg(a)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
> --
> TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an
> email to tf-a-leave(a)lists.trustedfirmware.org
