[PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"

[Miquel Raynal]

On 03/07/2026 at 07:45:56 +02, Richard Weinberger <richard at nod.at> wrote:

> ----- Ursprüngliche Mail -----
>> Von: "Ronan Dalton" <Ronan.Dalton at alliedtelesis.co.nz>
>> On Thu, 2026-07-02 at 07:39 +0200, Richard Weinberger wrote:
>>> Do you really need (POSIX) file system semantics?
>>> You could partition the FRAM into cells and then work with them.
>>> e.g. Just dd into it and erase it when needed...
>>> Maybe the NVMEM cells mechanism needs some polishing but this sounds
>>> reasonable to me.
>> 
>> Yes, that could work for secrets storage. However we also store
>> persistent logs and DHCP leases on this flash to minimize read/writes
>> on the main flash, and this data is stored as files of varying lengths.
>> A filesystem provides the most straightforward way of storing this data
>> for us.
>
> But the storage (FRAM) you chose is not suitable for any real filesystem.
> In a previous mail you said you use ext2 on it.
> I have a hard time to see how using ext2 on top of mtdblock on an FRAM
> does not end in a disaster.
>
>> That's not to say we couldn't develop some system of using the nvmem
>> device as a backend for this data. This may be something we look at in
>> the future.
>
> Maybe FUSE can help with building a super simple filesystem which provides
> just enough to fulfill your use case.

The NVMEM cells mechanism is very flexible now with layouts. We do have
support for ONIE Type-Length-Variable tables as well as an example of
support for the environment variables in U-Boot. If you format very
slightly your data you can very easily expose automatically one cell per
information with a rather simple NVMEM layout driver and consume it this
way.

Thanks,
Miquèl