Flashdisk driver based on spidev

[Jan.Sommer at dlr.de]

Thanks for all the pointers Chris, I will do some more research and see if I get a better idea how to go about this.

Best regards,
    Jan

> -----Original Message-----
> From: Chris Johns <chrisj at rtems.org>
> Sent: Wednesday, March 10, 2021 7:28 PM
> To: Sommer, Jan <Jan.Sommer at dlr.de>; devel at rtems.org
> Subject: Re: Flashdisk driver based on spidev
> 
> On 11/3/21 12:59 am, Jan.Sommer at dlr.de wrote:
> > Hello,
> >
> > We will probably at some point need support for Micron-based NOR-flash
> devices to store data which are connected via SPI.
> > I found the flashdisk API in RTEMS and was wondering if I understand
> everything correctly.
> > My idea would be to have the layers like this:
> > spidev-driver <-- micron-flashdisk-driver <-- (libblock?) <--
> > jffs2-filesystem <-- POSIX file operations
> >
> > Another option would be to have the flashdisk-driver do the SPI
> transaction itself, but I am not sure if there is a lot performance to gain.
> > The bus setup will not change between consecutive read/write accesses to
> the memory (except for CS if multiple flash devices are present).
> > From my work with the spidev drivers, which are currently in review, the
> overhead didn't seem very big to me for these conditions considering that
> writes will always be in the kB range due to the sector size.
> > Using the spidev API would have the benefit that the same flashdisk driver
> can be used with different SPI devices.
> >
> > Are these assumptions reasonable or does someone have further
> suggestions to consider?
> >
> 
> I do not think the JFFS2 will sit on top of libblock. The flashdisk does block
> management and I am not sure you want that with JFFSv2,
> 
> I suggest a CFI based NOR flash chip driver that uses the QSPI driver. Then a
> file to glue it to JFFS2. The flash chip driver needs to provide:
> 
>  - open
>  - read   - hooked to JFFSv2
>  - write  - hooked to JFFSv2
>  - erase  - hooked to JFFSv2
>  - close  - hooked to JFFSv2 destroy
> 
> I would also considering supporting a base and size in the JFFS flash chip glue.
> This lets you leave the bottom part of a boot QSPI flash to support a boot and
> factory image (anti-bricking) set of blocks. I have also used a top block to hold
> factory settings in some Zynq devices.
> 
> Chris