On Wed, Jul 25, 2018 at 06:27:45PM +0200, Andreas Kemnade wrote:

On Wed, 25 Jul 2018 10:33:05 +0200
Ladislav Michl [off-list ref] wrote:

quoted

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)

hmm, so using mtdparts kernel commandline parameter? Somehow it sounds
to be sane to not have partition tables in kernel. What only is needed
is to have a nice transition scheme for systems in the wild, can
commandline mtdparts overwrite dtb? So dtb is a fallback?

That's beginning to be offtopic here...  Anyway, see U-Boot's
CONFIG_FDT_FIXUP_PARTITIONS. Probably better to start a thread on
U-Boot mailing list if needed.

But I think all that is a future improvement?

Depends on vendor decision, it could be done in a few days :)

Best regards,
	ladis