Re: [ECOS] Some questions on JFFS2 interface to ECOS

[Tom Coates <Tom_Coates at trimble dot com>]

Thanks to andrew@lunn.ch for his informative answers.
I won't completely quote the whole chain as it is long.  But here are
responses to some of the questions he raised.

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

Yes, I'm aware if this requirement.  Our flash has 128KB erase-blocks,
so this represents about 1280KB for GC usage.
But we have between 27MB and 59MB (depending on the system type) of
available space.  So the free space requirements aren't a problem.

 
> > - 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've just become aware of the flash_v2 branch.  I think that's been part
of my confusion as I try to understand how the flash drivers work.
Some of the documentation I stumbled upon was for the v2 branch and some
for the mainline, with no indication in the documentation of which is
which.

I've just spotted the directions in old list emails on how to update
the affected packages directories to the branch.  I'll be reviewing the
new flash packages to see what's changed.


> > - I'd prefer to keep our existing Flash drivers and put eCos
> > wrappers around them.
> 
> Why?

- The main reason is "code inertia".  If I were to change everything to
  the eCos drivers, I'd have to modify and verify much more code in the
  existing application.  We have at least six different uses for flash
  through those old drivers.  All of them assume some non-eCos behavior.
  A complete rewrite poses a significant risk.  
- I was assuming there was no flash locking in the driver itself.
- I was assuming that the eCos flash driver could only handle a single
  type of flash.  

It appears that the flash_v2 drivers may remove some of these problems,
but that is new information to me.

If I were starting this project with eCos from the beginning, it would
be foolish NOT to use everything eCos provides.  But we are migrating
gradually to eCos, and have to take things one step at a time.


> > 1. Is it possible to have two JFFS2 partitions in the same build?
> 
> The flash_v2 branch in CVS supports this. 

Okay.  Sounds like I should definitely start with the flash_v2 branch
for all of this work.


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

Nothing wrong with the eCos way.  And please take nothing I said as
critical.  I am just working inside a tight little box.  I can't rewrite
all of the flash code in the current application at once.  At least, I
can't do that until I better understand the eCos way of doing things.
Eventually, I would like to migrate all of our code to the way eCos does
things.  But with 700,000 lines of code in the existing application, it
is hard to migrate everything at the same time.


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

In other words, each JFFS2 file system thinks it is connected to a
"logical" device which has blocks 0 to N-1, and an address range 0 to
( N * eraseBlockSize - 1 ).  JFFS2 obtains N and eraseBlockSize from the
driver.  JFFS2 reads bytes, writes bytes and erases blocks using
addresses in that logical space.  The device driver does the mapping
from logical addresses to the physical flash addresses.  I presume I'll
confirm that when I look over the flash_v2 code.


Your answers so far have given me a good direction to move and the
confidence to go there.  Many thanks.

Tom :::/

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