This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

JFFS2 sucess! (RE: JFFS2, for Redboot only?)


Well, I got JFFS2 going.

As Andrew's e-mail came in, I was in the midst of confirming my own
suspicions.  Thanks Andrew.

I modified flashiodev_init() to unlock the part of the flash that was in
question.  Could someone suggest a better place?  The file in particular is
in the ECOS distribution - seems wrong to modify it there.

I re-ran fileio1.  It seems JFFS2 will build its own file system if and only
if the flash has been previously erased.  Nice and safe.  If there is any
data it will refuse ("cowardly").

One issue remains, since our device was never intended for constant reads
and writes the flash is at address 0.  The problem is during writes we need
to disable interrupts so that interrupt vector lookup won't happen.  Can't
afford the time that a large flash write will take.  Seems the Intel flash
driver has some provisions for a word by word write.  Essentially write a
word, reset flash, read a word.  I think I can get away with bracketing
this - need to ask the hardware guys about this.

Could make the code generic:  If interrupt_vector_table is in active flash,
disable interrupts during write/erase.


So..... does JFFS2 buffer writes?  Any provision for async completion?  I'm
going to experiment a bit with performance tuning but so far it looks slick.
Hats off to the JFFS2 maintainers/developers.

Thanks Andrew Lunn and Gary Thomas

Can you tell I'm relived?

            __  __      ___   ________  ___      __  ___      ___
Dirk Broer / ||/ ||    /_ || /__  __// /__ \\   /// /__ \\   / __\\
          //||//|||   ///|||   ///    ///_///  __  /// |||  ///_
         ///| //|||  /___ ||  ///    /__  //  /// ///      /__ ||
        /// |// ||| ///  ||| ///    /// |||  /// ///__/// ____///
       ///      |||///   |||///    ///  ||| ///  |____// /____//
Software Engineer

#include <standard_disclaimer>
#include <funny_quote>

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Andrew Lunn
Sent: Tuesday, March 02, 2004 3:10 AM
To: Dirk Broer
Cc: ECOS
Subject: Re: [ECOS] JFFS2, for Redboot only?

On Tue, Mar 02, 2004 at 12:12:14AM -0500, Dirk Broer wrote:
> Looking through the ECOS code and looking through the archives?
>
> It seems to use JFFS2 I must load up an initial JFFS2 via redboot?
>
> If the flash is already clear can?t JFFS2 simply use it?

No you need to format the disk before you can write to it. eCos does
not have a native equivalent of mkfs.jffs2 so you need to make a file
system on a host and then transfer it somehow into the flash.

> Most importantly.  A quick test of JFFS2 and it seems that during
> write the flash is never unlocked.  I did a grep for flash_unlock
> and it only showed up in fis_unlock.  AFAIK, that is a Redboot
> interface.

A Filesystem are going to be making lots of writes to a flash. Do you
really want the overhead of unlocking and locking the flash every
time? It is better to unlock it once when you put in your empty
filesystem and leave it unlocked.

I suppose another way to look at it is, a locked flash is a read-only
filesystem. So jffs2 is probably doing the write thing by refusing to
write to it.

> Does this mean JFFS2 expects an unlocked flash and the unlocking typically
> comes from Redboot?
>
> Am I missing something?   A resource on the net?

You can also unlock the flash blocks from your own program. It simple
to do.

   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




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]