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

Daniel,

Am 19.06.2016 um 16:09 schrieb Daniel Golle:

quoted

DT already offer all you need and nothing hinders you from
using mtdparts=.

I know. However, it's much nicer to define partitions for a specific
flash chip inside the device tree (I've sent a link to the DTS of the
BTHOMEHUBV2B to illustrate that, please have a look at it and tell
me if you'd really like that partitioning currently stored as
device-tree nodes to be migrated back to 'mtdparts=...'.)

I'd be fine with having the partitions in DT and the UBI kernel parameters
as kernel cmdline also in DT.

quoted

I didn't recommend adding glibc+systemd in the initramfs. It can be very, very small
and trivial.

Again, please understand that the whole production firmware can be as
small as 3.5 megs for kernel and rootfs. Of course we never use glibc
or systemd anywhere.

I know these use cases, I design and maintain such stuff for customers.

Yes, it can be done. But you would have to define your flash chips in
device-tree, you may define the mtd partitions either in DT or by using
mtdparts=... in the cmdline. Now to define which MTD device to
ubiattach you will have to use ubi.mtd=X on the cmdline. If you defined
your partitions inside the of_node of the flash chip, changes there
(which do happen) may change the index of the partition you want to
ubi-attach. C'mon. This *is* messy. Just having a compatible-flag to
attach the partition would already greatly improve things.

You mean marking a MTD partition in DT and UBI will attach from it?
That makes sense.

To sum up, I asked a lot of questions to understand your use case(s).
Everything you described can be done with existing facilities.
But I agree that at least some UBI DT machinery would be nice to have
although we need to check with DT folks first.
At least marking an MTD partition should be fine, hopefully.

Brian, Boris, what do you think?

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html