From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12104 invoked by alias); 13 Dec 2007 13:28:51 -0000 Received: (qmail 12095 invoked by uid 22791); 13 Dec 2007 13:28:50 -0000 X-Spam-Check-By: sourceware.org Received: from anubis.medic.chalmers.se (HELO anubis.medic.chalmers.se) (129.16.30.218) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Dec 2007 13:28:38 +0000 Received: from webmail.chalmers.se (styx.ita.chalmers.se [129.16.222.185]) by mail.chalmers.se (Postfix) with ESMTP id DD45819D57 for ; Thu, 13 Dec 2007 14:28:35 +0100 (CET) Received: from 213.15.68.47 (SquirrelMail authenticated user perka) by webmail.chalmers.se with HTTP; Thu, 13 Dec 2007 14:28:35 +0100 (CET) Message-ID: <1354.213.15.68.47.1197552515.squirrel@webmail.chalmers.se> In-Reply-To: References: <31213.213.15.68.47.1196669035.squirrel@webmail.chalmers.se> Date: Thu, 13 Dec 2007 14:48:00 -0000 From: "Per-Erik Johansson" To: ecos-discuss@ecos.sourceware.org User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Questions about dual flash X-SW-Source: 2007-12/txt/msg00058.txt.bz2 >> Hello again >> >> Found some posts from 2004 about merging flash_v2 and trunk.. >> http://sources.redhat.com/ml/ecos-discuss/2004-10/msg00119.html >> will this still work? >> Also I have a home-cooked driver for the internal flash, do I have to >> change this driver or will it work with v2 as it is? > > Hi, > > Yes, the merging will work. > I've done it a couple of weeks ago in light of porting eCos on the > AT91SAM7SE family. > > Just start from the trunk tree and then replace the following > directories with their flash_v2 branch counter parts: > io/flash > dev/flash > redboot > fs/jffs2 > > You will probably have to make some small changes to your ecos.db too, > but those are pretty straight-forward. > > If you enable the flash legacy api (CYGHWR_IO_FLASH_DEVICE_LEGACY cdl > option), I guess your home-cooked driver should still work. > > Tom > Hi So, here we go again :) Now we are using am29xxxxxv2 driver and our home-cooked internal flash driver using the legacy driver.. It now lists both flashes on startup: >FLASH: 0x00000000 - 0x001fffff 16 x 0x20000 blocks >FLASH: 0x20000000 - 0x207fffff 8 x 0x4000 blocks 63 x 0x20000 blocks And with a uninitialized FIS directory everything seems fine, fis free just lists the rest of the flashes as free (set minimum image size to 0x40000): RedBoot> fis free ... Read from 0x001e0000-0x001fffff to 0x407e0000: 0x00040000 .. 0x001FFFFF 0x20000000 .. 0x207FFFFF But if we then run fis init, our output from fis free becomes a bit confusing.. RedBoot> fis free ... Read from 0x001e0000-0x001fffff to 0x407e0000: 0x00040000 .. 0x001C0000 0x001C1000 .. 0x001E0000 0x00200000 .. 0x001FFFFF 0x00000001 .. 0x20020042 We have set the Maximum number of free chunks to 40 ((2MB + 8MB flash)/256k min image size) Are we thinking totally wrong here?? One even more strange thing is that if we use telnet, instead of serial, we get get this output from the fis free: RedBoot> fis free ... Read from 0x001e0000-0x001fffff to 0x407e0000: 0x00040000 .. 0x001C0000 0x001C1000 .. 0x001E0000 0x00200000 .. 0x001FFFFF 0x3FFF2BA4 .. 0x000031AC Here the last line has totally different values from the ones we got when using serial.. Have anyone seen something like this? And knows how to resolve it? Best Regards Per-Erik -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss