External RAM filesystem

[Joel Sherrill]

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

Aitor.Viana.Sanchez at esa.int wrote:
>
> Thomas Doerfler <Thomas.Doerfler at embedded-brains.de> wrote on 
> 11/16/2007 06:12:58 PM:
>
> > Hi,
>
> > Aitor.Viana.Sanchez at esa.int schrieb:
> > >
> > > Hi,
> > >
> > > OK the problem eventually was only half mine ;). I'll try to explain.
> > >
> > >
> > >         #define _FILESYSTEM_SIZE                        (0x1000000)
> > >    // 16MB
> > >         static unsigned int numberOfBlocks = (_FILESYSTEM_SIZE / 512);
> > >
> > > The problem is that, with this numberOfBlocks  value, RTEMS is not 
> able
> > > to mount the filesystem, raising an error. The error shows up when
> > > msdos_format() is called, returning "not such file or directory". 
> On the
> > > contrary, if numberOfBlocks = 40 (for instance) everything goes well.
> > >
> > > Is there any limitation within RTEMS w.r.t. the size of the 
> filesystem?
>
> > Hm, this is strange. We are currently working with Compact Flash cards
> > with about 2GByte of capacity, and there are no such problems. We are
> > also formatting them with msdos_format().
>
> > There MIGHT be a problem with the ramdisk driver.
>
> > Normally you would not want to use a MSDOS-based ramdisk in RTEMS,
> > because you can also use the "IMFS" (in-memory-file system) which uses
> > the heap to get the memory it needs.
>
> Yes, i would also use the IMFS but the problem is that the heap is 
> located, in my board, in the static RAM (4 MB size) because is where 
> RTEMS is placed and I need a quite big filesystem. That's why I am 
> trying to used the SDRAM which is located from 0x60000000 on.
> I do not know whether  it is possible to do another thing to solve that.
>
> > The ramdisk driver was a test vehicle to implement the DOS filesystem
> > and, AFAIK, was not/seldomly used with the capacity you mentioned.
>
> > Can you see "/dev/ramdisk0" in the device tree of the (in memory) file
> > system?
>
> I think it is not, and that's why the "no such file or directory" is 
> raised, but anyway, how can a check that out?
>
> regards,
>
> //avs
>
> > wkr,
> > Thomas.
>
> >
> > >
> > > thanks in advanced.
> > >
> > > //avs
> > >
> > > -----------------------------
> > > Aitor Viana Sánchez
> > >
> > > ESA - European Space Technology Centre (ESTEC)
> > > TEC-EDD - Computer and Data Systems Section
> > > ESA/ESTEC P.O. Box 299 / 2200AG Noordwijk ZH, The Netherlands
> > > Tel (+31) 71 565 6727
> > > Email: aitor.viana.sanchez at esa.int
> > >
> > >
> > > *Thomas Doerfler <Thomas.Doerfler at embedded-brains.de>*
> > > Sent by: rtems-users-bounces at rtems.org
> > >
> > > 11/15/2007 09:54 PM
> > >
> > >
> > > To
> > >  Aitor.Viana.Sanchez at esa.int
> > > cc
> > >  rtems-users at rtems.org
> > > Subject
> > >  Re: External RAM filesystem
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > >
> > > Aitor.Viana.Sanchez at esa.int schrieb:
> > >>
> > >> Hi,
> > >>
> > >> I got everything ready to send an example and to include a wiki entry
> > >> but fist...the example is only working in rtems-4.7.99.2-1.0.3. I 
> also
> > >> tried with RTEMS 4.6.5 but looks like some functions are not 
> implemented
> > >> in this version. This is the compilation output.
> > >
> > > ys you are right, I implemented the msdos_format function somewhere
> > > after 4.6.5, so you might have missed it in that version.
> > >
> > > See:
> > >
> > > http://www.rtems.com/cgi-bin/cvsweb.
> > cgi/rtems/cpukit/libfs/src/dosfs/msdos_format.c
> > >
> > > The module should be back-portable if required, but there might be 
> some
> > > other unresolved references then.
> > >
> > > Are you currently stuck to 4.6.5 in your work? Which architecture are
> > > you working on?
> > >
> > > wkr,
> > > Thomas.
> > >
> > > --
> > > --------------------------------------------
> > > Embedded Brains GmbH
> > > Thomas Doerfler           Obere Lagerstr. 30
> > > D-82178 Puchheim          Germany
> > > email: Thomas.Doerfler at embedded-brains.de
> > > Phone: +49-89-18908079-2
> > > Fax:   +49-89-18908079-9
> > > _______________________________________________
> > > rtems-users mailing list
> > > rtems-users at rtems.com
> > > http://rtems.rtems.org/mailman/listinfo/rtems-users
>
> >
> > --
> > --------------------------------------------
> > embedded brains GmbH
> > Thomas Doerfler           Obere Lagerstr. 30
> > D-82178 Puchheim          Germany
> > Tel. : +49-89-18 90 80 79-2
> > Fax  : +49-89-18 90 80 79-9
> > email: Thomas.Doerfler at embedded-brains.de
> > PGP public key available on request
>
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ------------------------------------------------------------------------
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>