[U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing

[U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing

[Maxime Ripard]

Hi,

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

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

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

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

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

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

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

[U-Boot] [PATCH 1/4] part: efi: Add a Kconfig option for the number of partition entries

[Maxime Ripard]

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

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

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 \
-- 
2.14.3

[U-Boot] [PATCH 2/4] part: efi: Add default number of partition entries for sunxi

[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 <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
-- 
2.14.3

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[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 <maxime.ripard@free-electrons.com>
---
 include/configs/sunxi-common.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 4391a8cbc824..11da6ccfbf54 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;" \
+	"name=loader2,size=984k;" \
+	"name=boot,size=128M,bootable;" \
+	"name=system,size=-;"
+
 #define CONSOLE_ENV_SETTINGS \
 	CONSOLE_STDIN_SETTINGS \
 	CONSOLE_STDOUT_SETTINGS
@@ -511,6 +517,7 @@ extern int soft_i2c_gpio_scl;
 	"console=ttyS0,115200\0" \
 	SUNXI_MTDIDS_DEFAULT \
 	SUNXI_MTDPARTS_DEFAULT \
+	"partitions=" PARTS_DEFAULT "\0" \
 	BOOTCMD_SUNXI_COMPAT \
 	BOOTENV
 
-- 
2.14.3

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Alexander Graf]

On 15.11.17 11:11, 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 | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 4391a8cbc824..11da6ccfbf54 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;" \
> +	"name=loader2,size=984k;" \
> +	"name=boot,size=128M,bootable;" \
> +	"name=system,size=-;"

Is there a particular reason you're creating a boot and system
partition? In a normal distro world, the distro installer will take care
of creating ESP + root + swap + whatever for you - and they (or the user
driving the installation) usually know best what they need :)


Alex

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

Hi Alexander,

On Wed, Nov 15, 2017 at 10:03:32PM +0100, Alexander Graf wrote:
> On 15.11.17 11:11, 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 | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> > index 4391a8cbc824..11da6ccfbf54 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;" \
> > +	"name=loader2,size=984k;" \
> > +	"name=boot,size=128M,bootable;" \
> > +	"name=system,size=-;"
> 
> Is there a particular reason you're creating a boot and system
> partition? In a normal distro world, the distro installer will take care
> of creating ESP + root + swap + whatever for you - and they (or the user
> driving the installation) usually know best what they need :)

Right, so let me explain my thought process here :)

We really want a main partition for the system for people that will
not use any distro installer (either because they generated their
image by hand before using something like debootstrap or ELBE) or
because they're using a build system that will generate the system
image directly, without any alternative process.

Then, the boot partition is the one I'm not really sure about. As you
know, we will transition to an FAT-based environment in the future, so
we need to have partition to hold it on all systems, and it can't be
the system one since, well, FAT.

I also was under the impression that it would benefit you in some way
to store the EFI data, and it's actually what I'd really like input
on. I have basically no idea what are your requirements or what would
be a good size.

The only real constraints we have is that it needs to be at least able
to store 128kB for the environment. If we want to align it properly,
that would be 1MB. Then, if you're telling me you don't need anything
else, then that's fine by me :)

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: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171116/2fcb07af/attachment.sig>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Andre Przywara]

Hi,

On 15/11/17 21:03, Alexander Graf wrote:
> 
> 
> On 15.11.17 11:11, 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 | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
>> index 4391a8cbc824..11da6ccfbf54 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;" \
>> +	"name=loader2,size=984k;" \
>> +	"name=boot,size=128M,bootable;" \
>> +	"name=system,size=-;"
> 
> Is there a particular reason you're creating a boot and system
> partition? In a normal distro world, the distro installer will take care
> of creating ESP + root + swap + whatever for you - and they (or the user
> driving the installation) usually know best what they need :)

But do we actually care about this? If I understand this correctly,
these are default settings for U-Boot's "mtdparts default" command,
which honestly I didn't even know existed so far.
So in a distribution scenario I wouldn't expect somebody to actually use
this. Instead you boot from a (possibly unpartitioned) SD card with just
U-Boot on it or from SPI flash, then launch an installer from somewhere
(PXE, USB drive) and let it do its job. No U-Boot partition involved.
And even if you use mtdpart, you can always override these default
settings on the command line.

Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
Android-y/embedded to me (passing partition information via command line).

So apart from that I think it's good to have a default FAT/ESP
partition, also for storing the environment.

It's debatable whether we need a system partition defined at this stage.
Can't this just left be unpartitioned, to be actually populated later?
In a MBR/GPT scenario I would expect a big partition covering the whole
device causes headache later on.

Cheers,
Andre.

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

On Thu, Nov 16, 2017 at 10:30:38AM +0000, Andre Przywara wrote:
> Hi,
> 
> On 15/11/17 21:03, Alexander Graf wrote:
> > 
> > 
> > On 15.11.17 11:11, 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 | 7 +++++++
> >>  1 file changed, 7 insertions(+)
> >>
> >> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> >> index 4391a8cbc824..11da6ccfbf54 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;" \
> >> +	"name=loader2,size=984k;" \
> >> +	"name=boot,size=128M,bootable;" \
> >> +	"name=system,size=-;"
> > 
> > Is there a particular reason you're creating a boot and system
> > partition? In a normal distro world, the distro installer will take care
> > of creating ESP + root + swap + whatever for you - and they (or the user
> > driving the installation) usually know best what they need :)
> 
> But do we actually care about this?

I do.

> If I understand this correctly, these are default settings for
> U-Boot's "mtdparts default" command, which honestly I didn't even
> know existed so far.

No, this has nothing to do with MTD. It's a default GPT partitioning
scheme. And only when you want to create the table from U-Boot, it
will not mangle with any pre-existing partition table if there is any
(unless you tell U-Boot to overwrite it, of course).

> So in a distribution scenario I wouldn't expect somebody to actually use
> this. Instead you boot from a (possibly unpartitioned) SD card with just
> U-Boot on it or from SPI flash, then launch an installer from somewhere
> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
> And even if you use mtdpart, you can always override these default
> settings on the command line.

Like I was telling Alexander, that makes a number of assumptions, the
two most obvious one being that you have an installer and that you
want to use it, both with reasonable reasons on why they wouldn't be
true.

More tailored fit distros like ELBE, yocto or Buildroot will not have
an installer in the first place but an image.

And even if you have an installer for the distro you want to use, if
you ever go to production, you will not use it since the time spent to
flash a pre-filled image compared to running the installer is
significantly lower. And time is money :)

Just like plugging / unplugging microSD card isn't really realistic in
that scenario.

> Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
> Android-y/embedded to me (passing partition information via command line).
> 
> So apart from that I think it's good to have a default FAT/ESP
> partition, also for storing the environment.

What is the typical size of the files you usually put in there? My
actual question being is 128MB enough, way too big or too small? The
environment is just 128kB big at the moment, so it looks wayyyyy to
big for me, but I have no idea what is usually stored in an ESP
partition.

> It's debatable whether we need a system partition defined at this stage.
> Can't this just left be unpartitioned, to be actually populated later?

This would break the cases I talked about earlier.

> In a MBR/GPT scenario I would expect a big partition covering the whole
> device causes headache later on.

What kind of headaches?

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: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171116/c070aeba/attachment.sig>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Andre Przywara]

Hi,

On 16/11/17 11:21, Maxime Ripard wrote:
> On Thu, Nov 16, 2017 at 10:30:38AM +0000, Andre Przywara wrote:
>> Hi,
>>
>> On 15/11/17 21:03, Alexander Graf wrote:
>>>
>>>
>>> On 15.11.17 11:11, 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 | 7 +++++++
>>>>  1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
>>>> index 4391a8cbc824..11da6ccfbf54 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;" \
>>>> +	"name=loader2,size=984k;" \
>>>> +	"name=boot,size=128M,bootable;" \
>>>> +	"name=system,size=-;"
>>>
>>> Is there a particular reason you're creating a boot and system
>>> partition? In a normal distro world, the distro installer will take care
>>> of creating ESP + root + swap + whatever for you - and they (or the user
>>> driving the installation) usually know best what they need :)
>>
>> But do we actually care about this?
> 
> I do.

I know, this was a misunderstanding, sorry. By "we" I meant Alex and
Karsten's generic distribution point of view. I was arguing that this
patch is of no big importance for them.

I think we agree that there are quite different use cases, and I don't
fight the usefulness of both.

>> If I understand this correctly, these are default settings for
>> U-Boot's "mtdparts default" command, which honestly I didn't even
>> know existed so far.
> 
> No, this has nothing to do with MTD. It's a default GPT partitioning
> scheme. And only when you want to create the table from U-Boot, it
> will not mangle with any pre-existing partition table if there is any
> (unless you tell U-Boot to overwrite it, of course).

This is what I tried to say: It only affects you if you use U-Boot's
partitioning command, which you probably won't do if you are running an
off-the-shelf distribution installer. Is that understanding correct?

>> So in a distribution scenario I wouldn't expect somebody to actually use
>> this. Instead you boot from a (possibly unpartitioned) SD card with just
>> U-Boot on it or from SPI flash, then launch an installer from somewhere
>> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
>> And even if you use mtdpart, you can always override these default
>> settings on the command line.
> 
> Like I was telling Alexander, that makes a number of assumptions, the
> two most obvious one being that you have an installer and that you
> want to use it, both with reasonable reasons on why they wouldn't be
> true.
> 
> More tailored fit distros like ELBE, yocto or Buildroot will not have
> an installer in the first place but an image.
> 
> And even if you have an installer for the distro you want to use, if
> you ever go to production, you will not use it since the time spent to
> flash a pre-filled image compared to running the installer is
> significantly lower. And time is money :)
> 
> Just like plugging / unplugging microSD card isn't really realistic in
> that scenario.

I don't argue this (see above) and surely understand that generic
installers don't fly when it comes to bootstrapping devices.

But my understanding is that both Alex and Karsten don't really care
about this usage scenario, but instead are more looking into generic
distribution installers, which use U-Boot merely to launch grub.

Actually I wanted to help you out here by pointing out that their
concerns don't really apply to this patch ;-)

>> Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
>> Android-y/embedded to me (passing partition information via command line).
>>
>> So apart from that I think it's good to have a default FAT/ESP
>> partition, also for storing the environment.
> 
> What is the typical size of the files you usually put in there? My
> actual question being is 128MB enough, way too big or too small? The
> environment is just 128kB big at the moment, so it looks wayyyyy to
> big for me, but I have no idea what is usually stored in an ESP
> partition.

128MB is actually quite fine. I tend to use 150MB or 100MB. The Ubuntu
arm64 kernel is around 20MB, and you may want to store more than one of
those on the ESP, along with an initrd. I understand that distributions
may not use the ESP for that, but their own /boot partition. But this is
their choice. Also other OSes (BSDs?) want to use the ESP, so being too
miserly here may backfire.

Do you feel that's too big? We are talking about at least 8GB eMMCs
mostly here, right?

>> It's debatable whether we need a system partition defined at this stage.
>> Can't this just left be unpartitioned, to be actually populated later?
> 
> This would break the cases I talked about earlier.

Fair enough.

>> In a MBR/GPT scenario I would expect a big partition covering the whole
>> device causes headache later on.
> 
> What kind of headaches?

Just thinking if an installer wants to add partitions (swap, /home, ...)
it might be easier if some space is actually left unpartitioned.
But that's just my non-embedded experience, where adding partitions is
easier and safer, compared to deleting or resizing an existing partition.

Cheers,
Andre.

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Alexander Graf]

On 11/16/2017 12:41 PM, Andre Przywara wrote:
> Hi,
>
> On 16/11/17 11:21, Maxime Ripard wrote:
>> On Thu, Nov 16, 2017 at 10:30:38AM +0000, Andre Przywara wrote:
>>> Hi,
>>>
>>> On 15/11/17 21:03, Alexander Graf wrote:
>>>>
>>>> On 15.11.17 11:11, 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 | 7 +++++++
>>>>>   1 file changed, 7 insertions(+)
>>>>>
>>>>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
>>>>> index 4391a8cbc824..11da6ccfbf54 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;" \
>>>>> +	"name=loader2,size=984k;" \
>>>>> +	"name=boot,size=128M,bootable;" \
>>>>> +	"name=system,size=-;"
>>>> Is there a particular reason you're creating a boot and system
>>>> partition? In a normal distro world, the distro installer will take care
>>>> of creating ESP + root + swap + whatever for you - and they (or the user
>>>> driving the installation) usually know best what they need :)
>>> But do we actually care about this?
>> I do.
> I know, this was a misunderstanding, sorry. By "we" I meant Alex and
> Karsten's generic distribution point of view. I was arguing that this
> patch is of no big importance for them.
>
> I think we agree that there are quite different use cases, and I don't
> fight the usefulness of both.
>
>>> If I understand this correctly, these are default settings for
>>> U-Boot's "mtdparts default" command, which honestly I didn't even
>>> know existed so far.
>> No, this has nothing to do with MTD. It's a default GPT partitioning
>> scheme. And only when you want to create the table from U-Boot, it
>> will not mangle with any pre-existing partition table if there is any
>> (unless you tell U-Boot to overwrite it, of course).
> This is what I tried to say: It only affects you if you use U-Boot's
> partitioning command, which you probably won't do if you are running an
> off-the-shelf distribution installer. Is that understanding correct?

I'm not sure what the envisioned use of this is either. In general, it 
makes sense to keep the env on a partition and to mark the firmware 
residing on eMMC as off limits to an OS installer. So some sort of 
partitioning scheme is very useful and good to have.

>
>>> So in a distribution scenario I wouldn't expect somebody to actually use
>>> this. Instead you boot from a (possibly unpartitioned) SD card with just
>>> U-Boot on it or from SPI flash, then launch an installer from somewhere
>>> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
>>> And even if you use mtdpart, you can always override these default
>>> settings on the command line.
>> Like I was telling Alexander, that makes a number of assumptions, the
>> two most obvious one being that you have an installer and that you
>> want to use it, both with reasonable reasons on why they wouldn't be
>> true.
>>
>> More tailored fit distros like ELBE, yocto or Buildroot will not have
>> an installer in the first place but an image.
>>
>> And even if you have an installer for the distro you want to use, if
>> you ever go to production, you will not use it since the time spent to
>> flash a pre-filled image compared to running the installer is
>> significantly lower. And time is money :)
>>
>> Just like plugging / unplugging microSD card isn't really realistic in
>> that scenario.
> I don't argue this (see above) and surely understand that generic
> installers don't fly when it comes to bootstrapping devices.
>
> But my understanding is that both Alex and Karsten don't really care
> about this usage scenario, but instead are more looking into generic
> distribution installers, which use U-Boot merely to launch grub.
>
> Actually I wanted to help you out here by pointing out that their
> concerns don't really apply to this patch ;-)
>
>>> Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
>>> Android-y/embedded to me (passing partition information via command line).
>>>
>>> So apart from that I think it's good to have a default FAT/ESP
>>> partition, also for storing the environment.
>> What is the typical size of the files you usually put in there? My
>> actual question being is 128MB enough, way too big or too small? The
>> environment is just 128kB big at the moment, so it looks wayyyyy to
>> big for me, but I have no idea what is usually stored in an ESP
>> partition.
> 128MB is actually quite fine. I tend to use 150MB or 100MB. The Ubuntu
> arm64 kernel is around 20MB, and you may want to store more than one of
> those on the ESP, along with an initrd. I understand that distributions
> may not use the ESP for that, but their own /boot partition. But this is
> their choice. Also other OSes (BSDs?) want to use the ESP, so being too
> miserly here may backfire.

Right, in our case ~16MB would be enough, because we only store grub on 
the ESP. But there are other boot loaders out there like systemd-boot 
which put the kernel images and initrds onto the ESP.

>
> Do you feel that's too big? We are talking about at least 8GB eMMCs
> mostly here, right?
>
>>> It's debatable whether we need a system partition defined at this stage.
>>> Can't this just left be unpartitioned, to be actually populated later?
>> This would break the cases I talked about earlier.
> Fair enough.

The reason I'm not fully comfortable with prepopulated system partitions 
is mostly because I'm not sure all installers will deal with them 
properly. Some might decide you're better off resizing a system 
partition rather than removing it - and if there's nothing useful inside 
that may be the wrong choice.

But that's nothing earth shattering. If you do need a system partition 
to have other installers work well, that's ok too I guess.

>
>>> In a MBR/GPT scenario I would expect a big partition covering the whole
>>> device causes headache later on.
>> What kind of headaches?
> Just thinking if an installer wants to add partitions (swap, /home, ...)
> it might be easier if some space is actually left unpartitioned.
> But that's just my non-embedded experience, where adding partitions is
> easier and safer, compared to deleting or resizing an existing partition.

Yup, exactly that :)


Alex

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Emmanuel Vadot]

On Thu, 16 Nov 2017 12:54:13 +0100
Alexander Graf <agraf@suse.de> wrote:

> On 11/16/2017 12:41 PM, Andre Przywara wrote:
> > Hi,
> >
> > On 16/11/17 11:21, Maxime Ripard wrote:
> >> On Thu, Nov 16, 2017 at 10:30:38AM +0000, Andre Przywara wrote:
> >>> Hi,
> >>>
> >>> On 15/11/17 21:03, Alexander Graf wrote:
> >>>>
> >>>> On 15.11.17 11:11, 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 | 7 +++++++
> >>>>>   1 file changed, 7 insertions(+)
> >>>>>
> >>>>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> >>>>> index 4391a8cbc824..11da6ccfbf54 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;" \
> >>>>> +	"name=loader2,size=984k;" \
> >>>>> +	"name=boot,size=128M,bootable;" \
> >>>>> +	"name=system,size=-;"
> >>>> Is there a particular reason you're creating a boot and system
> >>>> partition? In a normal distro world, the distro installer will take care
> >>>> of creating ESP + root + swap + whatever for you - and they (or the user
> >>>> driving the installation) usually know best what they need :)
> >>> But do we actually care about this?
> >> I do.
> > I know, this was a misunderstanding, sorry. By "we" I meant Alex and
> > Karsten's generic distribution point of view. I was arguing that this
> > patch is of no big importance for them.
> >
> > I think we agree that there are quite different use cases, and I don't
> > fight the usefulness of both.
> >
> >>> If I understand this correctly, these are default settings for
> >>> U-Boot's "mtdparts default" command, which honestly I didn't even
> >>> know existed so far.
> >> No, this has nothing to do with MTD. It's a default GPT partitioning
> >> scheme. And only when you want to create the table from U-Boot, it
> >> will not mangle with any pre-existing partition table if there is any
> >> (unless you tell U-Boot to overwrite it, of course).
> > This is what I tried to say: It only affects you if you use U-Boot's
> > partitioning command, which you probably won't do if you are running an
> > off-the-shelf distribution installer. Is that understanding correct?
> 
> I'm not sure what the envisioned use of this is either. In general, it 
> makes sense to keep the env on a partition and to mark the firmware 
> residing on eMMC as off limits to an OS installer. So some sort of 
> partitioning scheme is very useful and good to have.
> 
> >
> >>> So in a distribution scenario I wouldn't expect somebody to actually use
> >>> this. Instead you boot from a (possibly unpartitioned) SD card with just
> >>> U-Boot on it or from SPI flash, then launch an installer from somewhere
> >>> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
> >>> And even if you use mtdpart, you can always override these default
> >>> settings on the command line.
> >> Like I was telling Alexander, that makes a number of assumptions, the
> >> two most obvious one being that you have an installer and that you
> >> want to use it, both with reasonable reasons on why they wouldn't be
> >> true.
> >>
> >> More tailored fit distros like ELBE, yocto or Buildroot will not have
> >> an installer in the first place but an image.
> >>
> >> And even if you have an installer for the distro you want to use, if
> >> you ever go to production, you will not use it since the time spent to
> >> flash a pre-filled image compared to running the installer is
> >> significantly lower. And time is money :)
> >>
> >> Just like plugging / unplugging microSD card isn't really realistic in
> >> that scenario.
> > I don't argue this (see above) and surely understand that generic
> > installers don't fly when it comes to bootstrapping devices.
> >
> > But my understanding is that both Alex and Karsten don't really care
> > about this usage scenario, but instead are more looking into generic
> > distribution installers, which use U-Boot merely to launch grub.
> >
> > Actually I wanted to help you out here by pointing out that their
> > concerns don't really apply to this patch ;-)
> >
> >>> Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
> >>> Android-y/embedded to me (passing partition information via command line).
> >>>
> >>> So apart from that I think it's good to have a default FAT/ESP
> >>> partition, also for storing the environment.
> >> What is the typical size of the files you usually put in there? My
> >> actual question being is 128MB enough, way too big or too small? The
> >> environment is just 128kB big at the moment, so it looks wayyyyy to
> >> big for me, but I have no idea what is usually stored in an ESP
> >> partition.
> > 128MB is actually quite fine. I tend to use 150MB or 100MB. The Ubuntu
> > arm64 kernel is around 20MB, and you may want to store more than one of
> > those on the ESP, along with an initrd. I understand that distributions
> > may not use the ESP for that, but their own /boot partition. But this is
> > their choice. Also other OSes (BSDs?) want to use the ESP, so being too
> > miserly here may backfire.
> 
> Right, in our case ~16MB would be enough, because we only store grub on 
> the ESP. But there are other boot loaders out there like systemd-boot 
> which put the kernel images and initrds onto the ESP.

 ~16MB would be enough for FreeBSD too, in a EFI environment we only
store our loader and the DTB, the kernel itself sits in the root
filesystem.

> >
> > Do you feel that's too big? We are talking about at least 8GB eMMCs
> > mostly here, right?
> >
> >>> It's debatable whether we need a system partition defined at this stage.
> >>> Can't this just left be unpartitioned, to be actually populated later?
> >> This would break the cases I talked about earlier.
> > Fair enough.
> 
> The reason I'm not fully comfortable with prepopulated system partitions 
> is mostly because I'm not sure all installers will deal with them 
> properly. Some might decide you're better off resizing a system 
> partition rather than removing it - and if there's nothing useful inside 
> that may be the wrong choice.
> 
> But that's nothing earth shattering. If you do need a system partition 
> to have other installers work well, that's ok too I guess.
> 
> >
> >>> In a MBR/GPT scenario I would expect a big partition covering the whole
> >>> device causes headache later on.
> >> What kind of headaches?
> > Just thinking if an installer wants to add partitions (swap, /home, ...)
> > it might be easier if some space is actually left unpartitioned.
> > But that's just my non-embedded experience, where adding partitions is
> > easier and safer, compared to deleting or resizing an existing partition.
> 
> Yup, exactly that :)
> 
> 
> Alex
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot


-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Tom Rini]

On Thu, Nov 16, 2017 at 11:41:57AM +0000, Andre Przywara wrote:
> Hi,
> 
> On 16/11/17 11:21, Maxime Ripard wrote:
> > On Thu, Nov 16, 2017 at 10:30:38AM +0000, Andre Przywara wrote:
> >> Hi,
> >>
> >> On 15/11/17 21:03, Alexander Graf wrote:
> >>>
> >>>
> >>> On 15.11.17 11:11, 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 | 7 +++++++
> >>>>  1 file changed, 7 insertions(+)
> >>>>
> >>>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> >>>> index 4391a8cbc824..11da6ccfbf54 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;" \
> >>>> +	"name=loader2,size=984k;" \
> >>>> +	"name=boot,size=128M,bootable;" \
> >>>> +	"name=system,size=-;"
> >>>
> >>> Is there a particular reason you're creating a boot and system
> >>> partition? In a normal distro world, the distro installer will take care
> >>> of creating ESP + root + swap + whatever for you - and they (or the user
> >>> driving the installation) usually know best what they need :)

So, from another part of this thread, yes, this should not be called
boot but be called esp so it's clearer.

> >> But do we actually care about this?
> > 
> > I do.
> 
> I know, this was a misunderstanding, sorry. By "we" I meant Alex and
> Karsten's generic distribution point of view. I was arguing that this
> patch is of no big importance for them.
> 
> I think we agree that there are quite different use cases, and I don't
> fight the usefulness of both.

Yes, "we" care about the use case here.  No one wants to re-invent the
wheel on "how do I find and boot the OS" and the generic distro
framework is fairly easy for most cases to tap into.

And then on the "we" side of things, the problem here that everyone
needs to care about it how do we setup a partition table so that we can
have SPL where it's required by firmware to be.  How is this particular
hurdle handled today in fedora/debian/opensuse?

> >> If I understand this correctly, these are default settings for
> >> U-Boot's "mtdparts default" command, which honestly I didn't even
> >> know existed so far.
> > 
> > No, this has nothing to do with MTD. It's a default GPT partitioning
> > scheme. And only when you want to create the table from U-Boot, it
> > will not mangle with any pre-existing partition table if there is any
> > (unless you tell U-Boot to overwrite it, of course).
> 
> This is what I tried to say: It only affects you if you use U-Boot's
> partitioning command, which you probably won't do if you are running an
> off-the-shelf distribution installer. Is that understanding correct?
> 
> >> So in a distribution scenario I wouldn't expect somebody to actually use
> >> this. Instead you boot from a (possibly unpartitioned) SD card with just
> >> U-Boot on it or from SPI flash, then launch an installer from somewhere
> >> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
> >> And even if you use mtdpart, you can always override these default
> >> settings on the command line.
> > 
> > Like I was telling Alexander, that makes a number of assumptions, the
> > two most obvious one being that you have an installer and that you
> > want to use it, both with reasonable reasons on why they wouldn't be
> > true.
> > 
> > More tailored fit distros like ELBE, yocto or Buildroot will not have
> > an installer in the first place but an image.
> > 
> > And even if you have an installer for the distro you want to use, if
> > you ever go to production, you will not use it since the time spent to
> > flash a pre-filled image compared to running the installer is
> > significantly lower. And time is money :)
> > 
> > Just like plugging / unplugging microSD card isn't really realistic in
> > that scenario.
> 
> I don't argue this (see above) and surely understand that generic
> installers don't fly when it comes to bootstrapping devices.

My recollection from having installed Debian the other week is that you
can say "I have things partitioned, please use this".  And what we're
talking about here is that there's cases where we might want to have a
layout suggested to the user / distribution.

-- 
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/20171116/10327508/attachment.sig>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

On Thu, Nov 16, 2017 at 12:30:04PM -0500, Tom Rini wrote:
> On Thu, Nov 16, 2017 at 11:41:57AM +0000, Andre Przywara wrote:
> > Hi,
> > 
> > On 16/11/17 11:21, Maxime Ripard wrote:
> > > On Thu, Nov 16, 2017 at 10:30:38AM +0000, Andre Przywara wrote:
> > >> Hi,
> > >>
> > >> On 15/11/17 21:03, Alexander Graf wrote:
> > >>>
> > >>>
> > >>> On 15.11.17 11:11, 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 | 7 +++++++
> > >>>>  1 file changed, 7 insertions(+)
> > >>>>
> > >>>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> > >>>> index 4391a8cbc824..11da6ccfbf54 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;" \
> > >>>> +	"name=loader2,size=984k;" \
> > >>>> +	"name=boot,size=128M,bootable;" \
> > >>>> +	"name=system,size=-;"
> > >>>
> > >>> Is there a particular reason you're creating a boot and system
> > >>> partition? In a normal distro world, the distro installer will take care
> > >>> of creating ESP + root + swap + whatever for you - and they (or the user
> > >>> driving the installation) usually know best what they need :)
> 
> So, from another part of this thread, yes, this should not be called
> boot but be called esp so it's clearer.

That works for me.

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: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171117/3fb9a60a/attachment.sig>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

On Thu, Nov 16, 2017 at 08:42:48PM +0100, Karsten Merker wrote:
> > And then on the "we" side of things, the problem here that everyone
> > needs to care about it how do we setup a partition table so that we can
> > have SPL where it's required by firmware to be.  How is this particular
> > hurdle handled today in fedora/debian/opensuse?
> 
> For Debian I have to say that it isn't currently handled at all. 
> Before this thread I wasn't even aware that it is possible to
> build a valid GPT with the SPL being where it has to be for sunxi
> devices and have therefore only used MBR-style partition tables.

You can use both alternatives I talked about in the cover letter in
gdisk, but both are experts commands and are obviously opt-in.

You can move the partition entries around by using the 'j' option, or
you can specify a smaller number of partitions using the 's' option.

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: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171117/b961cdd3/attachment.sig>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

Hi,

On Thu, Nov 16, 2017 at 11:41:57AM +0000, Andre Przywara wrote:
> >> If I understand this correctly, these are default settings for
> >> U-Boot's "mtdparts default" command, which honestly I didn't even
> >> know existed so far.
> > 
> > No, this has nothing to do with MTD. It's a default GPT partitioning
> > scheme. And only when you want to create the table from U-Boot, it
> > will not mangle with any pre-existing partition table if there is any
> > (unless you tell U-Boot to overwrite it, of course).
> 
> This is what I tried to say: It only affects you if you use U-Boot's
> partitioning command, which you probably won't do if you are running an
> off-the-shelf distribution installer. Is that understanding correct?

It is :)

> >> So in a distribution scenario I wouldn't expect somebody to actually use
> >> this. Instead you boot from a (possibly unpartitioned) SD card with just
> >> U-Boot on it or from SPI flash, then launch an installer from somewhere
> >> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
> >> And even if you use mtdpart, you can always override these default
> >> settings on the command line.
> > 
> > Like I was telling Alexander, that makes a number of assumptions, the
> > two most obvious one being that you have an installer and that you
> > want to use it, both with reasonable reasons on why they wouldn't be
> > true.
> > 
> > More tailored fit distros like ELBE, yocto or Buildroot will not have
> > an installer in the first place but an image.
> > 
> > And even if you have an installer for the distro you want to use, if
> > you ever go to production, you will not use it since the time spent to
> > flash a pre-filled image compared to running the installer is
> > significantly lower. And time is money :)
> > 
> > Just like plugging / unplugging microSD card isn't really realistic in
> > that scenario.
> 
> I don't argue this (see above) and surely understand that generic
> installers don't fly when it comes to bootstrapping devices.
> 
> But my understanding is that both Alex and Karsten don't really care
> about this usage scenario, but instead are more looking into generic
> distribution installers, which use U-Boot merely to launch grub.
> 
> Actually I wanted to help you out here by pointing out that their
> concerns don't really apply to this patch ;-)

It's good that we agree then :)

> >> Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
> >> Android-y/embedded to me (passing partition information via command line).
> >>
> >> So apart from that I think it's good to have a default FAT/ESP
> >> partition, also for storing the environment.
> > 
> > What is the typical size of the files you usually put in there? My
> > actual question being is 128MB enough, way too big or too small? The
> > environment is just 128kB big at the moment, so it looks wayyyyy to
> > big for me, but I have no idea what is usually stored in an ESP
> > partition.
> 
> 128MB is actually quite fine. I tend to use 150MB or 100MB. The Ubuntu
> arm64 kernel is around 20MB, and you may want to store more than one of
> those on the ESP, along with an initrd. I understand that distributions
> may not use the ESP for that, but their own /boot partition. But this is
> their choice. Also other OSes (BSDs?) want to use the ESP, so being too
> miserly here may backfire.

Ok. Given Alexander and Emmanuel answers, I guess that would cover it
too, so we can leave it that way :)

> Do you feel that's too big? We are talking about at least 8GB eMMCs
> mostly here, right?

Yeah, well, I guess I don't like wasted space. If you give me the
choice between a partition mostly unused or the ability to store one
more ripped CD, I'll take the latter any day. But if you guys need
that space, I'm totally fine with it.

> >> In a MBR/GPT scenario I would expect a big partition covering the whole
> >> device causes headache later on.
> > 
> > What kind of headaches?
> 
> Just thinking if an installer wants to add partitions (swap, /home, ...)
> it might be easier if some space is actually left unpartitioned.
> But that's just my non-embedded experience, where adding partitions is
> easier and safer, compared to deleting or resizing an existing partition.

I guess I also have a side question here. How do the installers deal
with the ESP partition? Would they create a new filesystem on it no
matter what, or are they a bit smarter than that?

My actual question being what will happen if one stores the U-Boot
environment on that partition, and then runs an installer? Would the
environment be gone?

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: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171117/5b5802fc/attachment.sig>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Andre Przywara]

Hi,

On 17/11/17 08:27, Maxime Ripard wrote:
> 
> I guess I also have a side question here. How do the installers deal
> with the ESP partition? Would they create a new filesystem on it no
> matter what, or are they a bit smarter than that?

I would expect any installer to not mess with the ESP. After all the ESP
belongs to the firmware, and multiboot (both multiple Linux versions as
well as other OSes like Windows or BSD) is one main feature of the ESP.

The only exception might be if the ESP is not formatted.

> My actual question being what will happen if one stores the U-Boot
> environment on that partition, and then runs an installer? Would the
> environment be gone?

I would say that the ESP is a perfect place for the environment. It's
FAT and it belongs to firmware, so OSes are just expected to *add* their
bootloaders, without touching any other file on it.

Cheers,
Andre.

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

On Fri, Nov 17, 2017 at 12:21:49PM +0000, Andre Przywara wrote:
> Hi,
> 
> On 17/11/17 08:27, Maxime Ripard wrote:
> > 
> > I guess I also have a side question here. How do the installers deal
> > with the ESP partition? Would they create a new filesystem on it no
> > matter what, or are they a bit smarter than that?
> 
> I would expect any installer to not mess with the ESP. After all the ESP
> belongs to the firmware, and multiboot (both multiple Linux versions as
> well as other OSes like Windows or BSD) is one main feature of the ESP.
> 
> The only exception might be if the ESP is not formatted.
> 
> > My actual question being what will happen if one stores the U-Boot
> > environment on that partition, and then runs an installer? Would the
> > environment be gone?
> 
> I would say that the ESP is a perfect place for the environment. It's
> FAT and it belongs to firmware, so OSes are just expected to *add* their
> bootloaders, without touching any other file on it.

Ok, perfect 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: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171117/802a909a/attachment.sig>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Alexander Graf]

On 17.11.17 14:04, Maxime Ripard wrote:
> On Fri, Nov 17, 2017 at 12:21:49PM +0000, Andre Przywara wrote:
>> Hi,
>>
>> On 17/11/17 08:27, Maxime Ripard wrote:
>>>
>>> I guess I also have a side question here. How do the installers deal
>>> with the ESP partition? Would they create a new filesystem on it no
>>> matter what, or are they a bit smarter than that?
>>
>> I would expect any installer to not mess with the ESP. After all the ESP
>> belongs to the firmware, and multiboot (both multiple Linux versions as
>> well as other OSes like Windows or BSD) is one main feature of the ESP.
>>
>> The only exception might be if the ESP is not formatted.
>>
>>> My actual question being what will happen if one stores the U-Boot
>>> environment on that partition, and then runs an installer? Would the
>>> environment be gone?
>>
>> I would say that the ESP is a perfect place for the environment. It's
>> FAT and it belongs to firmware, so OSes are just expected to *add* their
>> bootloaders, without touching any other file on it.
> 
> Ok, perfect then, thanks!

Please make sure to

  a) Format it as FAT and
  b) Mark it with the ESP GUID

though, so that it can actually be used by an installer ;)


Alex

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

Hi,

On Fri, Nov 17, 2017 at 03:20:03PM +0100, Alexander Graf wrote:
> 
> 
> On 17.11.17 14:04, Maxime Ripard wrote:
> > On Fri, Nov 17, 2017 at 12:21:49PM +0000, Andre Przywara wrote:
> >> Hi,
> >>
> >> On 17/11/17 08:27, Maxime Ripard wrote:
> >>>
> >>> I guess I also have a side question here. How do the installers deal
> >>> with the ESP partition? Would they create a new filesystem on it no
> >>> matter what, or are they a bit smarter than that?
> >>
> >> I would expect any installer to not mess with the ESP. After all the ESP
> >> belongs to the firmware, and multiboot (both multiple Linux versions as
> >> well as other OSes like Windows or BSD) is one main feature of the ESP.
> >>
> >> The only exception might be if the ESP is not formatted.
> >>
> >>> My actual question being what will happen if one stores the U-Boot
> >>> environment on that partition, and then runs an installer? Would the
> >>> environment be gone?
> >>
> >> I would say that the ESP is a perfect place for the environment. It's
> >> FAT and it belongs to firmware, so OSes are just expected to *add* their
> >> bootloaders, without touching any other file on it.
> > 
> > Ok, perfect then, thanks!
> 
> Please make sure to
> 
>   a) Format it as FAT and

That might be the toughest part :)

AFAIK, u-boot is not able to format any filesystem. We could just
flash a raw FAT filesystem though, but looking into it might help for
the environment discussion.

>   b) Mark it with the ESP GUID

That's easy thouh. What is this GUID?

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: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171120/e4d70306/attachment.sig>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Emmanuel Vadot]

On Mon, 20 Nov 2017 10:24:08 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

> Hi,
> 
> On Fri, Nov 17, 2017 at 03:20:03PM +0100, Alexander Graf wrote:
> > 
> > 
> > On 17.11.17 14:04, Maxime Ripard wrote:
> > > On Fri, Nov 17, 2017 at 12:21:49PM +0000, Andre Przywara wrote:
> > >> Hi,
> > >>
> > >> On 17/11/17 08:27, Maxime Ripard wrote:
> > >>>
> > >>> I guess I also have a side question here. How do the installers deal
> > >>> with the ESP partition? Would they create a new filesystem on it no
> > >>> matter what, or are they a bit smarter than that?
> > >>
> > >> I would expect any installer to not mess with the ESP. After all the ESP
> > >> belongs to the firmware, and multiboot (both multiple Linux versions as
> > >> well as other OSes like Windows or BSD) is one main feature of the ESP.
> > >>
> > >> The only exception might be if the ESP is not formatted.
> > >>
> > >>> My actual question being what will happen if one stores the U-Boot
> > >>> environment on that partition, and then runs an installer? Would the
> > >>> environment be gone?
> > >>
> > >> I would say that the ESP is a perfect place for the environment. It's
> > >> FAT and it belongs to firmware, so OSes are just expected to *add* their
> > >> bootloaders, without touching any other file on it.
> > > 
> > > Ok, perfect then, thanks!
> > 
> > Please make sure to
> > 
> >   a) Format it as FAT and
> 
> That might be the toughest part :)
> 
> AFAIK, u-boot is not able to format any filesystem. We could just
> flash a raw FAT filesystem though, but looking into it might help for
> the environment discussion.

 Also note that if we go to 16MB for the size you need to tweek
clusters and other properties for FAT32 as using the default ones will
not work (the minimal size is ~35MB iirc).

> >   b) Mark it with the ESP GUID
> 
> That's easy thouh. What is this GUID?
> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

On Mon, Nov 20, 2017 at 12:37:51PM +0100, Emmanuel Vadot wrote:
> On Mon, 20 Nov 2017 10:24:08 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> 
> > Hi,
> > 
> > On Fri, Nov 17, 2017 at 03:20:03PM +0100, Alexander Graf wrote:
> > > 
> > > 
> > > On 17.11.17 14:04, Maxime Ripard wrote:
> > > > On Fri, Nov 17, 2017 at 12:21:49PM +0000, Andre Przywara wrote:
> > > >> Hi,
> > > >>
> > > >> On 17/11/17 08:27, Maxime Ripard wrote:
> > > >>>
> > > >>> I guess I also have a side question here. How do the installers deal
> > > >>> with the ESP partition? Would they create a new filesystem on it no
> > > >>> matter what, or are they a bit smarter than that?
> > > >>
> > > >> I would expect any installer to not mess with the ESP. After all the ESP
> > > >> belongs to the firmware, and multiboot (both multiple Linux versions as
> > > >> well as other OSes like Windows or BSD) is one main feature of the ESP.
> > > >>
> > > >> The only exception might be if the ESP is not formatted.
> > > >>
> > > >>> My actual question being what will happen if one stores the U-Boot
> > > >>> environment on that partition, and then runs an installer? Would the
> > > >>> environment be gone?
> > > >>
> > > >> I would say that the ESP is a perfect place for the environment. It's
> > > >> FAT and it belongs to firmware, so OSes are just expected to *add* their
> > > >> bootloaders, without touching any other file on it.
> > > > 
> > > > Ok, perfect then, thanks!
> > > 
> > > Please make sure to
> > > 
> > >   a) Format it as FAT and
> > 
> > That might be the toughest part :)
> > 
> > AFAIK, u-boot is not able to format any filesystem. We could just
> > flash a raw FAT filesystem though, but looking into it might help for
> > the environment discussion.
> 
>  Also note that if we go to 16MB for the size you need to tweek
> clusters and other properties for FAT32 as using the default ones will
> not work (the minimal size is ~35MB iirc).

I guess the conclusion has been that we would stay with 128MB, so I
guess it's not a problem :)

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: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171120/0dd7f75b/attachment.sig>

[U-Boot] [PATCH 4/4] fastboot: Enable flashing by default on sunxi

[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 <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

[U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing

[Maxime Ripard]

Hi Karsten,

On Wed, Nov 15, 2017 at 09:41:34PM +0100, Karsten Merker wrote:
> > 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.
> 
> the partitioning scheme from patch no. 3 of this series looks like
> follows:
> 
> #define PARTS_DEFAULT \
>        "name=loader1,start=8k,size=32k;" \
>        "name=loader2,size=984k;" \
>        "name=boot,size=128M,bootable;" \
>        "name=system,size=-;"
> 
> I assume that the intended use is
> - loader1: SPL
> - loader2: u-boot
> - boot: Linux /boot
> - system: Linux /
> 
> AFAIK the UEFI spec requires that the EFI system partition (ESP)
> is FAT-formatted.  Most (probably all?) Linux package management
> tooling assumes that files from packages are installed onto
> filesystems that support POSIX semantics, including hardlinks,
> which FAT does not.  This means that distributions cannot re-use
> an EFI system partition as /boot and therefore need a partition
> for /boot and an additional ESP (AFAIK commonly mounted to
> /boot/efi).  I would therefore like to propose adding a small
> separate partition for use as ESP.

The original intent of the "boot" partition wasn't really to store
/boot, but to be a FAT partition to store the environment + whatever
data needed for the EFI partition.

Maybe we can rename it if it's confusing?

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: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171116/0f10f05d/attachment.sig>

[U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing

[Maxime Ripard]

Hi,

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

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

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

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

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

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

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

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[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 <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

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[André Przywara]

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
>  
> 

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

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>

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Andre Przywara]

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/

[U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

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>