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

[Richard Weinberger]

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