Is there a flash-based FS in rtems?

[Ed Sutter]

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.
Ed