Message ID | 20240326200645.1182803-1-sjg@chromium.org |
---|---|
State | New |
Headers | show |
Series | [v10,1/2] dt-bindings: mtd: fixed-partitions: Add alignment properties | expand |
Hi Simon, sjg@chromium.org 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@chromium.org> > Reviewed-by: Rob Herring <robh@kernel.org> > --- > > 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
Hi Miquel, On Mon, 8 Apr 2024 at 07:11, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Simon, > > sjg@chromium.org 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@chromium.org> > > Reviewed-by: Rob Herring <robh@kernel.org> > > --- > > > > 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
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. + + align-end: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 2 + maximum: 0x80000000 + multipleOf: 2 + 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 + 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 ]