[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
NULL is an absolute value and should not be relocated. After this correction code like: void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); will still print null after relocation.
Signed-off-by: Joakim Tjernlund Joakim.Tjernlund@transmode.se ---
I have only tested this on 83xx and on a somewhat older u-boot. The change is exactly the same on all PowerPC platforms though.
cpu/mpc512x/start.S | 6 ++++-- cpu/mpc5xx/start.S | 6 ++++-- cpu/mpc5xxx/start.S | 6 ++++-- cpu/mpc8220/start.S | 6 ++++-- cpu/mpc824x/start.S | 6 ++++-- cpu/mpc8260/start.S | 6 ++++-- cpu/mpc83xx/start.S | 6 ++++-- cpu/mpc85xx/start.S | 6 ++++-- cpu/mpc86xx/start.S | 6 ++++-- cpu/mpc8xx/start.S | 6 ++++-- 10 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/cpu/mpc512x/start.S b/cpu/mpc512x/start.S index 360682d..a00e045 100644 --- a/cpu/mpc512x/start.S +++ b/cpu/mpc512x/start.S @@ -609,15 +609,17 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
/* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 diff --git a/cpu/mpc5xx/start.S b/cpu/mpc5xx/start.S index 106935c..85ea7a8 100644 --- a/cpu/mpc5xx/start.S +++ b/cpu/mpc5xx/start.S @@ -458,15 +458,17 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
/* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 diff --git a/cpu/mpc5xxx/start.S b/cpu/mpc5xxx/start.S index 6b1162a..eb42939 100644 --- a/cpu/mpc5xxx/start.S +++ b/cpu/mpc5xxx/start.S @@ -684,15 +684,17 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
/* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 diff --git a/cpu/mpc8220/start.S b/cpu/mpc8220/start.S index 3abc619..af9472d 100644 --- a/cpu/mpc8220/start.S +++ b/cpu/mpc8220/start.S @@ -649,15 +649,17 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
/* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 diff --git a/cpu/mpc824x/start.S b/cpu/mpc824x/start.S index 39325cd..750457b 100644 --- a/cpu/mpc824x/start.S +++ b/cpu/mpc824x/start.S @@ -589,15 +589,17 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
/* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 diff --git a/cpu/mpc8260/start.S b/cpu/mpc8260/start.S index 379f2fb..edb95e6 100644 --- a/cpu/mpc8260/start.S +++ b/cpu/mpc8260/start.S @@ -909,15 +909,17 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
/* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S index 26e3106..ee4b862 100644 --- a/cpu/mpc83xx/start.S +++ b/cpu/mpc83xx/start.S @@ -957,16 +957,18 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
#ifndef CONFIG_NAND_SPL /* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S index 4f7236f..d56003b 100644 --- a/cpu/mpc85xx/start.S +++ b/cpu/mpc85xx/start.S @@ -932,15 +932,17 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
/* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 diff --git a/cpu/mpc86xx/start.S b/cpu/mpc86xx/start.S index 63cc8db..e65f1c0 100644 --- a/cpu/mpc86xx/start.S +++ b/cpu/mpc86xx/start.S @@ -733,15 +733,17 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
/* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 diff --git a/cpu/mpc8xx/start.S b/cpu/mpc8xx/start.S index 8864c37..e84326e 100644 --- a/cpu/mpc8xx/start.S +++ b/cpu/mpc8xx/start.S @@ -589,15 +589,17 @@ in_ram: sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) + cmpwi r0,0 + beq- 2f add r0,r0,r11 stw r0,0(r3) - bdnz 1b +2: bdnz 1b
/* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l + li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0
On Wed, 2009-09-23 at 13:51 +0200, Joakim Tjernlund wrote:
NULL is an absolute value and should not be relocated. After this correction code like: void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); will still print null after relocation.
Signed-off-by: Joakim Tjernlund Joakim.Tjernlund@transmode.se
I have only tested this on 83xx and on a somewhat older u-boot. The change is exactly the same on all PowerPC platforms though.
Hi Jocke, I made the same changes recently, but ran into an "issue" that prevented me from sending the change upstream. Some boards/arches have the bss at address 0 and later relocate it, unlike every other NULL pointer. If you don't fix up the bss address, the board will not function. If you run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be more clear what's going on. I was doing my testing on the XPedite5370 fwiw.
In any case, the change as is would break some other arches. Seems like the proper workaround would be to "fix" the 85xx (and other arches) link script to locate the bss similar to the 83xx boards.
It might be nice to consolidate all the ppc relocate code into 1 function while we were at it.
Best, Peter
On Wednesday 23 September 2009 14:17:51 Peter Tyser wrote:
On Wed, 2009-09-23 at 13:51 +0200, Joakim Tjernlund wrote:
NULL is an absolute value and should not be relocated. After this correction code like: void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); will still print null after relocation.
Signed-off-by: Joakim Tjernlund Joakim.Tjernlund@transmode.se
I have only tested this on 83xx and on a somewhat older u-boot. The change is exactly the same on all PowerPC platforms though.
Hi Jocke, I made the same changes recently, but ran into an "issue" that prevented me from sending the change upstream. Some boards/arches have the bss at address 0 and later relocate it, unlike every other NULL pointer. If you don't fix up the bss address, the board will not function. If you run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be more clear what's going on. I was doing my testing on the XPedite5370 fwiw.
In any case, the change as is would break some other arches. Seems like the proper workaround would be to "fix" the 85xx (and other arches) link script to locate the bss similar to the 83xx boards.
It might be nice to consolidate all the ppc relocate code into 1 function while we were at it.
Yes, please!
Cheers, 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@denx.de
Peter Tyser ptyser@xes-inc.com wrote on 23/09/2009 14:17:51:
On Wed, 2009-09-23 at 13:51 +0200, Joakim Tjernlund wrote:
NULL is an absolute value and should not be relocated. After this correction code like: void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); will still print null after relocation.
Signed-off-by: Joakim Tjernlund Joakim.Tjernlund@transmode.se
I have only tested this on 83xx and on a somewhat older u-boot. The change is exactly the same on all PowerPC platforms though.
Hi Jocke, I made the same changes recently, but ran into an "issue" that prevented me from sending the change upstream. Some boards/arches have the bss at address 0 and later relocate it, unlike every other NULL pointer. If you don't fix up the bss address, the board will not function. If you run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be more clear what's going on. I was doing my testing on the XPedite5370 fwiw.
Ouch, the horror continues :(
In any case, the change as is would break some other arches. Seems like the proper workaround would be to "fix" the 85xx (and other arches) link script to locate the bss similar to the 83xx boards.
Yes, something should be done. Does it work for you with a "fixed" linker script?
It might be nice to consolidate all the ppc relocate code into 1 function while we were at it.
Played around a little and this is what I got sofar, possibly WS damged and fixups untested:
From 5099be8f64a72080e89c325943b771932389c665 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund Joakim.Tjernlund@transmode.se Date: Tue, 22 Sep 2009 23:24:46 +0200 Subject: [PATCH] relocation: Use C-functions to do relocate the GOT & fixups.
--- cpu/mpc83xx/start.S | 29 ++++++++--------------------- lib_ppc/board.c | 31 +++++++++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 21 deletions(-)
diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S index 26e3106..868b070 100644 --- a/cpu/mpc83xx/start.S +++ b/cpu/mpc83xx/start.S @@ -950,35 +950,22 @@ in_ram: * Adjust got2 pointers, no need to check for 0, this code * already puts a few entries in the table. */ - li r0,__got2_entries@sectoff@l la r3,GOT(_GOT2_TABLE_) - lwz r11,GOT(_GOT2_TABLE_) - mtctr r0 - sub r11,r3,r11 - addi r3,r3,-4 -1: lwzu r0,4(r3) - add r0,r0,r11 - stw r0,0(r3) - bdnz 1b + li r4,__got2_entries@sectoff@l + lwz r5,GOT(_GOT2_TABLE_) + sub r5,r3,r5 + mr r30,r5 + bl __eabi_convert
#ifndef CONFIG_NAND_SPL /* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ -2: li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) - cmpwi r0,0 - mtctr r0 - addi r3,r3,-4 - beq 4f -3: lwzu r4,4(r3) - lwzux r0,r4,r11 - add r0,r0,r11 - stw r10,0(r3) - stw r0,0(r4) - bdnz 3b -4: + li r4,__fixup_entries@sectoff@l + mr r5,r30 + bl __eabi_uconvert #endif
clear_bss: diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 9e944fa..0afc7c3 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -148,6 +148,37 @@ static ulong mem_malloc_brk = 0; ************************************************************************ */
+/* Relocate the .got2 pointers. */ +void __eabi_convert(unsigned long *low, unsigned long len, + unsigned long addend) +{ + unsigned long val; + + for(--low; len; --len) { + val = *++low; + if (!val) + continue; + *low = val + addend; + } +} +/* Fixup any user initialized pointers (the compiler drops pointers to */ +/* each of the relocs that it does in the .fixup section). */ +void __eabi_uconvert(unsigned long *low, unsigned long len, + unsigned long addend) +{ + unsigned long val, *v2p, val2; + + for(--low; len; --len) { + val = *++low; + val += addend; + *low = val; + v2p = (unsigned long *)val; + val2 = *v2p; + val2 += addend; + *v2p = val2; + } +} + /* * The Malloc area is immediately below the monitor copy in DRAM */ -- 1.6.4.4
I made the same changes recently, but ran into an "issue" that prevented me from sending the change upstream. Some boards/arches have the bss at address 0 and later relocate it, unlike every other NULL pointer. If you don't fix up the bss address, the board will not function. If you run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be more clear what's going on. I was doing my testing on the XPedite5370 fwiw.
Ouch, the horror continues :(
Yeah... Its seemingly never ending:)
In any case, the change as is would break some other arches. Seems like the proper workaround would be to "fix" the 85xx (and other arches) link script to locate the bss similar to the 83xx boards.
Yes, something should be done. Does it work for you with a "fixed" linker script?
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
It might be nice to consolidate all the ppc relocate code into 1 function while we were at it.
Played around a little and this is what I got sofar, possibly WS damged and fixups untested:
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
Best, Peter
Peter Tyser ptyser@xes-inc.com wrote on 23/09/2009 14:57:19:
I made the same changes recently, but ran into an "issue" that prevented me from sending the change upstream. Some boards/arches have the bss at address 0 and later relocate it, unlike every other NULL pointer. If you don't fix up the bss address, the board will not function. If you run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be more clear what's going on. I was doing my testing on the XPedite5370 fwiw.
Ouch, the horror continues :(
Yeah... Its seemingly never ending:)
In any case, the change as is would break some other arches. Seems like the proper workaround would be to "fix" the 85xx (and other arches) link script to locate the bss similar to the 83xx boards.
Yes, something should be done. Does it work for you with a "fixed" linker script?
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
It might be nice to consolidate all the ppc relocate code into 1 function while we were at it.
Played around a little and this is what I got sofar, possibly WS damged and fixups untested:
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
Played some more and got this, running out of time now so I figured I should post as is in case you (or someone else) wants to play some more. I will answer questions though.
From 684443ce6870eac2878026e47cc107fbfcdefc02 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund Joakim.Tjernlund@transmode.se Date: Wed, 23 Sep 2009 18:41:44 +0200 Subject: [PATCH] relocation: Use C as much as possible to do relocation.
--- cpu/mpc83xx/start.S | 64 ++++++++++++++++++++++++++++++++------------------ lib_ppc/board.c | 21 ++++++++++++++++- 2 files changed, 61 insertions(+), 24 deletions(-)
diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S index 868b070..ccd337a 100644 --- a/cpu/mpc83xx/start.S +++ b/cpu/mpc83xx/start.S @@ -307,6 +307,39 @@ in_flash: /* run 1st part of board init code (in Flash)*/ bl board_init_f
+ .globl got_off /* void * got_off(void * ptr) */ +got_off: + /* Adds GOT offset to ptr, might be useful for true PIC too */ + /* Would be great if this could be inline C __asm__ instead */ +#if 1 + /* Hand coded as we cannot clobber r14 when called from C */ + mflr r4 + bl 1f + .text 2 +0: .long .LCTOC1-1f + .text +1: mflr r6 + lwz r0,0b-1b(r6) + add r6,r0,r6 + mtlr r4 + addi r4,r6,.L__GOT2_TABLE_ + lwz r5, .L__GOT2_TABLE_(r6) + sub r4,r5,r4 + sub r3,r3,r4 + blr +#else + /* Use predefined macros instead */ + mflr r4 + mr r6,r14 /* GET_GOT clobbers r14 so save it */ + GET_GOT + mtlr r4 + la r4,GOT(_GOT2_TABLE_) /* addi r4, r14, .L__GOT2_TABLE_ */ + lwz r5,GOT(_GOT2_TABLE_) /* lwz r5, .L__GOT2_TABLE_(r14) */ + sub r4,r5,r4 + sub r3,r3,r4 + mr r6,r14 + blr +#endif #ifndef CONFIG_NAND_SPL /* * Vector Table @@ -842,8 +875,8 @@ flush_dcache: .globl relocate_code relocate_code: mr r1, r3 /* Set new stack pointer */ - mr r9, r4 /* Save copy of Global Data pointer */ - mr r10, r5 /* Save copy of Destination Address */ + mr r16, r4 /* Save copy of Global Data pointer */ + mr r17, r5 /* Save copy of Destination Address */
mr r3, r5 /* Destination Address */ lis r4, CONFIG_SYS_MONITOR_BASE@h /* Source Address */ @@ -860,7 +893,7 @@ relocate_code: * * Offset: */ - sub r15, r10, r4 + sub r15, r17, r4
/* First our own GOT */ add r14, r14, r15 @@ -938,7 +971,7 @@ relocate_code: * We are done. Do not return, instead branch to second part of board * initialization, now running from RAM. */ - addi r0, r10, in_ram - _start + EXC_OFF_SYS_RESET + addi r0, r17, in_ram - _start + EXC_OFF_SYS_RESET mtlr r0 blr
@@ -950,24 +983,9 @@ in_ram: * Adjust got2 pointers, no need to check for 0, this code * already puts a few entries in the table. */ - la r3,GOT(_GOT2_TABLE_) - li r4,__got2_entries@sectoff@l - lwz r5,GOT(_GOT2_TABLE_) - sub r5,r3,r5 - mr r30,r5 - bl __eabi_convert - -#ifndef CONFIG_NAND_SPL - /* - * Now adjust the fixups and the pointers to the fixups - * in case we need to move ourselves again. - */ - lwz r3,GOT(_FIXUP_TABLE_) + li r3,__got2_entries@sectoff@l li r4,__fixup_entries@sectoff@l - mr r5,r30 - bl __eabi_uconvert -#endif - + bl __do_eabi_reloc clear_bss: /* * Now clear BSS segment @@ -997,8 +1015,8 @@ clear_bss: bne 5b 6:
- mr r3, r9 /* Global Data pointer */ - mr r4, r10 /* Destination Address */ + mr r3, r16 /* Global Data pointer */ + mr r4, r17 /* Destination Address */ bl board_init_r
#ifndef CONFIG_NAND_SPL diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 0afc7c3..2a9b16e 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -147,7 +147,9 @@ static ulong mem_malloc_brk = 0; * Utilities * ************************************************************************ */ - +extern unsigned long *_GOT2_TABLE_; +extern unsigned long *_FIXUP_TABLE_; +extern void * got_off(void*); /* Relocate the .got2 pointers. */ void __eabi_convert(unsigned long *low, unsigned long len, unsigned long addend) @@ -178,6 +180,23 @@ void __eabi_uconvert(unsigned long *low, unsigned long len, *v2p = val2; } } +void __do_eabi_reloc(unsigned long got2_len, unsigned long fixup_len) +{ + unsigned long addend = (unsigned long)got_off(NULL); + unsigned long *low; + + low = (unsigned long *)(*_GOT2_TABLE_ + addend); + printf("GOT2:%lx, addend:%lx low:%p\n", + *_GOT2_TABLE_, addend, low); + __eabi_convert(low, got2_len, addend); + +#ifndef CONFIG_NAND_SPL + low = (unsigned long *)(*_FIXUP_TABLE_ + addend); + printf("FIXUP:%lx, addend:%lx low:%p\n", + *_FIXUP_TABLE_, addend, low); + __eabi_uconvert(low, fixup_len, addend); +#endif +}
/* * The Malloc area is immediately below the monitor copy in DRAM -- 1.6.4.4
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
Any progress on this ?
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example: - for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) { + for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
Jocke
On Sun, Sep 27, 2009 at 11:15 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
I think you might want to look at the x86 relocation work I have just submitted for comment. It processes all relocation sections generated by gcc/ld using the ELF data structures defined in elf.h - I generate code at a text base equal to the boot flash (0x38004000) so I can easily check if the relocation entry is with the executable. After the elf relocation processing, there is ZERO need for any offset compensation once I've jumped into the relocated code
And its all in C ;)
Jocke
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Graeme Russ graeme.russ@gmail.com wrote on 27/09/2009 15:52:38:
On Sun, Sep 27, 2009 at 11:15 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
I think you might want to look at the x86 relocation work I have just submitted for comment. It processes all relocation sections generated by gcc/ld using the ELF data structures defined in elf.h - I generate code at a text base equal to the boot flash (0x38004000) so I can easily check if the relocation entry is with the executable. After the elf relocation processing, there is ZERO need for any offset compensation once I've jumped into the relocated code
And its all in C ;)
hmm, I don't know x86 that well, but I did look at your [RFC][PATCH 8/8] Final i386 Relocation and I don't understand it fully. To make sure, is it possible for you to link at address X and run from address Y directly from flash?
Jocke
On Mon, Sep 28, 2009 at 2:18 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 27/09/2009 15:52:38:
On Sun, Sep 27, 2009 at 11:15 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
hmm, I don't know x86 that well, but I did look at your [RFC][PATCH 8/8] Final i386 Relocation and I don't understand it fully. To make sure, is it possible for you to link at address X and run from address Y directly from flash?
Jocke
Ah, I know understand what you are trying to achieve - No, my code does not allow for in-flash relocation.
My code processes the ELF relocation structures rel.got (which has pointers into .got), got.plt (which is where the location of .got is retrieved at run-time), rel.dyn (pointers into other sections other than .got), .dynamic and .dynsym
I must admit, I do not know why there are so many sections which need to be patched - I originally thought that only .got would need modifying, but the rabbit-hole is much deeper
Regards,
G
Graeme Russ graeme.russ@gmail.com wrote on 28/09/2009 01:23:36:
On Mon, Sep 28, 2009 at 2:18 AM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Graeme Russ graeme.russ@gmail.com wrote on 27/09/2009 15:52:38:
On Sun, Sep 27, 2009 at 11:15 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
hmm, I don't know x86 that well, but I did look at your [RFC][PATCH 8/8] Final i386 Relocation and I don't understand it fully. To make sure, is it possible for you to link at address X and run from address Y directly from flash?
Jocke
Ah, I know understand what you are trying to achieve - No, my code does not allow for in-flash relocation.
My code processes the ELF relocation structures rel.got (which has pointers into .got), got.plt (which is where the location of .got is retrieved at run-time), rel.dyn (pointers into other sections other than .got), .dynamic and .dynsym
I must admit, I do not know why there are so many sections which need to be patched - I originally thought that only .got would need modifying, but the rabbit-hole is much deeper
Sounds a bit much. I did a lot of LDSO work for uClibc some years ago but I forgot the details now :( But I I do remember one thing, try using -Bsymbolic when linking.
Jocke
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
Any progress on this ?
I've been swamped the last few days, but think I have a workaround. I hope to test it tomorrow or tues. I'll send an email when I have a more definitive answer.
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Great!
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot image? I understand you could execute the image from different places in flash, but on the boards I've worked with this isn't a huge concern. For example, its possible to have a preliminary flash mapping that U-Boot executes from, then after relocation to RAM that flash mapping can be modified. So where U-Boot initially executes from isn't all that important for me. Is there some killer feature that a fully PIC U-Boot provides to make adding the got_off() workarounds you mention worthwhile?
Thanks, Peter
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 06:31:28:
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
Any progress on this ?
I've been swamped the last few days, but think I have a workaround. I hope to test it tomorrow or tues. I'll send an email when I have a more definitive answer.
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Great!
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot image? I understand you could execute the image from different places in flash, but on the boards I've worked with this isn't a huge concern. For example, its possible to have a preliminary flash mapping that U-Boot executes from, then after relocation to RAM that flash mapping can be modified. So where U-Boot initially executes from isn't all that important for me. Is there some killer feature that a fully PIC U-Boot provides to make adding the got_off() workarounds you mention worthwhile?
For me, it is mainly to be to have two u-boot partitions and be able to select one to boot from. This makes it safer to update u-boot in the field.
Jocke
On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 06:31:28:
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
Any progress on this ?
I've been swamped the last few days, but think I have a workaround. I hope to test it tomorrow or tues. I'll send an email when I have a more definitive answer.
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Great!
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot image? I understand you could execute the image from different places in flash, but on the boards I've worked with this isn't a huge concern. For example, its possible to have a preliminary flash mapping that U-Boot executes from, then after relocation to RAM that flash mapping can be modified. So where U-Boot initially executes from isn't all that important for me. Is there some killer feature that a fully PIC U-Boot provides to make adding the got_off() workarounds you mention worthwhile?
For me, it is mainly to be to have two u-boot partitions and be able to select one to boot from. This makes it safer to update u-boot in the field.
X-ES requires this same functionality of dual booting. We generally have a jumper on each card that swaps 2 chip select 0 and 1 so that either can be booted from (assuming CS 0 is always used to load U-Boot). The same U-Boot image can be programmed to both flashes. After U-Boot relocates to RAM, we remap the flashes (in board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a common flash layout regardless of which flash we booted from. Would it be possible to do something similar in your hardware setup so that the same U-Boot image could be loaded from either flash partition without the got_off() fixups you mention above?
Best, Peter
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 14:45:46:
On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 06:31:28:
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
Any progress on this ?
I've been swamped the last few days, but think I have a workaround. I hope to test it tomorrow or tues. I'll send an email when I have a more definitive answer.
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Great!
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot image? I understand you could execute the image from different places in flash, but on the boards I've worked with this isn't a huge concern. For example, its possible to have a preliminary flash mapping that U-Boot executes from, then after relocation to RAM that flash mapping can be modified. So where U-Boot initially executes from isn't all that important for me. Is there some killer feature that a fully PIC U-Boot provides to make adding the got_off() workarounds you mention worthwhile?
For me, it is mainly to be to have two u-boot partitions and be able to select one to boot from. This makes it safer to update u-boot in the field.
X-ES requires this same functionality of dual booting. We generally have a jumper on each card that swaps 2 chip select 0 and 1 so that either can be booted from (assuming CS 0 is always used to load U-Boot). The same U-Boot image can be programmed to both flashes. After U-Boot relocates to RAM, we remap the flashes (in board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a common flash layout regardless of which flash we booted from. Would it be possible to do something similar in your hardware setup so that the same U-Boot image could be loaded from either flash partition without the got_off() fixups you mention above?
Nope, we don't have that extra HW support and won't have in the future either. This type of extra HW logic should not be needed and even if you do have it, how do you flip a jumper remotely? Can be done I am sure, but all this extra HW logic should not be needed at all.
Jocke
<snip>
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot image? I understand you could execute the image from different places in flash, but on the boards I've worked with this isn't a huge concern. For example, its possible to have a preliminary flash mapping that U-Boot executes from, then after relocation to RAM that flash mapping can be modified. So where U-Boot initially executes from isn't all that important for me. Is there some killer feature that a fully PIC U-Boot provides to make adding the got_off() workarounds you mention worthwhile?
For me, it is mainly to be to have two u-boot partitions and be able to select one to boot from. This makes it safer to update u-boot in the field.
X-ES requires this same functionality of dual booting. We generally have a jumper on each card that swaps 2 chip select 0 and 1 so that either can be booted from (assuming CS 0 is always used to load U-Boot). The same U-Boot image can be programmed to both flashes. After U-Boot relocates to RAM, we remap the flashes (in board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a common flash layout regardless of which flash we booted from. Would it be possible to do something similar in your hardware setup so that the same U-Boot image could be loaded from either flash partition without the got_off() fixups you mention above?
Nope, we don't have that extra HW support and won't have in the future either. This type of extra HW logic should not be needed and even if you do have it, how do you flip a jumper remotely? Can be done I am sure, but all this extra HW logic should not be needed at all.
How do you provide true redundancy without some means of changing a chip select, hardware strapping pin, etc? Without hardware support you only have 1 code entry point, correct? If that fails, the board is toast, regardless if you have redundant U-Boot images. The "jumper" I was refering to could be a physical jumper, a non-volatile gpio device, FPGA, IPMI controller, etc.
Best, Peter
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 16:29:15:
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with
directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
Only code called before relocation to RAM needs this, mostly the _f
() functions.
Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot image? I understand you could execute the image from different places in flash, but on the boards I've worked with this isn't a huge concern. For example, its possible to have a preliminary flash mapping that U-Boot executes from, then after relocation to RAM that flash mapping can be modified. So where U-Boot initially executes from isn't all that important for me. Is there some killer feature that a fully PIC U-Boot provides to make adding the got_off() workarounds you mention worthwhile?
For me, it is mainly to be to have two u-boot partitions and be able to select one to boot from. This makes it safer to update u-boot in the field.
X-ES requires this same functionality of dual booting. We generally have a jumper on each card that swaps 2 chip select 0 and 1 so that either can be booted from (assuming CS 0 is always used to load U-Boot). The same U-Boot image can be programmed to both flashes. After U-Boot relocates to RAM, we remap the flashes (in board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a common flash layout regardless of which flash we booted from. Would it be possible to do something similar in your hardware setup so that the same U-Boot image could be loaded from either flash partition without the got_off() fixups you mention above?
Nope, we don't have that extra HW support and won't have in the future either. This type of extra HW logic should not be needed and even if you do have it, how do you flip a jumper remotely? Can be done I am sure, but all this extra HW logic should not be needed at all.
How do you provide true redundancy without some means of changing a chip select, hardware strapping pin, etc? Without hardware support you only have 1 code entry point, correct? If that fails, the board is toast, regardless if you have redundant U-Boot images. The "jumper" I was refering to could be a physical jumper, a non-volatile gpio device, FPGA, IPMI controller, etc.
I have a small flash block at the reset vector(which is never updated). This block should choose which boot to branch to. This small boot block only looks at the two boot images without any HW initialization. The exact method how to choose boot isn't ready yet, but I figure one could embed a simple crc sum in u-boot which will validate the boot images.
Jocke
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 14:45:46:
On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 06:31:28:
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote:
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
Any progress on this ?
I've been swamped the last few days, but think I have a workaround. I hope to test it tomorrow or tues. I'll send an email when I have a more definitive answer.
Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Great!
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot image? I understand you could execute the image from different places in flash, but on the boards I've worked with this isn't a huge concern. For example, its possible to have a preliminary flash mapping that U-Boot executes from, then after relocation to RAM that flash mapping can be modified. So where U-Boot initially executes from isn't all that important for me. Is there some killer feature that a fully PIC U-Boot provides to make adding the got_off() workarounds you mention worthwhile?
For me, it is mainly to be to have two u-boot partitions and be able to select one to boot from. This makes it safer to update u-boot in the field.
Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable with -fpie -fpie is about the same as -fpic and -fPIE is similar to -fPIC -fpie generates smaller code so one could consider using -fpie and -mrelocatable However -fpic/-fpie needs some fixes to the relocation code, but a quick hack by me works on my board.
Does -fpie and -mrelocatable compile for you and do you have a non zero fixup section?
Jocke
On Mon, 2009-09-28 at 16:41 +0200, Joakim Tjernlund wrote:
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 14:45:46:
On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 06:31:28:
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote: > > My "fix" to the linker script was to change: > __bss_start = .; > into: > __bss_start = . | 4; > > ie, a big hack, but it did work:) I'll take a peek at a more proper > link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
Any progress on this ?
I've been swamped the last few days, but think I have a workaround. I hope to test it tomorrow or tues. I'll send an email when I have a more definitive answer.
> Nice! It'd be great to have the magical 20 lines of assembly put into > some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Great!
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot image? I understand you could execute the image from different places in flash, but on the boards I've worked with this isn't a huge concern. For example, its possible to have a preliminary flash mapping that U-Boot executes from, then after relocation to RAM that flash mapping can be modified. So where U-Boot initially executes from isn't all that important for me. Is there some killer feature that a fully PIC U-Boot provides to make adding the got_off() workarounds you mention worthwhile?
For me, it is mainly to be to have two u-boot partitions and be able to select one to boot from. This makes it safer to update u-boot in the field.
Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable with -fpie -fpie is about the same as -fpic and -fPIE is similar to -fPIC -fpie generates smaller code so one could consider using -fpie and -mrelocatable However -fpic/-fpie needs some fixes to the relocation code, but a quick hack by me works on my board.
Does -fpie and -mrelocatable compile for you and do you have a non zero fixup section?
-fpie and -mrelocatable does compile for me (tested on the XPedite5370 with gcc 4.2.2) and has a non-zero fixup section. However, the -fpie U-Boot image is slightly larger:
ptyser@petert u-boot $ size u-boot.PIC text data bss dec hex filename 304300 28644 33156 366100 59614 u-boot.PIC
ptyser@petert u-boot $ size u-boot.pie text data bss dec hex filename 304508 28624 33156 366288 596d0 u-boot.pie
Let me know if I can provide any additional detail.
Best, Peter
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 17:08:58:
Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable with -fpie -fpie is about the same as -fpic and -fPIE is similar to -fPIC -fpie generates smaller code so one could consider using -fpie and -mrelocatable However -fpic/-fpie needs some fixes to the relocation code, but a quick hack by me works on my board.
Does -fpie and -mrelocatable compile for you and do you have a non zero fixup section?
-fpie and -mrelocatable does compile for me (tested on the XPedite5370 with gcc 4.2.2) and has a non-zero fixup section. However, the -fpie U-Boot image is slightly larger:
ptyser@petert u-boot $ size u-boot.PIC text data bss dec hex filename 304300 28644 33156 366100 59614 u-boot.PIC
ptyser@petert u-boot $ size u-boot.pie text data bss dec hex filename 304508 28624 33156 366288 596d0 u-boot.pie
Let me know if I can provide any additional detail.
ehh, that is strange. Did you run a make clean in between? Do you see any "bl _GLOBAL_OFFSET_TABLE_@local-4" if you generate assembler(-S)? Maybe you had both -fPIC and -fpie defined?
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 17:08:58:
Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable with -fpie -fpie is about the same as -fpic and -fPIE is similar to -fPIC -fpie generates smaller code so one could consider using -fpie and -mrelocatable However -fpic/-fpie needs some fixes to the relocation code, but a quick hack by me works on my board.
Does -fpie and -mrelocatable compile for you and do you have a non zero
fixup section?
-fpie and -mrelocatable does compile for me (tested on the XPedite5370 with gcc 4.2.2) and has a non-zero fixup section. However, the -fpie U-Boot image is slightly larger:
ptyser@petert u-boot $ size u-boot.PIC text data bss dec hex filename 304300 28644 33156 366100 59614 u-boot.PIC
ptyser@petert u-boot $ size u-boot.pie text data bss dec hex filename 304508 28624 33156 366288 596d0 u-boot.pie
Let me know if I can provide any additional detail.
ehh, that is strange. Did you run a make clean in between? Do you see any "bl _GLOBAL_OFFSET_TABLE_@local-4" if you generate assembler(-S)? Maybe you had both -fPIC and -fpie defined?
Seems like I was in a hurry, -fpie and -mrelocatable appears to silently transform into -fPIE -mrelocatable so no gain there.
Jocke
Dear Jocke & Peter,
In message OF1F14A150.6DF103F0-ONC125763F.00559936-C125763F.0055D143@transmode.se you wrote:
ehh, that is strange. Did you run a make clean in between? Do you see any "bl _GLOBAL_OFFSET_TABLE_@local-4" if you generate assembler(-S)? Maybe you had both -fPIC and -fpie defined?
Seems like I was in a hurry, -fpie and -mrelocatable appears to silently transform into -fPIE -mrelocatable so no gain there.
Sorry, but I lost thread on this.
It seems discussion stopped here. Is it correct forme to assume that there is no patch available yet that is considered ripe to be added (to the "reloc" branch) ?
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 03/10/2009 10:13:45:
Dear Jocke & Peter,
In message <OF1F14A150.6DF103F0-ONC125763F.00559936-C125763F. 0055D143@transmode.se> you wrote:
ehh, that is strange. Did you run a make clean in between? Do you see any "bl _GLOBAL_OFFSET_TABLE_@local-4" if you generate assembler(-S)? Maybe you had both -fPIC and -fpie defined?
Seems like I was in a hurry, -fpie and -mrelocatable appears to silently transform into -fPIE -mrelocatable so no gain there.
Sorry, but I lost thread on this.
It seems discussion stopped here. Is it correct forme to assume that there is no patch available yet that is considered ripe to be added (to the "reloc" branch) ?
That is correct. Some boards(85xx) seem to have bss_start at 0 sometimes and that won't play nice with this patch. Peter was looking into this but seems like he isn't finished yet.
Also, I have been looking at moving this relocation to C-code and it isn't quite ready yet. What is left is to modify all ppc boards to use this new C-code
Jocke
Dear Joakim Tjernlund,
In message OF3474ED49.C18DA041-ONC1257644.0033ADEB-C1257644.0034147E@transmode.se you wrote:
It seems discussion stopped here. Is it correct forme to assume that there is no patch available yet that is considered ripe to be added (to the "reloc" branch) ?
That is correct. Some boards(85xx) seem to have bss_start at 0 sometimes and that won't play nice with this patch. Peter was looking into this but seems like he isn't finished yet.
Also, I have been looking at moving this relocation to C-code and it isn't quite ready yet. What is left is to modify all ppc boards to use this new C-code
So how should we proceed? My plan was to merge the "reloc" branch by the end of next week. Is this still realistic?
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 03/10/2009 14:13:57:
Dear Joakim Tjernlund,
In message <OF3474ED49.C18DA041-ONC1257644.0033ADEB-C1257644. 0034147E@transmode.se> you wrote:
It seems discussion stopped here. Is it correct forme to assume that there is no patch available yet that is considered ripe to be added (to the "reloc" branch) ?
That is correct. Some boards(85xx) seem to have bss_start at 0 sometimes and that won't play nice with this patch. Peter was looking into this but seems like he isn't finished yet.
Also, I have been looking at moving this relocation to C-code and it isn't quite ready yet. What is left is to modify all ppc boards to use this new C-code
So how should we proceed? My plan was to merge the "reloc" branch by the end of next week. Is this still realistic?
Yes, my work is not required. Actually the current u-boot also suffers from this defect. I am only trying to future prof the relocation. Some day we might want to do: if (weak_fun) weak_fun(); but today nobody is using this in u-boot.
Jocke
On Sat, 2009-10-03 at 14:13 +0200, Wolfgang Denk wrote:
Dear Joakim Tjernlund,
In message OF3474ED49.C18DA041-ONC1257644.0033ADEB-C1257644.0034147E@transmode.se you wrote:
It seems discussion stopped here. Is it correct forme to assume that there is no patch available yet that is considered ripe to be added (to the "reloc" branch) ?
That is correct. Some boards(85xx) seem to have bss_start at 0 sometimes and that won't play nice with this patch. Peter was looking into this but seems like he isn't finished yet.
Also, I have been looking at moving this relocation to C-code and it isn't quite ready yet. What is left is to modify all ppc boards to use this new C-code
So how should we proceed? My plan was to merge the "reloc" branch by the end of next week. Is this still realistic?
That plan is realistic. The executive summary is: The current "reloc" branch works, and is an improvement on U-Boot's previous "semi-reolcation", so we should merge it for this release.
There are a few change which would further improve relocation that Jocke and I want to get merged. Whether these improvements occur in this release or the next is not a big deal to me. 1. Fix relocation of NULL pointers. eg the following code would print the relocation fixup offset instead of the expected NULL. void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); This was already an issue, so we're not breaking anything in the "reloc" branch
2. Move relocation fixup code to C-code
3. Possibly get true relocation working so that U-Boot could be located anywhere and still execute.
Jocke has 1 and 2 mostly figured out, I just need some time to play with the linker scripts a bit more to ensure nothing breaks. (Sorry Jocke, its been a busy week).
Peter
Dear Peter,
In message 1254577553.23101.14.camel@ptyser-laptop you wrote:
So how should we proceed? My plan was to merge the "reloc" branch by the end of next week. Is this still realistic?
That plan is realistic. The executive summary is: The current "reloc" branch works, and is an improvement on U-Boot's previous "semi-reolcation", so we should merge it for this release.
OK, so let's do that.
There are a few change which would further improve relocation that Jocke and I want to get merged. Whether these improvements occur in this release or the next is not a big deal to me.
- Fix relocation of NULL pointers.
eg the following code would print the relocation fixup offset instead of the expected NULL. void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); This was already an issue, so we're not breaking anything in the "reloc" branch
Move relocation fixup code to C-code
Possibly get true relocation working so that U-Boot could be located
anywhere and still execute.
I tend to get all of this (as far as it's available and considered to be ready) into this release, so we have it all in one big block.
Jocke has 1 and 2 mostly figured out, I just need some time to play with the linker scripts a bit more to ensure nothing breaks. (Sorry Jocke, its been a busy week).
You don't have to apologize. We've all been in similar situations before. And we really appreciate your efforts (and Jocke's, of course).
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 03/10/2009 16:28:23:
Dear Peter,
In message 1254577553.23101.14.camel@ptyser-laptop you wrote:
So how should we proceed? My plan was to merge the "reloc" branch by the end of next week. Is this still realistic?
That plan is realistic. The executive summary is: The current "reloc" branch works, and is an improvement on U-Boot's previous "semi-reolcation", so we should merge it for this release.
OK, so let's do that.
There are a few change which would further improve relocation that Jocke and I want to get merged. Whether these improvements occur in this release or the next is not a big deal to me.
- Fix relocation of NULL pointers.
eg the following code would print the relocation fixup offset instead of the expected NULL. void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); This was already an issue, so we're not breaking anything in the "reloc" branch
Move relocation fixup code to C-code
Possibly get true relocation working so that U-Boot could be located
anywhere and still execute.
I tend to get all of this (as far as it's available and considered to be ready) into this release, so we have it all in one big block.
3. isn't ready and won't be for a while more
1. is just a small fix the the existing asm reloc functions. Pretty much ready but needs some linker tweeks it seems. No idea if other boards than 85xx also needs a linker tweak or not.
2. is 1 in C and some common supporting asm for ppc. Any idea were to put common asm files for ppc? I was hoping I could get away with just 83xx and the rest could be done later by interested parties?
I have also done some work to fully relocate the IRQ code so one can remove the --fixed-r14 flag to gcc for 83xx.
Dear Jocke,
In message OFC719203E.B96F8807-ONC1257644.00522490-C1257644.005349B9@transmode.se you wrote:
I tend to get all of this (as far as it's available and considered to be ready) into this release, so we have it all in one big block.
- isn't ready and won't be for a while more
OK...
is just a small fix the the existing asm reloc functions. Pretty much ready but needs some linker tweeks it seems. No idea if other boards than 85xx also needs a linker tweak or not.
is 1 in C and some common supporting asm for ppc. Any idea were to put common asm files for ppc? I was hoping I could get away with just 83xx and the rest could be done later by interested parties?
What about lib_ppc/*.S ?
I have also done some work to fully relocate the IRQ code so one can remove the --fixed-r14 flag to gcc for 83xx.
Thanks.
Best regards,
Wolfgang Denk
Hi Jocke,
There are a few change which would further improve relocation that Jocke and I want to get merged. Whether these improvements occur in this release or the next is not a big deal to me.
- Fix relocation of NULL pointers.
eg the following code would print the relocation fixup offset instead of the expected NULL. void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); This was already an issue, so we're not breaking anything in the "reloc" branch
Move relocation fixup code to C-code
Possibly get true relocation working so that U-Boot could be located
anywhere and still execute.
I tend to get all of this (as far as it's available and considered to be ready) into this release, so we have it all in one big block.
isn't ready and won't be for a while more
is just a small fix the the existing asm reloc functions. Pretty much ready but needs some linker tweeks it seems. No idea if other boards than 85xx also needs a linker tweak or not.
It looks like 85xx is the only arch that needed linker script tweaks. I just submitted some patches a bit ago.
- is 1 in C and some common supporting asm for ppc. Any idea were to put common asm files for ppc? I was hoping I could get away with just 83xx and the rest could be done later by interested parties?
Assuming the 85xx link script changes are accepted, what's the gameplan now? #1 is pretty trivial (the original patch that spawned this thread with slight tweaks) and should be easy to get in this merge window. That would get us to the point that relocation is fully functional, including non-relocation of NULL pointers.
#2 looks more involved and prone to errors as it requires some shuffling of registers in assembly for all architectures. Are we aiming for getting #2 across all architectures in this window? I should be able to implement and test it on 85xx, 86xx, and 44x, and Jocke's tested on 83xx. I don't think I could do the rest of the arches by the end of this week though. Any other takers? Save it for the next merge window?
Best, Peter
Dear Peter Tyser,
In message 1254784811.24664.968.camel@localhost.localdomain you wrote:
- is just a small fix the the existing asm reloc functions. Pretty much ready but needs some linker tweeks it seems. No idea if other boards than 85xx also needs a linker tweak or not.
It looks like 85xx is the only arch that needed linker script tweaks. I just submitted some patches a bit ago.
I think this code is too complex. Eventually we could hard-wire something like ". = 0x40000" or similar for a fixed location of the (pre-relocation) bss on all 85xx/86xx systems.
- is 1 in C and some common supporting asm for ppc. Any idea were to put common asm files for ppc? I was hoping I could get away with just 83xx and the rest could be done later by interested parties?
Assuming the 85xx link script changes are accepted, what's the gameplan now? #1 is pretty trivial (the original patch that spawned this thread with slight tweaks) and should be easy to get in this merge window. That would get us to the point that relocation is fully functional, including non-relocation of NULL pointers.
I think this is a nice and realistic goal for the current release.
#2 looks more involved and prone to errors as it requires some shuffling of registers in assembly for all architectures. Are we aiming for getting #2 across all architectures in this window? I should be able to implement and test it on 85xx, 86xx, and 44x, and Jocke's tested on 83xx. I don't think I could do the rest of the arches by the end of this week though. Any other takers? Save it for the next merge window?
I guess this is for next version.
Um... jut to be sure - I understand that by "all architectures" above you actually mean "all Power architecture CPU families", i. e. you don't include the needed cleanup for ARM, MIPs, etc. here (yet) ?
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de 365 Days of drinking Lo-Cal beer. 1 Lite-year
Wolfgang Denk wd@denx.de wrote on 06/10/2009 10:58:53:
Dear Peter Tyser,
In message 1254784811.24664.968.camel@localhost.localdomain you wrote:
- is just a small fix the the existing asm reloc functions. Pretty much ready but needs some linker tweeks it seems. No idea if other boards than 85xx also needs a linker tweak or not.
It looks like 85xx is the only arch that needed linker script tweaks. I just submitted some patches a bit ago.
I think this code is too complex. Eventually we could hard-wire something like ". = 0x40000" or similar for a fixed location of the (pre-relocation) bss on all 85xx/86xx systems.
- is 1 in C and some common supporting asm for ppc. Any idea were to put common asm files for ppc? I was hoping I could get away with just 83xx and the rest could be done later by interested parties?
Assuming the 85xx link script changes are accepted, what's the gameplan now? #1 is pretty trivial (the original patch that spawned this thread with slight tweaks) and should be easy to get in this merge window. That would get us to the point that relocation is fully functional, including non-relocation of NULL pointers.
I think this is a nice and realistic goal for the current release.
Yes, then it works and the C-version can come on top.
#2 looks more involved and prone to errors as it requires some shuffling of registers in assembly for all architectures. Are we aiming for getting #2 across all architectures in this window? I should be able to implement and test it on 85xx, 86xx, and 44x, and Jocke's tested on 83xx. I don't think I could do the rest of the arches by the end of this week though. Any other takers? Save it for the next merge window?
I guess this is for next version.
Yes, I am getting behind due to some 8xx MMU problems. If I am really lucky I may be able to do 83xx only, but my code base is a mess ATM :(
Um... jut to be sure - I understand that by "all architectures" above you actually mean "all Power architecture CPU families", i. e. you don't include the needed cleanup for ARM, MIPs, etc. here (yet) ?
I sure hope so :)
Hi Wolfgang,
My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
I've tried a few ways to ensure the BSS isn't at address 0x0, and they all seem to have their shortcomings. I'm currently leaning towards doing something along the lines of the above, ie ORing 0x10 into the BSS address.
I had assumed 8 or 16 bit alignment of the BSS would be sufficient. Could you give a little background on your warning above about 32 bit alignment being insufficient?
Thanks, Peter
Dear Peter Tyser,
In message 1254773254.24664.657.camel@localhost.localdomain you wrote:
32 bit alignment of the BSS segment might not be sufficient. Be careful!
I've tried a few ways to ensure the BSS isn't at address 0x0, and they all seem to have their shortcomings. I'm currently leaning towards doing something along the lines of the above, ie ORing 0x10 into the BSS address.
I had assumed 8 or 16 bit alignment of the BSS would be sufficient. Could you give a little background on your warning above about 32 bit alignment being insufficient?
I don't know all flavours of Power machines, but gcc seems to align "double" on 64 bit boundaries. This makes me think it might be needed.
Best regards,
Wolfgang Denk
On Mon, Oct 05, 2009 at 11:18:11PM +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254773254.24664.657.camel@localhost.localdomain you wrote:
32 bit alignment of the BSS segment might not be sufficient. Be careful!
I've tried a few ways to ensure the BSS isn't at address 0x0, and they all seem to have their shortcomings. I'm currently leaning towards doing something along the lines of the above, ie ORing 0x10 into the BSS address.
I had assumed 8 or 16 bit alignment of the BSS would be sufficient. Could you give a little background on your warning above about 32 bit alignment being insufficient?
I don't know all flavours of Power machines, but gcc seems to align "double" on 64 bit boundaries. This makes me think it might be needed.
Plus, explicit alignment (cacheline, page, some DMA alignment restriction, etc) could have been requested on something in the BSS. I'd keep it at least page-aligned if possible.
-Scott
Dear Scott Wood,
In message 20091006171203.GA10244@b07421-ec1.am.freescale.net you wrote:
I don't know all flavours of Power machines, but gcc seems to align "double" on 64 bit boundaries. This makes me think it might be needed.
Plus, explicit alignment (cacheline, page, some DMA alignment restriction, etc) could have been requested on something in the BSS. I'd keep it at least page-aligned if possible.
We have no notation of "pages" in U-Boot. Linker scripts typically use 256 byte alignment as the most strict requriement, and this is randomly chosen, either. I guess cache line size would do just fine (and even this is probably overkill).
Best regards,
Wolfgang Denk
On Wednesday 23 September 2009 13:51:46 Joakim Tjernlund wrote:
NULL is an absolute value and should not be relocated. After this correction code like: void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); will still print null after relocation.
Signed-off-by: Joakim Tjernlund Joakim.Tjernlund@transmode.se
I have only tested this on 83xx and on a somewhat older u-boot. The change is exactly the same on all PowerPC platforms though.
cpu/mpc512x/start.S | 6 ++++-- cpu/mpc5xx/start.S | 6 ++++-- cpu/mpc5xxx/start.S | 6 ++++-- cpu/mpc8220/start.S | 6 ++++-- cpu/mpc824x/start.S | 6 ++++-- cpu/mpc8260/start.S | 6 ++++-- cpu/mpc83xx/start.S | 6 ++++-- cpu/mpc85xx/start.S | 6 ++++-- cpu/mpc86xx/start.S | 6 ++++-- cpu/mpc8xx/start.S | 6 ++++--
Thanks. But I think you missed ppc4xx here:
cpu/ppc4xx/start.S
Cheers, 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@denx.de
Stefan Roese sr@denx.de wrote on 23/09/2009 14:24:34:
On Wednesday 23 September 2009 13:51:46 Joakim Tjernlund wrote:
NULL is an absolute value and should not be relocated. After this correction code like: void weak_fun(void) __attribute__((weak)); printf("weak_fun:%p\n", weak_fun); will still print null after relocation.
Signed-off-by: Joakim Tjernlund Joakim.Tjernlund@transmode.se
I have only tested this on 83xx and on a somewhat older u-boot. The change is exactly the same on all PowerPC platforms though.
cpu/mpc512x/start.S | 6 ++++-- cpu/mpc5xx/start.S | 6 ++++-- cpu/mpc5xxx/start.S | 6 ++++-- cpu/mpc8220/start.S | 6 ++++-- cpu/mpc824x/start.S | 6 ++++-- cpu/mpc8260/start.S | 6 ++++-- cpu/mpc83xx/start.S | 6 ++++-- cpu/mpc85xx/start.S | 6 ++++-- cpu/mpc86xx/start.S | 6 ++++-- cpu/mpc8xx/start.S | 6 ++++--
Thanks. But I think you missed ppc4xx here:
cpu/ppc4xx/start.S
oops, if you rename ppc4xx to mpc4xx such mistakes can be avoided.
Jocke
participants (7)
-
Graeme Russ -
Joakim Tjernlund -
Joakim Tjernlund
-
Peter Tyser -
Scott Wood -
Stefan Roese -
Wolfgang Denk