Hi All, > -----Original Message----- > From: Simon Glass <s...@chromium.org> > Sent: 06 July 2022 09:34 > To: Rob Herring <r...@kernel.org> > Cc: Jose Marinho <jose.mari...@arm.com>; t...@lists.trustedfirmware.org; > u-boot@lists.denx.de; boot-architect...@lists.linaro.org; François Ozog > <francois.o...@linaro.org>; Manish Pandey2 <manish.pand...@arm.com>; > Joanna Farley <joanna.far...@arm.com>; Ilias Apalodimas > <ilias.apalodi...@linaro.org>; Matteo Carlini <matteo.carl...@arm.com>; > Dan Handley <dan.hand...@arm.com>; Harb Abdulhamid > (h...@amperecomputing.com) <h...@amperecomputing.com>; Samer El- > Haj-Mahmoud <samer.el-haj-mahm...@arm.com>; nd <n...@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 <r...@kernel.org> wrote: > > > > On Tue, Jul 5, 2022 at 10:37 AM Simon Glass <s...@chromium.org> wrote: > > > > > > Hi Rob, > > > > > > On Tue, 5 Jul 2022 at 09:24, Rob Herring <r...@kernel.org> wrote: > > > > > > > > On Thu, Jun 30, 2022 at 3:24 AM Simon Glass <s...@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
