[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ikudjl79.fsf@prevas.dk>
Date: Mon, 30 Sep 2024 16:00:10 +0200
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Rasmus Villemoes <linux@...musvillemoes.dk>, Jens Axboe
<axboe@...nel.dk>, Jonathan Corbet <corbet@....net>, Ulf Hansson
<ulf.hansson@...aro.org>, Rob Herring <robh@...nel.org>, Krzysztof
Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Kees
Cook <kees@...nel.org>, Andy Shevchenko <andy@...nel.org>, Daniel Golle
<daniel@...rotopia.org>, INAGAKI Hiroshi <musashino.open@...il.com>,
Christian Brauner <brauner@...nel.org>, Al Viro
<viro@...iv.linux.org.uk>, Li Lingfeng <lilingfeng3@...wei.com>, Ming
Lei <ming.lei@...hat.com>, Christian Heusel <christian@...sel.eu>,
linux-block@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
devicetree@...r.kernel.org, linux-hardening@...r.kernel.org, Miquel
Raynal <miquel.raynal@...tlin.com>, Lorenzo Bianconi
<lorenzo@...nel.org>, upstream@...oha.com
Subject: Re: [PATCH v4 5/5] dt-bindings: mmc: Document support for partition
table in mmc-card
Christian Marangi <ansuelsmth@...il.com> writes:
> On Mon, Sep 30, 2024 at 02:18:14PM +0200, Rasmus Villemoes wrote:
>> Christian Marangi <ansuelsmth@...il.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
Powered by blists - more mailing lists