On Wed, Jul 25, 2018 at 06:27:45PM +0200, Andreas Kemnade wrote: > 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? 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
