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]

Re: RE:FLASH driver problems on eCos 1.3.1 for edb7312


Chris Sekula wrote:
> 
> 1. Based upon the above observations, it appears to me that our driver
> code only worked since it had been executing from RAM with the gdb stub.
> I'm a bit confused however, since even though we built a binary image
> for ROM startup, isn't the application code (including my code for
> programming the FLASH) copied into RAM upon initialization and then
> executed from RAM?

No. eCos supports executing in place from FLASH, and there's no distinction
made between kernel and application.

> If this isn't the case, is it possible to build a
> binary image of eCos which resides on FLASH and is then copied into RAM
> upon power up so that the kernel and application executes only from RAM?

Yes, we call that ROMRAM startup. In current flash drivers, we now force
just the relevant parts of the flash driver into RAM, even when the rest of
the application is running from ROM. You can do this by making the
functions go in a different section, and then assigning that section to RAM
in the linker script (named ".2ram"). Not all the older flash drivers in
the current sources do this yet, but they hopefully will in future.
 
> 2. I've been looking over the code for the FLASH driver included with
> eCos 2.0

Note that v2.0 is the version of the configuration tool, not of eCos
itself. We'll clarify this in later versions of the config tool.

> since using this driver may be the easiest way to solve our
> problems. The code for programming and erasing is fairly straight
> forward and similar to the code which I had written. The source code for
> copying something into RAM and disabling the cache appears to be in the
> flash_hwr_init(void) function in the bootblock_flash.c file. However,
> the 'something' that is copied into RAM appears to be the flash_query
> function only. Perhaps I am not using the latest edition of the flash
> driver files? How do these functions work together? eg. to erase a
> sector do you first call the hwr_init function followed by the
> flash_erase_block function or do you have to provide your own setup code
> before calling the flash_erase_block function?

The hwr_init has to be called at some point, but it's not required
immediately prior to programming etc. The magic is really in
io/flash/current/src/flash.c. Look at flash_erase or flash_program.
CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM is defined by the underlying device
driver to indicate whether it needs copying "manually" to RAM (the old
style), or if you can just call it (new style). Note the use of
__anonymizer in order to avoid problems with the compiler trying to use a
short call when a long call is required (rom and ram may be far apart).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine


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