RFC: Partition type GUID for U-Boot environment

RFC: Partition type GUID for U-Boot environment

[Rasmus Villemoes]

Hi,

Would it make sense to choose a canonical "Partition type GUID" [1] for
partitions used to store a U-Boot environment?

The partition type is mostly informational, but I'm thinking it might
make sense to have some canonical thing to put into an image definition
rather than having the tool use something random or a default which
would often be "Linux filesystem data".

If so, I propose 3de21764-95bd-54bd-a5c3-4abe786f38a8 , which is from
https://www.uuidtools.com/v5 with a namespace of
25cbcde0-8642-47c6-a298-1a3a57cd256b (randomly generated just now, but
should be used for future v5 uuids within U-Boot context [2]) and name
"U-Boot environment" (sans quotes).


[1] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
[2]
https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions_3_and_5_(namespace_name-based)

Rasmus

RFC: Partition type GUID for U-Boot environment

[Marcin Juszkiewicz]

W dniu 17.11.2020 o?11:05, Rasmus Villemoes pisze:

> Would it make sense to choose a canonical "Partition type GUID" [1] for
> partitions used to store a U-Boot environment?
> 
> The partition type is mostly informational, but I'm thinking it might
> make sense to have some canonical thing to put into an image definition
> rather than having the tool use something random or a default which
> would often be "Linux filesystem data".
> 
> If so, I propose 3de21764-95bd-54bd-a5c3-4abe786f38a8 , which is from
> https://www.uuidtools.com/v5 with a namespace of
> 25cbcde0-8642-47c6-a298-1a3a57cd256b (randomly generated just now, but
> should be used for future v5 uuids within U-Boot context [2]) and name
> "U-Boot environment" (sans quotes).

If you device lacks flash for environment then create "BIOS boot 
partition" and use it for storing both bootloader and env?

Something like 552d426f-6f74-2070-6c75-7320456e762020 (plus some endian 
swaps) would be better UUID for U-Boot Env partition as it goes to 
"U-Boot plus Env" after ASCII convertion ("BIOS Boot partition" UUID is 
"Hah!IdontNeedEFI" so why not continue tradition).

RFC: Partition type GUID for U-Boot environment

[Rasmus Villemoes]

On 17/11/2020 13.21, Marcin Juszkiewicz wrote:
> W dniu 17.11.2020 o?11:05, Rasmus Villemoes pisze:
> 
>> Would it make sense to choose a canonical "Partition type GUID" [1] for
>> partitions used to store a U-Boot environment?
>>
>> The partition type is mostly informational, but I'm thinking it might
>> make sense to have some canonical thing to put into an image definition
>> rather than having the tool use something random or a default which
>> would often be "Linux filesystem data".
>>
>> If so, I propose 3de21764-95bd-54bd-a5c3-4abe786f38a8 , which is from
>> https://www.uuidtools.com/v5 with a namespace of
>> 25cbcde0-8642-47c6-a298-1a3a57cd256b (randomly generated just now, but
>> should be used for future v5 uuids within U-Boot context [2]) and name
>> "U-Boot environment" (sans quotes).
> 
> If you device lacks flash for environment then create "BIOS boot
> partition" and use it for storing both bootloader and env?

I'm afraid I don't understand what you're asking about. I'm dealing with
multiple different boards, with lots of different ways of storing U-Boot
and/or its environment. I'm merely asking if, for the cases where one
chooses to define a GPT partition to hold the environment (and nothing
else), does it make sense to have something to put in the Partition Type
field?

I don't think I've ever had occasion to put U-Boot and the environment
in the same partition, but I have cases where both are stored raw - and
it's that hardcoding of offsets I'd like to get rid of by defining a
partition for the environment - it's much nicer to be able to put
/dev/disk/by-partlabel/u-boot-env in fw_env.config. I can do that
without a canonical partition type uuid of course.

> Something like 552d426f-6f74-2070-6c75-7320456e762020 (plus some endian
> swaps) would be better UUID for U-Boot Env partition as it goes to
> "U-Boot plus Env" after ASCII convertion ("BIOS Boot partition" UUID is
> "Hah!IdontNeedEFI" so why not continue tradition).

Eh, because, at least according to that wiki page, " The formation of
this GUID does not follow the GUID definition;". But whichever uuid the
U-Boot project would elect I'd use. (Though one spelling "U-Boot plus
Env" would be somewhat misleading for something only containing an
environment).

Rasmus

RFC: Partition type GUID for U-Boot environment

[Tom Rini]

On Tue, Nov 17, 2020 at 11:05:36AM +0100, Rasmus Villemoes wrote:

> Hi,
> 
> Would it make sense to choose a canonical "Partition type GUID" [1] for
> partitions used to store a U-Boot environment?
> 
> The partition type is mostly informational, but I'm thinking it might
> make sense to have some canonical thing to put into an image definition
> rather than having the tool use something random or a default which
> would often be "Linux filesystem data".
> 
> If so, I propose 3de21764-95bd-54bd-a5c3-4abe786f38a8 , which is from
> https://www.uuidtools.com/v5 with a namespace of
> 25cbcde0-8642-47c6-a298-1a3a57cd256b (randomly generated just now, but
> should be used for future v5 uuids within U-Boot context [2]) and name
> "U-Boot environment" (sans quotes).
> 
> 
> [1] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
> [2]
> https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions_3_and_5_(namespace_name-based)

Sure.  Do we need to, well, register that GUID with anyone so that other
tools will see and pick it up and print something nice?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201117/91a427f2/attachment.sig>

RFC: Partition type GUID for U-Boot environment

[Rasmus Villemoes]

On 17/11/2020 19.27, Tom Rini wrote:
> On Tue, Nov 17, 2020 at 11:05:36AM +0100, Rasmus Villemoes wrote:
> 
>> Hi,
>>
>> Would it make sense to choose a canonical "Partition type GUID" [1] for
>> partitions used to store a U-Boot environment?
>>
>> The partition type is mostly informational, but I'm thinking it might
>> make sense to have some canonical thing to put into an image definition
>> rather than having the tool use something random or a default which
>> would often be "Linux filesystem data".
>>
>> If so, I propose 3de21764-95bd-54bd-a5c3-4abe786f38a8 , which is from
>> https://www.uuidtools.com/v5 with a namespace of
>> 25cbcde0-8642-47c6-a298-1a3a57cd256b (randomly generated just now, but
>> should be used for future v5 uuids within U-Boot context [2]) and name
>> "U-Boot environment" (sans quotes).
>>
>>
>> [1] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
>> [2]
>> https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions_3_and_5_(namespace_name-based)
> 
> Sure.  Do we need to, well, register that GUID with anyone so that other
> tools will see and pick it up and print something nice?

I don't think so - there's no central authority for these. It seems that
the GUID for "Linux filesystem data" was decided by someone proposing it
on appropriate mailing lists. So I think just adding it to
doc/README.gpt and hooking it up in lib/uuid.c should be enough. I'll
send a patch.

Rasmus

[PATCH 0/3] add partition type GUID for U-Boot environment

[Rasmus Villemoes]

Adding the GUID to README.gpt and hooking it up in code turned out to
require two other, mostly janitorial, patches, the first and last
here.

I've tested that "part list host 0" does show the

        type:   u-boot-env

for a test image I generated with one partition's type guid set to the
value defined here.


Rasmus Villemoes (3):
  lib/uuid.c: change prototype of uuid_guid_get_str()
  doc/README.gpt: define partition type GUID for U-Boot environment
  doc/README.gpt: reflow partition type GUID table

 disk/part_efi.c    |  9 +++++----
 doc/README.gpt     | 34 ++++++++++++++++++----------------
 include/part_efi.h |  3 +++
 include/uuid.h     |  4 +---
 lib/uuid.c         | 14 +++++++-------
 5 files changed, 34 insertions(+), 30 deletions(-)

-- 
2.23.0

[PATCH 1/3] lib/uuid.c: change prototype of uuid_guid_get_str()

[Rasmus Villemoes]

There's no reason to require an appropriately sized output parameter
for the string, that's error-prone should the table ever grow an
element with a longer string. We can just return the const char*
pointer directly.

Update the only caller accordingly, and get rid of pointless ifdeffery
in the header so that the compiler always sees a declaration and can
thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled
or not.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
 disk/part_efi.c |  9 +++++----
 include/uuid.h  |  4 +---
 lib/uuid.c      | 11 +++++------
 3 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 60b1c1d761..2f922662e6 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -247,10 +247,11 @@ void part_print_efi(struct blk_desc *dev_desc)
 		uuid_bin = (unsigned char *)gpt_pte[i].partition_type_guid.b;
 		uuid_bin_to_str(uuid_bin, uuid, UUID_STR_FORMAT_GUID);
 		printf("\ttype:\t%s\n", uuid);
-#ifdef CONFIG_PARTITION_TYPE_GUID
-		if (!uuid_guid_get_str(uuid_bin, uuid))
-			printf("\ttype:\t%s\n", uuid);
-#endif
+		if (CONFIG_IS_ENABLED(PARTITION_TYPE_GUID)) {
+			const char *type = uuid_guid_get_str(uuid_bin);
+			if (type)
+				printf("\ttype:\t%s\n", type);
+		}
 		uuid_bin = (unsigned char *)gpt_pte[i].unique_partition_guid.b;
 		uuid_bin_to_str(uuid_bin, uuid, UUID_STR_FORMAT_GUID);
 		printf("\tguid:\t%s\n", uuid);
diff --git a/include/uuid.h b/include/uuid.h
index 73c5a89ec7..0c653cb087 100644
--- a/include/uuid.h
+++ b/include/uuid.h
@@ -39,10 +39,8 @@ int uuid_str_to_bin(const char *uuid_str, unsigned char *uuid_bin,
 		    int str_format);
 void uuid_bin_to_str(const unsigned char *uuid_bin, char *uuid_str,
 		     int str_format);
-#ifdef CONFIG_PARTITION_TYPE_GUID
 int uuid_guid_get_bin(const char *guid_str, unsigned char *guid_bin);
-int uuid_guid_get_str(const unsigned char *guid_bin, char *guid_str);
-#endif
+const char *uuid_guid_get_str(const unsigned char *guid_bin);
 void gen_rand_uuid(unsigned char *uuid_bin);
 void gen_rand_uuid_str(char *uuid_str, int str_format);
 #endif
diff --git a/lib/uuid.c b/lib/uuid.c
index e62d5ca264..6cfb6cd449 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -122,20 +122,19 @@ int uuid_guid_get_bin(const char *guid_str, unsigned char *guid_bin)
  * uuid_guid_get_str() - this function get string for GUID.
  *
  * @param guid_bin - pointer to string with partition type guid [16B]
- * @param guid_str - pointer to allocated partition type string [7B]
+ *
+ * Returns NULL if the type GUID is not known.
  */
-int uuid_guid_get_str(const unsigned char *guid_bin, char *guid_str)
+const char *uuid_guid_get_str(const unsigned char *guid_bin)
 {
 	int i;
 
-	*guid_str = 0;
 	for (i = 0; i < ARRAY_SIZE(list_guid); i++) {
 		if (!memcmp(list_guid[i].guid.b, guid_bin, 16)) {
-			strcpy(guid_str, list_guid[i].string);
-			return 0;
+			return list_guid[i].string;
 		}
 	}
-	return -ENODEV;
+	return NULL;
 }
 #endif
 
-- 
2.23.0

[PATCH 1/3] lib/uuid.c: change prototype of uuid_guid_get_str()

[Tom Rini]

On Fri, Nov 20, 2020 at 11:45:35AM +0100, Rasmus Villemoes wrote:

> There's no reason to require an appropriately sized output parameter
> for the string, that's error-prone should the table ever grow an
> element with a longer string. We can just return the const char*
> pointer directly.
> 
> Update the only caller accordingly, and get rid of pointless ifdeffery
> in the header so that the compiler always sees a declaration and can
> thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled
> or not.
> 
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210118/d6c23740/attachment.sig>

[PATCH 2/3] doc/README.gpt: define partition type GUID for U-Boot environment

[Rasmus Villemoes]

When setting aside a GPT partition for holding the U-Boot environment,
having a partition type GUID [1] indicating "Linux filesystem" (as
most tools default to) is somewhat misleading - and there's no other
well-known type GUID that is better suited. So to have a canonical
value to put into the type field, define

    3de21764-95bd-54bd-a5c3-4abe786f38a8

to mean a partition holding a U-Boot environment.

This is a v5 namespace-name GUID [2], generated [3] from a namespace
of "25cbcde0-8642-47c6-a298-1a3a57cd256b" and name "U-Boot
environment".

Should future type GUIDs be defined in the context of U-Boot, it's
sensible to use that same namespace GUID.

[1] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
[2] https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions_3_and_5_(namespace_name-based)
[3] https://www.uuidtools.com/v5

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
 doc/README.gpt     | 2 ++
 include/part_efi.h | 3 +++
 lib/uuid.c         | 3 ++-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/doc/README.gpt b/doc/README.gpt
index facd7afc3a..9e0d2221ef 100644
--- a/doc/README.gpt
+++ b/doc/README.gpt
@@ -267,6 +267,8 @@ Some strings can be also used at the place of known GUID :
 	           (0657FD6D-A4AB-43C4-84E5-0933C84B4F4F)
 	"lvm"    = PARTITION_LINUX_LVM_GUID
 	           (E6D6D379-F507-44C2-A23C-238F2A3DF928)
+	"u-boot-env"      = PARTITION_U_BOOT_ENVIRONMENT
+	                    (3DE21764-95BD-54BD-A5C3-4ABE786F38A8)
 
     "uuid_disk=...;name=u-boot,size=60MiB,uuid=...;
 	name=kernel,size=60MiB,uuid=...,type=linux;"
diff --git a/include/part_efi.h b/include/part_efi.h
index 1929e4400f..c68529b4da 100644
--- a/include/part_efi.h
+++ b/include/part_efi.h
@@ -56,6 +56,9 @@
 #define PARTITION_LINUX_LVM_GUID \
 	EFI_GUID( 0xe6d6d379, 0xf507, 0x44c2, \
 		0xa2, 0x3c, 0x23, 0x8f, 0x2a, 0x3d, 0xf9, 0x28)
+#define PARTITION_U_BOOT_ENVIRONMENT \
+	EFI_GUID( 0x3de21764, 0x95bd, 0x54bd, \
+		0xa5, 0xc3, 0x4a, 0xbe, 0x78, 0x6f, 0x38, 0xa8)
 
 /* linux/include/efi.h */
 typedef u16 efi_char16_t;
diff --git a/lib/uuid.c b/lib/uuid.c
index 6cfb6cd449..54a93aacc9 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -96,7 +96,8 @@ static const struct {
 	{"linux",	PARTITION_LINUX_FILE_SYSTEM_DATA_GUID},
 	{"raid",	PARTITION_LINUX_RAID_GUID},
 	{"swap",	PARTITION_LINUX_SWAP_GUID},
-	{"lvm",		PARTITION_LINUX_LVM_GUID}
+	{"lvm",		PARTITION_LINUX_LVM_GUID},
+	{"u-boot-env",	PARTITION_U_BOOT_ENVIRONMENT},
 };
 
 /*
-- 
2.23.0

[PATCH 2/3] doc/README.gpt: define partition type GUID for U-Boot environment

[Tom Rini]

On Fri, Nov 20, 2020 at 11:45:36AM +0100, Rasmus Villemoes wrote:

> When setting aside a GPT partition for holding the U-Boot environment,
> having a partition type GUID [1] indicating "Linux filesystem" (as
> most tools default to) is somewhat misleading - and there's no other
> well-known type GUID that is better suited. So to have a canonical
> value to put into the type field, define
> 
>     3de21764-95bd-54bd-a5c3-4abe786f38a8
> 
> to mean a partition holding a U-Boot environment.
> 
> This is a v5 namespace-name GUID [2], generated [3] from a namespace
> of "25cbcde0-8642-47c6-a298-1a3a57cd256b" and name "U-Boot
> environment".
> 
> Should future type GUIDs be defined in the context of U-Boot, it's
> sensible to use that same namespace GUID.
> 
> [1] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
> [2] https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions_3_and_5_(namespace_name-based)
> [3] https://www.uuidtools.com/v5
> 
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210118/a7c20d1b/attachment.sig>

[PATCH 3/3] doc/README.gpt: reflow partition type GUID table

[Rasmus Villemoes]

The previous patch made the table look bad. Fix it, and leave some
space for a future element being a bit longer than the current
maximum.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
 doc/README.gpt | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/doc/README.gpt b/doc/README.gpt
index 9e0d2221ef..ac975f66b8 100644
--- a/doc/README.gpt
+++ b/doc/README.gpt
@@ -251,22 +251,22 @@ can specify a other partition type guid:
 	type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;"
 
 Some strings can be also used at the place of known GUID :
-	"system" = PARTITION_SYSTEM_GUID
-	           (C12A7328-F81F-11D2-BA4B-00A0C93EC93B)
-	"mbr"    = LEGACY_MBR_PARTITION_GUID
-	           (024DEE41-33E7-11D3-9D69-0008C781F39F)
-	"msft"   = PARTITION_MSFT_RESERVED_GUID
-	           (E3C9E316-0B5C-4DB8-817D-F92DF00215AE)
-	"data"   = PARTITION_BASIC_DATA_GUID
-	            (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7)
-	"linux"  = PARTITION_LINUX_FILE_SYSTEM_DATA_GUID
-	           (0FC63DAF-8483-4772-8E79-3D69D8477DE4)
-	"raid"   = PARTITION_LINUX_RAID_GUID
-	           (A19D880F-05FC-4D3B-A006-743F0F84911E)
-	"swap"   = PARTITION_LINUX_SWAP_GUID
-	           (0657FD6D-A4AB-43C4-84E5-0933C84B4F4F)
-	"lvm"    = PARTITION_LINUX_LVM_GUID
-	           (E6D6D379-F507-44C2-A23C-238F2A3DF928)
+	"system"          = PARTITION_SYSTEM_GUID
+	                    (C12A7328-F81F-11D2-BA4B-00A0C93EC93B)
+	"mbr"             = LEGACY_MBR_PARTITION_GUID
+	                    (024DEE41-33E7-11D3-9D69-0008C781F39F)
+	"msft"            = PARTITION_MSFT_RESERVED_GUID
+	                    (E3C9E316-0B5C-4DB8-817D-F92DF00215AE)
+	"data"            = PARTITION_BASIC_DATA_GUID
+	                     (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7)
+	"linux"           = PARTITION_LINUX_FILE_SYSTEM_DATA_GUID
+	                    (0FC63DAF-8483-4772-8E79-3D69D8477DE4)
+	"raid"            = PARTITION_LINUX_RAID_GUID
+	                    (A19D880F-05FC-4D3B-A006-743F0F84911E)
+	"swap"            = PARTITION_LINUX_SWAP_GUID
+	                    (0657FD6D-A4AB-43C4-84E5-0933C84B4F4F)
+	"lvm"             = PARTITION_LINUX_LVM_GUID
+	                    (E6D6D379-F507-44C2-A23C-238F2A3DF928)
 	"u-boot-env"      = PARTITION_U_BOOT_ENVIRONMENT
 	                    (3DE21764-95BD-54BD-A5C3-4ABE786F38A8)
 
-- 
2.23.0

[PATCH 3/3] doc/README.gpt: reflow partition type GUID table

[Tom Rini]

On Fri, Nov 20, 2020 at 11:45:37AM +0100, Rasmus Villemoes wrote:

> The previous patch made the table look bad. Fix it, and leave some
> space for a future element being a bit longer than the current
> maximum.
> 
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210118/fdc567a6/attachment.sig>