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(+)
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;
+ };
+ };
};
};
--
2.45.2Christian 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.
--
Ansuel
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
© 2016 - 2024 Red Hat, Inc.