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

[Ladislav Michl]

On Tue, Jun 07, 2016 at 09:43:20AM +0200, Michal Suchanek wrote:
> On 6 June 2016 at 23:21, Ladislav Michl <ladis at linux-mips.org> wrote:
> > On Mon, Jun 06, 2016 at 08:50:55PM +0200, Michal Suchanek wrote:
> > Linux already depends on U-Boot as U-Boot feeds Linux with MTD partitions.
> 
> No. It depends on getting the partition layout on commandline or in
> DT. This can be something U-Boot generates, or something it passes on
> from its environment or something it does not touch at all.

I really fail to understand how your wording conflicts with what I wrote
above. Both cmdline and DT are provided by bootloader, so Linux depends on
that. Unlike HDD for example where its layout is stored on media in the
partition table.

> > So this patch does not introduce any change in this regard. And whenever
> > are paritions altered by user, saved to U-Boot environment or default
> > layout provided according actual eraseblock size is just not important
> > here. In the end both U-Boot and Linux are working with the same partition
> > layout. This is the only thing that matters and this patch does not change
> 
> But for the layout to be correct you must build current u-boot with
> this patch and not use compiled-in command line, devicetree, older
> u-boot or different bootloader.

No, layout is correct as it is for all boards I have there. But I was told
boards with different NAND chips were produced. Also I have to change
paritioning anyway, as original solution does not work in long term and
devices are failing in field. I'm not proposing to break any existing setup.
Your solution does the contrary as it requires both recent U-Boot and recent
kernel. Also, that function is only helper one. If you decide to use static
defaults, I'm fine with that. But with above patch, every user of that board
will start with sane and optimal defaults. This is the sole point.
Also I'm pretty sure previous patch which enables mtdparts to use defaults
implicitely will not break anything, otherwise someone would notice bugs
present in mtdparts code. (Perhaps it's time to read UBI SPL patch serie
and related discusion for a reason I started to work on that)

> > that. It changes only this: instead of hardcoding default layout into string
> > provided at compile time, there is now posibility to create that string
> > runtime. That's all.
> 
> The only problem with that is that the code for generating the string
> is in u-boot and the string is needed in Linux so the logical thing is
> to move the code to Linux where it is needed.

No. The string is needed in both U-Boot _and_ Linux. I see no reason to
change kernel as it is not byuig anything.

> > And now... Your recomended solution is to change both U-Boot and Linux
> > to understand partition layout based on indexes and sizes expressed
> > in eraseblocks. While size of SPL could be nicely evaluated in terms
> > of eraseblocks, it is a bit more complicated with kernel partition,
> > because 10 eraseblocks says nothing about partition size, therefore
> > you cannot say whenever kernel will fit that space without knowledge
> > of eraseblock size.
> 
> That's why you need the possibility to start a partition at the end of
> preceding partition. That way you can have sizes of different
> partitions in different units.

That posibility is already there for ages.

> It's interesting that your firmware uses erase block size for the boot
> partition. The sunxi firmware loads the bootloader from fixed number
> of pages.

DM3730 tries to load from first eraseblock, if that fails, then second
and finaly gives up at fourth (including).

> > So you just reverted the problem and both U-Boot
> > and Linux would end with more code to be maintained for compatibility.
> 
> Yes, if you want U-Boot and Linux to talk the same units you need both
> implementing the code to handle them. Still U-Boot will only need to
> pass around a string with partition layout and parse it in the cases
> it is accessing the partitions.

And since U-Boot environment is usually stored in partition(s)...
Also note that this change will break non-Linux systems and older Linux
systems. And as you said, I'm doing that to save few megabytes on media,
so now it seems to be too high price even to me.

Best regards,
	ladis