On Thu, 16 Nov 2017 12:54:13 +0100 Alexander Graf <ag...@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.rip...@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@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Emmanuel Vadot <m...@bidouilliste.com> <m...@freebsd.org> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot