-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Stefan Roese Sent: den 8 april 2008 21:53 To: joakim.tjernlund@transmode.se Cc: u-boot-users@lists.sourceforge.net; 'Kim Phillips'; Wolfgang Denk Subject: Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
On Tuesday 08 April 2008, Joakim Tjernlund wrote:
On 4xx execution always starts at 0xfffffffc (last lword in 32bit address space). This location holds a jump to _start for 405 PPC's and to _start_440 for 440 PPC's. 440 PPC's need some extended initialization (TLB setup etc) and later jump to the 4xx common _start.
OK, then it is like I suspected. What if you rename _start to _common_start. Make _start equal _common_start for 405 and rename _start_440 to _start, i.e make sure that _start is defined where you start executing after the jump.
As I mentioned earlier, _start_440 is mapped to 0xfffff000 via the linker script since the jump from 0xfffffffc can't be too long (because of the 4k shadow TLB entry). So renaming _start_440 to _start won't help here. It can be done, but frankly I don't have the time for it currently.
I see, suspected that we would not get away that easy :(
I'm an linker script dyslexic. So no idea if we can handle this solely in the linker script or if we need a new common symbol in the PPC start.S's.
Both ways should be doable I think. A linker script would probably look something like(pseudo diff below): .text : {
- _monitor_base = . ;
- PROVIDE (_monitor_base = .); cpu/mpc83xx/start.o (.text)
And then add a GOT_ENTRY(_monitor_base) in start.S
The disadvantage I see is that I need to change the linker scripts for all boards for such a solution. Doesn't sound like fun.
Yeah, probably easier to define the symbol in start.S and skip the linker version.
So for now, I would really like to see the old version with the ugly CFG_MONITOR_BASE back so that 4xx board can be used again.
Then I would ask you to do an #ifdef for ppc440(or similar). If the long term solution should be to move _start to its true start vector, you could just go back to the old way for ppc4xx. If the long term solution should be a new symbol you could just impl. that for ppc4xx and just use it for ppc4xx only, then the other archs can follow when the next merge window opens.
Jocke
Best regards, Stefan