On 06/24/2016 08:28 PM, Ezequiel Garcia wrote: > On 18 June 2016 at 16:35, Hauke Mehrtens <hauke@xxxxxxxxxx> wrote: >> On 06/18/2016 09:30 PM, Richard Weinberger wrote: >>> Am 18.06.2016 um 21:17 schrieb Hauke Mehrtens: >>>> This makes it possible to open a ubi layer in device tree, this is >>>> helpful when the rootfs is on a ubi layer. It loops though all mtd >>>> partitions and mounts the partition which is compatible with >>>> "ubi,volume". The same was only possible with kernel command line >>>> arguments before. >>>> >>>> Signed-off-by: Hauke Mehrtens <hauke@xxxxxxxxxx> >>>> --- >>>> Documentation/devicetree/bindings/mtd/ubi.txt | 33 ++++++++++++++ >>>> drivers/mtd/ubi/block.c | 63 +++++++++++++++++++++++++++ >>>> 2 files changed, 96 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/mtd/ubi.txt >>> >>> Some time ago I thought about an UBI DT binding too, but >>> I have been told that device tree is only for describing the hardware >>> and nothing else. >>> So I fear this will be rejected by DT folks. >> >> There are some devices on the market that are storing the root file >> system in an ubi layer. >> To make this work there are currently two options. >> 1. patch the kernel to specify which partitions to open in the code. > > I wouldn't go as far as to claim this an option. I would also not do this, but when you look into the Linux patches of "professional" embedded devices you see many strange things. > >> 2. provide some kernel command line parameter which specifies what to open. >> > > There's another option: use an initramfs, where you can do whatever you want > to find your UBI and mount it. An initramfs probably needs some 10 to 100 KBytes of additional memory on the flash chip and we only have 4 MBytes on some devices for the bootloader, kernel and rootfs, adding 100 KBytes there is a significant amount of memory. Instead of adding a initramfs I would like to be able to define the rootfs somewhere in device tree and not by adding a bootargs line into device tree. These particular patches are probably the wrong way, but nobody told me how to do this in a better way. > Frankly, I don't see a real need for this in the devicetree, other than solving > someone's particular workflow/use case. -- 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
