Is there a flash-based FS in rtems?

[Robert S. Grimes]

Ed Sutter wrote:
> Robert S. Grimes wrote:
>   
>> Ed Sutter wrote:
>>     
>>> MicroMonitor has a simple NOR flash file system for managing updates etc...
>>> It hooks together with RTEMS pretty nicely.  It's not designed for heavy
>>> file activity (no wear leveling), but does provide a nice platform
>>> to support system updates etc...
>>> Obviously, this would mean a bootloader change.
>>> Ed
>>>   
>>>       
>> Let me add a bit here, as I am using MicroMonitor as my bootloader, and 
>> I can vouch for its utility with application updates, etc.  It also 
>> gives you scripting abilities for miscellaneous startup activities, such 
>> as running separate power-up tests before application startup, etc.
>>
>> If you need to access files on the MicroMonitor file system from your 
>> application (keeping Ed's caveat in mind, of course), you have two 
>> choices.  The obvious approach is to call back into MicroMonitor, as 
>> documented in its User Manual; this would allow you the usual file 
>> operations (eg. read, write, etc.).  I haven't used this approach, so I 
>> can't comment on it, but it seems certainly the way to go if you wish to 
>> create/write files.
>>
>> If you only need to read from files, for example, configuration files, 
>> etc., another (simpler?) option is not to use MicroMonitor at all from 
>> your application.  This is made feasible because the file structure is 
>> extremely simple, with files being a single, contiguous region of memory 
>> _within the processor's address space_.  Hence, you can simple set a 
>> pointer to the beginning of the file and treat it as a regular, 
>> in-memory data structure!  (Note: these comments apply only to RAM and 
>> XOR Flash disks.)  An exercise for the reader is determining the start 
>> location (and optionally, the  size of the file) - of course, I can tell 
>> you how I did it if you are interested...
>>     
>
> Actually, the uMon API makes it pretty easy to retrieve the starting point
> and size of the file in TFS.  The call "mon_tfsstat(filename)" returns a
> pointer to a structure that contains all that information.  Then, as Bob
> said, you can treat it just like a contiguous block of memory.
> For writing, you can use the open/write/close model (similar, but not
> identical to Unix), or you can just build an array in ram, then call
> mon_tfsadd(name,flags,buffer,size) to create the file. Either way works,
> it just depends on what you're comfortable with.
>   
Okay, Ed, here is another way to do it, without having to call into 
MicroMonitor (in case you are wondering, once my application is running, 
I'm not allowed to write to flash, which I accomplish by 1) not 
implementing any flash write/erase functionality, and 2) intentionally 
trashing MicroMonitor's RAM-resident image upon loading my app).  
Instead of using the API, use its most-excellent scripting ability to 
write a startup script that does something like this - here I want to 
make a file, named 'faults.dat', that resides in the flash TFS drive 
available to my application:

    # Create a RAM-base TFS "disk" - name is //var/
    tfs ramdev var 0x2d0000 0x130000

    # Expose fault file info
    tfs base faults.dat FAULTBASE
    tfs size faults.dat FAULTSIZE

    # Get the uMon environment and store it on //var
    set -f //var/environ

    # Find the enviroment file and make it known to ETILL
    tfs base //var/environ ENVBASE
    tfs size //var/environ ENVSIZE
    pm -4 $WELLKNOWNADDR $ENVBASE $ENVSIZE


Now, the uMon environment (which consists of a string list of "set 
KEY=VALUE" pairs) is readily accessible by setting a pointer to 
$WELLKNOWNADDR, which then gives you access to the file's information.  
Note that this also give you access to any other environment variables 
you might have set in uMon; of course, the uMon API function 
mon_genenv() does this more easily, if you aren't restricted like I 
am...  ;-)

-Bob