* [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing
@ 2017-11-28 10:34 Maxime Ripard
2017-11-28 10:34 ` [U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries Maxime Ripard
` (4 more replies)
0 siblings, 5 replies; 18+ messages in thread
From: Maxime Ripard @ 2017-11-28 10:34 UTC (permalink / raw)
To: u-boot
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
--
git-series 0.9.1
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries
2017-11-28 10:34 [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing Maxime Ripard
@ 2017-11-28 10:34 ` Maxime Ripard
2017-11-28 14:50 ` Tom Rini
2017-11-30 0:20 ` André Przywara
2017-11-28 10:34 ` [U-Boot] [PATCH 2/4] part: efi: Add default number of partition entries for sunxi Maxime Ripard
` (3 subsequent siblings)
4 siblings, 2 replies; 18+ messages in thread
From: Maxime Ripard @ 2017-11-28 10:34 UTC (permalink / raw)
To: u-boot
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 \
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries
2017-11-28 10:34 ` [U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries Maxime Ripard
@ 2017-11-28 14:50 ` Tom Rini
2017-11-30 0:20 ` André Przywara
1 sibling, 0 replies; 18+ messages in thread
From: Tom Rini @ 2017-11-28 14:50 UTC (permalink / raw)
To: u-boot
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>
--
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries
2017-11-28 10:34 ` [U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries Maxime Ripard
2017-11-28 14:50 ` Tom Rini
@ 2017-11-30 0:20 ` André Przywara
1 sibling, 0 replies; 18+ messages in thread
From: André Przywara @ 2017-11-30 0:20 UTC (permalink / raw)
To: u-boot
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 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 \
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 2/4] part: efi: Add default number of partition entries for sunxi
2017-11-28 10:34 [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing Maxime Ripard
2017-11-28 10:34 ` [U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries Maxime Ripard
@ 2017-11-28 10:34 ` Maxime Ripard
2017-11-30 0:22 ` André Przywara
2017-11-28 10:34 ` [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme Maxime Ripard
` (2 subsequent siblings)
4 siblings, 1 reply; 18+ messages in thread
From: Maxime Ripard @ 2017-11-28 10:34 UTC (permalink / raw)
To: u-boot
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
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 2/4] part: efi: Add default number of partition entries for sunxi
2017-11-28 10:34 ` [U-Boot] [PATCH 2/4] part: efi: Add default number of partition entries for sunxi Maxime Ripard
@ 2017-11-30 0:22 ` André Przywara
0 siblings, 0 replies; 18+ messages in thread
From: André Przywara @ 2017-11-30 0:22 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme
2017-11-28 10:34 [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing Maxime Ripard
2017-11-28 10:34 ` [U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries Maxime Ripard
2017-11-28 10:34 ` [U-Boot] [PATCH 2/4] part: efi: Add default number of partition entries for sunxi Maxime Ripard
@ 2017-11-28 10:34 ` Maxime Ripard
2017-11-30 0:23 ` André Przywara
2017-11-28 10:34 ` [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi Maxime Ripard
2017-11-28 10:35 ` [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing Maxime Ripard
4 siblings, 1 reply; 18+ messages in thread
From: Maxime Ripard @ 2017-11-28 10:34 UTC (permalink / raw)
To: u-boot
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
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme
2017-11-28 10:34 ` [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme Maxime Ripard
@ 2017-11-30 0:23 ` André Przywara
2017-11-30 7:56 ` Maxime Ripard
0 siblings, 1 reply; 18+ messages in thread
From: André Przywara @ 2017-11-30 0:23 UTC (permalink / raw)
To: u-boot
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
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme
2017-11-30 0:23 ` André Przywara
@ 2017-11-30 7:56 ` Maxime Ripard
2017-11-30 9:22 ` Andre Przywara
0 siblings, 1 reply; 18+ messages in thread
From: Maxime Ripard @ 2017-11-30 7:56 UTC (permalink / raw)
To: u-boot
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
--
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme
2017-11-30 7:56 ` Maxime Ripard
@ 2017-11-30 9:22 ` Andre Przywara
2017-11-30 15:49 ` Maxime Ripard
0 siblings, 1 reply; 18+ messages in thread
From: Andre Przywara @ 2017-11-30 9:22 UTC (permalink / raw)
To: u-boot
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/boot-arch/android_ia/gpt.ini
[3]
https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme
2017-11-30 9:22 ` Andre Przywara
@ 2017-11-30 15:49 ` Maxime Ripard
0 siblings, 0 replies; 18+ messages in thread
From: Maxime Ripard @ 2017-11-30 15:49 UTC (permalink / raw)
To: u-boot
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
--
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi
2017-11-28 10:34 [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing Maxime Ripard
` (2 preceding siblings ...)
2017-11-28 10:34 ` [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme Maxime Ripard
@ 2017-11-28 10:34 ` Maxime Ripard
2017-11-30 0:23 ` André Przywara
2017-11-28 10:35 ` [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing Maxime Ripard
4 siblings, 1 reply; 18+ messages in thread
From: Maxime Ripard @ 2017-11-28 10:34 UTC (permalink / raw)
To: u-boot
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
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi
2017-11-28 10:34 ` [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi Maxime Ripard
@ 2017-11-30 0:23 ` André Przywara
2017-11-30 7:58 ` Maxime Ripard
0 siblings, 1 reply; 18+ messages in thread
From: André Przywara @ 2017-11-30 0:23 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi
2017-11-30 0:23 ` André Przywara
@ 2017-11-30 7:58 ` Maxime Ripard
2017-11-30 9:56 ` Andre Przywara
0 siblings, 1 reply; 18+ messages in thread
From: Maxime Ripard @ 2017-11-30 7:58 UTC (permalink / raw)
To: u-boot
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
--
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi
2017-11-30 7:58 ` Maxime Ripard
@ 2017-11-30 9:56 ` Andre Przywara
2017-11-30 15:50 ` Maxime Ripard
0 siblings, 1 reply; 18+ messages in thread
From: Andre Przywara @ 2017-11-30 9:56 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi
2017-11-30 9:56 ` Andre Przywara
@ 2017-11-30 15:50 ` Maxime Ripard
0 siblings, 0 replies; 18+ messages in thread
From: Maxime Ripard @ 2017-11-30 15:50 UTC (permalink / raw)
To: u-boot
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
--
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing
2017-11-28 10:34 [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing Maxime Ripard
` (3 preceding siblings ...)
2017-11-28 10:34 ` [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi Maxime Ripard
@ 2017-11-28 10:35 ` Maxime Ripard
4 siblings, 0 replies; 18+ messages in thread
From: Maxime Ripard @ 2017-11-28 10:35 UTC (permalink / raw)
To: u-boot
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
--
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing
@ 2017-11-15 10:11 Maxime Ripard
2017-11-15 10:11 ` [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi Maxime Ripard
0 siblings, 1 reply; 18+ messages in thread
From: Maxime Ripard @ 2017-11-15 10:11 UTC (permalink / raw)
To: u-boot
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
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 | 7 +++++++
include/part_efi.h | 2 +-
4 files changed, 23 insertions(+), 1 deletion(-)
--
2.14.3
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi
2017-11-15 10:11 Maxime Ripard
@ 2017-11-15 10:11 ` Maxime Ripard
0 siblings, 0 replies; 18+ messages in thread
From: Maxime Ripard @ 2017-11-15 10:11 UTC (permalink / raw)
To: u-boot
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
--
2.14.3
^ permalink raw reply related [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-11-30 15:50 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-28 10:34 [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing Maxime Ripard
2017-11-28 10:34 ` [U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries Maxime Ripard
2017-11-28 14:50 ` Tom Rini
2017-11-30 0:20 ` André Przywara
2017-11-28 10:34 ` [U-Boot] [PATCH 2/4] part: efi: Add default number of partition entries for sunxi Maxime Ripard
2017-11-30 0:22 ` André Przywara
2017-11-28 10:34 ` [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme Maxime Ripard
2017-11-30 0:23 ` André Przywara
2017-11-30 7:56 ` Maxime Ripard
2017-11-30 9:22 ` Andre Przywara
2017-11-30 15:49 ` Maxime Ripard
2017-11-28 10:34 ` [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi Maxime Ripard
2017-11-30 0:23 ` André Przywara
2017-11-30 7:58 ` Maxime Ripard
2017-11-30 9:56 ` Andre Przywara
2017-11-30 15:50 ` Maxime Ripard
2017-11-28 10:35 ` [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing Maxime Ripard
-- strict thread matches above, loose matches on Subject: below --
2017-11-15 10:11 Maxime Ripard
2017-11-15 10:11 ` [U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi Maxime Ripard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.