This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: MPC8260 cache patch
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Gary Thomas <gary at mlbassoc dot com>
- Cc: eCos developers <ecos-devel at sources dot redhat dot com>
- Date: Mon, 31 Mar 2003 18:32:22 +0100
- 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>
[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).
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine