On Wed, 25 Jul 2018 10:33:05 +0200 Ladislav Michl <ladis@xxxxxxxxxxxxxx> wrote: > On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote: > > > > > Am 25.07.2018 um 10:07 schrieb Ladislav Michl <ladis@xxxxxxxxxxxxxx>: > > > > > > On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote: > > >> 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). > > > > > 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? But I think all that is a future improvement? Regards, Andreas
Attachment:
pgpqkDBMappVd.pgp
Description: OpenPGP digital signature
