From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27083 invoked by alias); 4 Nov 2003 15:11:48 -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 27073 invoked from network); 4 Nov 2003 15:11:46 -0000 Received: from unknown (HELO mail.libertysurf.net) (213.36.80.91) by sources.redhat.com with SMTP; 4 Nov 2003 15:11:46 -0000 Received: from PC4 (213.36.214.117) by mail.libertysurf.net (6.5.026) id 3F94E7F101188AD1; Tue, 4 Nov 2003 16:11:45 +0100 From: "David POUTY" To: "'Gary Thomas'" Cc: "'eCos Discussion'" Date: Tue, 04 Nov 2003 15:11:00 -0000 Message-ID: <001701c3a2e5$f5ade290$8300a8c0@PC4> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal In-Reply-To: <2615.62.166.230.82.1067692678.squirrel@www.chez-thomas.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [ECOS] RE : [ECOS] fis free command X-SW-Source: 2003-11/txt/msg00033.txt.bz2 I think there's another problem with 'fis free'. In the following code 'idx' is never incremented, so ... // This free chunk has collapsed while (idx < (num_chunks-1)) { chunks[idx] =3D chunks[idx+1]; } There's also a limitation. fis free doesn't work well when FIS end at address 0xFFFFFFFF (I'm in this case).=20 I'll try to submit a patch this week. David -----Message d'origine----- De : Gary Thomas [mailto:gary@mlbassoc.com]=20 Envoy=E9 : samedi 1 novembre 2003 14:18 =C0 : Chris Garry Cc : Gary Thomas; eCos Discussion Objet : Re: [ECOS] fis free command Chris Garry said: >> > > I just re-built RedBoot and noticed a small problem with the fis=20 >> > > free command. Output from RedBoot below: >> > > >> > > -- Begin -- >> > > RedBoot(tm) bootstrap and debug environment [ROM] Non-certified=20 >> > > 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=20 >> > > each. >> > > RedBoot> fis free >> > > 0x0183B000 .. 0x0187E000 >> > > 0x01880000 .. 0x0187FFFF >> > > RedBoot> >> > > -- End -- >> > > >> > > The last line of output from the fis free command (0x01880000 ..=20 >> > > 0x0187FFFF) is bogus since the highest FLASH address is=20 >> > > 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=20 >> > 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=20 >> free'method is better so I'll have a look at what is going wrong on=20 >> my target. >> >> Chris >> > > Okay, the problem looks to be in the find_free function. > This fix works for me: I think I had it that way before and had troubles, so I'm not sure. Today, I'm 6000+ miles from my office, so I can't do much checking. I'll give this a look on Monday. Thanks for looking into it. > > Index: redboot/current/src/flash.c=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 =3D 0; idx < num_chunks; idx++) { > if ((img->flash_base >=3D chunks[idx].start) && > (img->flash_base <=3D chunks[idx].end)) { > if (img->flash_base =3D=3D chunks[idx].start) { > chunks[idx].start +=3D img->size; > - if (chunks[idx].start =3D=3D chunks[idx].end) > + if (chunks[idx].start >=3D chunks[idx].end) > // This free chunk has collapsed > while (idx < (num_chunks-1)) { > chunks[idx] =3D chunks[idx+1]; > } > num_chunks--; > > > Would this fix be safe for other targets? > > -- > Chris > > ------------------------------------------------------------ Gary Thomas | MLB Associates | Consulting for the +1 (970) 229-1963 | Embedded world http://www.mlbassoc.com/ | email: | gpg: http://www.chez-thomas.org/gary/gpg_key.asc ------------------------------------------------------------ -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss