From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22495 invoked by alias); 23 Oct 2005 11:10:45 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 22485 invoked by uid 22791); 23 Oct 2005 11:10:41 -0000 Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 23 Oct 2005 11:10:41 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1ETdkL-0000Pf-00; Sun, 23 Oct 2005 13:10:37 +0200 Date: Sun, 23 Oct 2005 11:10:00 -0000 To: Ali Sina Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20051023111037.GW7087@lunn.ch> Mail-Followup-To: Ali Sina , ecos-discuss@ecos.sourceware.org References: <20051016211751.GA7087@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 From: Andrew Lunn Subject: Re: [ECOS] Porting eCos / Redboot / Memory map modifications / E7T X-SW-Source: 2005-10/txt/msg00187.txt.bz2 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. 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