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]

RE: JFFS2 filesystem and eCos code on the same chip?


I studied the flash driver code in preparation of porting additional flash
devices for my project.  I observed that it does take steps to disable the
instruction and data chaches, but does not disable interrupts.  It has been
my experience with other projects that it is necessary to disable the
interrupts during "critical" flash operations.  This is necessary for two
reasons:
	1) timing.  Some flash chips require certain timing when programming
them (Winbond W29EE011 for example).  If an interrupt goes off during a
critical section, the part may get programmed wrong.
	2) running out of flash.  When executing out of the flash chip being
programmed, the routines are copied to RAM, but the exception vector table
and the exception handlers themselves are still in flash, so you cannot let
the interrupts in during the time the flash chip is in a programming mode.

Disabling the interrupts, though, brings up additional issues, namely the
watchdog.  My previous projects had a mechanism to temporarily slow down the
watchdog during the flash critical sections.  This is not typical of
watchdog timers.  The alternative is to have a method of petting the
watchdog from the flash driver's critical section.  Is there a CYG_HAL_xxx
macro to do this?

Jay Foster
jay at systech dot com.

-----Original Message-----
From: Gary Thomas [mailto:gthomas@ecoscentric.com]
Sent: Tuesday, October 15, 2002 6:37 AM
To: Andrew Lunn
Cc: llandre; eCos Disuss
Subject: Re: [ECOS] JFFS2 filesystem and eCos code on the same chip?


On Tue, 2002-10-15 at 07:28, Andrew Lunn wrote:
> On Tue, Oct 15, 2002 at 03:26:22PM +0200, llandre wrote:
> > Is it possible to have the JFFS2 file system and eCos binary code on the

> > same physical chip?
> 
> The flash driver API functions copy themselves itself into RAM before
> doing anything with the flash. Redboot uses this feature.
> 

Firstly, it's not common to actually be executing from FLASH.  RedBoot
does this, and an application can do so as well, but the more common
case is for programs to execute out of RAM.  That noted, the drivers
are designed to handle this case anyway by insisting that the access
routines are in RAM before running them.

> What i don't know about is if this is thread safe. Does the flash code
> disable interrupts while its doing dangerous things? You need to check
> the code, or probably Gary knows.

This is an interesting observation.  Currently nothing specific is being
done about interrupts.  It probably should, so I'll think about it.

-- 
------------------------------------------------------------
Gary Thomas                  |
eCosCentric, Ltd.            |  
+1 (970) 229-1963            |  eCos & RedBoot experts
gthomas@ecoscentric.com      |
http://www.ecoscentric.com/  |
------------------------------------------------------------


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

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


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