Hi Miquel, On Mon, 8 Apr 2024 at 07:11, Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > Hi Simon, > > sjg@xxxxxxxxxxxx wrote on Tue, 26 Mar 2024 14:06:44 -0600: > > > Add three properties for controlling alignment of partitions, aka > > 'entries' in fixed-partition. > > > > For now there is no explicit mention of hierarchy, so a 'section' is > > just the 'fixed-partitions' node. > > > > These new properties are inputs to the Binman packaging process, but are > > also needed if the firmware is repacked, to ensure that alignment > > constraints are not violated. Therefore they are provided as part of > > the schema. > > > > Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx> > > Reviewed-by: Rob Herring <robh@xxxxxxxxxx> > > --- > > > > Changes in v10: > > - Update the minimum to 2 > > > > Changes in v9: > > - Move binding example to next batch to avoid build error > > > > Changes in v7: > > - Drop patch 'Add binman compatible' > > - Put the alignment properties into the fixed-partition binding > > > > Changes in v6: > > - Correct schema-validation errors missed due to older dt-schema > > (enum fix and reg addition) > > > > Changes in v5: > > - Add value ranges > > - Consistently mention alignment must be power-of-2 > > - Mention that alignment refers to bytes > > > > Changes in v2: > > - Fix 'a' typo in commit message > > > > .../bindings/mtd/partitions/partition.yaml | 51 +++++++++++++++++++ > > 1 file changed, 51 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml > > index 1ebe9e2347ea..656ca3db1762 100644 > > --- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml > > +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml > > @@ -57,6 +57,57 @@ properties: > > user space from > > type: boolean > > > > + align: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + minimum: 2 > > + maximum: 0x80000000 > > + multipleOf: 2 > > + description: > > + This sets the alignment of the entry in bytes. > > + > > + The entry offset is adjusted so that the entry starts on an aligned > > + boundary within the containing section or image. For example ‘align = > > + <16>’ means that the entry will start on a 16-byte boundary. This may > > + mean that padding is added before the entry. The padding is part of > > + the containing section but is not included in the entry, meaning that > > + an empty space may be created before the entry starts. Alignment > > + must be a power of 2. If ‘align’ is not provided, no alignment is > > + performed. > > + > > + align-size: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + minimum: 2 > > + maximum: 0x80000000 > > + multipleOf: 2 > > + description: > > + This sets the alignment of the entry size in bytes. It must be a power > > + of 2. > > + > > + For example, to ensure that the size of an entry is a multiple of 64 > > + bytes, set this to 64. While this does not affect the contents of the > > + entry within binman itself (the padding is performed only when its > > + parent section is assembled), the end result is that the entry ends > > + with the padding bytes, so may grow. If ‘align-size’ is not provided, > > + no alignment is performed. > > I don't think we should mention binman here. Can we have a software > agnostic description? This should be understandable from anyone playing > with mtd partitions I guess. OK > > > + > > + align-end: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + minimum: 2 > > + maximum: 0x80000000 > > + multipleOf: 2 > > seems not to perfectly match the constraint, but I don't know if there > is a powerOf keyword? (same above) I believe this was discussed earlier. No there is no such option! > > > + description: > > + This sets the alignment (in bytes) of the end of an entry with respect > > + to the containing section. It must be a power of 2. > > + > > + Some entries require that they end on an alignment boundary, > > + regardless of where they start. This does not move the start of the > > + entry, so the contents of the entry will still start at the beginning. > > + But there may be padding at the end. While this does not affect the > > + contents of the entry within binman itself (the padding is performed > > content? same comment about binman? OK > > > + only when its parent section is assembled), the end result is that the > > + entry ends with the padding bytes, so may grow. If ‘align-end’ is not > > + provided, no alignment is performed. > > + > > if: > > not: > > required: [ reg ] Regards, SImon
