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?). > 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. 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. Rob
