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 <chr...@rtems.org>
> Sent: Wednesday, March 10, 2021 7:28 PM
> To: Sommer, Jan <jan.som...@dlr.de>; devel@rtems.org
> Subject: Re: Flashdisk driver based on spidev
>
> 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
