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. >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
