public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Gary Thomas" <gary@mlbassoc.com>
To: "Chris Garry" <cgarry@sweeneydesign.co.uk>
Cc: "Gary Thomas" <gary@mlbassoc.com>,
	"eCos Discussion" <ecos-discuss@sources.redhat.com>
Subject: Re: [ECOS] fis free command
Date: Sat, 01 Nov 2003 13:18:00 -0000	[thread overview]
Message-ID: <2615.62.166.230.82.1067692678.squirrel@www.chez-thomas.org> (raw)
In-Reply-To: <004201c3a07a$5821a4c0$500ba8c0@jasper>


Chris Garry said:
>> > > 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:

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
> ===================================================================
> 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?
>
> --
> Chris
>
>


------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
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

  reply	other threads:[~2003-11-01 13:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-31 18:23 Chris Garry
2003-11-01  7:56 ` Gary Thomas
2003-11-01 11:28   ` Chris Garry
2003-11-01 13:11     ` Chris Garry
2003-11-01 13:18       ` Gary Thomas [this message]
2003-11-04 15:11         ` [ECOS] RE : " David POUTY
2003-11-04 14:02       ` Gary Thomas
2003-11-19 21:32   ` [ECOS] IXP420 Problems Sleepy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2615.62.166.230.82.1067692678.squirrel@www.chez-thomas.org \
    --to=gary@mlbassoc.com \
    --cc=cgarry@sweeneydesign.co.uk \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).