[PATCH 1/2] ubi: mount partitions specified in device tree

[Brian Norris]

On Mon, Jun 20, 2016 at 05:08:51PM +0200, Arnd Bergmann wrote:
> On Monday, June 20, 2016 10:26:11 AM CEST Richard Weinberger wrote:
> > Am 20.06.2016 um 10:09 schrieb Arnd Bergmann:
> > > - MTD partitioning unfortunately does not seem to have a widely used
> > >   method for identifying partitions from what's stored on the flash,
> > >   unlike block devices, so whatever we normally have in the partition
> > >   table has to be stored in DT. This really sucks, but I don't know
> > >   what else to do about it.
> > 
> > Since blocks on a MTD can render bad you'd lose the table sooner or later.
> > That's why we cannot store it on the MTD directly.

That's assuming you're talking about NAND, and that no one has devised
any clever partition scheme that is robust against bad blocks. I've seen
attempts at the latter, but nothing widely used. And eventually, you're
just reimplementing UBI anyway.

About the former: some systems will still use a dual-flash system, where
they get reliable partition information from a NOR flash to bootstrap
getting the NAND up and running. So it's possible to avoid sticking all
partitions in DT.

> > Defining the table in DT is at least less ugly than using the mtdparts=
> > kernel parameter.
> 
> Right, there would be no benefit in using the kernel command line,
> it just moves the information to another place inside of the same DT
> (the /chosen property).
> 
> I think you can normally rely on the first block being readable
> on flash, in particular if you write it very rarely (when updating
> the partition information), so it would be technically possible to
> have a partition table in there, but in practice that's not how
> things are done, so the argument is useless.

It's not completely useless, but it's difficult for real technical
reasons: many SoCs boot straight off address 0 of a flash (hopefully
something reliable like NOR flash, but I've even seen that for NAND...),
so you can't possibly put a partition table there. That doesn't preclude
coming up with a decent non-0-address-based scheme, but nobody's really
done that generically, although there are various vendor-specific
attempts to just progressively scan all blocks on the flash -- see a few
drivers/mtd/*part.c.

Brian