nvmem: Defining cells on mtd created by mtdparts
sven at narfation.org
Tue Oct 12 11:59:29 PDT 2021
On Tuesday, 12 October 2021 20:24:46 CEST Pratyush Yadav wrote:
> I have been wanting to fix this problem for a while but just never got
> around to it. I was thinking about either extending the mtdparts syntax
> to maybe add nvmem cell information in there or adding a separate
> cmdline argument that complements mtdparts with nvmem cell info. Dunno
> if either of these would work well though...
At least for the devices I have in mind, this doesn't seem to be a good
solution. The devices are shipped since years and the bootloader isn't updated
with firmware updates. So changing to a different mtdparts might sometimes not
be easily possible.
But this might help in situations which don't have this limitation.
> > Ansuel Smith just proposed in OpenWrt  a workaround. It basically adds a
> > minimal fixed-partitions parser to the mtd cmdlinepart parser (responsible for
> > the mtdparts=) that tries to find the matching (size + offset) fixed-partition
> > from the devicetree. The code in mtd_device_parse_register
> > (add_mtd_partitions -> add_mtd_device -> mtd_nvmem_add) will then
> > automatically take care of the rest.
> I don't quite see how this helps. You say that some devices don't have a
> device tree at all so how would you even match the fixed partition? And
> this of course doesn't solve the problem where you might want nvmem
> cells with a partition layout that is different from the one in device
I personally had a different thing in mind. The situation for OpenWrt's ath79
target (and Linux's ath79) is that they use DTs and some of these devices are
still using some information which are not part of the device tree. But the
DT partitions for the nvmem-cells MUST match the ones in mtdparts
But you are right, this will definitely not solve situations when there is no
DT used. And didn't say that I needed a solution for this - I was (hopefully)
always referring to devices which use mtdparts (which can also be used with
devices which are using DTs)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the openwrt-devel