Is there a flash-based FS in rtems?

[Ed Sutter]

>>>> 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,
Cool!  Neat idea
Thanks