MPC8260 cache patch

[Jonathan Larmour]

[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