Skip to contentSkip to conversation

sunxi: Ease eMMC usage and flashing

PATCH New Maxime Ripard 3 participants 17 messages Nov 28, 2017 – Nov 30, 2017 Arm/Allwinner sunXi SoC support

lore
Share & tools
lore
#0 lore raw

cover sunxi: Ease eMMC usage and flashing

Hi,

Here is a set of patches that have been sitting in some variations for quite some time now.

This is mostly to ease the eMMC (and MMC, to some extent) flashing using fastboot that in turn rely on GPT.

The Allwinner SoCs need to have the SPL located right in the middle of a traditional GPT, at 8kB.

To deal with this, we would basically have two options:
- Use the already in-tree solution to move the partition entries to another arbitrary offset in the MMC.
- Use a smaller number of partitions entries

Both are non-standards, but are dealt with nicely by the regular tools and users (at least on a Linux system). However, the first solution is quite confusing for users (that needs to be aware where the partitions will be), might be less flexible because not all tools will allow to create partitions for things between the GPT main entry and the partition entries, and might confuse tools if such a setup is available.

In our case, using the first solution, gdisk will for example refuse to create a partition for the SPL.

The second solution though seems to be well handled by all the tools, and just feels the same, except that you end up with a smaller number of partitions. In our case, that number is 56 partitions (16 sectors before the SPL, 1 sector for the protective MBR, 1 sector for the GPT header, and 4 partition entries per sector) instead of 128, which doesn't sound very impractical either.

The two first patches deal with that.

We then provide a default partitionning scheme. I'd like feedback on that one. I appreciate that having a good default in such a case, but I'd like to have a reasonably simple layout that works good enough to install a distro. I'm a bit short on background on what an EFI partition is supposed to look like, and what a good size would be. I'd really like some input on this.

Finally, we enable fastboot flashing to be able to flash a pristine system just by using FEL, fastboot oem format, and then fastboot flash for the various components.

Let me know what you think,
Maxime

Changes from v1:
- Changed the boot partition name to ESP
- Used default UUID for the rootfs and esp partitions

Maxime Ripard (4):
part: efi: Add a Kconfig option for the number of partition entries
part: efi: Add default number of partition entries for sunxi
sunxi: Add default partition scheme
fastboot: Enable flashing by default on sunxi

 cmd/fastboot/Kconfig           |  1 +
 disk/Kconfig                   | 14 ++++++++++++++
 include/configs/sunxi-common.h |  9 +++++++++
 include/part_efi.h             |  2 +-
 4 files changed, 25 insertions(+), 1 deletion(-)

base-commit: c253573f3e269fd9a24ee6684d87dd91106018a5

Signature · 1 line
git-series 0.9.1
#1 lore raw

PATCH 1/4 part: efi: Add a Kconfig option for the number of partition entries

On some SoCs, the SPL needs to be located right in the middle of the GPT partition entries.

One way to work around that is to create partition entries for a smaller number of partitions to accomodate with where the SPL will be. Create a Kconfig option to allow to do that.

---
 disk/Kconfig       | 13 +++++++++++++
 include/part_efi.h |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)
disk/Kconfig +13 -0
index 939656212065..f82beef6e689 100644
@@ -78,6 +78,19 @@ config EFI_PARTITION
 	  common when EFI is the bootloader.  Note 2TB partition limit;
 	  see disk/part_efi.c
 
+config EFI_PARTITION_ENTRIES_NUMBERS
+	int "Number of the EFI partition entries"
+	depends on EFI_PARTITION
+	default 128
+	help
+	  Specify the number of partition entries in the GPT. This is
+	  meant to allow less than the standard specifies for devices
+	  that might need to place their first-stage bootloader in the
+	  middle of a regular GPT.
+
+	  If unsure, leave at 128 entries, which is the standard
+	  number.
+
 config EFI_PARTITION_ENTRIES_OFF
         int "Offset (in bytes) of the EFI partition entries"
 	depends on EFI_PARTITION
include/part_efi.h +1 -1
index 31e6bc6e140f..4c8f6cc473c8 100644
@@ -27,7 +27,7 @@
 #define GPT_HEADER_SIGNATURE 0x5452415020494645ULL
 #define GPT_HEADER_REVISION_V1 0x00010000
 #define GPT_PRIMARY_PARTITION_TABLE_LBA 1ULL
-#define GPT_ENTRY_NUMBERS		128
+#define GPT_ENTRY_NUMBERS		CONFIG_EFI_PARTITION_ENTRIES_NUMBERS
 #define GPT_ENTRY_SIZE			128
 
 #define PARTITION_SYSTEM_GUID \
Signature · 1 line
git-series 0.9.1
#2 lore raw

PATCH 1/4 part: efi: Add a Kconfig option for the number of partition entries

Quoted 8 lines · Maxime Ripard

On some SoCs, the SPL needs to be located right in the middle of the GPT partition entries.

One way to work around that is to create partition entries for a smaller number of partitions to accomodate with where the SPL will be. Create a Kconfig option to allow to do that.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171128/c9d0831a/attachment.sig>
#3 lore raw

PATCH 1/4 part: efi: Add a Kconfig option for the number of partition entries

In reply to Maxime Ripard
Quoted 8 lines · Maxime Ripard

On some SoCs, the SPL needs to be located right in the middle of the GPT partition entries.

One way to work around that is to create partition entries for a smaller number of partitions to accomodate with where the SPL will be. Create a Kconfig option to allow to do that.

Thanks,
Andre.

Quoted 43 lines
---
 disk/Kconfig       | 13 +++++++++++++
 include/part_efi.h |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)
disk/Kconfig +13 -0
index 939656212065..f82beef6e689 100644
@@ -78,6 +78,19 @@ config EFI_PARTITION
 	  common when EFI is the bootloader.  Note 2TB partition limit;
 	  see disk/part_efi.c
 
+config EFI_PARTITION_ENTRIES_NUMBERS
+	int "Number of the EFI partition entries"
+	depends on EFI_PARTITION
+	default 128
+	help
+	  Specify the number of partition entries in the GPT. This is
+	  meant to allow less than the standard specifies for devices
+	  that might need to place their first-stage bootloader in the
+	  middle of a regular GPT.
+
+	  If unsure, leave at 128 entries, which is the standard
+	  number.
+
 config EFI_PARTITION_ENTRIES_OFF
         int "Offset (in bytes) of the EFI partition entries"
 	depends on EFI_PARTITION
include/part_efi.h +1 -1
index 31e6bc6e140f..4c8f6cc473c8 100644
@@ -27,7 +27,7 @@
 #define GPT_HEADER_SIGNATURE 0x5452415020494645ULL
 #define GPT_HEADER_REVISION_V1 0x00010000
 #define GPT_PRIMARY_PARTITION_TABLE_LBA 1ULL
-#define GPT_ENTRY_NUMBERS		128
+#define GPT_ENTRY_NUMBERS		CONFIG_EFI_PARTITION_ENTRIES_NUMBERS
 #define GPT_ENTRY_SIZE			128
 
 #define PARTITION_SYSTEM_GUID \
#4 lore raw

PATCH 2/4 part: efi: Add default number of partition entries for sunxi

In reply to Maxime Ripard

The SPL must be located at 8kB (16 sectors) offset. That's right in the middle of the GPT, so we need to define a smaller amount of partitions to accomodate for that location.

---
 disk/Kconfig | 1 +
 1 file changed, 1 insertion(+)
disk/Kconfig +1 -0
index f82beef6e689..0446bb63ca7e 100644
@@ -81,6 +81,7 @@ config EFI_PARTITION
 config EFI_PARTITION_ENTRIES_NUMBERS
 	int "Number of the EFI partition entries"
 	depends on EFI_PARTITION
+	default 56 if ARCH_SUNXI
 	default 128
 	help
 	  Specify the number of partition entries in the GPT. This is
Signature · 1 line
git-series 0.9.1
#5 lore raw

PATCH 2/4 part: efi: Add default number of partition entries for sunxi

Quoted 5 lines · Maxime Ripard

The SPL must be located at 8kB (16 sectors) offset. That's right in the middle of the GPT, so we need to define a smaller amount of partitions to accomodate for that location.

The math is correct ;-)

Thanks!
Andre

Quoted 17 lines
---
 disk/Kconfig | 1 +
 1 file changed, 1 insertion(+)
disk/Kconfig +1 -0
index f82beef6e689..0446bb63ca7e 100644
@@ -81,6 +81,7 @@ config EFI_PARTITION
 config EFI_PARTITION_ENTRIES_NUMBERS
 	int "Number of the EFI partition entries"
 	depends on EFI_PARTITION
+	default 56 if ARCH_SUNXI
 	default 128
 	help
 	  Specify the number of partition entries in the GPT. This is
#6 lore raw

PATCH 3/4 sunxi: Add default partition scheme

In reply to Maxime Ripard

The partitions variable is especially useful to create a partition table from U-Boot, either directly from the U-Boot shell, or through flashing tools like fastboot and its oem format command.

This is especially useful on devices with an eMMC you can't take out to flash from another system, and booting a Linux system first to flash our system then is not really practical.

---
 include/configs/sunxi-common.h |  9 +++++++++
 1 file changed, 9 insertions(+)
include/configs/sunxi-common.h +9 -0
index 4391a8cbc824..c9214a709221 100644
@@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
 #define SUNXI_MTDPARTS_DEFAULT
 #endif
 
+#define PARTS_DEFAULT \
+	"name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};" \
+	"name=loader2,size=984k,uuid=${uuid_gpt_loader2};" \
+	"name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};" \
+	"name=system,size=-,uuid=${uuid_gpt_system};"
+
 #define CONSOLE_ENV_SETTINGS \
 	CONSOLE_STDIN_SETTINGS \
 	CONSOLE_STDOUT_SETTINGS
@@ -511,6 +517,9 @@ extern int soft_i2c_gpio_scl;
 	"console=ttyS0,115200\0" \
 	SUNXI_MTDIDS_DEFAULT \
 	SUNXI_MTDPARTS_DEFAULT \
+	"uuid_gpt_esp=C12A7328-F81F-11D2-BA4B-00A0C93EC93B\0" \
+	"uuid_gpt_system=0FC63DAF-8483-4772-8E79-3D69D8477DE4\0" \
+	"partitions=" PARTS_DEFAULT "\0" \
 	BOOTCMD_SUNXI_COMPAT \
 	BOOTENV
 
Signature · 1 line
git-series 0.9.1
#7 lore raw

PATCH 3/4 sunxi: Add default partition scheme

Hi Maxime,

Quoted 18 lines · Maxime Ripard

The partitions variable is especially useful to create a partition table from U-Boot, either directly from the U-Boot shell, or through flashing tools like fastboot and its oem format command.

This is especially useful on devices with an eMMC you can't take out to flash from another system, and booting a Linux system first to flash our system then is not really practical.

---
 include/configs/sunxi-common.h |  9 +++++++++
 1 file changed, 9 insertions(+)
include/configs/sunxi-common.h +0 -0
index 4391a8cbc824..c9214a709221 100644

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 499

Quoted 7 lines
include/configs/sunxi-common.h +4 -0
@@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
 #define SUNXI_MTDPARTS_DEFAULT
 #endif
 
+#define PARTS_DEFAULT \
+	"name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};" \
+	"name=loader2,size=984k,uuid=${uuid_gpt_loader2};" \
+	"name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};" \

Those numbers look right to me, but I can't find the definition of uuid_gpt_loader{1,2} in U-Boot. Only I see them referenced by some rockchip header.
Is there some magic definition I missed or do we actually need to add them? I guess you are after the Android-IA bootloader UUIDs from the Wikipedia page, starting with 2568845D- and 114EAFFE-?

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 500

Quoted 1 line
include/configs/sunxi-common.h +1 -0
+	"name=system,size=-,uuid=${uuid_gpt_system};"

So does fastboot require a system partition? And it wouldn't know where to put the rootfs to without one?
In this case I guess it's fine, because it fits the use case. But otherwise (as mentioned before) one giant partition to fill the rest of the "disk" is more annoying than helpful for regular Linux installers.

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 521

Quoted 10 lines
include/configs/sunxi-common.h +3 -0
+
 #define CONSOLE_ENV_SETTINGS \
 	CONSOLE_STDIN_SETTINGS \
 	CONSOLE_STDOUT_SETTINGS
@@ -511,6 +517,9 @@ extern int soft_i2c_gpio_scl;
 	"console=ttyS0,115200\0" \
 	SUNXI_MTDIDS_DEFAULT \
 	SUNXI_MTDPARTS_DEFAULT \
+	"uuid_gpt_esp=C12A7328-F81F-11D2-BA4B-00A0C93EC93B\0" \
+	"uuid_gpt_system=0FC63DAF-8483-4772-8E79-3D69D8477DE4\0" \

The ESP GUID is correct, the other is "Linux filesystem data", right? Technically I guess root partition would be more suitable, but we would need to know whether it's AArch64 or ARM, if I get this correctly. Shall we use #ifdef CONFIG_ARM64 here?

Cheers,
Andre.

Quoted 5 lines
include/configs/sunxi-common.h +1 -0
+	"partitions=" PARTS_DEFAULT "\0" \
 	BOOTCMD_SUNXI_COMPAT \
 	BOOTENV
 
#8 lore raw

PATCH 3/4 sunxi: Add default partition scheme

Hi,

Quoted 24 lines · André Przywara

Hi Maxime,

Quoted 21 lines · Maxime Ripard

The partitions variable is especially useful to create a partition table from U-Boot, either directly from the U-Boot shell, or through flashing tools like fastboot and its oem format command.

This is especially useful on devices with an eMMC you can't take out to flash from another system, and booting a Linux system first to flash our system then is not really practical.

---
 include/configs/sunxi-common.h |  9 +++++++++
 1 file changed, 9 insertions(+)
include/configs/sunxi-common.h +0 -0
index 4391a8cbc824..c9214a709221 100644
@@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
 #define SUNXI_MTDPARTS_DEFAULT
 #endif
 
Quoted 11 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 499

Quoted 4 lines
include/configs/sunxi-common.h +4 -0
+#define PARTS_DEFAULT \
+	"name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};" \
+	"name=loader2,size=984k,uuid=${uuid_gpt_loader2};" \
+	"name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};" \

Those numbers look right to me, but I can't find the definition of uuid_gpt_loader{1,2} in U-Boot. Only I see them referenced by some rockchip header.
Is there some magic definition I missed or do we actually need to add them? I guess you are after the Android-IA bootloader UUIDs from the Wikipedia page, starting with 2568845D- and 114EAFFE-?

The fact that they have been left out is intentional. Without a UUID defined, U-Boot will generate a random one if you have CONFIG_RANDOM_UUID set. That kind of construct allow you to specifiy a UUID if you want, without modifying the partitions variable.

I'm totally fine with having a default one though. I just couldn't find one that would be relevant, so I left it out.

Quoted 7 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 500

Quoted 1 line
include/configs/sunxi-common.h +1 -0
+	"name=system,size=-,uuid=${uuid_gpt_system};"

So does fastboot require a system partition? And it wouldn't know where to put the rootfs to without one?
In this case I guess it's fine, because it fits the use case. But otherwise (as mentioned before) one giant partition to fill the rest of the "disk" is more annoying than helpful for regular Linux installers.

So fasboot is dumber than you assume it to be ;)

The only thing you do is giving it a file and a partition. So yeah, you would need to have a partition defined for that.

Quoted 7 lines
Quoted 7 lines
include/configs/sunxi-common.h +1 -0
+
 #define CONSOLE_ENV_SETTINGS \
 	CONSOLE_STDIN_SETTINGS \
 	CONSOLE_STDOUT_SETTINGS
@@ -511,6 +517,9 @@ extern int soft_i2c_gpio_scl;
 	"console=ttyS0,115200\0" \
 	SUNXI_MTDIDS_DEFAULT \
Quoted 8 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 521

Quoted 3 lines
include/configs/sunxi-common.h +2 -0
 	SUNXI_MTDPARTS_DEFAULT \
+	"uuid_gpt_esp=C12A7328-F81F-11D2-BA4B-00A0C93EC93B\0" \
+	"uuid_gpt_system=0FC63DAF-8483-4772-8E79-3D69D8477DE4\0" \

The ESP GUID is correct, the other is "Linux filesystem data", right? Technically I guess root partition would be more suitable, but we would need to know whether it's AArch64 or ARM, if I get this correctly. Shall we use #ifdef CONFIG_ARM64 here?

We can, what UUID do you have in mind?

Maxime

Signature · 10 lines
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171130/7091c8b6/attachment-0001.sig>
#9 lore raw

PATCH 3/4 sunxi: Add default partition scheme

Hi,

Quoted 39 lines · Maxime Ripard

Hi,

Quoted 24 lines · André Przywara

Hi Maxime,

Quoted 21 lines · Maxime Ripard

The partitions variable is especially useful to create a partition table from U-Boot, either directly from the U-Boot shell, or through flashing tools like fastboot and its oem format command.

This is especially useful on devices with an eMMC you can't take out to flash from another system, and booting a Linux system first to flash our system then is not really practical.

---
 include/configs/sunxi-common.h |  9 +++++++++
 1 file changed, 9 insertions(+)
include/configs/sunxi-common.h +0 -0
index 4391a8cbc824..c9214a709221 100644
@@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
 #define SUNXI_MTDPARTS_DEFAULT
 #endif
 
Quoted 11 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 499

Quoted 4 lines
include/configs/sunxi-common.h +4 -0
+#define PARTS_DEFAULT \
+	"name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};" \
+	"name=loader2,size=984k,uuid=${uuid_gpt_loader2};" \
+	"name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};" \

Those numbers look right to me, but I can't find the definition of uuid_gpt_loader{1,2} in U-Boot. Only I see them referenced by some rockchip header.
Is there some magic definition I missed or do we actually need to add them? I guess you are after the Android-IA bootloader UUIDs from the Wikipedia page, starting with 2568845D- and 114EAFFE-?

Quoted 4 lines

The fact that they have been left out is intentional. Without a UUID defined, U-Boot will generate a random one if you have CONFIG_RANDOM_UUID set. That kind of construct allow you to specifiy a UUID if you want, without modifying the partitions variable.

Ah, thanks for the explanation, I was afraid I missed something.

Quoted 2 lines

I'm totally fine with having a default one though. I just couldn't find one that would be relevant, so I left it out.

I guess this is fine. Wikipedia[1] points me to Android-IA having specified two UUIDs for boot loader partitions here [2], but I don't think they are really authoritative.

Quoted 29 lines
Quoted 7 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 500

Quoted 1 line
include/configs/sunxi-common.h +1 -0
+	"name=system,size=-,uuid=${uuid_gpt_system};"

So does fastboot require a system partition? And it wouldn't know where to put the rootfs to without one?
In this case I guess it's fine, because it fits the use case. But otherwise (as mentioned before) one giant partition to fill the rest of the "disk" is more annoying than helpful for regular Linux installers.

So fasboot is dumber than you assume it to be ;)

The only thing you do is giving it a file and a partition. So yeah, you would need to have a partition defined for that.

Quoted 7 lines
Quoted 7 lines
include/configs/sunxi-common.h +1 -0
+
 #define CONSOLE_ENV_SETTINGS \
 	CONSOLE_STDIN_SETTINGS \
 	CONSOLE_STDOUT_SETTINGS
@@ -511,6 +517,9 @@ extern int soft_i2c_gpio_scl;
 	"console=ttyS0,115200\0" \
 	SUNXI_MTDIDS_DEFAULT \
Quoted 8 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 521

Quoted 3 lines
include/configs/sunxi-common.h +2 -0
 	SUNXI_MTDPARTS_DEFAULT \
+	"uuid_gpt_esp=C12A7328-F81F-11D2-BA4B-00A0C93EC93B\0" \
+	"uuid_gpt_system=0FC63DAF-8483-4772-8E79-3D69D8477DE4\0" \

The ESP GUID is correct, the other is "Linux filesystem data", right? Technically I guess root partition would be more suitable, but we would need to know whether it's AArch64 or ARM, if I get this correctly. Shall we use #ifdef CONFIG_ARM64 here?

Quoted 1 line

We can, what UUID do you have in mind?

FreeDesktop [3] seems to define some UUIDs for Linux root partitions, separated by architectures, and it lists ARM and AArch64.

Cheers,
Andre.

[1] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
[2]
https://github.com/android-ia/device-androidia-mixins/blob/master/groups/boot-arch/android_ia/gpt.ini
[3]
https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/

#10 lore raw

PATCH 3/4 sunxi: Add default partition scheme

Quoted 47 lines · Andre Przywara

Hi,

Quoted 39 lines · Maxime Ripard

Hi,

Quoted 24 lines · André Przywara

Hi Maxime,

Quoted 21 lines · Maxime Ripard

The partitions variable is especially useful to create a partition table from U-Boot, either directly from the U-Boot shell, or through flashing tools like fastboot and its oem format command.

This is especially useful on devices with an eMMC you can't take out to flash from another system, and booting a Linux system first to flash our system then is not really practical.

---
 include/configs/sunxi-common.h |  9 +++++++++
 1 file changed, 9 insertions(+)
include/configs/sunxi-common.h +0 -0
index 4391a8cbc824..c9214a709221 100644
@@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
 #define SUNXI_MTDPARTS_DEFAULT
 #endif
 
Quoted 11 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 499

Quoted 4 lines
include/configs/sunxi-common.h +4 -0
+#define PARTS_DEFAULT \
+	"name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};" \
+	"name=loader2,size=984k,uuid=${uuid_gpt_loader2};" \
+	"name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};" \

Those numbers look right to me, but I can't find the definition of uuid_gpt_loader{1,2} in U-Boot. Only I see them referenced by some rockchip header.
Is there some magic definition I missed or do we actually need to add them? I guess you are after the Android-IA bootloader UUIDs from the Wikipedia page, starting with 2568845D- and 114EAFFE-?

Quoted 4 lines

The fact that they have been left out is intentional. Without a UUID defined, U-Boot will generate a random one if you have CONFIG_RANDOM_UUID set. That kind of construct allow you to specifiy a UUID if you want, without modifying the partitions variable.

Quoted 8 lines

Ah, thanks for the explanation, I was afraid I missed something.

Quoted 2 lines

I'm totally fine with having a default one though. I just couldn't find one that would be relevant, so I left it out.

I guess this is fine. Wikipedia[1] points me to Android-IA having specified two UUIDs for boot loader partitions here [2], but I don't think they are really authoritative.

Yeah, I saw those as well, and came to the same conclusion :)

Quoted 29 lines
Quoted 29 lines
Quoted 7 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 500

Quoted 1 line
include/configs/sunxi-common.h +1 -0
+	"name=system,size=-,uuid=${uuid_gpt_system};"

So does fastboot require a system partition? And it wouldn't know where to put the rootfs to without one?
In this case I guess it's fine, because it fits the use case. But otherwise (as mentioned before) one giant partition to fill the rest of the "disk" is more annoying than helpful for regular Linux installers.

So fasboot is dumber than you assume it to be ;)

The only thing you do is giving it a file and a partition. So yeah, you would need to have a partition defined for that.

Quoted 15 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 521

Quoted 10 lines
include/configs/sunxi-common.h +3 -0
+
 #define CONSOLE_ENV_SETTINGS \
 	CONSOLE_STDIN_SETTINGS \
 	CONSOLE_STDOUT_SETTINGS
@@ -511,6 +517,9 @@ extern int soft_i2c_gpio_scl;
 	"console=ttyS0,115200\0" \
 	SUNXI_MTDIDS_DEFAULT \
 	SUNXI_MTDPARTS_DEFAULT \
+	"uuid_gpt_esp=C12A7328-F81F-11D2-BA4B-00A0C93EC93B\0" \
+	"uuid_gpt_system=0FC63DAF-8483-4772-8E79-3D69D8477DE4\0" \

The ESP GUID is correct, the other is "Linux filesystem data", right? Technically I guess root partition would be more suitable, but we would need to know whether it's AArch64 or ARM, if I get this correctly. Shall we use #ifdef CONFIG_ARM64 here?

Quoted 4 lines
Quoted 1 line

We can, what UUID do you have in mind?

FreeDesktop [3] seems to define some UUIDs for Linux root partitions, separated by architectures, and it lists ARM and AArch64.

Ok, I'll use them then.

Thanks!
maxime

Signature · 10 lines
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171130/27e1ed98/attachment.sig>
#11 lore raw

PATCH 4/4 fastboot: Enable flashing by default on sunxi

In reply to Maxime Ripard

Now that more and more devices are built using eMMC, providing a way to easily flash the system without too much hassle seems like a right thing to do.

Since fastboot is the most deployed tool to do that these days, we can just rely on it to provide a way to flash the various components in the system (SPL, U-Boot and the system itself) easily, especially since you can upload the U-Boot hosting the fastboot "server" through FEL.

---
 cmd/fastboot/Kconfig | 1 +
 1 file changed, 1 insertion(+)
cmd/fastboot/Kconfig +1 -0
index 4ce7a775e28e..cbb9183ea266 100644
@@ -66,6 +66,7 @@ config FASTBOOT_USB_DEV
 
 config FASTBOOT_FLASH
 	bool "Enable FASTBOOT FLASH command"
+	default y if ARCH_SUNXI
 	help
 	  The fastboot protocol includes a "flash" command for writing
 	  the downloaded image to a non-volatile storage device. Define
Signature · 1 line
git-series 0.9.1
#12 lore raw

PATCH 4/4 fastboot: Enable flashing by default on sunxi

Quoted 10 lines · Maxime Ripard

Now that more and more devices are built using eMMC, providing a way to easily flash the system without too much hassle seems like a right thing to do.

Since fastboot is the most deployed tool to do that these days, we can just rely on it to provide a way to flash the various components in the system (SPL, U-Boot and the system itself) easily, especially since you can upload the U-Boot hosting the fastboot "server" through FEL.

The binary size for 32-bit targets is still reasonable with this addition (thanks to Thumb2).

But if I enable MUSB for the Pine64 it generates a 537KB u-boot.itb. And the build process does not complain, I guess because I don't generate a combined binary (glueing SPL in front). But this isn't really caused by this patch, so just a heads up.

Cheers,
Andre.

Quoted 17 lines
---
 cmd/fastboot/Kconfig | 1 +
 1 file changed, 1 insertion(+)
cmd/fastboot/Kconfig +1 -0
index 4ce7a775e28e..cbb9183ea266 100644
@@ -66,6 +66,7 @@ config FASTBOOT_USB_DEV
 
 config FASTBOOT_FLASH
 	bool "Enable FASTBOOT FLASH command"
+	default y if ARCH_SUNXI
 	help
 	  The fastboot protocol includes a "flash" command for writing
 	  the downloaded image to a non-volatile storage device. Define
#13 lore raw

PATCH 4/4 fastboot: Enable flashing by default on sunxi

Quoted 14 lines · André Przywara
Quoted 10 lines · Maxime Ripard

Now that more and more devices are built using eMMC, providing a way to easily flash the system without too much hassle seems like a right thing to do.

Since fastboot is the most deployed tool to do that these days, we can just rely on it to provide a way to flash the various components in the system (SPL, U-Boot and the system itself) easily, especially since you can upload the U-Boot hosting the fastboot "server" through FEL.

Quoted 7 lines

The binary size for 32-bit targets is still reasonable with this addition (thanks to Thumb2).

But if I enable MUSB for the Pine64 it generates a 537KB u-boot.itb. And the build process does not complain, I guess because I don't generate a combined binary (glueing SPL in front). But this isn't really caused by this patch, so just a heads up.

I guess we would need to have kind of the same check at compile time for ARM64 then. I'm not sure exactly how that would be doable though...

Maxime

Signature · 10 lines
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171130/41930f03/attachment.sig>
#14 lore raw

PATCH 4/4 fastboot: Enable flashing by default on sunxi

Hi,

Quoted 18 lines · Maxime Ripard
Quoted 17 lines · André Przywara
Quoted 10 lines · Maxime Ripard

Now that more and more devices are built using eMMC, providing a way to easily flash the system without too much hassle seems like a right thing to do.

Since fastboot is the most deployed tool to do that these days, we can just rely on it to provide a way to flash the various components in the system (SPL, U-Boot and the system itself) easily, especially since you can upload the U-Boot hosting the fastboot "server" through FEL.

The binary size for 32-bit targets is still reasonable with this addition (thanks to Thumb2).

Quoted 8 lines
Quoted 4 lines

But if I enable MUSB for the Pine64 it generates a 537KB u-boot.itb. And the build process does not complain, I guess because I don't generate a combined binary (glueing SPL in front). But this isn't really caused by this patch, so just a heads up.

I guess we would need to have kind of the same check at compile time for ARM64 then. I'm not sure exactly how that would be doable though...

Me neither without digging deeply into the build system ;-)

By the way, can you point me to the part which triggers the generation of u-boot-sunxi-with-spl.bin? This does not get generated for ARM64 at the moment, though it should. And this is probably the place where the check lives for ARM.

Cheers,
Andre.

#15 lore raw

PATCH 4/4 fastboot: Enable flashing by default on sunxi

Quoted 30 lines · Andre Przywara

Hi,

Quoted 18 lines · Maxime Ripard
Quoted 17 lines · André Przywara
Quoted 10 lines · Maxime Ripard

Now that more and more devices are built using eMMC, providing a way to easily flash the system without too much hassle seems like a right thing to do.

Since fastboot is the most deployed tool to do that these days, we can just rely on it to provide a way to flash the various components in the system (SPL, U-Boot and the system itself) easily, especially since you can upload the U-Boot hosting the fastboot "server" through FEL.

The binary size for 32-bit targets is still reasonable with this addition (thanks to Thumb2).

Quoted 8 lines
Quoted 4 lines

But if I enable MUSB for the Pine64 it generates a 537KB u-boot.itb. And the build process does not complain, I guess because I don't generate a combined binary (glueing SPL in front). But this isn't really caused by this patch, so just a heads up.

I guess we would need to have kind of the same check at compile time for ARM64 then. I'm not sure exactly how that would be doable though...

Quoted 6 lines

Me neither without digging deeply into the build system ;-)

By the way, can you point me to the part which triggers the generation of u-boot-sunxi-with-spl.bin? This does not get generated for ARM64 at the moment, though it should. And this is probably the place where the check lives for ARM.

I *think* this is in arch/arm/cpu/armv7/sunxi/config.mk

Maxime

Signature · 10 lines
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171130/01493611/attachment.sig>
#16 lore raw

cover sunxi: Ease eMMC usage and flashing

In reply to Maxime Ripard
Quoted 27 lines · Maxime Ripard

Hi,

Here is a set of patches that have been sitting in some variations for quite some time now.

This is mostly to ease the eMMC (and MMC, to some extent) flashing using fastboot that in turn rely on GPT.

The Allwinner SoCs need to have the SPL located right in the middle of a traditional GPT, at 8kB.

To deal with this, we would basically have two options:
- Use the already in-tree solution to move the partition entries to another arbitrary offset in the MMC.
- Use a smaller number of partitions entries

Both are non-standards, but are dealt with nicely by the regular tools and users (at least on a Linux system). However, the first solution is quite confusing for users (that needs to be aware where the partitions will be), might be less flexible because not all tools will allow to create partitions for things between the GPT main entry and the partition entries, and might confuse tools if such a setup is available.

In our case, using the first solution, gdisk will for example refuse to create a partition for the SPL.

Quoted 6 lines

The second solution though seems to be well handled by all the tools, and just feels the same, except that you end up with a smaller number of partitions. In our case, that number is 56 partitions (16 sectors before the SPL, 1 sector for the protective MBR, 1 sector for the GPT header, and 4 partition entries per sector) instead of 128, which doesn't sound very impractical either.

That was meant to be a v2...

Thanks!
Maxime

Signature · 10 lines
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171128/1e9827ac/attachment.sig>