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

[Michal Suchanek]

On 5 June 2016 at 20:23, Ladislav Michl <ladis at linux-mips.org> wrote:
> On Sun, Jun 05, 2016 at 07:58:46PM +0200, Michal Suchanek wrote:
>> Hello,
>>
>> On 5 June 2016 at 19:43, Ladislav Michl <ladis at 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

Sure.

It does not, however, support size in anything but some kind of fixed
size blocks.

It cannot adjust the layout for different media page size or erase
block size. It cannot specify that a partition follows after another
or extends to the end of medium.

What you specify on the commandline is in no way related to the actual
medium you are partitioning.

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

That's not it. The problem is that if this patch changes the layout
then building u-boot before this patch gives one layout and after this
patch it gives another layout effectively changing the partitioning.
All to save a few megabytes of a several gigiabyte medium. And if you
say that people can always set the partitioning by hand then it
completely defeats the purpose of fine-tuning the default in the first
place.

If on the other hand Linux got support for sizing partitions in nand
pages or eraseblocks and a patch changed the mtdparts layout to use
the new units then either both u-boot and Linux support the units or
parsing the partition fails. So it's safe and flexible and more
general and probably even less work on u-boot's part.

Thanks

Michal