Re: [ECOS] Porting eCos / Redboot / Memory map modifications / E7T

[Andrew Lunn <andrew at lunn dot ch>]

On Sun, Oct 23, 2005 at 01:10:37PM +0200, Andrew Lunn wrote:
> On Sun, Oct 23, 2005 at 10:10:45AM +0000, Ali Sina wrote:
> > Andrew, thanks again- both problems solved, following your advice below:
> > - took the redoobot repository code and worked from there
> > - disabled the init of UART0 in hal_diag.c
> > 
> > Now one small thing is left regarding the redboot start address 
> > modification:
> > 
> > - I have noticed that upon hardware reset everything works fine.
> > However, when calling "reset" from within redboot, it seems that the
> > flash is somehow not properly seen. See output below:
> > 
> > ----
> > RedBoot> reset
> > ... Resetting.
> > +FLASH: driver init failed: Driver does not support device
> 
> This is strange. Normally warm reset and flash problems means the
> system hangs solid. The normal problem is that a flash erase/write
> operation is active when the warm reset happens. Two things can then
> happen:
> 
> The warm-reset causes the reset CPU pin to be active and the flash is
> connected to this, so gets reset back into read mode.
> 
> The flash is not connected to the reset pin so stays in erase/write
> mode. All subsequent reads result in the flash returning status
> information, not contents of the flash. So the CPU has only junk to
> execute and crashs imeadietly.
> 
> You seem to have something else happening. It is booting so the flash
> must be readable. Yet the flash is not responding correctly to the ID
> request. You might want to print out the ID information. Take a look
> at the flash_query() function for the flash driver you are using. Does
> the values it is returning look like an ID? Does it look like status
> information?
> 
> This is probably something you want to fix before going into
> production. The watchdog code uses the same process to reboot the
> system. So the watchdog is not going to work. There is also a
> posibility this is a hardware problem with the flash resets. So you
> might want to get your hardware people to take a look just to make
> sure everything is as it is supposed to be.

Something else thought about last night. It could be a cache
issue. When doing something other than reading from the FLASH you need
the cache disabled. It could be that something is enabling caching on
the memory region the FLASH uses. A warm restart may not to disabling
the caches. So when the flash driver tries to access the flash after
the warm start it fails. This might be easy to prove. Getting the ID
of the flash generally means writing a command and then reading back
the result. If what you read back is the same as the command you have
just written you know you have a cache problem.

        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