NAND Flash filesystem

[Sebastian Huber]

On 10/19/2010 08:51 AM, Mick Davis wrote:
> Hi
> 
> Yes, good progress.

This is good to hear.

> 
> I have a basic working bsp for the at91sam9263-ek. It might be a good
> time to share it so that others can contribute, but I still have
> improvements to make.
> 
> For the NAND filesystem, I'm currently on the route of adapting UFFS.
> 
> I've built it as a library for RTEMS, which involved creating a makefile
> and supplying some functions to the library from RTEMS. That part was
> pretty easy.

Does this library depend on the BSP?  We should avoid dependencies on the BSP
here so that we can integrate the basic UFFS support in the cpukit
(cpukit/libfs/src/uffs).  It would be nice if we can use unpatched UFFS sources
so that future updates are possible.

> 
> In my app, I then had to write hardware interface functions.  These are
> specific to the atmel processors, and require some config for the NAND
> chips you want to support.  I should move them into the BSP I guess.

Yes.

> 
> I've been testing with the UFFS API, and so far it seems good.  It
> doesn't lose files and handles bad blocks.  I don't have performance
> figures yet, but there's no noticeable startup delay, which was a
> concern for the 512Mb+ chips I'm working with.

This sounds promising.

> 
> I haven't made a lot of progress with integrating UFFS into the RTEMS
> filesystem.  I've had a look at the RTEMS Filesystem Design Guide.  I've
> been looking at how the ftp and tftp filesystems do it, because they're
> similar.  I don't have blocks or nodes, just filenames and directories,
> and handles for open files.

Yes, these file systems are a good example.

> 
> I can see how to setup with the mount table and that I need to supply
> functions for the rtems_filesystem_operations_table and
> rtems_filesystem_file_handlers_r structures.  It's not clear to me
> what's then expected of the functions I write.  I'd also like to
> understand what sequence the functions are used in.

Ok, I you have any questions, you can write me a (private) mail.  I am quite
familiar with the file system.  Which RTEMS version do you use?  The mount
mechanic changed recently (2010-05-31).

The rtems_filesystem_operations_table is used for file system level access:

http://www.rtems.org/onlinedocs/doxygen/cpukit/html/struct__rtems__filesystem__operations__table.html

Important are here evalpath_h and evalformake_h.  They should return a node
structure that can be later used with the node specific operations
(rtems_filesystem_location_info):

http://www.rtems.org/onlinedocs/doxygen/cpukit/html/structrtems__filesystem__location__info__tt.html

This node structure will be released with freenod_h.

The rtems_filesystem_file_handlers is used to work with file system nodes like
directories and files (they use the node structure returned by evalpath_h or
evalformake_h):

http://www.rtems.org/onlinedocs/doxygen/cpukit/html/struct__rtems__filesystem__file__handlers__r.html

> 
> I've actually been testing without UFFS at all to get things worked out.
>  It should be possible to develop a model for how to integrate a generic
> file + directory names filesystem.
> 
> 
> On 18/10/10 21:19, Sebastian Huber wrote:
>> Hello Mick,
>>
>> have you made some progress with your flash file system issues?
>>
>> Have a nice day!
>>
> 


-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.