Hi Richard, On Sun, Jun 19, 2016 at 04:35:05PM +0200, Richard Weinberger wrote: > Daniel, > > Am 19.06.2016 um 16:09 schrieb Daniel Golle: > >> 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. That's the current state of affairs. I'd just want to have it in one place, so if the MTD partitioning gets updated one would see easily how that affects UBI. For that, I don't think it's good enough to have 'ubi.mtd=X' in the cmdline (in DT or wherever, it's a single string in a different place than the MTD partitioning if people use DT for MTD partitioning). > > >> 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. Yes. Currently we just use a naming convention (the first MTD partition named 'ubi' will be auto-attached), that's obviously not very clean... > > 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. Great. That'd already greatly improve things. I can see that sooner or later we will need some way to reference UBI volumes in DT, independently of the whole rootfs selection. Vendors do use UBI volumes also for things like WiFi EEPROM data. Currentlhy, we extract that in user-space and save a copy in /lib/firmware/... for things more crazy than plain offsets inside MTD partitions. Cheers Daniel > > Brian, Boris, what do you think? > > Thanks, > //richard > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
