Am 25.07.2018 um 10:33 schrieb Ladislav Michl [off-list ref]:

On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote:

quoted

quoted

Am 25.07.2018 um 10:07 schrieb Ladislav Michl [off-list ref]:

On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote:

quoted

Vendor defined U-Boot has changed the partition scheme a while ago:

* kernel partition 6MB
* file system partition uses the remainder up to end of the NAND
* increased size of the environment partition (to get an OneNAND compatible base address)
* shrink the U-Boot partition

Let's be compatible (e.g. Debian kernel built from upstream).

That, in fact, is breaking compatibility.

With what? Nobody is using the old u-boot partition scheme any more
(it is >5 years old).

quoted

So once you are touching this
what about relying on partitioning provided by bootloader just to prevent
something like this happening again?

Well, we define what compatible means here (since we are the vendor).
And people complain with us. We simply recommend them to upgrade the
boot-loader.

Fair enough. Suggestion was to remove partitioning scheme from DTB alltogether
and let U-Boot provide one. But you being vendor you decide, of course :)
(I'd use only two partitions: MLO and UBI, latter one with BCH8, and store
everything in UBI volumes. That's a bit more flexible approach)

Yes, that is a good goal for a future setup and would of course be better.
Like U-Boot already provides the memory layout for RAM.

Hopefully, someone will work out patches for u-boot plus kernel (which is always
painful to keep these two in sync and tested). But I don't want to do that now.

BR and thanks,
Nikolaus