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