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