[U-Boot] [PATCH 0/4] 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
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.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com --- disk/Kconfig | 13 +++++++++++++ include/part_efi.h | 2 +- 2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/disk/Kconfig b/disk/Kconfig index 939656212065..f82beef6e689 100644 --- a/disk/Kconfig +++ b/disk/Kconfig @@ -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 diff --git a/include/part_efi.h b/include/part_efi.h index 31e6bc6e140f..4c8f6cc473c8 100644 --- a/include/part_efi.h +++ b/include/part_efi.h @@ -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 \
On Tue, Nov 28, 2017 at 11:34:38AM +0100, Maxime Ripard wrote:
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.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
Reviewed-by: Tom Rini trini@konsulko.com
On 28/11/17 10:34, Maxime Ripard wrote:
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.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
Reviewed-by: Andre Przywara andre.przywara@arm.com
Thanks, Andre.
disk/Kconfig | 13 +++++++++++++ include/part_efi.h | 2 +- 2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/disk/Kconfig b/disk/Kconfig index 939656212065..f82beef6e689 100644 --- a/disk/Kconfig +++ b/disk/Kconfig @@ -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 ismeant to allow less than the standard specifies for devicesthat might need to place their first-stage bootloader in themiddle of a regular GPT.If unsure, leave at 128 entries, which is the standardnumber.config EFI_PARTITION_ENTRIES_OFF int "Offset (in bytes) of the EFI partition entries" depends on EFI_PARTITION diff --git a/include/part_efi.h b/include/part_efi.h index 31e6bc6e140f..4c8f6cc473c8 100644 --- a/include/part_efi.h +++ b/include/part_efi.h @@ -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 \
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 maxime.ripard@free-electrons.com --- disk/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/disk/Kconfig b/disk/Kconfig index f82beef6e689..0446bb63ca7e 100644 --- a/disk/Kconfig +++ b/disk/Kconfig @@ -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
On 28/11/17 10:34, Maxime Ripard wrote:
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 maxime.ripard@free-electrons.com
The math is correct ;-)
Reviewed-by: Andre Przywara andre.przywara@arm.com
Thanks! Andre
disk/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/disk/Kconfig b/disk/Kconfig index f82beef6e689..0446bb63ca7e 100644 --- a/disk/Kconfig +++ b/disk/Kconfig @@ -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
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 maxime.ripard@free-electrons.com --- include/configs/sunxi-common.h | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 4391a8cbc824..c9214a709221 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -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
Hi Maxime,
On 28/11/17 10:34, Maxime Ripard wrote:
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 maxime.ripard@free-electrons.com
include/configs/sunxi-common.h | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 4391a8cbc824..c9214a709221 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -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-?
- "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.
#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.
- "partitions=" PARTS_DEFAULT "\0" \ BOOTCMD_SUNXI_COMPAT \ BOOTENV
Hi,
On Thu, Nov 30, 2017 at 12:23:06AM +0000, André Przywara wrote:
Hi Maxime,
On 28/11/17 10:34, Maxime Ripard wrote:
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 maxime.ripard@free-electrons.com
include/configs/sunxi-common.h | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 4391a8cbc824..c9214a709221 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -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-?
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.
- "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.
#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?
We can, what UUID do you have in mind?
Maxime
Hi,
On 30/11/17 07:56, Maxime Ripard wrote:
Hi,
On Thu, Nov 30, 2017 at 12:23:06AM +0000, André Przywara wrote:
Hi Maxime,
On 28/11/17 10:34, Maxime Ripard wrote:
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 maxime.ripard@free-electrons.com
include/configs/sunxi-common.h | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 4391a8cbc824..c9214a709221 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -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-?
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.
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.
- "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.
#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?
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/boo... [3] https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
On Thu, Nov 30, 2017 at 09:22:07AM +0000, Andre Przywara wrote:
Hi,
On 30/11/17 07:56, Maxime Ripard wrote:
Hi,
On Thu, Nov 30, 2017 at 12:23:06AM +0000, André Przywara wrote:
Hi Maxime,
On 28/11/17 10:34, Maxime Ripard wrote:
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 maxime.ripard@free-electrons.com
include/configs/sunxi-common.h | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 4391a8cbc824..c9214a709221 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -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-?
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.
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 :)
- "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.
#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?
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
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 maxime.ripard@free-electrons.com --- cmd/fastboot/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/cmd/fastboot/Kconfig b/cmd/fastboot/Kconfig index 4ce7a775e28e..cbb9183ea266 100644 --- a/cmd/fastboot/Kconfig +++ b/cmd/fastboot/Kconfig @@ -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
On 28/11/17 10:34, Maxime Ripard wrote:
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 maxime.ripard@free-electrons.com
Reviewed-by: Andre Przywara andre.przywara@arm.com
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.
cmd/fastboot/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/cmd/fastboot/Kconfig b/cmd/fastboot/Kconfig index 4ce7a775e28e..cbb9183ea266 100644 --- a/cmd/fastboot/Kconfig +++ b/cmd/fastboot/Kconfig @@ -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
On Thu, Nov 30, 2017 at 12:23:28AM +0000, André Przywara wrote:
On 28/11/17 10:34, Maxime Ripard wrote:
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 maxime.ripard@free-electrons.com
Reviewed-by: Andre Przywara andre.przywara@arm.com
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
Hi,
On 30/11/17 07:58, Maxime Ripard wrote:
On Thu, Nov 30, 2017 at 12:23:28AM +0000, André Przywara wrote:
On 28/11/17 10:34, Maxime Ripard wrote:
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 maxime.ripard@free-electrons.com
Reviewed-by: Andre Przywara andre.przywara@arm.com
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...
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.
On Thu, Nov 30, 2017 at 09:56:18AM +0000, Andre Przywara wrote:
Hi,
On 30/11/17 07:58, Maxime Ripard wrote:
On Thu, Nov 30, 2017 at 12:23:28AM +0000, André Przywara wrote:
On 28/11/17 10:34, Maxime Ripard wrote:
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 maxime.ripard@free-electrons.com
Reviewed-by: Andre Przywara andre.przywara@arm.com
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...
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
On Tue, Nov 28, 2017 at 11:34:37AM +0100, Maxime Ripard wrote:
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.
That was meant to be a v2...
Thanks! Maxime
participants (4)
-
Andre Przywara -
André Przywara
-
Maxime Ripard -
Tom Rini