GPT over MTD

RFC PATCH Superseded Patrick Delaunay 4 participants 13 messages Nov 22, 2016 – Nov 30, 2016

Subsystems (2)

Library code Uuid helpers

lore

Share & tools

lore

Patrick Delaunay

author

2016-11-22 13:24 UTC #0 lore raw

cover GPT over MTD

I have a request to support GPT over MTD to be able to have dynamic MTD informations without u-Boot environment(CONFIG_ENV_IS_NOWHERE is a other requirement of my project).

The idea is to use the GPT header to save partitioning information directly in flash device (NOR or NAND), then the MTD variables are rebuild from these GPT partitions and can be used by DISTRO to search bootable binary.

I make a first prototyping for this request but I want ask you if this feature is acceptable for u-boot and if this patches, after some update and cleanups, would be merged in u-boot mainline.
Do you see already some blocking points ?

- added code is under a new CONFIG : CONFIG_EFI_PARTITION_MTD
- for implementation details, see doc/README.gpt.mtd

TODO:
- split patch between core impact (disk/part_efi.c)
and command update
- full support for modified command
(today I limit the support for the command used by DISTRO macro)
- DISTRO macro update for automatic boot on GPT bootable partition found in MTD devices

the current level is tested manually on sandbox with :

Quoted 2 lines

make O=sandbox
sandbox/u-boot -d sandbox/arch/sandbox/dts/test.dtb

=> sf probe
SF: Detected M25P16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB

=> setenv nor_part "name=part1,size=64KiB;name=part2,size=128KiB;\
name=boot,type=linux,bootable,size=512KiB"
=> gpt write nor 0 $nor_part
Writing GPT: success!

=> part list nor 0
Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00000080 0x000000ff "part1"

	attrs:	0x0000000000000000
	type:	ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
	type:	data
	guid:	d117f98e-6f2c-0040-00b2-331a19f91cb2
  2	0x00000100	0x000001ff	"part2"
	attrs:	0x0000000000000000
	type:	ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
	type:	data
	guid:	25718777-d0ad-0000-8060-02cb591c9737
  3	0x00000200	0x000005ff	"boot"
	attrs:	0x0000000000000004
	type:	0fc63daf-8483-4772-8e79-3d69d8477de4
	type:	linux
	guid:	8a4bb8b4-e304-0040-0036-aff5c9c495b1

=> setenv mtdids "nor0=nor0"
=> setenv mtdparts "mtdparts="
=> mtdparts gpt nor0
=> mtdparts
device nor0 <nor0>, # parts = 3
#: name size offset mask_flags

 0: part1               0x00010000	0x00010000	0
 1: part2               0x00020000	0x00020000	0
 2: boot                0x00080000	0x00040000	0

active partition: nor0,0 - (part1) 0x00010000 @ 0x00010000

defaults:
mtdids : none
mtdparts: none

=> part list nor 0 -bootable nor_boot_part
=> printenv nor_boot_part
nor_boot_part=3

Patrick Delaunay (3):
add support of GPT partitioning over MTD
uuid: remove dependency with io.h
sandbox: GPT over MTD test

 Kconfig                   |  12 ++
 cmd/gpt.c                 |  98 +++++++--
 cmd/mtdparts.c            | 103 ++++++++-
 cmd/part.c                |  48 ++++-
 configs/sandbox_defconfig |   2 +
 disk/part_efi.c           | 526 +++++++++++++++++++++++++++++++++++++++++-----
 doc/README.gpt.mtd        | 189 +++++++++++++++++
 include/configs/sandbox.h |   7 +
 include/part.h            |  13 +-
 include/uuid.h            |   1 +
 lib/uuid.c                |  46 +++-
 11 files changed, 959 insertions(+), 86 deletions(-)
 create mode 100644 doc/README.gpt.mtd

Signature · 1 line

1.9.1

Patrick Delaunay

author

2016-11-22 13:24 UTC #1 lore raw

RFC PATCH 1/3 add support of GPT partitioning over MTD

From: Patrick Delaunay <[email protected]>

Signed-off-by Patrick Delaunay <[email protected]>

---

 Kconfig            |  12 ++
 cmd/gpt.c          |  98 ++++++++--
 cmd/mtdparts.c     | 103 ++++++++++-
 cmd/part.c         |  48 ++++-
 disk/part_efi.c    | 526 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 doc/README.gpt.mtd | 189 +++++++++++++++++++
 include/part.h     |  13 +-
 include/uuid.h     |   1 +
 lib/uuid.c         |  33 ++++
 9 files changed, 944 insertions(+), 79 deletions(-)
 create mode 100644 doc/README.gpt.mtd

Kconfig +12 -0

index 1263d0b..c2388e1 100644
@@ -335,6 +335,18 @@ config ARCH_FIXUP_FDT
 
 endmenu		# Boot images
 
+config EFI_PARTITION_MTD
+	bool "Support GPT over MTD"
+	help
+	  The GPT partition is normally defined only for block device with
+	  built-in controller which manage flash translation layer
+	  This option activate the GPT partition support over RAW device
+	  using the MTD framework
+	  - manage partition over MTD devices (as flash: NOR and NAND)
+	  - extract MTD information
+	  - update command gpt, mtdparts and part
+	  NB: depends on EFI_PARTITION
+
 source "common/Kconfig"
 
 source "cmd/Kconfig"

cmd/gpt.c +82 ~~-16~~

181 lines not on this page · raw message

cmd/mtdparts.c +101 -2

133 lines not on this page · raw message

cmd/part.c +39 -9

78 lines not on this page · raw message

disk/part_efi.c +476 ~~-50~~

572 lines not on this page · raw message

doc/README.gpt.mtd new file +189 -0

189 lines not on this page · raw message

include/part.h +11 -2

index 0979005..0660c27 100644
@@ -9,6 +9,7 @@
 
 #include <blk.h>
 #include <ide.h>
+#include <linux/mtd/mtd.h>
 
 struct block_drvr {
 	char *name;

@@ -308,7 +309,6 @@ int gpt_fill_header(struct blk_desc *dev_desc, gpt_header *gpt_h,
  */
 int gpt_restore(struct blk_desc *dev_desc, char *str_disk_guid,
 		disk_partition_t *partitions, const int parts_count);
-
 /**
  * is_valid_gpt_buf() - Ensure that the Primary GPT information is valid
  *

@@ -363,7 +363,16 @@ int gpt_verify_headers(struct blk_desc *dev_desc, gpt_header *gpt_head,
 int gpt_verify_partitions(struct blk_desc *dev_desc,
 			  disk_partition_t *partitions, int parts,
 			  gpt_header *gpt_head, gpt_entry **gpt_pte);
-#endif
+
+#ifdef CONFIG_EFI_PARTITION_MTD
+#define MTD_LBA_SIZE	512
+int gpt_restore_mtd(struct mtd_info *mtd, char *str_disk_guid,
+		    disk_partition_t *partitions, int parts_count);
+void part_print_efi_mtd(struct mtd_info *mtd_info);
+int part_get_info_efi_mtd(struct mtd_info *mtd, int part,
+			       disk_partition_t *info);
+#endif /* CONFIG_EFI_PARTITION_MTD */
+#endif /* CONFIG_EFI_PARTITION */
 
 #ifdef CONFIG_DOS_PARTITION
 /**

include/uuid.h +1 -0

index c3f423f..f444095 100644
@@ -40,6 +40,7 @@ void uuid_bin_to_str(unsigned char *uuid_bin, char *uuid_str, int str_format);
 int uuid_guid_get_bin(const char *guid_str, unsigned char *guid_bin);
 int uuid_guid_get_str(unsigned char *guid_bin, char *guid_str);
 #endif
+int uuid_guid_parse_str(const char *str, char *guid_str);
 void gen_rand_uuid(unsigned char *uuid_bin);
 void gen_rand_uuid_str(char *uuid_str, int str_format);
 #endif

lib/uuid.c +33 -0

index c8584ed..eb8d8eb 100644
@@ -136,6 +136,39 @@ int uuid_guid_get_str(unsigned char *guid_bin, char *guid_str)
 #endif
 
 /*
+ * uuid_guid_parse_str() - this function parse string for GUID.
+ *
+ * @param guid_str - pointer to string with partition type guid [37B]
+ *                   or GUID shorcut
+ * @param guid_str - pointer to allocated partition type string [37B]
+ */
+int uuid_guid_parse_str(const char *str, char *guid_str)
+{
+#ifdef CONFIG_PARTITION_TYPE_GUID
+	int i;
+#endif
+
+	if (guid_str == NULL)
+		return -ENODEV;
+
+	if (uuid_str_valid(str)) {
+		memcpy(guid_str, str, UUID_STR_LEN + 1);
+		return 0;
+	}
+
+#ifdef CONFIG_PARTITION_TYPE_GUID
+	for (i = 0; i < ARRAY_SIZE(list_guid); i++) {
+		if (!strcmp(list_guid[i].string, str)) {
+			uuid_bin_to_str((unsigned char *)list_guid[i].guid.b,
+					guid_str, UUID_STR_FORMAT_GUID);
+			return 0;
+		}
+	}
+#endif
+	return -ENODEV;
+}
+
+/*
  * uuid_str_to_bin() - convert string UUID or GUID to big endian binary data.
  *
  * @param uuid_str - pointer to UUID or GUID string [37B] or GUID shorcut

Signature · 1 line

1.9.1

Simon Glass

2016-11-24 02:20 UTC #2 lore raw

RFC PATCH 1/3 add support of GPT partitioning over MTD

Hi Patrick,

Quoted 6 lines · Patrick Delaunay

From: Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
---

Quoted 11 lines

 Kconfig            |  12 ++
 cmd/gpt.c          |  98 ++++++++--
 cmd/mtdparts.c     | 103 ++++++++++-
 cmd/part.c         |  48 ++++-
 disk/part_efi.c    | 526 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 doc/README.gpt.mtd | 189 +++++++++++++++++++
 include/part.h     |  13 +-
 include/uuid.h     |   1 +
 lib/uuid.c         |  33 ++++
 9 files changed, 944 insertions(+), 79 deletions(-)
 create mode 100644 doc/README.gpt.mtd

General comments:

- use 'U-Boot' consistently rather than variations
- can you split your large function up a bit?
- can you make a precursor patch to refactor things, so reducing the size of this one?
- nice README!

Quoted 10 lines

Kconfig +1 -0

index 1263d0b..c2388e1 100644
@@ -335,6 +335,18 @@ config ARCH_FIXUP_FDT
 
 endmenu                # Boot images
 
+config EFI_PARTITION_MTD

Kconfig config ARCH_FIXUP_FDT · line 348

Quoted 10 lines

Kconfig +10 -0

+       bool "Support GPT over MTD"
+       help
+         The GPT partition is normally defined only for block device with
+         built-in controller which manage flash translation layer
+         This option activate the GPT partition support over RAW device
+         using the MTD framework
+         - manage partition over MTD devices (as flash: NOR and NAND)
+         - extract MTD information
+         - update command gpt, mtdparts and part
+         NB: depends on EFI_PARTITION

So do you want 'depends on EFI_PARTITION'?

Regards,
Simon

Patrick DELAUNAY

2016-11-24 10:27 UTC #3 lore raw

RFC PATCH 1/3 add support of GPT partitioning over MTD

Hi Simon,

Quoted 24 lines

Hi Patrick,
Quoted 11 lines · Patrick Delaunay
From: Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
---
 Kconfig            |  12 ++
 cmd/gpt.c          |  98 ++++++++--
 cmd/mtdparts.c     | 103 ++++++++++-
 cmd/part.c         |  48 ++++-
 disk/part_efi.c    | 526
++++++++++++++++++++++++++++++++++++++++++++++++-----
Quoted 6 lines
 doc/README.gpt.mtd | 189 +++++++++++++++++++
 include/part.h     |  13 +-
 include/uuid.h     |   1 +
 lib/uuid.c         |  33 ++++
 9 files changed, 944 insertions(+), 79 deletions(-)  create mode
100644 doc/README.gpt.mtd

Quoted 6 lines

General comments:
- use 'U-Boot' consistently rather than variations
- can you split your large function up a bit?
- can you make a precursor patch to refactor things, so reducing the size of this one?

Yes, I will do this split in v2 to reduce each patch size:
- one patch to uuid new function
- one precursor for efi part : refactor
- one patch for GPT over MTD in part_efi.c
& I will split large function
- one patch for each command update

Quoted 11 lines

- nice README!

Quoted 9 lines

Kconfig +0 -0

index 1263d0b..c2388e1 100644
@@ -335,6 +335,18 @@ config ARCH_FIXUP_FDT
 
 endmenu                # Boot images

Quoted 13 lines

Kconfig config ARCH_FIXUP_FDT · line 348

Quoted 11 lines

Kconfig +11 -0

+config EFI_PARTITION_MTD
+       bool "Support GPT over MTD"
+       help
+         The GPT partition is normally defined only for block device with
+         built-in controller which manage flash translation layer
+         This option activate the GPT partition support over RAW device
+         using the MTD framework
+         - manage partition over MTD devices (as flash: NOR and NAND)
+         - extract MTD information
+         - update command gpt, mtdparts and part
+         NB: depends on EFI_PARTITION

So do you want 'depends on EFI_PARTITION'?

Yes I expect it, I try to add
depends on EFI_PARTITION
but is not working as it is not (yet ?) one KCONFIG option. I add this comment to add this line when part lib will integrate KCONFIG

Quoted 3 lines

Regards,
Simon

Regards,
Patrick

Simon Glass

2016-11-27 17:02 UTC #4 lore raw

RFC PATCH 1/3 add support of GPT partitioning over MTD

Hi Patrick,

Quoted 65 lines · Patrick DELAUNAY

Hi Simon,
Quoted 24 lines
Hi Patrick,
Quoted 11 lines · Patrick Delaunay
From: Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
---
 Kconfig            |  12 ++
 cmd/gpt.c          |  98 ++++++++--
 cmd/mtdparts.c     | 103 ++++++++++-
 cmd/part.c         |  48 ++++-
 disk/part_efi.c    | 526
++++++++++++++++++++++++++++++++++++++++++++++++-----
Quoted 6 lines
 doc/README.gpt.mtd | 189 +++++++++++++++++++
 include/part.h     |  13 +-
 include/uuid.h     |   1 +
 lib/uuid.c         |  33 ++++
 9 files changed, 944 insertions(+), 79 deletions(-)  create mode
100644 doc/README.gpt.mtd
Quoted 6 lines
General comments:
- use 'U-Boot' consistently rather than variations
- can you split your large function up a bit?
- can you make a precursor patch to refactor things, so reducing the size of this one?
Yes, I will do this split in v2 to reduce each patch size:
- one patch to uuid new function
- one precursor for efi part : refactor
- one patch for GPT over MTD in part_efi.c
& I will split large function
- one patch for each command update
Quoted 11 lines
- nice README!
Quoted 9 lines
Kconfig +0 -0
index 1263d0b..c2388e1 100644
@@ -335,6 +335,18 @@ config ARCH_FIXUP_FDT
 
 endmenu                # Boot images
 
Quoted 13 lines
Kconfig config ARCH_FIXUP_FDT · line 348
Quoted 11 lines
Kconfig +11 -0
+config EFI_PARTITION_MTD
+       bool "Support GPT over MTD"
+       help
+         The GPT partition is normally defined only for block device with
+         built-in controller which manage flash translation layer
+         This option activate the GPT partition support over RAW device
+         using the MTD framework
+         - manage partition over MTD devices (as flash: NOR and NAND)
+         - extract MTD information
+         - update command gpt, mtdparts and part
+         NB: depends on EFI_PARTITION
So do you want 'depends on EFI_PARTITION'?

Quoted 4 lines

Yes I expect it, I try to add
depends on EFI_PARTITION
but is not working as it is not (yet ?) one KCONFIG option. I add this comment to add this line when part lib will integrate KCONFIG

I see. Well if you have the energy you could use moveconfig.py to convert it.

Regards,
Simon

Patrick DELAUNAY

2016-11-28 15:06 UTC #5 lore raw

RFC PATCH 1/3 add support of GPT partitioning over MTD

Hi Simon,

Quoted 70 lines

Hi Patrick,
Quoted 65 lines · Patrick DELAUNAY
Hi Simon,
Quoted 24 lines
Hi Patrick,
Quoted 11 lines · Patrick Delaunay
From: Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
---
 Kconfig            |  12 ++
 cmd/gpt.c          |  98 ++++++++--
 cmd/mtdparts.c     | 103 ++++++++++-
 cmd/part.c         |  48 ++++-
 disk/part_efi.c    | 526
++++++++++++++++++++++++++++++++++++++++++++++++-----
Quoted 6 lines
 doc/README.gpt.mtd | 189 +++++++++++++++++++
 include/part.h     |  13 +-
 include/uuid.h     |   1 +
 lib/uuid.c         |  33 ++++
 9 files changed, 944 insertions(+), 79 deletions(-)  create mode
100644 doc/README.gpt.mtd
Quoted 6 lines
General comments:
- use 'U-Boot' consistently rather than variations
- can you split your large function up a bit?
- can you make a precursor patch to refactor things, so reducing the size of this one?
Yes, I will do this split in v2 to reduce each patch size:
- one patch to uuid new function
- one precursor for efi part : refactor
- one patch for GPT over MTD in part_efi.c
& I will split large function
- one patch for each command update
Quoted 24 lines
- nice README!
Quoted 10 lines
Kconfig +1 -0
index 1263d0b..c2388e1 100644
@@ -335,6 +335,18 @@ config ARCH_FIXUP_FDT
 
 endmenu                # Boot images
 
+config EFI_PARTITION_MTD
Kconfig config ARCH_FIXUP_FDT · line 348
Quoted 10 lines
Kconfig +10 -0
+       bool "Support GPT over MTD"
+       help
+         The GPT partition is normally defined only for block device with
+         built-in controller which manage flash translation layer
+         This option activate the GPT partition support over RAW device
+         using the MTD framework
+         - manage partition over MTD devices (as flash: NOR and NAND)
+         - extract MTD information
+         - update command gpt, mtdparts and part
+         NB: depends on EFI_PARTITION
So do you want 'depends on EFI_PARTITION'?

Quoted 7 lines

Quoted 5 lines
Yes I expect it, I try to add
depends on EFI_PARTITION
but is not working as it is not (yet ?) one KCONFIG option. I add this comment to add this line when part lib will integrate KCONFIG
I see. Well if you have the energy you could use moveconfig.py to convert it.

I will try to propose something (first usage of moveconfig.py script...) if I have no issue with cross-compilation

=> Create "disk/Kconfig" with PARTITIONS all associated option (MAC_PARTITION, DOS_PARTITION, ISO_PARTITION, AMIGA_PARTITION, EFI_PARTITION)

Quoted 2 lines

Regards,
Simon

Patrick DELAUNAY

2016-11-30 10:45 UTC #6 lore raw

RFC PATCH 1/3 add support of GPT partitioning over MTD

In reply to Simon Glass

Hi Simon,

Quoted 80 lines

Hi Simon,
Quoted 70 lines
Hi Patrick,
Quoted 65 lines · Patrick DELAUNAY
Hi Simon,
Quoted 24 lines
Hi Patrick,
Quoted 11 lines · Patrick Delaunay
From: Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
Signed-off-by Patrick Delaunay <[email protected]>
---
 Kconfig            |  12 ++
 cmd/gpt.c          |  98 ++++++++--
 cmd/mtdparts.c     | 103 ++++++++++-
 cmd/part.c         |  48 ++++-
 disk/part_efi.c    | 526
++++++++++++++++++++++++++++++++++++++++++++++++-----
Quoted 6 lines
 doc/README.gpt.mtd | 189 +++++++++++++++++++
 include/part.h     |  13 +-
 include/uuid.h     |   1 +
 lib/uuid.c         |  33 ++++
 9 files changed, 944 insertions(+), 79 deletions(-)  create mode
100644 doc/README.gpt.mtd
Quoted 6 lines
General comments:
- use 'U-Boot' consistently rather than variations
- can you split your large function up a bit?
- can you make a precursor patch to refactor things, so reducing the size of this one?
Yes, I will do this split in v2 to reduce each patch size:
- one patch to uuid new function
- one precursor for efi part : refactor
- one patch for GPT over MTD in part_efi.c
& I will split large function
- one patch for each command update
Quoted 24 lines
- nice README!
Quoted 10 lines
Kconfig +1 -0
index 1263d0b..c2388e1 100644
@@ -335,6 +335,18 @@ config ARCH_FIXUP_FDT
 
 endmenu                # Boot images
 
+config EFI_PARTITION_MTD
Kconfig config ARCH_FIXUP_FDT · line 348
Quoted 10 lines
Kconfig +10 -0
+       bool "Support GPT over MTD"
+       help
+         The GPT partition is normally defined only for block device with
+         built-in controller which manage flash translation layer
+         This option activate the GPT partition support over RAW device
+         using the MTD framework
+         - manage partition over MTD devices (as flash: NOR and NAND)
+         - extract MTD information
+         - update command gpt, mtdparts and part
+         NB: depends on EFI_PARTITION
So do you want 'depends on EFI_PARTITION'?
Quoted 7 lines
Quoted 5 lines
Yes I expect it, I try to add
depends on EFI_PARTITION
but is not working as it is not (yet ?) one KCONFIG option. I add this comment to add this line when part lib will integrate KCONFIG
I see. Well if you have the energy you could use moveconfig.py to convert

Quoted 8 lines

it.
I will try to propose something (first usage of moveconfig.py script...) if I have no issue with cross-compilation
=> Create "disk/Kconfig" with PARTITIONS all associated option (MAC_PARTITION, DOS_PARTITION, ISO_PARTITION, AMIGA_PARTITION, EFI_PARTITION)

I push today the proposed patch for move disk to Kconfig in mailing list (after some issue for target with SPL) And I will rebase this RFC for GPT over MTD only when I will really push it on master branch.

Quoted 4 lines

Quoted 4 lines
Regards,
Simon

Regards Patrick

Patrick Delaunay

author

2016-11-22 13:24 UTC #7 lore raw

RFC PATCH 2/3 uuid: remove dependency with io.h

In reply to Patrick Delaunay

From: Patrick Delaunay <[email protected]>

io.h is only used for CONFIG_RANDOM_UUID
- for clrsetbits_be16
- for clrsetbits_8
available only for some target (but not for SANDBOX)

Signed-off-by Patrick Delaunay <[email protected]>

---

 lib/uuid.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

lib/uuid.c +6 -7

index eb8d8eb..47646e3 100644
@@ -8,7 +8,6 @@
 #include <linux/ctype.h>
 #include <errno.h>
 #include <common.h>
-#include <asm/io.h>
 #include <part_efi.h>
 #include <malloc.h>

@@ -276,13 +275,13 @@ void gen_rand_uuid(unsigned char *uuid_bin)
 	for (i = 0; i < sizeof(struct uuid) / sizeof(*ptr); i++)
 		*(ptr + i) = cpu_to_be32(rand());
 
-	clrsetbits_be16(&uuid.time_hi_and_version,
-			UUID_VERSION_MASK,
-			UUID_VERSION << UUID_VERSION_SHIFT);
+	/* UUID is big endian */
+	uuid.time_hi_and_version |= ~cpu_to_be16(UUID_VERSION_MASK);
+	uuid.time_hi_and_version &=
+		cpu_to_be16(UUID_VERSION << UUID_VERSION_SHIFT);
 
-	clrsetbits_8(&uuid.clock_seq_hi_and_reserved,
-		     UUID_VARIANT_MASK,
-		     UUID_VARIANT << UUID_VARIANT_SHIFT);
+	uuid.clock_seq_hi_and_reserved |= ~UUID_VARIANT_MASK;
+	uuid.clock_seq_hi_and_reserved &= UUID_VARIANT << UUID_VARIANT_SHIFT;
 
 	memcpy(uuid_bin, &uuid, sizeof(struct uuid));
 }

Signature · 1 line

1.9.1

Patrick Delaunay

author

2016-11-22 13:24 UTC #8 lore raw

RFC PATCH 3/3 sandbox: GPT over MTD test

In reply to Patrick Delaunay

From: Patrick Delaunay <[email protected]>

activate needed feature in sandbox to allow test GPT over MTD
- EFI_PARTITION_MTD
- SPI_FLASH_MTD
- CMD_MTDPARTS
- MTD_PARTITIONS
- MTD_DEVICE

activate 2 features useful for test
- RANDOM_UUID
- PARTITION_TYPE_GUID

Signed-off-by Patrick Delaunay <[email protected]>

---

 configs/sandbox_defconfig | 2 ++
 include/configs/sandbox.h | 7 +++++++
 2 files changed, 9 insertions(+)

configs/sandbox_defconfig +2 -0

index 380d4fe..1ba8d2a 100644
@@ -5,6 +5,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_EFI_PARTITION_MTD=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_BOOTSTAGE_USER_COUNT=0x20

@@ -110,6 +111,7 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_MTD=y
 CONFIG_DM_ETH=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y

include/configs/sandbox.h +7 -0

index 2daf02d..66707e3 100644
@@ -49,13 +49,20 @@
 #define CONFIG_CMD_MD5SUM
 
 #define CONFIG_CMD_GPT
+#define CONFIG_RANDOM_UUID
 #define CONFIG_PARTITION_UUIDS
+#define CONFIG_PARTITION_TYPE_GUID
 #define CONFIG_AMIGA_PARTITION
 #define CONFIG_DOS_PARTITION
 #define CONFIG_EFI_PARTITION
 #define CONFIG_ISO_PARTITION
 #define CONFIG_MAC_PARTITION
 
+/* Dynamic MTD partition support */
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_MTD_PARTITIONS
+#define CONFIG_MTD_DEVICE
+
 /*
  * Size of malloc() pool, before and after relocation
  */

Signature · 1 line

1.9.1

Ladislav Michl

2016-11-22 14:57 UTC #9 lore raw

cover GPT over MTD

In reply to Patrick Delaunay

Hi,

Quoted 4 lines · Patrick Delaunay

I have a request to support GPT over MTD to be able to have dynamic MTD informations without u-Boot environment(CONFIG_ENV_IS_NOWHERE is a other requirement of my project).

I'm just curious, could you provide some reasoning, why this is a requirement?

Quoted 3 lines

The idea is to use the GPT header to save partitioning information directly in flash device (NOR or NAND), then the MTD variables are rebuild from these GPT partitions and can be used by DISTRO to search bootable binary.

Ok, so you stored partitioning information on flash... That seems to be some kind of limited environment saved :-)

Quoted 4 lines

I make a first prototyping for this request but I want ask you if this feature is acceptable for u-boot and if this patches, after some update and cleanups, would be merged in u-boot mainline.
Do you see already some blocking points ?

Is there any reason why you cannot use UBI?

Quoted 10 lines

- added code is under a new CONFIG : CONFIG_EFI_PARTITION_MTD
- for implementation details, see doc/README.gpt.mtd
TODO:
- split patch between core impact (disk/part_efi.c)
and command update
- full support for modified command
(today I limit the support for the command used by DISTRO macro)
- DISTRO macro update for automatic boot on GPT bootable partition found in MTD devices

Best regards,
ladis

Patrick DELAUNAY

2016-11-24 14:14 UTC #10 lore raw

cover GPT over MTD

Hi Ladislav,

Quoted 5 lines

Hi,
Quoted 1 line · Patrick Delaunay

Quoted 7 lines

Quoted 2 lines
I have a request to support GPT over MTD to be able to have dynamic MTD informations without u-Boot
environment(CONFIG_ENV_IS_NOWHERE is a
Quoted 1 line
other requirement of my project).
I'm just curious, could you provide some reasoning, why this is a requirement?

One platform requirement is to boot from any supported device (NOR, NAND, eMMC, ...) with the same boot chain (including SPL and U-Boot) WITHOUT recompilation and only by changing the hardware boot configuration (OTP).

So I can't use environment (CONFIG_ENV_IS_NOWHERE), because I don't know which device is expected for tests (boot from NAND, eMMC, NOR).
PS: I agree that in final client board, the u-boot will be optimized and u-boot env could be used.

For block device(eMMC), it is not an issue
- first boot stage uses the GPT header in block device, to found, load and execute SPL and U-Boot.
- U-Boot Generic Distro feature is used in U-Boot to load kernel (found extlinux.conf in bootable partition)

For Flash Device, the offset for SPL and U-Boot can't be determined easily by first boot stage.
It is why GPT is re-used to save MTD partition offset without hardcoded part in first boot stage or in SPL (and without U-Boot env). => partition offsets are determined dynamically

So it should be easier to have the same behavior, based on GPT, for every boot device, block or flash. And the same tools (programmer) or command in U-Boot will use to update/read every device, based on GPT header.

Quoted 7 lines

Quoted 3 lines
The idea is to use the GPT header to save partitioning information directly in flash device (NOR or NAND), then the MTD variables are rebuild from these GPT partitions and can be used by DISTRO to search
bootable binary.
Ok, so you stored partitioning information on flash... That seems to be some kind of limited environment saved :-)

Yes I use standard GPT to save partitioning information, to save offset of MTD partition in flash device. So it is limited environment :-) but limited to partition offset and it can be discovered dynamically by first boot stage.

Quoted 6 lines

Quoted 4 lines
I make a first prototyping for this request but I want ask you if this feature is acceptable for u-boot and if this patches, after some update and cleanups, would be merged in u-boot mainline.
Do you see already some blocking points ?
Is there any reason why you cannot use UBI?

UBIFS will be used in U-Boot not in previous boot stage Kernel and device tree will be found in a UBIFS volume

Quoted 11 lines

Quoted 10 lines
- added code is under a new CONFIG : CONFIG_EFI_PARTITION_MTD
- for implementation details, see doc/README.gpt.mtd
TODO:
- split patch between core impact (disk/part_efi.c)
and command update
- full support for modified command
(today I limit the support for the command used by DISTRO macro)
- DISTRO macro update for automatic boot on GPT bootable partition found in MTD devices

Quoted 2 lines

Best regards,
ladis

Best regards
Patrick

Ladislav Michl

2016-11-25 12:21 UTC #11 lore raw

cover GPT over MTD

Hi Patrick,

Quoted 9 lines · Patrick DELAUNAY

Hi Ladislav,
Quoted 7 lines
Hi,
Quoted 3 lines · Patrick Delaunay
I have a request to support GPT over MTD to be able to have dynamic MTD informations without u-Boot

Quoted 7 lines

Quoted 5 lines
environment(CONFIG_ENV_IS_NOWHERE is a
Quoted 1 line
other requirement of my project).
I'm just curious, could you provide some reasoning, why this is a requirement?
One platform requirement is to boot from any supported device (NOR, NAND, eMMC, ...) with the same boot chain (including SPL and U-Boot) WITHOUT recompilation and only by changing the hardware boot configuration (OTP).

Ok, the very same requirement here...

Quoted 8 lines

So I can't use environment (CONFIG_ENV_IS_NOWHERE), because I don't know which device is expected for tests (boot from NAND, eMMC, NOR).
PS: I agree that in final client board, the u-boot will be optimized and u-boot env could be used.
For block device(eMMC), it is not an issue
- first boot stage uses the GPT header in block device, to found, load and execute SPL and U-Boot.
- U-Boot Generic Distro feature is used in U-Boot to load kernel (found extlinux.conf in bootable partition)
For Flash Device, the offset for SPL and U-Boot can't be determined easily by first boot stage.

Offset of SPL? Isn't that determined by boot ROM code? So you actually cannot do much with that. What hardware are you planning to use your solution with?

Quoted 2 lines

It is why GPT is re-used to save MTD partition offset without hardcoded part in first boot stage or in SPL (and without U-Boot env). => partition offsets are determined dynamically

As SPL offset is given and only U-Boot offset can be changed (is that assumption right?), you can store U-Boot in UBI volume.

Quoted 2 lines

So it should be easier to have the same behavior, based on GPT, for every boot device, block or flash. And the same tools (programmer) or command in U-Boot will use to update/read every device, based on GPT header.

I have to admit, that UBI solution would not let you use the same scenario for eMMC and NAND in terms of U-Boot commands used, but otherwise it is more robust.

Quoted 10 lines

Quoted 7 lines
Quoted 3 lines
The idea is to use the GPT header to save partitioning information directly in flash device (NOR or NAND), then the MTD variables are rebuild from these GPT partitions and can be used by DISTRO to search
bootable binary.
Ok, so you stored partitioning information on flash... That seems to be some kind of limited environment saved :-)
Yes I use standard GPT to save partitioning information, to save offset of MTD partition in flash device. So it is limited environment :-) but limited to partition offset and it can be discovered dynamically by first boot stage.

First boot stage is SPL here?

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
I make a first prototyping for this request but I want ask you if this feature is acceptable for u-boot and if this patches, after some update and cleanups, would be merged in u-boot mainline.
Do you see already some blocking points ?
Is there any reason why you cannot use UBI?
UBIFS will be used in U-Boot not in previous boot stage

Just to make it completely clear: UBIFS is a filesystem used on the top of UBI volume...

Quoted 1 line

Kernel and device tree will be found in a UBIFS volume

...so kernel and DTB are stored as a files inside UBIFS (filesystem)?

Both SPL and U-Boot can load images from UBI volumes. Also you'll get Falcon mode for free :-)

Best regards,
ladis

Patrick DELAUNAY

2016-11-28 15:02 UTC #12 lore raw

cover GPT over MTD

Hi Ladislav,

Quoted 37 lines

Hi Patrick,
Quoted 9 lines · Patrick DELAUNAY
Hi Ladislav,
Quoted 7 lines
Hi,
Quoted 3 lines · Patrick Delaunay
I have a request to support GPT over MTD to be able to have dynamic MTD informations without u-Boot
Quoted 7 lines
Quoted 5 lines
environment(CONFIG_ENV_IS_NOWHERE is a
Quoted 1 line
other requirement of my project).
I'm just curious, could you provide some reasoning, why this is a requirement?
One platform requirement is to boot from any supported device (NOR,
NAND, eMMC, ...) with the same boot chain (including SPL and U-Boot) WITHOUT recompilation and only by changing the hardware boot configuration (OTP).
Ok, the very same requirement here...
Quoted 1 line
So I can't use environment (CONFIG_ENV_IS_NOWHERE), because I don't
know which device is expected for tests (boot from NAND, eMMC, NOR).
Quoted 1 line
PS: I agree that in final client board, the u-boot will be optimized and u-
boot env could be used.
Quoted 3 lines
For block device(eMMC), it is not an issue
- first boot stage uses the GPT header in block device, to found, load
and execute SPL and U-Boot.
Quoted 3 lines
- U-Boot Generic Distro feature is used in U-Boot to
load kernel (found extlinux.conf in bootable partition)

Quoted 6 lines

Quoted 1 line
For Flash Device, the offset for SPL and U-Boot can't be determined easily
by first boot stage.
Offset of SPL? Isn't that determined by boot ROM code? So you actually cannot do much with that. What hardware are you planning to use your solution with?

Not necessarily, we may have a first stage boot loader (let's say ARM Trusted Firmware) loaded by the ROM code before SPL execution. Then SPL is executed as plugin, without Flash driver only to initialize DDR (as FEL for sunxi platform or bootrom plugin for mvebu) The HW used is a board based on the STMicroelectronics 96Board with STiH410 soc (ARM core).

Quoted 7 lines

Quoted 1 line
It is why GPT is re-used to save MTD partition offset without hardcoded
part in first boot stage or in SPL (and without U-Boot env).
Quoted 1 line
=> partition offsets are determined dynamically
As SPL offset is given and only U-Boot offset can be changed (is that assumption right?), you can store U-Boot in UBI volume.

With SPL executed as plugin, U-Boot is loaded by first boot loader, which support GPT but not UBI...

Quoted 18 lines

Quoted 1 line
So it should be easier to have the same behavior, based on GPT, for every
boot device, block or flash.
Quoted 1 line
And the same tools (programmer) or command in U-Boot will use to
update/read every device, based on GPT header.
I have to admit, that UBI solution would not let you use the same scenario for eMMC and NAND in terms of U-Boot commands used, but otherwise it is more robust.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
The idea is to use the GPT header to save partitioning information directly in flash device (NOR or NAND), then the MTD variables are rebuild from these GPT partitions and can be used by DISTRO to search
bootable binary.
Ok, so you stored partitioning information on flash... That seems to be some kind of limited environment saved :-)

Quoted 6 lines

Quoted 1 line
Yes I use standard GPT to save partitioning information, to save offset of
MTD partition in flash device.
Quoted 1 line
So it is limited environment :-) but limited to partition offset and it can be
discovered dynamically by first boot stage.
First boot stage is SPL here?

Not necessary, SPL is loaded and executed as plugin by first boot stage...

Quoted 13 lines

Quoted 9 lines
Quoted 7 lines
Quoted 5 lines
I make a first prototyping for this request but I want ask you if this feature is acceptable for u-boot and if this patches, after some update and cleanups, would be merged in u-boot mainline. Do you see already some blocking points ?
Is there any reason why you cannot use UBI?
UBIFS will be used in U-Boot not in previous boot stage
Just to make it completely clear: UBIFS is a filesystem used on the top of UBI volume...

Quoted 6 lines

Quoted 1 line
Kernel and device tree will be found in a UBIFS volume
...so kernel and DTB are stored as a files inside UBIFS (filesystem)?
Both SPL and U-Boot can load images from UBI volumes. Also you'll get Falcon mode for free :-)

In our case, when SPL is loaded as plugin, without file system and flash driver support, the FALCON mode is not possible :-<

The expected Flash layout is

MTD partition1 => First Boot stage (with Flash driver / GPT support) MTD partition2 => U-Boot SPL (only DDR init)
MTD partition3 => U-Boot (UBI / UBIFS stage)
MTD partition4 => UBI (several volume : boot, kernel used by u-boot)

- First boot stage is loaded by ROM in internal RAM
- SPL is loaded as plugin to initialize DDR
- Uboot is loaded in DDR by First Boot Stage / found UBI volume

=> my issue is : how to found MTD offset if they are not hardcoded in U-Boot and First Boot Stage ?

Quoted 2 lines

Best regards,
ladis

Best Regards
Patrick