External RAM filesystem

[Aitor.Viana.Sanchez at esa.int]

Hi,

Yes, I am also quite interested in that solution but i am still one step 
back stuck with the IMFS trying to mount an external RAMDisk and using it 
properly. And, i don't know whether the problems I am getting are because 
of my configuration and or they are coming from the RTEMS IMFS.

Basically, the configuration I got is this:

        rtems_bdbuf_config rtems_bdbuf_configuration[] = {
          { 512, 200, (unsigned char *) _SDRAM_FS_ADDR }
        };
        int rtems_bdbuf_configuration_size =( 
sizeof(rtems_bdbuf_configuration)
 /sizeof(rtems_bdbuf_configuration[0]));

        rtems_ramdisk_config rtems_ramdisk_configuration[] = {
          {512, 200, (void *) _SDRAM_FS_ADDR}
        };

        size_t rtems_ramdisk_configuration_size = ( 
sizeof(rtems_ramdisk_configuration)
 /sizeof(rtems_ramdisk_configuration[0]));

and when I mount the ramdisk space

        memset(&rqdata, 0, sizeof(rqdata));
        rqdata.OEMName = "Rtems";
        rqdata.VolLabel = "RAMDISK";
        rqdata.fattype = MSDOS_FMT_FATANY;
        rqdata.quick_format = TRUE;

        assert(msdos_format("/dev/ramdisk0", &rqdata) == 0);
 
        status = (rtems_status_code)rtems_fsmount(
                        fs_mnt_table, 
                        sizeof(fs_mnt_table)/sizeof(fs_mnt_table[0]),
                        NULL
                        );

everything goes well. Now if I try to store files sized ~50Kbyte, 
gorgeous...but now, writting files sized ~2MB raised an I/O error in the 
fwrite routine and I do not understand why.

any clue?


//avs



rtems-users-bounces at rtems.org wrote on 11/20/2007 03:22:18 PM:

> Hi Joel,

> I should probably join in the conversation too, as a persistent RAM
> disk will be important in our upcoming RTEMS applications.

> I like this idea for the IMFS.
> But a question: for our vxWorks based systems, we create a RAM disk
> in an area of RAM that is preserved during OS restarts. We can then
> verify/remount the disk after vxWorks restarts. Would this be a
> possibility for the IMFS with a custom pool/malloc/free ?

> Thanks,

> Alan

> On Nov 20, 2007, at 9:05 AM, Joel Sherrill wrote:

> > I'm late in the discussion but I proposed a couple of years
> > ago adding a configuration item for the IMFS.  If you defined
> > a structure with three callback functions, you could change
> > where memory was allocated in the IMFS.
> >
> > + initialize pool  (default NULL)
> > + allocate memory (default malloc)
> > + free memory  (default free)
> >
> > Change the IMFS code to use the provided functions and
> > it can easily be switched.
> >
> > --joel
> >

> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20071120/5e0ff9cd/attachment-0001.html>