[ECOS] Some questions on JFFS2 interface to ECOS

[Tom Coates <Tom_Coates at trimble dot com>]

Hello-

I need some information about how JFFS2 is interfaced to ECOS so that I
can port JFFS2 into our system.  We have an embedded system product that
was recently upgraded from a home-brew OS to ECOS.  That's working
great.  The system does data logging to a home-brew flash file system,
which is NOT an ECOS file system.  That file system is showing its age
and limitations.  

I've been asked to figure out how to switch over to better system and
I hope to implement a JFFS2 file system in a portion of our flash
memory.  I have the following constraints:

- We have a single block of 16-bit wide flash memory.

- Parts of the flash are used for other legacy purposes.  JFFS2
  must leave those regions alone.  In other words, JFFS2 is only allowed
  to use erase-blocks in its own, contiguous, section of the Flash.

- Ideally, we'd like to end up with two JFFS partitions, splitting the
  portion of flash dedicated to JFFS2 into two pieces.

- Our existing, non-ecos Flash drivers have mutex locks to protect
  against thread-conflicts.  This functionality would have to be
  maintained after the switch to ECOS.  

- I'd prefer to keep our existing Flash drivers and put ECOS wrappers
  around them.

In researching and planning this implementation I have run into several
issues that I'm having trouble resolving from the existing documentation
and source code.  Any answers to these questions would be of great
help...

1. Is it possible to have two JFFS2 partitions in the same build?
   I'm guessing that I would need to differentiate them by having 
   a separate "device" for each one, with each device being mapped to
   different areas of flash.  Does that make sense?
   Is there anything that prevents this from working?  Is there an
   easier way?

2. It appears that JFFS2-ECOS uses a fairly small set of flash
   interface functions, mostly in flashio.c and fs-ecos.c.  I'm having
   trouble understanding the details of these interfaces.

   cyg_io_bread()  called by jffs2_flash_read()
       This appears to be the way JFFS2 reads data from the flash
       device.  I thought 'bread' parameters are supposed to be block
       oriented.  But JFFS2 is byte or word oriented and I would expect
       the read routine parameters like size and offset to be in bytes,
       not blocks.
       What are the units and meanings of the parameters to
       jffs2_flash_read()?  
       read_buffer_offset sounds like there's a buffer involved?  What
       buffer are we talking about?  Or is this really an offset within
       the flash parition?
       Is 'size' in bytes?  Or what?

   cyg_io_bwrite() called by jffs2_flash_write().
       Same sort of question as for bread().
       Is this being used to write bytes rather than blocks?
       Are the parameters in units of bytes or blocks?

   cyg_io_get_config()
        Used for several purposes depending on the key parameter.

        CYG_IO_GET_CONFIG_FLASH_ERASE
            Used in jffs2_eraseblock().  Does an erase request.  I
            think it erases a single erase-block.
            Is jeb->offset the address of an erase block in the flash?
            Or is it a block number?
            Is it an absolute address, or relative to the beginning of
            the flash, or relative to the jffs2 partition?
            

        CYG_IO_GET_CONFIG_FLASH_DEVSIZE
        CYG_IO_GET_CONFIG_FLASH_BLOCKSIZE
            These two appear to fetch some characteristics of the
            flash memory.  
            What are the values returned are supposed to be?  
            Is DEVSIZE the partition size?   In blocks or in Bytes?
            Is BLOCKSIZE the eraseable-block size?  Is that in Bytes?

3. If I can put ecos-wrappers around my existing drivers, to implement
   those five functions, is that all that is needed for JFFS2 to connect
   to my flash?  Or are there other required interfaces?

4. What sort of flash memory model does JFFS2 expect the flash memory
   and driver(s) to have?
   For example, if the flash has 512 erase-blocks and the first 12 
   erase-blocks are used for something else, how does JFFS2 know this?
   Does JFFS2 "pretend" it has 'virtual' blocks 0 to 499, while the
   flash driver translates requests to actual addresses within the
   flash?  Or does JFFS2 somehow "learn" about the blocks that are off
   limits, and just avoid using them?
   Any sort of overall discussion of how jffs2 models its Flash
   memory would be helpful.

TIA,

Tom Coates :::/

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss