Simple eLua flash file system

[mpthompson]

Hi everyone,

In my working with eLua on the AT91SAM7S I would like to use the unused portion of flash on the chip (about 50K to 100K) as a simple read/write file system accessible via the standard libc file system calls open(), close(), read(), write(), seek(), etc...  At this point I am looking to use FatFs as I already have it working on an sd/mmc card.  Making the changes to to instead use the on-chip flash for storing files shouldn't be too difficult.

However, I am wondering if someone knows of an alternative file system I might consider?  FAT seems like overkill for such a small need and file system compatibility with other devices is a non-issue in this scenario as the flash is non-removable.

Thanks,

Mike Thompson

[BogdanM]

Hi,

We will have such a FS at some point (I have a proof of concept ready), but I can't tell you why, as right now I'm so busy that I don't even get to work on the 0.6 docs anymore (hope this will change soon).
I do not recommend using FAT on Flash directly. You might kill your Flash soon. FAT was not designed to work directly with a medium such as Flash that generally needs a wear leveling algorithm for a nice, long life :)

Best,
Bogdan

On Fri, Apr 3, 2009 at 12:52 AM, mpthompson <[hidden email]> wrote:

Hi everyone,

In my working with eLua on the AT91SAM7S I would like to use the unused portion of flash on the chip (about 50K to 100K) as a simple read/write file system accessible via the standard libc file system calls open(), close(), read(), write(), seek(), etc...  At this point I am looking to use FatFs as I already have it working on an sd/mmc card.  Making the changes to to instead use the on-chip flash for storing files shouldn't be too difficult.

However, I am wondering if someone knows of an alternative file system I might consider?  FAT seems like overkill for such a small need and file system compatibility with other devices is a non-issue in this scenario as the flash is non-removable.

Thanks,

Mike Thompson
--
View this message in context: http://n2.nabble.com/Simple-eLua-flash-file-system-tp2577775p2577775.html
Sent from the eLua Development mailing list archive at Nabble.com.

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[mpthompson]

The FatFs file system integrated very easily and thanks to the work of
Jesus Alvarez it just works.  It's a very short term solution for me so
I can get other pieces of the system working.  However, you are correct
that it isn't suitable to my purposes over the long term

Another file system I've been looking at is YAFFS:

http://www.yaffs.net/

While primarily intended to be Linux filesystem over raw NAND or NOR
flash devices, there is a variant called YAFFS Direct intended for small
embedded systems such as eLua.  The good thing is that wear leveling is
built into the file system and SRAM footprint doesn't look too bad.  I
don't know if it is good for 50K to 100K file systems, but I'll be
looking further into this.  YAFFS is dual licensed under both GPL and
there is a non-GPL commercial license.

Mike Thompson


Bogdan Marinescu wrote:

> Hi,
>
> We will have such a FS at some point (I have a proof of concept ready),
> but I can't tell you why, as right now I'm so busy that I don't even get
> to work on the 0.6 docs anymore (hope this will change soon).
> I do not recommend using FAT on Flash directly. You might kill your
> Flash soon. FAT was not designed to work directly with a medium such as
> Flash that generally needs a wear leveling algorithm for a nice, long
> life :)
>
> Best,
> Bogdan
>
> On Fri, Apr 3, 2009 at 12:52 AM, mpthompson <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     Hi everyone,
>
>     In my working with eLua on the AT91SAM7S I would like to use the
>     unused portion of flash on the chip (about 50K to 100K) as a simple
>     read/write file system accessible via the standard libc file system
>     calls open(), close(), read(), write(), seek(), etc...  At this
>     point I am looking to use FatFs as I already have it working on an
>     sd/mmc card.  Making the changes to to instead use the on-chip flash
>     for storing files shouldn't be too difficult.
>
>     However, I am wondering if someone knows of an alternative file
>     system I might consider?  FAT seems like overkill for such a small
>     need and file system compatibility with other devices is a non-issue
>     in this scenario as the flash is non-removable.
>
>     Thanks,
>
>     Mike Thompson
>     --
>     View this message in context:
>     http://n2.nabble.com/Simple-eLua-flash-file-system-tp2577775p2577775.html
>     Sent from the eLua Development mailing list archive at Nabble.com.
>
>     _______________________________________________
>     Elua-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Elua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[mpthompson]

Bogdan Marinescu wrote:
> We will have such a FS at some point (I have a proof of concept ready),
> but I can't tell you why, as right now I'm so busy that I don't even get
> to work on the 0.6 docs anymore (hope this will change soon).
> I do not recommend using FAT on Flash directly. You might kill your
> Flash soon. FAT was not designed to work directly with a medium such as
> Flash that generally needs a wear leveling algorithm for a nice, long
> life :)

Just a follow up on this, I did take Bogdan's warning to heart about
using the FAT file system over raw NAND flash.  After scouring the
Internet with Google and not finding anything suitable (small, free and
easy to use) I've put together my own simple linear file store system
for the AT91SAM7 EFC.  It should correctly implement a wear leveling
strategy whereby it keeps track of the order of writes to the underlying
flash to distribute them evenly across all blocks in the filestore --
even when rewriting portions of an existing file.

Because there is no central table at the top of the filesystem it won't
win any speed contests as all searches for file blocks are linear across
the filestore.  I took this approach to minimize bookkeeping structures
in SRAM which other linear file stores will typically use.  This
strategy should work fine for small file systems on the order of a few
hundred flash pages.

It's very simple and just supports a root directory with an arbitrary
number of files, but it should get the job done.  It will intergrate
with eLua as a filesystem connected via newlib just as FatFs does so the
usual open, close, read, write, etc. calls should work.

I want to spend a few days cleaning up code and performing unit testing,
but I'll be happy to share it with others who may find it useful.  I'm
sure a few other sets of eyes looking it over would help with ideas for
making it more portable and more efficient.

I'll be using this to store Lua byte code and other resources on the
internal flash of the AT91SAM7S of the NXT Lego brick.  I wanted
something well integrated with the file system, but reasonable for the
raw NAND flash.

Mike Thompson

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Just Great Mike !
   Pls keep this as a branch on svn for now, while we manage to polish up v0.6 to release.

Thanks !
Dado

On Sun, Apr 5, 2009 at 04:40, Mike Thompson <[hidden email]> wrote:

Bogdan Marinescu wrote:
> We will have such a FS at some point (I have a proof of concept ready),
> but I can't tell you why, as right now I'm so busy that I don't even get
> to work on the 0.6 docs anymore (hope this will change soon).
> I do not recommend using FAT on Flash directly. You might kill your
> Flash soon. FAT was not designed to work directly with a medium such as
> Flash that generally needs a wear leveling algorithm for a nice, long
> life :)

Just a follow up on this, I did take Bogdan's warning to heart about
using the FAT file system over raw NAND flash.  After scouring the
Internet with Google and not finding anything suitable (small, free and
easy to use) I've put together my own simple linear file store system
for the AT91SAM7 EFC.  It should correctly implement a wear leveling
strategy whereby it keeps track of the order of writes to the underlying
flash to distribute them evenly across all blocks in the filestore --
even when rewriting portions of an existing file.

Because there is no central table at the top of the filesystem it won't
win any speed contests as all searches for file blocks are linear across
the filestore.  I took this approach to minimize bookkeeping structures
in SRAM which other linear file stores will typically use.  This
strategy should work fine for small file systems on the order of a few
hundred flash pages.

It's very simple and just supports a root directory with an arbitrary
number of files, but it should get the job done.  It will intergrate
with eLua as a filesystem connected via newlib just as FatFs does so the
usual open, close, read, write, etc. calls should work.

I want to spend a few days cleaning up code and performing unit testing,
but I'll be happy to share it with others who may find it useful.  I'm
sure a few other sets of eyes looking it over would help with ideas for
making it more portable and more efficient.

I'll be using this to store Lua byte code and other resources on the
internal flash of the AT91SAM7S of the NXT Lego brick.  I wanted
something well integrated with the file system, but reasonable for the
raw NAND flash.

Mike Thompson

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev