Loading application data

[Eric Norum]

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.

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

-- 
Eric Norum
wenorum at lbl.gov