[En-Nut-Discussion] Different dataflash APIs: NUTSERIALFLASH <-> NUTBLOCKIO

[Harald Kipp]

Hi Ole,

On 15.01.2015 16:13, Ole Reinhardt wrote:

> What i found is:
> 
> - We have several different drivers for the AT45d* flash devices

This general statement deserves a general confirmation: Yes! ;-)


> - We have two different APIs
> 
>   * NUTSERIALFLASH
>   * NUTBLOCKIO

NUTBLOCKIO is a different concept, in use, for example, for the raw file
system. In general, it can only read and write full pages.

NUTSERIALFLASH drivers provide a hardware-independent utility layer for
file systems. As a specific feature, they do not need any internal
record buffers. This makes them suitable for devices with a few hundred
bytes of RAM, even if the flash page size is 1k or more. As a result,
its API is far more complicated than NUTBLOCKIO.

Access to the SPI hardware is done via NUTSPIBUS drivers:
http://www.ethernut.de/en/documents/ntn-6_spi.html

uFlash is a very special beast and comes with several limitations. It
doesn't use nodes and just simulates subdirectories in a fixed directory
space. As a side note: The initial idea was to use 16-bit _integers_ as
filenames! But that would have required too many changes in the HTTP/FTP
servers. ;-)

Accessing the serial flash without page buffers in RAM (NUTSERIALFLASH
in spi_at45dib.c) can be quite slow. Saving large binaries like MP3
files became a PITA. Therefore a faster but more memory hungry version
(NUTSERIALFLASH in spi_flash_at45d.c) had been added later.


> Uflashfs only works together with the NUTSERIALFLASH API.

Yes, I created it for an IP/SNA gateway, which was based on Ethernut 2.
As an additional requirement, we needed to update the web content via
ftp and, most important, write various log files. The whole thing needs
to be immune to power failures. Last not least, we had only a few
hundred bytes of RAM left to implement this. It was a lot of fun to
implement a journaling file system under such conditions. I'm still
wondering how much time we had in these days.


> Further more it looks like no filesystem driver, or any other code uses
> the NUTBLOCKIO API based drivers.

Well, IMHO it is actually the other way round. Almost all access to
external flash is done via NUTBLOCKIO. For SPI this is normally done via
blockdev.c. Note, that also MMC access for the PHAT filesystem uses this
layer. Therefore, it should be possible to run PHAT on an SPI flash...of
course not very useful without wear-leveling and journaling like uFlash.
A power loss at a specific point may make the file system unusable
within a millisecond.


> My question: Why do we have two different driver APIs for serial flash
> devices, and what is the NUTBLOCKIO API is used for? Especially we have
> more flash drivers providing the NUTBLOCKIO API than the NUTSERIALFLASH API?

In short: NUTSERIALFLASH was done to provide an API for insane file
systems in extreme low memory situations. NUTBLOCKIO is the way used by
all other file systems, which can afford to keep several records in RAM.

In our latest product we have a single Adesto dataflash with the
following configuration:

NUT_CONFIG_AT45D = "0"
NUT_CONFIG_AT45D_CS = "0"
NUT_CONFIG_AT45D_PAGE = "8132"
NUT_CONFIG_AT45D_SIZE = "2112"
FLASH_MOUNT_OFFSET_AT45D0 = "0"
FLASH_MOUNT_TOP_RESERVE_AT45D0 = "4096"
BLKIO_MOUNT_OFFSET_AT45D0 = "4096"
BLKIO_MOUNT_TOP_RESERVE_AT45D0 = "60"
UFLASH_MAX_PATH = "128"
UFLASH_USE_TIMESTAMP = ""
UFLASH_USAGE_CACHE = "32"

Using the output from meminfo.c in app/editconf gives:

Driver  : AT45D0
Pages   : 8192
uFlash  :    0 - 4095
Raw     : 4096 - 8131
Config  : 8132 - 8191
ConfSize: 2112

However, a few first tests showed, that uFlash doesn't seem to work
reliable on this Cortex hardware. Many things had changed since the time
I implemented the first uFlash version on an ATmega. So I'm not sure if
this is a platform-specific problem or caused by other general changes.
We just reserved the space for uFlash in this product, but use UROM and
rawFS only.


> And to not invent the wheel twice: Does anybody have implemented a
> NUTSERIALFLASH style driver for the AT25 chips yet?

IMHO, there is currently no general read/write filesystem for Nut/OS
except PHAT.

Regards,

Harald


P.S.: Btw. your contrib (done long ago) for extending the configuration
area to more than a single page is often used, as you can see above.
However, it hurts a bit, that it additionally allocates the full config
area instead of a just single page. So we had to move some parts of the
configuration to the rawFS. I always wanted to fix this, but never got
that time. As you are digging in SPI flash stuff...may be... ;-)