Hi Richard, On Sun, Jun 19, 2016 at 03:19:38PM +0200, Richard Weinberger wrote: > Daniel, > > Am 19.06.2016 um 15:05 schrieb Daniel Golle: > >>> The same kernel gets used on many devices having different $vendor > >>> mtd-partition layouts. A way other than the kernel cmdline allows > >>> to specify the default behaviour without restricting the user to > >>> manually use those cmdline options. > >> > >> You can put the cmdline into the per-device device tree. > >> This is the concept of a multi-device kernel. One kernel and > >> many device trees. > > > > Exactly true. However, as the mtd partitions are defined in the tree > > itself rather than using 'mtdparts=...' in the cmdline built-into the > > device-tree, it'd be nice to also select that a specific partition > > should be ubiattached. > > 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=...'.) > > >> > >>>> > >>>>> To auto-select the rootfs, we currently carry another bunch of patches > >>>>> > >>>>> https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/491-ubi-auto-create-ubiblock-device-for-rootfs.patch > >>>> > >>>> Same question here. > >>>> > >>>>> https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch > >>>> > >>>> Ditto. > >>>> > >>>>> https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch > >>>> > >>>> Ditto. > >>>> > >>> > >>> Same arguments as above. In addition, we do not want to hard-code the > >>> filesystem type used for the rootfs volume, as it can either be UBIFS > >>> or a read-only filesystem needing a ubiblock device. Thus we would > >>> need the bootloader to know which filesystem *type* is being used and > >>> then decide wether to pass 'rootfs=ubiX:Y' or > >>> 'ubiblock=... rootfs=/dev/ubiblock0'. > >> > >> What is wrong with having a very minimal initramfs to do such an > >> auto discovery logic? > > > > Sorry, but we are not talking about traditional desktop or server > > systems. OpenWrt/LEDE runs on devices with as little as 32 MB of RAM > > and 4 MB of Flash. Devices with UBI will typically have at least > > 32 MB of NAND Flash, but still not necessarily a lot of RAM. > > Have a look at > > https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/lantiq/dts/BTHOMEHUBV2B.dts > > for a good example of the type of hardware we are talking about. > > 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. What you imagine to be the ways to make a initramfs really small is what we already do for *all* our system, ie. we use busybox on top of a very tiny libc. > At least it would be much more clean than your pile of not so fancy MTD/UBI patches. > In the end, do_mounts.c is already running in user-space, just the source-code happens to be part of the kernel tree. Sure, that could become a seperate executable binary which mounts the rootfs and then passes control to /sbin/init. On the other hand that would add quite some redundant infrastructure, because we already got ROOT_DEV and lots of automagic mounting going on in the kernel. > > Apart from that we already automatically generate initramfs-based > > images for devices to be used in situations where you cannot or don't > > want to touch the devices' flash. > > The initramfs can be part of the kernel image. No additional file needed. That's excatctly what we've already been doing for initramfs-only images, see e.g. http://downloads.lede-project.org/snapshots/targets/lantiq/xway/lede-lantiq-xway-BTHOMEHUBV2B-uImage-initramfs So if we need an initramfs to mount the on-flash rootfs and *another* initfamfs containing the whole system for other cases, things become even more fishy on our side. But yes, I'm aware that this would be possible. > > >> This is something you need to discuss wit DT folks. > >> I'm not per se against UBI DT bindings it just does not feel right > >> and contradicts my understanding of it. > > > > I agree with your view when it comes to describing UBI volumes > > in the device tree. That's wrong just as it would be wrong to add > > DT bindings for LVM2. > > As said previously, the situation is different for flash chips having > > partitions defined for use with UBI on some boards. > > Everything can be done with the existing framework. DT binding maybe be nice > for your use case but I fear it is not applicable. 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. Hauke: Maybe we should discuss the two patches individually, as I feel that ubiattaching specific mtd partitions flagged in DT is quite straight forward, while specifying volumes inside the ubi device might be out-of-scope. Cheers Daniel > > 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
