From: briannorris@chromium.org (Brian Norris)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
Date: Thu, 5 Jan 2017 09:56:20 -0800 [thread overview]
Message-ID: <20170105175619.GA56877@google.com> (raw)
In-Reply-To: <20170105171845.GK4310@atomide.com>
On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [170105 07:37]:
> > * Teresa Remmet <t.remmet@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
next prev parent reply other threads:[~2017-01-05 17:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-05 14:50 [PATCH 0/6] ARM: dts: phyBOARD-WEGA-AM335x updates Teresa Remmet
2017-01-05 14:50 ` [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table Teresa Remmet
2017-01-05 15:36 ` Tony Lindgren
2017-01-05 17:18 ` Tony Lindgren
2017-01-05 17:56 ` Brian Norris [this message]
2017-01-06 9:27 ` Teresa Remmet
2017-01-06 16:02 ` Tony Lindgren
2017-01-06 16:05 ` Adam Ford
2017-01-06 16:14 ` Tony Lindgren
2017-01-06 18:20 ` Brian Norris
2017-01-06 18:43 ` Tony Lindgren
2017-01-06 17:39 ` Ladislav Michl
2017-01-05 14:50 ` [PATCH 2/6] ARM: dts: am335x-phycore-som: Update compatible string for spi nor Teresa Remmet
2017-01-05 14:50 ` [PATCH 3/6] ARM: dts: am335x-phycore-som: Add i2c temp sensor Teresa Remmet
2017-01-05 14:50 ` [PATCH 4/6] ARM: dts: am335x-wega: Set USB0 mode to otg Teresa Remmet
2017-01-05 14:50 ` [PATCH 5/6] ARM: dts: am335x-phycore-som: Update ethernet phy node Teresa Remmet
2017-01-05 14:50 ` [PATCH 6/6] ARM: dts: am335x-wega: " Teresa Remmet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170105175619.GA56877@google.com \
--to=briannorris@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).