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. > + > + 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) > + 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? > + 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 ] Thanks, Miquèl
