[U-Boot] [PATCH 5/6] cmd: mtdparts: support runtime generated mtdparts

[Ladislav Michl <ladis@linux-mips.org>]

On Sun, Jun 05, 2016 at 07:58:46PM +0200, Michal Suchanek wrote:
> Hello,
> 
> On 5 June 2016 at 19:43, Ladislav Michl <ladis@linux-mips.org> wrote:
> > Some CPUs contains boot ROM code capable reading first few blocks
> > (where SPL resides) of NAND flash and executing it. It is wise to
> > create separate partition here for SPL. As block size depends on
> > NAND chip used, we could either use worst case (biggest) partition
> > size or base its size on actual block size. This patch adds support
> > for the latter option.
> >
> 
> There is similar problem on sunxi.
> 
> Given this flash is non-removable and has many pins you are unlikely
> going to encounter its content on any system that was not loaded with
> u-boot.
> 
> Still Linux can only produce fixed size mtdparts. You can prepend
> perfectly sized mtdparts for u-boot but until Linux is taught to
> follow that with its own partitions without gap you still need to use
> the worst case scenario for the start of the Linux partitions.

I didn't get 'fixed size mtdparts' part. Linux supports cmdline
partition layout passing since the dawn of mtd subsystem (I used it more
than a decade ago for netstar board). Finally that's a reason mtdparts
implementation in U-Boot is done this way. Both U-Boot and Linux (can)
see the same partition layout as it is passed either via kernel cmdline
or device tree blob.

> On sunxi the range of supported block sizes and the size of the
> SPL+U-BOOT are not large so this is generally not worth the effort.
> 
> If support for this is attempted Linux should be probably taught to
> get mtdparts in pages and eraseblocks and then the default mtdparts
> can be in those.
> 
> If on the other hand you generate the fixed layout for Linux
> partitions on the fly and this patch changes how the Linux partitions
> are generated it can happen that the Linux partitions are at different
> place with different versions of u-boot giving potentially disastrous
> results.

Unless I'm missing something, partition layout is passed to the kernel
from the bootloader. So if kernel ends up with a different layout than
a bootloader, there's a bug somewhere and that should be fixed.

Regards,
	ladis