Hello Brian, Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris: > On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote: > > > > * Tony Lindgren <tony@xxxxxxxxxxx> [170105 07:37]: > > > > > > * Teresa Remmet <t.remmet@xxxxxxxxx> [170105 06:57]: > > > > > > > > To improve NAND safety we updated the partition layout. > > > > Added barebox backup partition and removed kernel and oftree > > > > partition. They are kept in ubi now. > > > What about the users with earlier partition tables? > > > > > > Please read about "flag day" changes, typically they are not > > > acceptable. > > Adding Brian and Adam to Cc. Can you guys come up with some > > solution on this? > I don't have much context for this thread, and no I don't plan to > solve > your problems for you. But I can provide tips! > > > > > I'm suggesting we leave the kernel nodes empty and let u-boot > > populate them, so maybe you guys can discuss this on the related > > lists. > That's an option. I've worked with platforms that did something like > this, and that's really one of the only ways you can handle putting > partition information in the device tree. You're really hamstringing > yourself when you put all the partition information in the device > tree. > And it's just dumb once that gets codified in the kernel source tree. > In our case the bootloader does pass the partition table to the kernel. So it gets overwritten anyway. This was just more for backup, if someone uses a different bootloader. But I'm fine with removing the nand partition table completely from the kernel device tree. Same with the SPI nor partition table. I will send patches for this. Regards, Teresa > The best solution would be to try to migrate away from static device > tree representations of partition info entirely. UBI volumes are best > where possible. If not, then some other kind of on-flash data > structures > (along the lines of a GPT) with a corresponding MTD partition parser > is > an OK alternative. Unfortunately, there isn't any good standard > format > for this on MTD, so it's typically all custom -- and so people use > the > easiest approach: device tree. And it's even more difficult with > NAND, > which has reliability problems, especially with static data (e.g., > read > disturb). > > Anyway, the parser solution is helpful only if one can properly fix > the > "flag day" first. And it requires a little bit more work to be > generally > useful; I posted some work for this over a year ago, but bikeshedding > brought it down. > > > > > The rest of the series looks fine to me so applying it into > > omap-for-v4.11/dt. > Brian > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
