[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Stefan Roese <sr@denx.de>]

On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > I'm afraid, but the "other ppc's" did break with this patch. At least 4xx
> > does. With your patch applied relocation to SDRAM does not work anymore.
> > Here's what I get:
> >
> > CFG_MONITOR_BASE=fffa0000
> > (ulong)&_start + EXC_OFF_SYS_RESET=fffa2200
> > EXC_OFF_SYS_RESET=100
> >
> > I haven't looked into it closer yet. Any idea on how to fix this?
> >
> > Thanks.
> >
> > Best regards,
> > Stefan
>
> Oops, didn't see that coming. Your _start symbol in ppc4xx/start.S isn't
> pointing to your real start of execution. Seems like _start_440 is your
> real start but I can't be sure.

No, unfortunately it's not. _start_440 is loaded into the last 4k of bootrom 
(via linker script), since 440 has a shadow TLB upon startup to only map 4k 
of address space. After looking at System.map it seems that _start_of_vectors 
seems to be the way to go for 4xx:

fffa0004 T version_string
fffa0100 t CritcalInput
fffa0100 T _start_of_vectors

But I don't want to introduce some #ifdef here. Perhaps it would be better to 
introduce a common (PPC) label that points to the beginning of the U-Boot 
image here.

BTW: I think this version:

	len = (ulong)&_end - ((ulong)&_start - EXC_OFF_SYS_RESET);

instead of:

	len = (ulong)&_end - (ulong)&_start + EXC_OFF_SYS_RESET;

is better. Makes the transition from CFG_MONITOR_BASE clearer, don't you think 
so?

> There are some strange code in there 
> that I don't understand.

Yes, it's quite complex because it supports all 4xx variants.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================