This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: MPC8260 cache patch
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Jonathan Larmour <jifl at eCosCentric dot com>
- Cc: eCos developers <ecos-devel at sources dot redhat dot com>
- Date: 31 Mar 2003 12:17:07 -0700
- Subject: Re: MPC8260 cache patch
- References: <NFBBJAJICAKJPMMKDAGBOELMDNAA.wpd@delcomsys.com> <1049054176.8091.13201.came l@hermes.chez-thomas.org> <3E876701.3060807@eCosCentric.com> <1049061486.9286.13449.camel@hermes.chez -thomas.org> <3E876CCC.6010802@eCosCentric.com> <1049062718.8091.13494.camel@hermes.chez-thomas.org> <3E87D87D.4090709@eCosCentric.com><1049126388.16207.798.camel@hermes.chez-thomas.org> <3E887BA6.9000603@eCosCentric.com>
On Mon, 2003-03-31 at 10:32, Jonathan Larmour wrote:
> [Moved off ecos-patches to ecos-devel]
>
> Summary: I've worked it out...
>
> > I just tried this on mine:
> > RedBoot> lo -b 0x100000 -r viper.rbb
> > Raw file loaded 0x00100000-0x00125abb, assumed entry at 0x00100000
> > RedBoot> cksum
> > Computing cksum for area 0x00100000-0x00125abc
> > POSIX cksum = 3844061083 154300 (0xe51fb79b 0x00025abc)
> >
> > So, what's special/different about your board?
>
> Nothing. In fact for consistency with yours it's even the "Linux" one, not
> the "eCos" one.
>
> I tested and gave the board a complete power cycle, not just soft reset.
> Loading the srec produced the wrong cksum, then loading the raw binary
> gave the correct result.
>
> Then I compared memory dumps, and it differed between 0x102000 and
> 0x103400 - aha, that's .vectors! And sure enough the srec has a hole
> between offset 0x2000 and 0x3400. As it evidently should as an objdump -h
> shows:
>
> Idx Name Size VMA LMA File off Algn
> 0 .vectors 00002000 00000000 00000000 00010000 2**8
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 1 .text 0001c51c 00003400 00003400 00013400 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
>
> i.e. a gap between the end of .vectors and start of .text. So that's the
> explanation. Phew. So it was operator error after all - just a slightly
> obscure one that doing a cksum of the .bin file doesn't necessarily give
> the same result when loading the .srec.
>
> So the question becomes whether we can do something to stop this being a
> gotcha for others. Using objcopy with --gap-fill didn't seem to work and I
> don't know quite what else to try (converting to binary and back is a
> little lossy).
We could add an option to "load" which says to zero fill any
gaps, but I'm a bit leery of that as well.
Something to thing more about.
--
------------------------------------------------------------
Gary Thomas |
MLB Associates | Consulting for the
+1 (970) 229-1963 | Embedded world
http://www.mlbassoc.com/ |
email: <gary at mlbassoc dot com> |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------