On Thu, Nov 16, 2023 at 10:28:50AM -0700, Simon Glass wrote:
Add a compatible string for binman, so we can extend fixed-partitions in various ways.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v5)
Changes in v5:
- Add #address/size-cells and parternProperties
- Drop $ref to fixed-partitions.yaml
- Drop 'select: false'
Changes in v4:
- Change subject line
Changes in v3:
- Drop fixed-partition additional compatible string
- Drop fixed-partitions from the example
- Mention use of compatible instead of label
Changes in v2:
- Drop mention of 'enhanced features' in fixed-partitions.yaml
- Mention Binman input and output properties
- Use plain partition@xxx for the node name
.../bindings/mtd/partitions/binman.yaml | 68 +++++++++++++++++++ .../bindings/mtd/partitions/partitions.yaml | 1 + MAINTAINERS | 5 ++ 3 files changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/binman.yaml
diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml new file mode 100644 index 000000000000..329217550a98 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2023 Google LLC
+%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: Binman firmware layout
+maintainers:
- Simon Glass sjg@chromium.org
+description: |
- The binman node provides a layout for firmware, used when packaging firmware
- from multiple projects. It is based on fixed-partitions, with some
- extensions, but uses 'compatible' to indicate the contents of the node, to
- avoid perturbing or confusing existing installations which use 'label' for a
- particular purpose.
- Binman supports properties used as inputs to the firmware-packaging process,
- such as those which control alignment of partitions. This binding addresses
- these 'input' properties. For example, it is common for the 'reg' property
- (an 'output' property) to be set by Binman, based on the alignment requested
- in the input.
- Once processing is complete, input properties have mostly served their
- purpose, at least until the firmware is repacked later, e.g. due to a
- firmware update. The 'fixed-partitions' binding should provide enough
- information to read the firmware at runtime, including decompression if
- needed.
How is this going to work exactly? binman reads these nodes and then writes out 'fixed-partitions' nodes. But then you've lost the binman specifc parts needed for repacking.
Rob