[ECOS] newbie jffs2 / nvram question

Retallack, Mark (Siemens) mark.retallack@siemens.com
Thu Apr 15 09:57:00 GMT 2004

I have moded the ramfs to allow for a persistent ram memory file system. I
have attached a patch file. This is still in active development (still need
to clean and added options to cdl), but it might give you some ideas. The
CRC checking is not very good at this time.

I defined labels in my mlt_powerpc_pluto_app.ldi (memory layout) file to say
where the ramfs should be.

    // define the location of the ram file system
    CYG_LABEL_DEFN(__ramfs_memory_block) = 0x1c0000;
    CYG_LABEL_DEFN(__ramfs_runtime_data) = 0x1d0000;

I also needed to set-up the ramfs package with the following options:

CYGPKG_FS_RAM_BLOCKS_ARRAY_NAME = __ramfs_memory_block

Hope that helps.

> -----Original Message-----
> From: Richard.von.Lehe@gd-ais.com [mailto:Richard.von.Lehe@gd-ais.com]
> Sent: Wednesday 14 April 2004 10:54 PM
> To: ecos-discuss@sources.redhat.com; Richard.von.Lehe@gd-ais.com;
> rvonlehe@comcast.net
> Subject: [ECOS] newbie jffs2 / nvram question
> Does it make any sense to use the jffs2 filesystem for a 32KB 
> NVRAM part?
> Some questions I have:
> 1) If I used ramfs for my nvram, would I be able to mount the fs and 
> read files after a power loss?  Is this always true?  What about if 
> power is lost during a write?  Is it easy to modify a linker 
> script to 
> place the ramfs block array into the nvram address space?  I've seen 
> examples of locating functions in specific areas using the 
> __attribute__ 
> specifier, and thought this would also work with an array.
> So in ramfs.c, I would do something like:
> static ramfs_block 
> cyg_ramfs_block_array[CYGNUM_FS_RAM_BLOCKS_ARRAY_SIZE] __attribute__ 
> ((section (".2nvram.cyg_ramfs_block_array")));
> Where .2nvram is a section defined like the .2ram section (populated 
> with flash program routines).
> Is the above a reasonable approach for this idea?
> 2) Is the compiled size of jffs2 and ramfs quite a bit 
> different?  Just 
> looking at the src for each, I would guess jffs2 would be 
> several times 
> bigger.
> 3) Has anyone used a filesystem on top of nvram?  A block 
> device driver 
> might be enough for me, but the only example I have been able 
> to find of 
> such a block driver is the flash device driver that jffs2 
> sits on top of 
> (packages/io/flash/current/src/flash.c & flashiodev.c?).
> I couldn't find anything in the archives to address my 
> particular situation.
> Rich
> -- 
> Before posting, please read the FAQ: 
> http://ecos.sourceware.org/fom/ecos
> and search the list archive: 
> http://ecos.sourceware.org/ml/ecos-discuss

Siemens Traffic Controls is a division of Siemens plc. Registered No.
727817, England. 
Registered office: Siemens House, Oldbury, Bracknell, Berkshire, RG12 8FZ. 

This communication contains information which is confidential and 
may also be privileged. It is for the exclusive use of the addressee. 
If you are not the addressee please note that any distribution, 
reproduction, copying, publication or use of this communication 
or the information in it is prohibited.  If you have received this 
communication in error, please contact us immediately and also 
delete the communication from your computer. 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: my.patch
Type: application/octet-stream
Size: 39072 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/ecos-discuss/attachments/20040415/6d15988e/attachment.obj>
-------------- next part --------------
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list