Hello,
> > > > > These are firmware bindings, as indicated, but I
> > > > > took them out of the /firmware node since that is for a different
> > > > > purpose. Rob suggested that partitions was a good place. We have fwupd
> > > > > using DT to hold the firmware-update information, so I expect it will
> > > > > move to use these bindings too.
> > > >
> > > > I would definitely use fixed partitions as that's what you need then:
> > > > registering where everything starts and ends. If you have "in-band"
> > > > meta data you might require a compatible, but I don't think you
> > > > do, in this case you should probably carry the content through a label
> > > > (which will become the partition name) and we can discuss additional
> > > > properties if needed.
> > >
> > > I believe I am going to need a compatible string at the 'partitions'
> > > level to indicate that this is the binman scheme. But we can leave
> > > that until later.
> >
> > Perhaps:
> >
> > compatible = "binman", "fixed-partitions";
> >
> > Though I don't understand why binman couldn't just understand what
> > "fixed-partitions" means rather than "binman".
>
> Well so long as we don't add any binman things in here, you are right.
>
> But the eventual goal is parity with current Binman functionality,
> which writes the entire (augmented) description to the DT, allowing
> tools to rebuild / repack / replace pieces later, maintaining the same
> alignment constraints, etc. I am assuming that properties like 'align
> = <16>' would not fit with fixed-partitions.
I am personally not bothered by this kind of properties. But if we plan
on adding too much properties, I will advise to indeed use another name
than fixed-partitions (or add the "binman" secondary compatible)
otherwise it's gonna be hard to support in the code while still
restraining as much as we can the other partition schema.
> But if we don't preserve
> these properties then Binman cannot do repacking reliably. Perhaps for
> now I could put the augmented DT in its own section somewhere, but I
> am just not sure if that will work in a real system. E.g. with VBE the
> goal is to use the DT to figure out how to access the firmware, update
> it, etc.
>
> Is it not possible to have my own node with whatever things Binman
> needs in it (subject to review of course)? i.e. could we discuss how
> to encode it, but argue less about whether things are needed? I
> kind-of feel I know what is needed, since I wrote the tool.
>
> >
> >
> > > So you are suggesting 'label' for the contents. Rob suggested
> > > 'compatible' [1], so what should I do?
> >
> > "label" is for consumption by humans, not tools/software. Compatible
> > values are documented, label values are not. Though the partition
> > stuff started out using label long ago and it's evolved to preferring
> > compatible.
>
> OK so we are agreed that we are going with 'compatible'.
Still strongly disagree here.
My understanding is that a compatible carries how the content is
organized, and how this maybe specific (like you have in-band meta data
data that needs to be parsed in a specific way or in your case
additional specific properties in the DT which give more context about
how the data is stored). But the real content of the partition, ie. if
it contains a firmware, the kernel or some user data does not belong to
the compatible.
I.e:
- The first byte of my partition gives the compression algorithm:
-> compatible = "compressed-partition-foo";
or
-> compatible = "fixed-partitions" + compression-algorithm = "foo";
- The partition contains a picture of my dog:
-> label = "my dog is beautiful"
but certainly not
-> compatible = "my-dog";
I don't see why, for the binman schema, we could not constrain the
labels?
> > > With this schema, would every node be called 'partition@...' or is
> > > there flexibility to use other names?
> >
> > The preference is to use generic names. Do you mean without a
> > unit-address or different from "partition"? The need for the input
> > side of binman to have dynamic addresses seems like the biggest issue.
> > That's allowed in other cases with "partition-N" or "partition-foo"
> > IIRC. I don't think we want to allow that for "fixed-partitions" at
> > least in the DTB (i.e. the output side of binman).
>
> OK I suppose this is the problem with starting small. I was hoping to
> build up the schema piece by piece but now I am wondering whether
> every little detail will get redirected and I'll end up with something
> that Binman cannot use.
>
> So far all I have is that I can add a 'compress' property and a
> 'compatible' which describes the contents. I suppose it is a start.
I guess defining all you need in one go would be better. At least
showing a full and typical example might help. But some items like
encoding if you have TF-A or U-Boot in the compatible, I'm far from
convinced...
Thanks,
Miquèl
