On Tue, Jun 07, 2016 at 09:43:20AM +0200, Michal Suchanek wrote:
On 6 June 2016 at 23:21, Ladislav Michl ladis@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