Flashdisk driver based on spidev

Chris Johns chrisj at rtems.org
Wed Mar 10 18:27:42 UTC 2021


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


More information about the devel mailing list