[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
External RAM filesystem
- Date: Fri, 16 Nov 2007 18:21:17 +0100
- From: Aitor.Viana.Sanchez at esa.int (Aitor.Viana.Sanchez at esa.int)
- Subject: External RAM filesystem
Thomas Doerfler <Thomas.Doerfler at embedded-brains.de> wrote on 11/16/2007
> 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
> > to mount the filesystem, raising an error. The error shows up when
> > msdos_format() is called, returning "not such file or directory". On
> > contrary, if numberOfBlocks = 40 (for instance) everything goes well.
> > Is there any limitation within RTEMS w.r.t. the size of the
> 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
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?
> > 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-18.104.22.168-1.0.3. I
> >> tried with RTEMS 4.6.5 but looks like some functions are not
> >> 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.
> > The module should be back-portable if required, but there might be
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...