| Message ID | 20240930113045.28616-6-ansuelsmth@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | block: partition table OF support | expand |
Christian Marangi <ansuelsmth@gmail.com> writes: > 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. > > If an OF partition table is detected, any partition table written in the > eMMC will be ignored and won't be parsed. > > eMMC provide a generic disk for user data and if supported (JEDEC 4.4+) > also provide two additional disk ("boot0" and "boot1") for special usage > of boot operation where normally is stored the bootloader or boot info. > This looks quite useful. Could this be extended to also be applicable to the four "general purpose" hardware partitions, i.e. what is exposed as /dev/mmcblkXgpY ? These would often also contain some fundamental boot data at various offsets but also, as for the boot partitions, often without a regular partition table. The eMMC spec consistently refers to the boot partitions as "boot partition 1" and "boot partition 2"; the boot0/boot1 naming is kind of a linux'ism. Similarly, the general purpose partitions are _almost_ exclusively referred to as 1 through 4, except (at least in my copy), the heading for 7.4.89 says GP_SIZE_MULT_GP0 - GP_SIZE_MULT_GP3, but then goes on to describe GP_SIZE_MULT_1_y through GP_SIZE_MULT_4_y. So I wonder if on the binding level one should use partitions-{boot1,boot2} and, if implemented, partitions-{gp1,gp2,gp3,gp4} ? Rasmus
On Mon, Sep 30, 2024 at 02:18:14PM +0200, Rasmus Villemoes wrote: > Christian Marangi <ansuelsmth@gmail.com> writes: > > > 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. > > > > If an OF partition table is detected, any partition table written in the > > eMMC will be ignored and won't be parsed. > > > > eMMC provide a generic disk for user data and if supported (JEDEC 4.4+) > > also provide two additional disk ("boot0" and "boot1") for special usage > > of boot operation where normally is stored the bootloader or boot info. > > > > This looks quite useful. > > Could this be extended to also be applicable to the four "general > purpose" hardware partitions, i.e. what is exposed as /dev/mmcblkXgpY ? > These would often also contain some fundamental boot data at various > offsets but also, as for the boot partitions, often without a regular > partition table. > > The eMMC spec consistently refers to the boot partitions as "boot > partition 1" and "boot partition 2"; the boot0/boot1 naming is kind of a > linux'ism. Similarly, the general purpose partitions are _almost_ > exclusively referred to as 1 through 4, except (at least in my copy), > the heading for 7.4.89 says GP_SIZE_MULT_GP0 - GP_SIZE_MULT_GP3, but > then goes on to describe GP_SIZE_MULT_1_y through GP_SIZE_MULT_4_y. So I > wonder if on the binding level one should use partitions-{boot1,boot2} > and, if implemented, partitions-{gp1,gp2,gp3,gp4} ? > Just to make sure, they are exposed as disk or char device? This is the case of rpmb. Adding support for this should be no-brainer as it's just a matter of more case of the strends and more regex case on the binding. I also notice the conflicting names, to adapt to JEDEC naming I will rename the property to boot1 and boot2.
Christian Marangi <ansuelsmth@gmail.com> writes: > On Mon, Sep 30, 2024 at 02:18:14PM +0200, Rasmus Villemoes wrote: >> Christian Marangi <ansuelsmth@gmail.com> writes: >> >> > 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. >> > >> > If an OF partition table is detected, any partition table written in the >> > eMMC will be ignored and won't be parsed. >> > >> > eMMC provide a generic disk for user data and if supported (JEDEC 4.4+) >> > also provide two additional disk ("boot0" and "boot1") for special usage >> > of boot operation where normally is stored the bootloader or boot info. >> > >> >> This looks quite useful. >> >> Could this be extended to also be applicable to the four "general >> purpose" hardware partitions, i.e. what is exposed as /dev/mmcblkXgpY ? >> These would often also contain some fundamental boot data at various >> offsets but also, as for the boot partitions, often without a regular >> partition table. >> >> The eMMC spec consistently refers to the boot partitions as "boot >> partition 1" and "boot partition 2"; the boot0/boot1 naming is kind of a >> linux'ism. Similarly, the general purpose partitions are _almost_ >> exclusively referred to as 1 through 4, except (at least in my copy), >> the heading for 7.4.89 says GP_SIZE_MULT_GP0 - GP_SIZE_MULT_GP3, but >> then goes on to describe GP_SIZE_MULT_1_y through GP_SIZE_MULT_4_y. So I >> wonder if on the binding level one should use partitions-{boot1,boot2} >> and, if implemented, partitions-{gp1,gp2,gp3,gp4} ? >> > > Just to make sure, they are exposed as disk or char device? This is the > case of rpmb. > They are block devices, just as the so-called "user area" (the main mmcblkX) and the boot partitions. > Adding support for this should be no-brainer as it's just a matter of > more case of the strends and more regex case on the binding. Yes, that's what I thought as well. > I also notice the conflicting names, to adapt to JEDEC naming I will rename > the property to boot1 and boot2. Thanks, Rasmus
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml index fd347126449a..5f93bb77f246 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,24 @@ properties: Use this to indicate that the mmc-card has a broken hpi implementation, and that hpi should not be used. +patternProperties: + "^partitions(-boot[01])?$": + $ref: /schemas/mtd/partitions/partitions.yaml + + patternProperties: + "^partition@[0-9a-f]+$": + $ref: /schemas/mtd/partitions/partition.yaml + + properties: + reg: + description: Must be multiple of 512 as it's converted + internally from bytes to SECTOR_SIZE (512 bytes) + + required: + - reg + + unevaluatedProperties: false + required: - compatible - reg @@ -42,6 +64,36 @@ examples: compatible = "mmc-card"; reg = <0>; broken-hpi; + + partitions { + compatible = "fixed-partitions"; + + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "kernel"; /* Kernel */ + reg = <0x0 0x2000000>; /* 32 MB */ + }; + + partition@2000000 { + label = "rootfs"; + reg = <0x2000000 0x40000000>; /* 1GB */ + }; + }; + + partitions-boot0 { + compatible = "fixed-partitions"; + + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "bl"; + reg = <0x0 0x2000000>; /* 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. If an OF partition table is detected, any partition table written in the eMMC will be ignored and won't be parsed. eMMC provide a generic disk for user data and if supported (JEDEC 4.4+) also provide 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 | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+)