sunxi: Ease eMMC usage and flashing
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
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
@@ -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
@@ -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
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
Kconfigoption to allow to do that.Signed-off-by Maxime Ripard <[email protected]>
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>
PATCH 1/4 part: efi: Add a Kconfig option for the number of partition entries
In reply to Maxime RipardQuoted 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
Kconfigoption to allow to do that.Signed-off-by Maxime Ripard <[email protected]>
Thanks,
Andre.
Quoted 43 lines
--- disk/Kconfig | 13 +++++++++++++ include/part_efi.h | 2 +- 2 files changed, 14 insertions(+), 1 deletion(-)disk/Kconfig +13
-0@@ -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_PARTITIONinclude/part_efi.h +1
-1@@ -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 \
PATCH 2/4 part: efi: Add default number of partition entries for sunxi
In reply to Maxime RipardThe 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
@@ -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
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.
Signed-off-by Maxime Ripard <[email protected]>
The math is correct ;-)
Thanks!
Andre
Quoted 17 lines
--- disk/Kconfig | 1 + 1 file changed, 1 insertion(+)disk/Kconfig +1
-0@@ -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
PATCH 3/4 sunxi: Add default partition scheme
In reply to Maxime RipardThe 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
@@ -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
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.
Signed-off-by Maxime Ripard <[email protected]>--- include/configs/sunxi-common.h | 9 +++++++++ 1 file changed, 9 insertions(+)include/configs/sunxi-common.h +0
-0
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
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.
Signed-off-by Maxime Ripard <[email protected]>--- include/configs/sunxi-common.h | 9 +++++++++ 1 file changed, 9 insertions(+)include/configs/sunxi-common.h +0
-0@@ -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
-0SUNXI_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_ARM64here?
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>
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.
Signed-off-by Maxime Ripard <[email protected]>--- include/configs/sunxi-common.h | 9 +++++++++ 1 file changed, 9 insertions(+)include/configs/sunxi-common.h +0
-0@@ -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_UUIDset. 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
-0SUNXI_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_ARM64here?
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/
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.
Signed-off-by Maxime Ripard <[email protected]>--- include/configs/sunxi-common.h | 9 +++++++++ 1 file changed, 9 insertions(+)include/configs/sunxi-common.h +0
-0@@ -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_UUIDset. 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_ARM64here?
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>
PATCH 4/4 fastboot: Enable flashing by default on sunxi
In reply to Maxime RipardNow 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
@@ -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
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.
Signed-off-by Maxime Ripard <[email protected]>
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@@ -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
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.
Signed-off-by Maxime Ripard <[email protected]>Reviewed-by Andre Przywara <[email protected]>
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>
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.
Signed-off-by Maxime Ripard <[email protected]>Reviewed-by Andre Przywara <[email protected]>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.
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.
Signed-off-by Maxime Ripard <[email protected]>Reviewed-by Andre Przywara <[email protected]>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>
cover sunxi: Ease eMMC usage and flashing
In reply to Maxime RipardQuoted 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 entriesBoth 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>