Am 20.06.2016 um 10:09 schrieb Arnd Bergmann: > A few more thoughts on various things that came up in the discussion > so far (so I don't have to reply to each of them separately) > > - The /chosen and /aliases nodes do configure the OS to some degree, > and historically we have used them to specify the device names that > show up in the kernel (e.g. on MacOS and AIX) as well as the rootfs > itself > > - The device tree should give us enough information to identify the > root partition by a GUID from the kernel. This works on all block > devices (at least with MBR and EFI partition tables, probably many > of the lesser known ones as well) and it should really also work > on UBI. It does. > - MTD partitioning unfortunately does not seem to have a widely used > method for identifying partitions from what's stored on the flash, > unlike block devices, so whatever we normally have in the partition > table has to be stored in DT. This really sucks, but I don't know > what else to do about it. 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. > - The UBI design was originally meant to cover the entire flash > device and provide the partitioning information inside. I have not > looked at UBI in a long time (actually not since before embedded > PPC moved to DT), but I would hope that this case works without > any DT magic. Of course it works without DT magic. So, I don't see a urge to have UBI DT bindings. First I thought having an attach flag would be handy but it turned out that this behavior can easily achieved by naming. i.e. you a kernel command line such as "ubi.mtd=UBI" and name the to be attached MTD "UBI" in your DT. 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
