[PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table

Brian Norris briannorris at chromium.org
Thu Jan 5 09:56:20 PST 2017


On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony at atomide.com> [170105 07:37]:
> > * Teresa Remmet <t.remmet at phytec.de> [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



More information about the linux-arm-kernel mailing list