From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 523 invoked by alias); 4 Nov 2003 14:02:13 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 509 invoked from network); 4 Nov 2003 14:02:12 -0000 Received: from unknown (HELO hermes.chez-thomas.org) (63.225.98.241) by sources.redhat.com with SMTP; 4 Nov 2003 14:02:12 -0000 Received: by hermes.chez-thomas.org (Postfix, from userid 2000) id 4255150DF91; Tue, 4 Nov 2003 07:02:11 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by hermes.chez-thomas.org (Postfix) with ESMTP id B242250DF8F; Tue, 4 Nov 2003 07:02:09 -0700 (MST) From: Gary Thomas To: Chris Garry Cc: eCos Discussion In-Reply-To: <004201c3a07a$5821a4c0$500ba8c0@jasper> References: <003c01c39fdc$bc7631f0$500ba8c0@jasper> <1142.62.166.230.82.1067673372.squirrel@www.chez-thomas.org> <003401c3a06b$dae4d300$500ba8c0@jasper> <004201c3a07a$5821a4c0$500ba8c0@jasper> Content-Type: text/plain Organization: MLB Associates Message-Id: <1067954529.13745.3339.camel@hermes> Mime-Version: 1.0 Date: Tue, 04 Nov 2003 14:02:00 -0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Re: [ECOS] fis free command X-SW-Source: 2003-11/txt/msg00032.txt.bz2 On Sat, 2003-11-01 at 06:16, Chris Garry wrote: > > > > I just re-built RedBoot and noticed a small problem with the fis free > > > > command. Output from RedBoot below: > > > > > > > > -- Begin -- > > > > RedBoot(tm) bootstrap and debug environment [ROM] > > > > Non-certified release, version E7T-DBoard - built 16:51:24, Oct 31 2003 > > > > > > > > Copyright (C) 2000, 2001, 2002, Red Hat, Inc. > > > > > > > > RAM: 0x00000000-0x00080000, [0x00017cc8-0x0006f000] available > > > > 0x01900000-0x03900000, [0x01900000-0x03900000] available > > > > FLASH: 0x01800000 - 0x01880000, 128 blocks of 0x00001000 bytes each. > > > > RedBoot> fis free > > > > 0x0183B000 .. 0x0187E000 > > > > 0x01880000 .. 0x0187FFFF > > > > RedBoot> > > > > -- End -- > > > > > > > > The last line of output from the fis free command > > > > (0x01880000 .. 0x0187FFFF) is bogus since the highest FLASH address > > > > is 0x0187FFFF. > > > > > > > > Has this been seen on other platforms? > > > > > > No. What does 'fis list' show? > > > > > > > RedBoot> fis free > > 0x0183B000 .. 0x0187E000 > > 0x01880000 .. 0x0187FFFF > > RedBoot> fis list > > Name FLASH addr Mem addr Length Entry point > > (reserved) 0x01800000 0x01800000 0x00010000 0x00000000 > > RedBoot[post] 0x01810000 0x01810000 0x00020000 0x00000000 > > support.fpga 0x01830000 0x01900000 0x0000B000 0x01900000 > > RedBoot config 0x0187E000 0x0187E000 0x00001000 0x00000000 > > FIS directory 0x0187F000 0x0187F000 0x00001000 0x00000000 > > RedBoot> > > > > > Note: 'fis free' has recently been changed to believe the values in > > > the fis directory. If it is incorrect, then all bets are off. A > > > configuration control can be used to restore the previous [dubious] > > > behaviour. > > > > I rebuilt RedBoot with CYGDAT_REDBOOT_FIS_MAX_FREE_CHUNKS > > disabled and 'fis free' worked correctly. I agree that the new 'fis free'method is > > better so I'll have a look at what is going wrong on my target. > > > > Chris > > > > Okay, the problem looks to be in the find_free function. > This fix works for me: > > Index: redboot/current/src/flash.c > =================================================================== > RCS file: /cvs/ecos/ecos/packages/redboot/current/src/flash.c,v > retrieving revision 1.58 > diff -u -5 -b -p -r1.58 flash.c > --- redboot/current/src/flash.c 15 Oct 2003 15:52:03 -0000 1.5 > +++ redboot/current/src/flash.c 1 Nov 2003 13:07:00 -0000 > @@ -536,11 +536,11 @@ find_free(struct free_chunk *chunks) > for (idx = 0; idx < num_chunks; idx++) { > if ((img->flash_base >= chunks[idx].start) && > (img->flash_base <= chunks[idx].end)) { > if (img->flash_base == chunks[idx].start) { > chunks[idx].start += img->size; > - if (chunks[idx].start == chunks[idx].end) > + if (chunks[idx].start >= chunks[idx].end) > // This free chunk has collapsed > while (idx < (num_chunks-1)) { > chunks[idx] = chunks[idx+1]; > } > num_chunks--; > > > Would this fix be safe for other targets? Yes, this does appear to be a safe fix. I'll check it in. -- Gary Thomas MLB Associates -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss