| Message ID | 20240923105937.4374-5-ansuelsmth@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | block: partition table OF support | expand |
On Mon, Sep 23, 2024 at 12:59:33PM +0200, Christian Marangi wrote: > Document support for defining a partition table in the mmc-card node. > > This is needed if the eMMC doesn't have a partition table written and > the bootloader of the device load data by using absolute offset of the > block device. This is common on embedded device that have eMMC installed > to save space and have non removable block devices. What if the partition table is written? What does one use? One of them or both and merge them? > eMMC provide a generic disk for user data and if supported also provide > one or two additional disk (boot0 and boot1) for special usage of boot > operation where normally is stored the bootloader or boot info. > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > --- > .../devicetree/bindings/mmc/mmc-card.yaml | 75 +++++++++++++++++++ > 1 file changed, 75 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml > index fd347126449a..fab9fa5c170a 100644 > --- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml > +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml > @@ -13,6 +13,10 @@ description: | > This documents describes the devicetree bindings for a mmc-host controller > child node describing a mmc-card / an eMMC. > > + It's possible to define a fixed partition table for an eMMC for the user > + partition and one of the 2 boot partition (boot0/boot1) if supported by the > + eMMC. > + > properties: > compatible: > const: mmc-card > @@ -26,6 +30,48 @@ properties: > Use this to indicate that the mmc-card has a broken hpi > implementation, and that hpi should not be used. > > + "#address-cells": true > + > + "#size-cells": true > + > +patternProperties: > + "^partitions(-boot[01])?$": > + type: object You don't define this is fixed partitions with a fixed-partitions compatible. Why not reuse that? Then this all goes away with a reference to it. > + > + properties: > + "#address-cells": true > + > + "#size-cells": true > + > + patternProperties: > + "@[0-9a-f]+$": > + type: object > + > + properties: > + reg: > + description: partition's offset and size within the flash (in sector > + block, 512byte) Units are sectors? Use bytes instead because everything else does in DT. > + maxItems: 1 > + > + > + label: > + description: The label / name for this partition. > + > + read-only: > + description: This parameter, if present, is a hint that this partition > + should only be mounted read-only. This is usually used for flash > + partitions containing early-boot firmware images or data which should > + not be clobbered. > + type: boolean > + > + required: > + - reg > + - label > + > + additionalProperties: false > + > + additionalProperties: false Put the indented cases of additionalProperties/unevaluatedProperties before 'properties'. Easier to see what they apply to that way. Rob
On Tue, Sep 24, 2024 at 05:53:43PM -0500, Rob Herring wrote: > On Mon, Sep 23, 2024 at 12:59:33PM +0200, Christian Marangi wrote: > > Document support for defining a partition table in the mmc-card node. > > > > This is needed if the eMMC doesn't have a partition table written and > > the bootloader of the device load data by using absolute offset of the > > block device. This is common on embedded device that have eMMC installed > > to save space and have non removable block devices. > > What if the partition table is written? What does one use? One of them > or both and merge them? > Hi Rob, thanks a lot for the review! The block code parse partition table with some kind of priority system. Example if cmdline is found, then anything else is ignored. (simple logic, first parser that match an expected structure win) We apply the same logic. So with partition table defined in OF, then anything written will be ignored. > > eMMC provide a generic disk for user data and if supported also provide > > one or two additional disk (boot0 and boot1) for special usage of boot > > operation where normally is stored the bootloader or boot info. > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > --- > > .../devicetree/bindings/mmc/mmc-card.yaml | 75 +++++++++++++++++++ > > 1 file changed, 75 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml > > index fd347126449a..fab9fa5c170a 100644 > > --- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml > > +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml > > @@ -13,6 +13,10 @@ description: | > > This documents describes the devicetree bindings for a mmc-host controller > > child node describing a mmc-card / an eMMC. > > > > + It's possible to define a fixed partition table for an eMMC for the user > > + partition and one of the 2 boot partition (boot0/boot1) if supported by the > > + eMMC. > > + > > properties: > > compatible: > > const: mmc-card > > @@ -26,6 +30,48 @@ properties: > > Use this to indicate that the mmc-card has a broken hpi > > implementation, and that hpi should not be used. > > > > + "#address-cells": true > > + > > + "#size-cells": true > > + > > +patternProperties: > > + "^partitions(-boot[01])?$": > > + type: object > > You don't define this is fixed partitions with a fixed-partitions > compatible. Why not reuse that? Then this all goes away with a > reference to it. > My problem is that the fixed-partition schema in MTD have some additional property that can't be supported. Ideally I should define a generic schema that can be shared and then expand it in MTD. Any hint on the directory structure tho? Where should I put this generic schema? > > + > > + properties: > > + "#address-cells": true > > + > > + "#size-cells": true > > + > > + patternProperties: > > + "@[0-9a-f]+$": > > + type: object > > + > > + properties: > > + reg: > > + description: partition's offset and size within the flash (in sector > > + block, 512byte) > > Units are sectors? Use bytes instead because everything else does in DT. > Ok will try to convert value to bytes internally. > > + maxItems: 1 > > + > > + > > + label: > > + description: The label / name for this partition. > > + > > + read-only: > > + description: This parameter, if present, is a hint that this partition > > + should only be mounted read-only. This is usually used for flash > > + partitions containing early-boot firmware images or data which should > > + not be clobbered. > > + type: boolean > > + > > + required: > > + - reg > > + - label > > + > > + additionalProperties: false > > + > > + additionalProperties: false > > Put the indented cases of additionalProperties/unevaluatedProperties > before 'properties'. Easier to see what they apply to that way. > ack.
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml index fd347126449a..fab9fa5c170a 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml @@ -13,6 +13,10 @@ description: | This documents describes the devicetree bindings for a mmc-host controller child node describing a mmc-card / an eMMC. + It's possible to define a fixed partition table for an eMMC for the user + partition and one of the 2 boot partition (boot0/boot1) if supported by the + eMMC. + properties: compatible: const: mmc-card @@ -26,6 +30,48 @@ properties: Use this to indicate that the mmc-card has a broken hpi implementation, and that hpi should not be used. + "#address-cells": true + + "#size-cells": true + +patternProperties: + "^partitions(-boot[01])?$": + type: object + + properties: + "#address-cells": true + + "#size-cells": true + + patternProperties: + "@[0-9a-f]+$": + type: object + + properties: + reg: + description: partition's offset and size within the flash (in sector + block, 512byte) + maxItems: 1 + + + label: + description: The label / name for this partition. + + read-only: + description: This parameter, if present, is a hint that this partition + should only be mounted read-only. This is usually used for flash + partitions containing early-boot firmware images or data which should + not be clobbered. + type: boolean + + required: + - reg + - label + + additionalProperties: false + + additionalProperties: false + required: - compatible - reg @@ -42,6 +88,35 @@ examples: compatible = "mmc-card"; reg = <0>; broken-hpi; + + #address-cells = <0>; + #size-cells = <0>; + + partitions { + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "kernel"; /* Kernel */ + reg = <0x0 0x10000>; /* 32 MB */ + }; + + partition@3400 { + label = "rootfs"; + reg = <0x3400 0x200000>; /* 1GB */ + }; + }; + + partitions-boot0 { + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "bl"; + reg = <0x0 0x10000>; /* 32MB */ + read-only; + }; + }; }; };
Document support for defining a partition table in the mmc-card node. This is needed if the eMMC doesn't have a partition table written and the bootloader of the device load data by using absolute offset of the block device. This is common on embedded device that have eMMC installed to save space and have non removable block devices. eMMC provide a generic disk for user data and if supported also provide one or two additional disk (boot0 and boot1) for special usage of boot operation where normally is stored the bootloader or boot info. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> --- .../devicetree/bindings/mmc/mmc-card.yaml | 75 +++++++++++++++++++ 1 file changed, 75 insertions(+)