Reply by rickman February 23, 20052005-02-23
Mastupristi wrote:
> 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.
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.
Reply by CBFalconer February 15, 20052005-02-15
jetmarc@hotmail.com wrote:
> >> 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. > > 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).
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 "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson
Reply by February 14, 20052005-02-14
> 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. 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).
Reply by Peter Dickerson February 8, 20052005-02-08
"Mastupristi" <cialdi.NO@SPAM.gmail.com> wrote in message
news:20050205193329.542728ad.cialdi.NO@SPAM.gmail.com...
> 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?
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
Reply by Hans-Bernhard Broeker February 7, 20052005-02-07
Mastupristi <cialdi.NO@spam.gmail.com> wrote:

> where can I find some infos or internet resource about writing a > simple flash filesyestem?
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 (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Reply by GMM50 February 7, 20052005-02-07
> > 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] > ...
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
Reply by February 6, 20052005-02-06
Mastupristi schrieb:
> 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.
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&#4294967295;er matthias@matwei.de http://www.matwei.de
Reply by RusH February 6, 20052005-02-06
Mastupristi <cialdi.NO@SPAM.gmail.com> wrote :

> 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.
the easiest - no filesystem Pozdrawiam. -- RusH // http://randki.o2.pl/profil.php?id_r=352019 Like ninjas, true hackers are shrouded in secrecy and mystery. You may never know -- UNTIL IT'S TOO LATE.
Reply by Bob McConnell February 6, 20052005-02-06
On Sat, 5 Feb 2005 19:33:29 +0100, Mastupristi
<cialdi.NO@SPAM.gmail.com> wrote:

>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
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?PRID=3615> Good luck, Bob McConnell N2SPP
Reply by Mastupristi February 5, 20052005-02-05
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?