On 11/3/21 12:59 am, jan.som...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
