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

Hauke Mehrtens hauke at hauke-m.de
Mon Jun 20 14:18:45 PDT 2016


On 06/20/2016 09:57 PM, Richard Weinberger wrote:
> Am 20.06.2016 um 17:08 schrieb Arnd Bergmann:
>>> Since blocks on a MTD can render bad you'd lose the table sooner or later.
>>> That's why we cannot store it on the MTD directly.
>>> Defining the table in DT is at least less ugly than using the mtdparts=
>>> kernel parameter.
>>
>> Right, there would be no benefit in using the kernel command line,
>> it just moves the information to another place inside of the same DT
>> (the /chosen property).
>>
>> I think you can normally rely on the first block being readable
>> on flash, in particular if you write it very rarely (when updating
>> the partition information), so it would be technically possible to
>> have a partition table in there, but in practice that's not how
>> things are done, so the argument is useless.
> 
> Speaking of NAND, only SLC (and also here not all) chips guarantee that the first
> block is better than the other ones.

Being able to define a rootfs the kernel should load with a /chosen
property would also be nice.

https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt

These UBI patches were just one step to make it possible to define the
root partition in device tree. It would probably be better to first look
on how to do that with normal mtd partitions and then see how to extend
that to UBI.

Currently I have to extend the boot args with these parameters to boot a
unmodified mainline kernel: "ubi.mtd=ubi ubi.block=0,rootfsA
root=/dev/ubiblock0_1"
This is a SquashFS in a UBI layer on a mtd partition. I know that I can
put this into the bootargs in a device tree file.

Hauke



More information about the linux-mtd mailing list