Re: [PATCH v10 1/2] dt-bindings: mtd: fixed-partitions: Add alignment properties

Miquel Raynal
2024-04-08T13:11:04Z

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