[ECOS] Some questions on JFFS2 interface to ECOS

Andrew Lunn andrew@lunn.ch
Sun Oct 15 19:07:00 GMT 2006


On Fri, Oct 13, 2006 at 04:07:16PM -0700, Tom Coates wrote:
> 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.

How full will these filesystem be. jffs2 needs around 5 empty erase
blocks per filesystem for garbage collect to work. Two filesystems
mean 2x5. Does you have sufficient space for this?
 
> - 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.  

This you need to check. The trunk does not support this. The flash_v2
branch does. However it could be that the fileio layer has the ability
to serialize all fileio access. I just don't know if this is per
filesystem, or all file systems. You need to look at the fileio CDL
and code and work it out what it can really do.
 
> - I'd prefer to keep our existing Flash drivers and put ECOS wrappers
>   around them.

Why?

> 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?

The flash_v2 branch in CVS supports this. 

>    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?

That is exactly how the flash_v2 branch works.

 
> 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?

There is a lot of confusion here. The functions are implemented in
packages/io/flash/current/src/flashiodev.c and use a different idea of
blocks, bytes, size etc as to bread/bwrite on block devices. Flash is
not really a block device, so liberties were taken.....

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

Correct.

>             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?

Its the bytes from the beginning of the /dev/flash1 device. It erases
the page that contains that address.

>         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?

It is the /dev/flash1 size in bytes.

>             Is BLOCKSIZE the eraseable-block size?  Is that in Bytes?

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?

I think that is all you need, but nobody before has decided the ignore
the eCos way of doing things and do it some other way. You could hack
the CDL, remove the io_flash package, link one of the jffs2 test cases
and see what the linker complains about is missing.

What is wrong with the eCos way anyway?

> 
> 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?

jffs2 It does not. The /dev/flash1 knows this, when you configure
it. jffs2 just works inside this device.

    Andrew


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



More information about the Ecos-discuss mailing list