simple flash file system

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
where can I find some infos or internet resource about writing a simple flash
filesyestem?
We don't need something complex (like jffs), since we have 1MB flash and few
Kbytes sram.

thanks


--
Mastupristi?

Re: simple flash file system
On Sat, 5 Feb 2005 19:33:29 +0100, Mastupristi

Quoted text here. Click to load it
filesyestem?
Quoted text here. Click to load it
Kbytes sram.
Quoted text here. Click to load it

The source for JFFS is available with several Linux kernel packages.
There has also been some info published on the IBM web site.

Or try <http://developer.axis.com/software/jffs/

Or <http://www.realtime-info.be/vpr/layout/display/pr.asp?PRID36%15

Good luck,

Bob McConnell
N2SPP


Re: simple flash file system

Quoted text here. Click to load it

the easiest - no filesystem

Pozdrawiam.
--
RusH   //
 http://randki.o2.pl/profil.php?id_r35%2019
We've slightly trimmed the long signature. Click to see the full one.
Re: simple flash file system
Mastupristi schrieb:
Quoted text here. Click to load it
filesyestem?
Quoted text here. Click to load it
Kbytes sram.

How about a simple look-up table at some fixed position in the flash.
Something like:

[filename1(as a '0'-terminated string)][offset][length]
[filename2(as a '0'-terminated string)][offset][length]
...

--
Matthias Wei▀er
snipped-for-privacy@matwei.de
We've slightly trimmed the long signature. Click to see the full one.
Re: simple flash file system
Quoted text here. Click to load it


If you want to keep the table in ram and rebuild on power up, you can
have

RAM:

   File Table[numberof files]
      Pointer to 1st file information Block
      Pointer to 2nd file information Block
      NULL end of files

FLASH:

struct FileInformationBlock
   char FileName[20]
   int  FileSize
   int  OtherFileCharacteristics
   int  StartofFileData

The you can rebuild the table in ram on power up by scanning your FLASH
Data.

Keep us Posted.
George


Re: simple flash file system

Quoted text here. Click to load it

Well, there's simple, and then theres's SIMPLE.  How simple exactly do
you need it?  

It might help to start thinking at what an ANSI C <stdio.h>
implementation does, and reduce from there.  E.g., do you need
fseek/ftell?  Do you need append mode?  How many files will you need?
What's the relation between the sum of all maximum file lengths and
the actual file system size?  Do you need file names more complicated
than "1", "2" and "b"?  I'm quite sure you don't need directories,
file attributes or access control.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: simple flash file system
Quoted text here. Click to load it
flash filesyestem?
Quoted text here. Click to load it
few Kbytes sram.
Quoted text here. Click to load it

I had exactly this issue with an on-going project. I looked at jffs 1 (axis)
& 2 (red hat/cygnus). 1 has the problem that all the metadata is read into
RAM at start-up and red-hat report reliability problems when power cycling.
2 is more sophisticated but still requires more RAM and hooks into the OS.
My target is OS-less, 4 MByte total flash and 128K RAM.

While it stinks of NIH I ended up rolling my own. Currently it is not hooked
into standard system calls because that's not required in my case. It uses a
journal type system by with deletion marks. Files can be opened for read,
write, append or overwrite. The main simplification is no random access for
writes just sequential. However there are full path names with a current
directory (eight deep, configurable) and names are 31 chars per component
(configurable).

Anyway looking at the memory map of the current project the footprint is
1096 bytes plus what the Flash driver takes (0 in my case). There is no
dynamic allocation. This can certainly be reduced because some of it
consists of small mapping caches, and by reducing the number of
simultaneously open files. I use a 40-block * 64K file system (one block
free for compacting).

So it is certainly doable.


--
Peter
Peter.Dickerson (at) ukonline (dot) co (dot) uk



Re: simple flash file system
Quoted text here. Click to load it
simple flash filesyestem?
Quoted text here. Click to load it
and few Kbytes sram.

There is little information available.

I came up with a simple flash filesystem for CF (512 bytes
per sector) that is optimized for fast sequential reads with
very low RAM footprint.  The read-write version (with API
similar to ANSI file i/o) occupies about 3.5K of CODE and
50 bytes of RAM, plus a configurable number of 512 byte disk
sector caches (two minimum), and a few bytes per concurrently
opened file.  It should be possible to trade in speed for
more footprint savings, or for better DELETE performance
(which I did not optimize for at all).


Re: simple flash file system
Quoted text here. Click to load it

You could probably do quite well by building around LUDEF5, which
has been around for 30+ years, and maps files into a single unit
with random access (unlike tar, which is basically sequential
access).  Google for LUDEF5.

Please don't remove attributions for any material you quote.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: simple flash file system
Quoted text here. Click to load it
filesyestem?
Quoted text here. Click to load it
Kbytes sram.

You might want to take a look at MicroMonitor from Lucent.  It is free,
open source and includes a "simple" ffs.  I guess one question is what
aspects of a ffs are you looking for?  One major components is wear
leveling/bad block management.  The bad block management is mostly for
NAND flash.  At 1 MB, I expect you are using NOR flash which is much
more reliable.




Site Timeline