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=. >> >>>> >>>>> 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. At least it would be much more clean than your pile of not so fancy MTD/UBI patches. > 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. >> 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. 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
