[PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Tim Harvey]

eMMC devices have hardware partitions such as user, boot0, and boot1.

Add an enumerated type defining the hardware partition values and an
array of names describing them by name that can be used throughout
U-Boot.

Allow these names to be displayed when reading and used when setting
the mmc PARTITION_CONFIG field via 'mmc partconf'.

Before:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0

After:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1 (boot0)
PARTITION_ACCESS: 0x0
u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2 (boot1)
PARTITION_ACCESS: 0x0

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
v3:
 - define partition names and values in mmc.h/mmc.c for others to use

v2:
 - fix typo in subject
 - add names for gp1..gp4
---
 cmd/mmc.c         | 14 +++++++++++---
 drivers/mmc/mmc.c | 11 +++++++++++
 include/mmc.h     | 15 +++++++++++++++
 3 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index 2d5430a53079..26ab4450816b 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -14,6 +14,7 @@
 #include <part.h>
 #include <sparse_format.h>
 #include <image-sparse.h>
+#include <linux/ctype.h>
 
 static int curr_device = -1;
 
@@ -918,8 +919,8 @@ static int mmc_partconf_print(struct mmc *mmc, const char *varname)
 
 	printf("EXT_CSD[179], PARTITION_CONFIG:\n"
 		"BOOT_ACK: 0x%x\n"
-		"BOOT_PARTITION_ENABLE: 0x%x\n"
-		"PARTITION_ACCESS: 0x%x\n", ack, part, access);
+		"BOOT_PARTITION_ENABLE: 0x%x (%s)\n"
+		"PARTITION_ACCESS: 0x%x\n", ack, part, emmc_hwpart_names[part], access);
 
 	return CMD_RET_SUCCESS;
 }
@@ -949,7 +950,14 @@ static int do_mmc_partconf(struct cmd_tbl *cmdtp, int flag,
 		return mmc_partconf_print(mmc, cmd_arg2(argc, argv));
 
 	ack = dectoul(argv[2], NULL);
-	part_num = dectoul(argv[3], NULL);
+	if (!isdigit(*argv[3])) {
+		for (part_num = 0; part_num <= EMMC_HWPART_USER; part_num++) {
+			if (!strcmp(argv[3], emmc_hwpart_names[part_num]))
+				break;
+		}
+	} else {
+		part_num = dectoul(argv[3], NULL);
+	}
 	access = dectoul(argv[4], NULL);
 
 	/* acknowledge to be sent during boot operation */
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 7b068c71ff37..132afe1b8a29 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -29,6 +29,17 @@
 
 #define DEFAULT_CMD6_TIMEOUT_MS  500
 
+const char *emmc_hwpart_names[] = {
+	"user",
+	"boot0",
+	"boot1",
+	"gp1",
+	"gp2",
+	"gp3",
+	"gp4",
+	"user",
+};
+
 static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage);
 
 #if !CONFIG_IS_ENABLED(DM_MMC)
diff --git a/include/mmc.h b/include/mmc.h
index 4b8327f1f93b..7243bd761202 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -381,6 +381,21 @@ enum mmc_voltage {
 #define MMC_TIMING_MMC_HS200	9
 #define MMC_TIMING_MMC_HS400	10
 
+/* emmc hardware partition values */
+enum emmc_hwpart {
+	EMMC_HWPART_DEFAULT = 0,
+	EMMC_HWPART_BOOT0 = 1,
+	EMMC_HWPART_BOOT1 = 2,
+	EMMC_HWPART_GP1 = 3,
+	EMMC_HWPART_GP2 = 4,
+	EMMC_HWPART_GP3 = 5,
+	EMMC_HWPART_GP4 = 6,
+	EMMC_HWPART_USER = 7,
+};
+
+/* emmc hardware partition names */
+extern const char *emmc_hwpart_names[];
+
 /* Driver model support */
 
 /**
-- 
2.25.1

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Marek Vasut]

[...]

> diff --git a/include/mmc.h b/include/mmc.h
> index 4b8327f1f93b..7243bd761202 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -381,6 +381,21 @@ enum mmc_voltage {
>   #define MMC_TIMING_MMC_HS200	9
>   #define MMC_TIMING_MMC_HS400	10
>   
> +/* emmc hardware partition values */
> +enum emmc_hwpart {
> +	EMMC_HWPART_DEFAULT = 0,
> +	EMMC_HWPART_BOOT0 = 1,
> +	EMMC_HWPART_BOOT1 = 2,
> +	EMMC_HWPART_GP1 = 3,
> +	EMMC_HWPART_GP2 = 4,
> +	EMMC_HWPART_GP3 = 5,
> +	EMMC_HWPART_GP4 = 6,
> +	EMMC_HWPART_USER = 7,
> +};
> +
> +/* emmc hardware partition names */
> +extern const char *emmc_hwpart_names[];

Maybe the array should have fixed size here, i.e. 8 ?

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[E Shattow]

Hi Marek,

On Fri, Apr 26, 2024 at 5:49 PM Marek Vasut <marex@denx.de> wrote:
>
> [...]
>
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 4b8327f1f93b..7243bd761202 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -381,6 +381,21 @@ enum mmc_voltage {
> >   #define MMC_TIMING_MMC_HS200        9
> >   #define MMC_TIMING_MMC_HS400        10
> >
> > +/* emmc hardware partition values */
> > +enum emmc_hwpart {
> > +     EMMC_HWPART_DEFAULT = 0,
> > +     EMMC_HWPART_BOOT0 = 1,
> > +     EMMC_HWPART_BOOT1 = 2,
> > +     EMMC_HWPART_GP1 = 3,
> > +     EMMC_HWPART_GP2 = 4,
> > +     EMMC_HWPART_GP3 = 5,
> > +     EMMC_HWPART_GP4 = 6,
> > +     EMMC_HWPART_USER = 7,
> > +};
> > +
> > +/* emmc hardware partition names */
> > +extern const char *emmc_hwpart_names[];
>
> Maybe the array should have fixed size here, i.e. 8 ?

Is there an ABI reason to do so? Can you explain further why it would
be needed to do that?

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Marek Vasut]

On 4/27/24 3:29 AM, E Shattow wrote:
> Hi Marek,
> 
> On Fri, Apr 26, 2024 at 5:49 PM Marek Vasut <marex@denx.de> wrote:
>>
>> [...]
>>
>>> diff --git a/include/mmc.h b/include/mmc.h
>>> index 4b8327f1f93b..7243bd761202 100644
>>> --- a/include/mmc.h
>>> +++ b/include/mmc.h
>>> @@ -381,6 +381,21 @@ enum mmc_voltage {
>>>    #define MMC_TIMING_MMC_HS200        9
>>>    #define MMC_TIMING_MMC_HS400        10
>>>
>>> +/* emmc hardware partition values */
>>> +enum emmc_hwpart {
>>> +     EMMC_HWPART_DEFAULT = 0,
>>> +     EMMC_HWPART_BOOT0 = 1,
>>> +     EMMC_HWPART_BOOT1 = 2,
>>> +     EMMC_HWPART_GP1 = 3,
>>> +     EMMC_HWPART_GP2 = 4,
>>> +     EMMC_HWPART_GP3 = 5,
>>> +     EMMC_HWPART_GP4 = 6,
>>> +     EMMC_HWPART_USER = 7,
>>> +};
>>> +
>>> +/* emmc hardware partition names */
>>> +extern const char *emmc_hwpart_names[];
>>
>> Maybe the array should have fixed size here, i.e. 8 ?
> 
> Is there an ABI reason to do so? Can you explain further why it would
> be needed to do that?

It has nothing to do with ABI, it is only to let the compiler validate 
that nobody would index the array with index > 7 by accident.

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[E Shattow]

On Sat, Apr 27, 2024 at 3:22 AM Marek Vasut <marex@denx.de> wrote:
>
> On 4/27/24 3:29 AM, E Shattow wrote:
> > Hi Marek,
> >
> > On Fri, Apr 26, 2024 at 5:49 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> [...]
> >>
> >>> diff --git a/include/mmc.h b/include/mmc.h
> >>> index 4b8327f1f93b..7243bd761202 100644
> >>> --- a/include/mmc.h
> >>> +++ b/include/mmc.h
> >>> @@ -381,6 +381,21 @@ enum mmc_voltage {
> >>>    #define MMC_TIMING_MMC_HS200        9
> >>>    #define MMC_TIMING_MMC_HS400        10
> >>>
> >>> +/* emmc hardware partition values */
> >>> +enum emmc_hwpart {
> >>> +     EMMC_HWPART_DEFAULT = 0,
> >>> +     EMMC_HWPART_BOOT0 = 1,
> >>> +     EMMC_HWPART_BOOT1 = 2,
> >>> +     EMMC_HWPART_GP1 = 3,
> >>> +     EMMC_HWPART_GP2 = 4,
> >>> +     EMMC_HWPART_GP3 = 5,
> >>> +     EMMC_HWPART_GP4 = 6,
> >>> +     EMMC_HWPART_USER = 7,
> >>> +};
> >>> +
> >>> +/* emmc hardware partition names */
> >>> +extern const char *emmc_hwpart_names[];
> >>
> >> Maybe the array should have fixed size here, i.e. 8 ?
> >
> > Is there an ABI reason to do so? Can you explain further why it would
> > be needed to do that?
>
> It has nothing to do with ABI, it is only to let the compiler validate
> that nobody would index the array with index > 7 by accident.

At least GCC knows this without doing its work again ourselves. How
about a const for the upper limit, where currently EMMC_HWPART_USER
substitutes for expressing an upper limit? You may as well be writing
EMMC_HWPART_MAX = 8 in the enum and using that for the initializer
also any iterators with a less-than condition to make it more
expressive.

$ gcc -o testobj test.c -Wall -Wextra -O2
test.c: In function ‘main’:
test.c:16:5: warning: array subscript 8 is above array bounds of
‘const char *[8]’ [-Warray-bounds=]
   16 |     printf(emmc_hwpart_names[8]);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
test.c:3:13: note: while referencing ‘emmc_hwpart_names’
    3 | const char *emmc_hwpart_names[] = {
      |             ^~~~~~~~~~~~~~~~~

#include <stdio.h>

const char *emmc_hwpart_names[] = {
       "user",
       "boot0",
       "boot1",
       "gp1",
       "gp2",
       "gp3",
       "gp4",
       "user",
};

int main(int argc, char** argv) {
    (void) argc; (void) argv;
    printf(emmc_hwpart_names[8]);

    return 0;
}

Sorry to belabor this and I'm not a professional programmer. Best regards, -E

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Marek Vasut]

On 4/27/24 2:06 PM, E Shattow wrote:
> On Sat, Apr 27, 2024 at 3:22 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 4/27/24 3:29 AM, E Shattow wrote:
>>> Hi Marek,
>>>
>>> On Fri, Apr 26, 2024 at 5:49 PM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/include/mmc.h b/include/mmc.h
>>>>> index 4b8327f1f93b..7243bd761202 100644
>>>>> --- a/include/mmc.h
>>>>> +++ b/include/mmc.h
>>>>> @@ -381,6 +381,21 @@ enum mmc_voltage {
>>>>>     #define MMC_TIMING_MMC_HS200        9
>>>>>     #define MMC_TIMING_MMC_HS400        10
>>>>>
>>>>> +/* emmc hardware partition values */
>>>>> +enum emmc_hwpart {
>>>>> +     EMMC_HWPART_DEFAULT = 0,
>>>>> +     EMMC_HWPART_BOOT0 = 1,
>>>>> +     EMMC_HWPART_BOOT1 = 2,
>>>>> +     EMMC_HWPART_GP1 = 3,
>>>>> +     EMMC_HWPART_GP2 = 4,
>>>>> +     EMMC_HWPART_GP3 = 5,
>>>>> +     EMMC_HWPART_GP4 = 6,
>>>>> +     EMMC_HWPART_USER = 7,
>>>>> +};
>>>>> +
>>>>> +/* emmc hardware partition names */
>>>>> +extern const char *emmc_hwpart_names[];
>>>>
>>>> Maybe the array should have fixed size here, i.e. 8 ?
>>>
>>> Is there an ABI reason to do so? Can you explain further why it would
>>> be needed to do that?
>>
>> It has nothing to do with ABI, it is only to let the compiler validate
>> that nobody would index the array with index > 7 by accident.
> 
> At least GCC knows this without doing its work again ourselves. How
> about a const for the upper limit, where currently EMMC_HWPART_USER
> substitutes for expressing an upper limit? You may as well be writing
> EMMC_HWPART_MAX = 8 in the enum and using that for the initializer
> also any iterators with a less-than condition to make it more
> expressive.

You could use ARRAY_SIZE(emmc_hwpart_names) in iterators, no extra 
symbols should be necessary.

> $ gcc -o testobj test.c -Wall -Wextra -O2
> test.c: In function ‘main’:
> test.c:16:5: warning: array subscript 8 is above array bounds of
> ‘const char *[8]’ [-Warray-bounds=]
>     16 |     printf(emmc_hwpart_names[8]);
>        |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> test.c:3:13: note: while referencing ‘emmc_hwpart_names’
>      3 | const char *emmc_hwpart_names[] = {
>        |             ^~~~~~~~~~~~~~~~~
> 
> #include <stdio.h>
> 
> const char *emmc_hwpart_names[] = {
>         "user",
>         "boot0",
>         "boot1",
>         "gp1",
>         "gp2",
>         "gp3",
>         "gp4",
>         "user",
> };
> 
> int main(int argc, char** argv) {
>      (void) argc; (void) argv;
>      printf(emmc_hwpart_names[8]);
> 
>      return 0;
> }

In case of this patched code here, the example is more like this:

a.c:
#include <stdio.h>
#include "h.h"

int main(void)
{
     printf("%d\n", arr[8]); // This code contains a bug here
     return 0;
}

b.c:
int arr[2] = { 1, 2 };

h.h:
extern int arr[];

Compile:
$ gcc -O2 -Wall -c -o a.o a.c
$ gcc -O2 -Wall -c -o b.o b.c
$ gcc -O2 -Wall -o out a.o b.o

You won't get warning when compiling a.c , because gcc does not know the 
size of the array until the linking step. You will get a warning if you 
change the header like this:

h.h:
-extern int arr[];
+extern int arr[2];

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Marek Vasut]

On 4/27/24 2:11 AM, Tim Harvey wrote:

[...]

> diff --git a/include/mmc.h b/include/mmc.h
> index 4b8327f1f93b..7243bd761202 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -381,6 +381,21 @@ enum mmc_voltage {
>   #define MMC_TIMING_MMC_HS200	9
>   #define MMC_TIMING_MMC_HS400	10
>   
> +/* emmc hardware partition values */
> +enum emmc_hwpart {
> +	EMMC_HWPART_DEFAULT = 0,

One more thing ... eMMC hardware partition 0 and 7 are both referring to 
USER HW partition. Have a look at the git log, there have been patches 
which handled this case in the MMC subsystem from about a year ago.

> +	EMMC_HWPART_BOOT0 = 1,
> +	EMMC_HWPART_BOOT1 = 2,
> +	EMMC_HWPART_GP1 = 3,
> +	EMMC_HWPART_GP2 = 4,
> +	EMMC_HWPART_GP3 = 5,
> +	EMMC_HWPART_GP4 = 6,
> +	EMMC_HWPART_USER = 7,

[...]

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Tim Harvey]

On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut <marex@denx.de> wrote:
>
> On 4/27/24 2:11 AM, Tim Harvey wrote:
>
> [...]
>
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 4b8327f1f93b..7243bd761202 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -381,6 +381,21 @@ enum mmc_voltage {
> >   #define MMC_TIMING_MMC_HS200        9
> >   #define MMC_TIMING_MMC_HS400        10
> >
> > +/* emmc hardware partition values */
> > +enum emmc_hwpart {
> > +     EMMC_HWPART_DEFAULT = 0,
>
> One more thing ... eMMC hardware partition 0 and 7 are both referring to
> USER HW partition. Have a look at the git log, there have been patches
> which handled this case in the MMC subsystem from about a year ago.

Hi Marek,

I can't find what you are referring to. I assume you are talking about
calling the first name something other than 'user' as technically it's
not (but it gets treated as user).

Can you find the commit or discussion you are thinking about?

Best Regards,

Tim

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Marek Vasut]

On 4/29/24 6:48 PM, Tim Harvey wrote:
> On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 4/27/24 2:11 AM, Tim Harvey wrote:
>>
>> [...]
>>
>>> diff --git a/include/mmc.h b/include/mmc.h
>>> index 4b8327f1f93b..7243bd761202 100644
>>> --- a/include/mmc.h
>>> +++ b/include/mmc.h
>>> @@ -381,6 +381,21 @@ enum mmc_voltage {
>>>    #define MMC_TIMING_MMC_HS200        9
>>>    #define MMC_TIMING_MMC_HS400        10
>>>
>>> +/* emmc hardware partition values */
>>> +enum emmc_hwpart {
>>> +     EMMC_HWPART_DEFAULT = 0,
>>
>> One more thing ... eMMC hardware partition 0 and 7 are both referring to
>> USER HW partition. Have a look at the git log, there have been patches
>> which handled this case in the MMC subsystem from about a year ago.
> 
> Hi Marek,
> 
> I can't find what you are referring to. I assume you are talking about
> calling the first name something other than 'user' as technically it's
> not (but it gets treated as user).
> 
> Can you find the commit or discussion you are thinking about?

It seems this whole thing is much older:

7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to 
CONFIG_SPL_FRAMEWORK")

+                * We need to check what the partition is configured to.
+                * 1 and 2 match up to boot0 / boot1 and 7 is user data
+                * which is the first physical partition (0).
+                */
+               int part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
+
+               if (part == 7)
+                       part = 0;

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Tim Harvey]

On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut <marex@denx.de> wrote:
>
> On 4/29/24 6:48 PM, Tim Harvey wrote:
> > On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 4/27/24 2:11 AM, Tim Harvey wrote:
> >>
> >> [...]
> >>
> >>> diff --git a/include/mmc.h b/include/mmc.h
> >>> index 4b8327f1f93b..7243bd761202 100644
> >>> --- a/include/mmc.h
> >>> +++ b/include/mmc.h
> >>> @@ -381,6 +381,21 @@ enum mmc_voltage {
> >>>    #define MMC_TIMING_MMC_HS200        9
> >>>    #define MMC_TIMING_MMC_HS400        10
> >>>
> >>> +/* emmc hardware partition values */
> >>> +enum emmc_hwpart {
> >>> +     EMMC_HWPART_DEFAULT = 0,
> >>
> >> One more thing ... eMMC hardware partition 0 and 7 are both referring to
> >> USER HW partition. Have a look at the git log, there have been patches
> >> which handled this case in the MMC subsystem from about a year ago.
> >
> > Hi Marek,
> >
> > I can't find what you are referring to. I assume you are talking about
> > calling the first name something other than 'user' as technically it's
> > not (but it gets treated as user).
> >
> > Can you find the commit or discussion you are thinking about?
>
> It seems this whole thing is much older:
>
> 7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to
> CONFIG_SPL_FRAMEWORK")
>
> +                * We need to check what the partition is configured to.
> +                * 1 and 2 match up to boot0 / boot1 and 7 is user data
> +                * which is the first physical partition (0).
> +                */
> +               int part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
> +
> +               if (part == 7)
> +                       part = 0;

Hi Marek,

Sorry, I haven't been able to work on U-Boot for the past week or so
and am just getting back to this.

I'm glad you pointed this out as it made me aware that there is a bit
of a mixing of eMMC PARTITION_CONFIG (Ext CSD 179) fields
BOOT_PARTITION_ENABLE and PARTITION_ACCESS in U-Boot currently.

I'm going to add an enumerated type for each and update the various
places where a 'conversion' as above is done but I'm still a bit torn
on naming conventions.

Consider the following:
- the eMMC spec refers to boot partitions and gp partitions as 1 based
- the Linux kernel device names for these are 0 based
- U-Boot does not currently refer to the boot devices by names but
does currently refer to the gp's by names using 1-based names (the
'mmc hwpartition' command)

Personally I would like to name the boot partitions 'boot0' and
'boot1' to match Linux but I think I should name the gp's
'gp1'...'gp4' to be backward compatible with the 'mmc hwpartition'
command.

What do you think?

Best Regards,

Tim

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Marek Vasut]

On 5/13/24 10:52 PM, Tim Harvey wrote:
> On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 4/29/24 6:48 PM, Tim Harvey wrote:
>>> On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 4/27/24 2:11 AM, Tim Harvey wrote:
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/include/mmc.h b/include/mmc.h
>>>>> index 4b8327f1f93b..7243bd761202 100644
>>>>> --- a/include/mmc.h
>>>>> +++ b/include/mmc.h
>>>>> @@ -381,6 +381,21 @@ enum mmc_voltage {
>>>>>     #define MMC_TIMING_MMC_HS200        9
>>>>>     #define MMC_TIMING_MMC_HS400        10
>>>>>
>>>>> +/* emmc hardware partition values */
>>>>> +enum emmc_hwpart {
>>>>> +     EMMC_HWPART_DEFAULT = 0,
>>>>
>>>> One more thing ... eMMC hardware partition 0 and 7 are both referring to
>>>> USER HW partition. Have a look at the git log, there have been patches
>>>> which handled this case in the MMC subsystem from about a year ago.
>>>
>>> Hi Marek,
>>>
>>> I can't find what you are referring to. I assume you are talking about
>>> calling the first name something other than 'user' as technically it's
>>> not (but it gets treated as user).
>>>
>>> Can you find the commit or discussion you are thinking about?
>>
>> It seems this whole thing is much older:
>>
>> 7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to
>> CONFIG_SPL_FRAMEWORK")
>>
>> +                * We need to check what the partition is configured to.
>> +                * 1 and 2 match up to boot0 / boot1 and 7 is user data
>> +                * which is the first physical partition (0).
>> +                */
>> +               int part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
>> +
>> +               if (part == 7)
>> +                       part = 0;
> 
> Hi Marek,

Hello Tim,

> Sorry, I haven't been able to work on U-Boot for the past week or so
> and am just getting back to this.

No worries.

> I'm glad you pointed this out as it made me aware that there is a bit
> of a mixing of eMMC PARTITION_CONFIG (Ext CSD 179) fields
> BOOT_PARTITION_ENABLE and PARTITION_ACCESS in U-Boot currently.
> 
> I'm going to add an enumerated type for each and update the various
> places where a 'conversion' as above is done but I'm still a bit torn
> on naming conventions.
> 
> Consider the following:
> - the eMMC spec refers to boot partitions and gp partitions as 1 based
> - the Linux kernel device names for these are 0 based
> - U-Boot does not currently refer to the boot devices by names but
> does currently refer to the gp's by names using 1-based names (the
> 'mmc hwpartition' command)
> 
> Personally I would like to name the boot partitions 'boot0' and
> 'boot1' to match Linux but I think I should name the gp's
> 'gp1'...'gp4' to be backward compatible with the 'mmc hwpartition'
> command.
> 
> What do you think?

I agree.

Maybe you could also check this with Ulf (Linux MMC maintainer) and Avri 
(mmc-utils), both on To:, so we would be consistent and in sync ?

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Dragan Simic]

Hello all,

On 2024-05-14 01:02, Marek Vasut wrote:
> On 5/13/24 10:52 PM, Tim Harvey wrote:
>> On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut <marex@denx.de> wrote:
>>> 
>>> On 4/29/24 6:48 PM, Tim Harvey wrote:
>>>> On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut <marex@denx.de> wrote:
>>>>> 
>>>>> On 4/27/24 2:11 AM, Tim Harvey wrote:
>>>>> 
>>>>> [...]
>>>>> 
>>>>>> diff --git a/include/mmc.h b/include/mmc.h
>>>>>> index 4b8327f1f93b..7243bd761202 100644
>>>>>> --- a/include/mmc.h
>>>>>> +++ b/include/mmc.h
>>>>>> @@ -381,6 +381,21 @@ enum mmc_voltage {
>>>>>>     #define MMC_TIMING_MMC_HS200        9
>>>>>>     #define MMC_TIMING_MMC_HS400        10
>>>>>> 
>>>>>> +/* emmc hardware partition values */
>>>>>> +enum emmc_hwpart {
>>>>>> +     EMMC_HWPART_DEFAULT = 0,
>>>>> 
>>>>> One more thing ... eMMC hardware partition 0 and 7 are both 
>>>>> referring to
>>>>> USER HW partition. Have a look at the git log, there have been 
>>>>> patches
>>>>> which handled this case in the MMC subsystem from about a year ago.
>>>> 
>>>> I can't find what you are referring to. I assume you are talking 
>>>> about
>>>> calling the first name something other than 'user' as technically 
>>>> it's
>>>> not (but it gets treated as user).
>>>> 
>>>> Can you find the commit or discussion you are thinking about?
>>> 
>>> It seems this whole thing is much older:
>>> 
>>> 7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to
>>> CONFIG_SPL_FRAMEWORK")
>>> 
>>> +                * We need to check what the partition is configured 
>>> to.
>>> +                * 1 and 2 match up to boot0 / boot1 and 7 is user 
>>> data
>>> +                * which is the first physical partition (0).
>>> +                */
>>> +               int part = (mmc->part_config >> 3) & 
>>> PART_ACCESS_MASK;
>>> +
>>> +               if (part == 7)
>>> +                       part = 0;
>> Sorry, I haven't been able to work on U-Boot for the past week or so
>> and am just getting back to this.
> 
> No worries.
> 
>> I'm glad you pointed this out as it made me aware that there is a bit
>> of a mixing of eMMC PARTITION_CONFIG (Ext CSD 179) fields
>> BOOT_PARTITION_ENABLE and PARTITION_ACCESS in U-Boot currently.
>> 
>> I'm going to add an enumerated type for each and update the various
>> places where a 'conversion' as above is done but I'm still a bit torn
>> on naming conventions.
>> 
>> Consider the following:
>> - the eMMC spec refers to boot partitions and gp partitions as 1 based
>> - the Linux kernel device names for these are 0 based
>> - U-Boot does not currently refer to the boot devices by names but
>> does currently refer to the gp's by names using 1-based names (the
>> 'mmc hwpartition' command)
>> 
>> Personally I would like to name the boot partitions 'boot0' and
>> 'boot1' to match Linux but I think I should name the gp's
>> 'gp1'...'gp4' to be backward compatible with the 'mmc hwpartition'
>> command.
>> 
>> What do you think?
> 
> I agree.
> 
> Maybe you could also check this with Ulf (Linux MMC maintainer) and
> Avri (mmc-utils), both on To:, so we would be consistent and in sync ?

As I promised earlier, I went through a few JEDEC standards and some
publicly available JEDEC documents and presentations, and my conclusion
is that no official numbering scheme for the partitions seems to be
defined there.

However, I'd propose that we keep "boot0" and "boot1", because that's
pretty much become a de facto standard, and also switch to using "gp0"
through "gp3" for the general-purpose partitions.  That switch might
be some kind of a backward-incompatible change, but it would follow
the names of the corresponding GP_SIZE_MULT_GP0 ... GP_SIZE_MULT_GP3
fields in the EXT_CSD register, as defined by JEDEC, and it would also
be more consistent with the numbering of the boot partitions.

Though, general-purpose partitions are mentioned as GPP1 ... GPP4 in
one place in the JEDEC standard, which just confirms that no official
numbering scheme seems to be defined.  Moreover, the boot partitions
are more than once referred to as "boot partition 1" and "boot partition
2" in the JEDEC standard, which means we're already not following the
standard with "boot0" and "boot1".

Frankly, it's all a bit contradictory and confusing, but I think that
the increased consistency would outweigh the backward-incompatible
downside of the switch to "gp0" through "gp3".

Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf

[Tim Harvey]

On Tue, May 14, 2024 at 5:05 AM Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello all,
>
> On 2024-05-14 01:02, Marek Vasut wrote:
> > On 5/13/24 10:52 PM, Tim Harvey wrote:
> >> On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut <marex@denx.de> wrote:
> >>>
> >>> On 4/29/24 6:48 PM, Tim Harvey wrote:
> >>>> On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut <marex@denx.de> wrote:
> >>>>>
> >>>>> On 4/27/24 2:11 AM, Tim Harvey wrote:
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>> diff --git a/include/mmc.h b/include/mmc.h
> >>>>>> index 4b8327f1f93b..7243bd761202 100644
> >>>>>> --- a/include/mmc.h
> >>>>>> +++ b/include/mmc.h
> >>>>>> @@ -381,6 +381,21 @@ enum mmc_voltage {
> >>>>>>     #define MMC_TIMING_MMC_HS200        9
> >>>>>>     #define MMC_TIMING_MMC_HS400        10
> >>>>>>
> >>>>>> +/* emmc hardware partition values */
> >>>>>> +enum emmc_hwpart {
> >>>>>> +     EMMC_HWPART_DEFAULT = 0,
> >>>>>
> >>>>> One more thing ... eMMC hardware partition 0 and 7 are both
> >>>>> referring to
> >>>>> USER HW partition. Have a look at the git log, there have been
> >>>>> patches
> >>>>> which handled this case in the MMC subsystem from about a year ago.
> >>>>
> >>>> I can't find what you are referring to. I assume you are talking
> >>>> about
> >>>> calling the first name something other than 'user' as technically
> >>>> it's
> >>>> not (but it gets treated as user).
> >>>>
> >>>> Can you find the commit or discussion you are thinking about?
> >>>
> >>> It seems this whole thing is much older:
> >>>
> >>> 7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to
> >>> CONFIG_SPL_FRAMEWORK")
> >>>
> >>> +                * We need to check what the partition is configured
> >>> to.
> >>> +                * 1 and 2 match up to boot0 / boot1 and 7 is user
> >>> data
> >>> +                * which is the first physical partition (0).
> >>> +                */
> >>> +               int part = (mmc->part_config >> 3) &
> >>> PART_ACCESS_MASK;
> >>> +
> >>> +               if (part == 7)
> >>> +                       part = 0;
> >> Sorry, I haven't been able to work on U-Boot for the past week or so
> >> and am just getting back to this.
> >
> > No worries.
> >
> >> I'm glad you pointed this out as it made me aware that there is a bit
> >> of a mixing of eMMC PARTITION_CONFIG (Ext CSD 179) fields
> >> BOOT_PARTITION_ENABLE and PARTITION_ACCESS in U-Boot currently.
> >>
> >> I'm going to add an enumerated type for each and update the various
> >> places where a 'conversion' as above is done but I'm still a bit torn
> >> on naming conventions.
> >>
> >> Consider the following:
> >> - the eMMC spec refers to boot partitions and gp partitions as 1 based
> >> - the Linux kernel device names for these are 0 based
> >> - U-Boot does not currently refer to the boot devices by names but
> >> does currently refer to the gp's by names using 1-based names (the
> >> 'mmc hwpartition' command)
> >>
> >> Personally I would like to name the boot partitions 'boot0' and
> >> 'boot1' to match Linux but I think I should name the gp's
> >> 'gp1'...'gp4' to be backward compatible with the 'mmc hwpartition'
> >> command.
> >>
> >> What do you think?
> >
> > I agree.
> >
> > Maybe you could also check this with Ulf (Linux MMC maintainer) and
> > Avri (mmc-utils), both on To:, so we would be consistent and in sync ?
>
> As I promised earlier, I went through a few JEDEC standards and some
> publicly available JEDEC documents and presentations, and my conclusion
> is that no official numbering scheme for the partitions seems to be
> defined there.
>
> However, I'd propose that we keep "boot0" and "boot1", because that's
> pretty much become a de facto standard, and also switch to using "gp0"
> through "gp3" for the general-purpose partitions.  That switch might
> be some kind of a backward-incompatible change, but it would follow
> the names of the corresponding GP_SIZE_MULT_GP0 ... GP_SIZE_MULT_GP3
> fields in the EXT_CSD register, as defined by JEDEC, and it would also
> be more consistent with the numbering of the boot partitions.
>
> Though, general-purpose partitions are mentioned as GPP1 ... GPP4 in
> one place in the JEDEC standard, which just confirms that no official
> numbering scheme seems to be defined.  Moreover, the boot partitions
> are more than once referred to as "boot partition 1" and "boot partition
> 2" in the JEDEC standard, which means we're already not following the
> standard with "boot0" and "boot1".
>
> Frankly, it's all a bit contradictory and confusing, but I think that
> the increased consistency would outweigh the backward-incompatible
> downside of the switch to "gp0" through "gp3".

Dragan,

Thanks for your freedback and sorry for the late reply.

I also went over the spec and found that they used 1 based naming in
their referencing of the partitions but noticed that Linux uses 0
based naming for both boot partitions as well as gp's when creating
devs. Seeing as both Linux and U-Boot tend to use 0 based naming I
wanted to go that route but then I noticed the 'mmc hwpartition'
command (enabled via MMC_HW_PARTITIONING) which is used to create gp's
uses 1-based gp names in its parameter list and that 'mmc info' will
display the gp's, if configured, as 1 based as well.

I submitted yesterday a new v3 series where I use boot0, boot1 for
boot partitions but gp1, gp2, gp3, gp4 for gp names just to stick with
the current usage of 'gp' in U-Boot (although the array of names isn't
used currently in the 'mmc hwpartition' or 'mmc info' commands.

I'm open to further discussion on the matter. I hate to make things
non-standard just to be backward compatible but I have no idea who is
using the 'mmc hwpartition' or output of 'mmc info' currently with
regards to gp's.

Best Regards,

Tim