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. 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 -- 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
