Loading application data

[Leontie Eugen]

Is there a limitation on the file sizes of IMFS ?

I successfully used the method below for(multiple)small files, but I get errors if I try to create a file that is larger than 512k or so. 
This is not the problem of untar.
ex.
FILE * fp= fopen("/xxx","w");
n=fwrite(ptr,1, 623616,fp);
the operation only writes up to a point. n is 558080.

( I am working with the Sparc64 port so I am just trying to see if this might be a 32/64 bit issue, an insufficient sizing of some memory region or just a IMFS limitation)

Eugen
--- On Wed, 3/10/10, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:

> From: Joel Sherrill <joel.sherrill at oarcorp.com>
> Subject: Re: Loading application data
> To: "Eric Norum" <wenorum at lbl.gov>
> Cc: "RTEMS" <rtems-users at rtems.org>
> Date: Wednesday, March 10, 2010, 8:08 PM
> On 03/10/2010 11:59 AM, Eric Norum
> wrote:
> > I do this for my standalone EPICS applications by
> concatenating the tar file at the end of the bootstrap
> flash.  I then set up the IMFS with the tar image
> during my application startup with the following code. 
> The salient routine is rtems_tarfs_load.    You'll
> have to figure out some way of determining the value of the
> tar image in memory, but once you can do that
> rtems_tarfs_load() takes care of the rest.
> >
> >    
> The network-demos httpd does this.  It is fairly
> straightforward.
> 
> --joel
> > static int
> > initialize_local_filesystem(char **argv)
> > {
> >      extern char _DownloadLocation[]
> __attribute__((weak));
> >      extern char _FlashBase[]
> __attribute__((weak));
> >      extern char _FlashSize[] 
> __attribute__((weak));
> >
> >      if (_FlashSize&& 
> (_DownloadLocation || _FlashBase)) {
> >          extern char
> _edata[];
> >          size_t flashIndex =
> _edata - _DownloadLocation;
> >          char *header =
> _FlashBase + flashIndex;
> >
> >          if (memcmp(header +
> 257, "ustar  ", 8) == 0) {
> >              int
> fd;
> >              printf
> ("***** Unpack in-memory file system (IMFS) *****\n");
> >              if
> (rtems_tarfs_load("/", (unsigned char *)header,
> (size_t)_FlashSize - flashIndex) != 0) {
> >               
>   printf("Can't unpack tar filesystem\n");
> >               
>   return 0;
> >              }
> >     .........do whatever you want
> with the IMFS at this point.........
> >          }
> >      }
> >      return 0;
> > }
> >
> > On Mar 10, 2010, at 9:39 AM, Gedare Bloom wrote:
> >
> >    
> >> Hi,
> >>
> >> I'm trying to figure out what is the most portable
> (with respect to
> >> BSP) way to get file-based data in to an
> application.  I can't use
> >> network or ATA-type disk drive.  I've had
> some thoughts, and was
> >> hoping someone might have faced this type of
> problem before me.  My
> >> motivation is to do benchmarking of RTEMS systems
> with respect to
> >> compute and memory usage. My particular board does
> not support hard
> >> drive or network I/O -- and in general I would
> like to have a portable
> >> set of benchmarks that any other RTEMS user can
> use.  Most of the
> >> benchmarks that I'm looking at use file i/o to get
> parameters for
> >> execution.
> >>
> >> I was looking at the various filesystems, and was
> intrigued by the
> >> IMFS, The Wiki says the following: "After an
> application restart you
> >> will need to construct its contents. RTEMS
> provides some supporting
> >> calls for this plus there is the ability to tar
> files into it." What
> >> is that bit about the ability to tar files into
> it? Does this require
> >> network support?
> >>
> >> I could try to use a RAM disk and somehow
> interface that with an RTEMS
> >> filesystem. Is there any support for this in
> RTEMS?  Any idea how I
> >> would get RTEMS to know where to find the RAM
> disk?
> >>
> >> My last option is to convert the files that I have
> in to arrays of
> >> data (compressed binary/hex or ascii strings) that
> are stored as part
> >> of the application. This would definitely be the
> most portable way to
> >> get the data in to applications, but involves a
> bit of work
> >> translating the files to something usable by the
> application.
> >>
> >> Maybe someone has done something similar -- I
> really just need a good,
> >> portable way to get application data in to RTEMS.
> Although the data is
> >> currently organized in Unix files, if there are
> some tools to convert
> >> files in to some other format that makes it easy
> to place in memory
> >> alongside the RTEMS application, it would probably
> satisfy my
> >> constraints.
> >>
> >> Also, if anyone else is interested in such a set
> of benchmarks, let me
> >> know and I can keep you appraised of my progress.
> >>
> >> Thanks,
> >> Gedare
> >> _______________________________________________
> >> rtems-users mailing list
> >> rtems-users at rtems.org
> >> http://www.rtems.org/mailman/listinfo/rtems-users
> >>      
> >    
> 
> 
> -- 
> Joel Sherrill, Ph.D.         
>    Director of Research& 
> Development
> joel.sherrill at OARcorp.com 
>       On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>     Support Available       
>      (256) 722-9985
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>