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

Thu Nov 16 12:32:29 UTC 2017

On Thu, 16 Nov 2017 12:54:13 +0100
Alexander Graf <agraf at 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 at 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 at bidouilliste.com> <manu at freebsd.org>