[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs
The fixup routine must not fixup NULL pointers. Problem can be seen by char *testfun(void) __attribute__((weak)); char *(*myfun)(void) = testfun;
Then add printf("myfun:%p, &myfun:%p\n", myfun, &myfun); before relocation and after relocation. myfun should be NULL in both cases but it is not.
Signed-off-by: Joakim Tjernlund Joakim.Tjernlund@transmode.se --- arch/powerpc/cpu/74xx_7xx/start.S | 4 +++- arch/powerpc/cpu/mpc512x/start.S | 4 +++- arch/powerpc/cpu/mpc5xx/start.S | 4 +++- arch/powerpc/cpu/mpc5xxx/start.S | 4 +++- arch/powerpc/cpu/mpc8220/start.S | 4 +++- arch/powerpc/cpu/mpc824x/start.S | 4 +++- arch/powerpc/cpu/mpc8260/start.S | 4 +++- arch/powerpc/cpu/mpc83xx/start.S | 4 +++- arch/powerpc/cpu/mpc85xx/start.S | 4 +++- arch/powerpc/cpu/mpc86xx/start.S | 4 +++- arch/powerpc/cpu/mpc8xx/start.S | 4 +++- arch/powerpc/cpu/ppc4xx/start.S | 4 +++- 12 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/cpu/74xx_7xx/start.S b/arch/powerpc/cpu/74xx_7xx/start.S index 88fdf88..ce0fa3d 100644 --- a/arch/powerpc/cpu/74xx_7xx/start.S +++ b/arch/powerpc/cpu/74xx_7xx/start.S @@ -722,10 +722,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: /* clear_bss: */ /* diff --git a/arch/powerpc/cpu/mpc512x/start.S b/arch/powerpc/cpu/mpc512x/start.S index d26b617..64eb657 100644 --- a/arch/powerpc/cpu/mpc512x/start.S +++ b/arch/powerpc/cpu/mpc512x/start.S @@ -615,10 +615,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: clear_bss: /* diff --git a/arch/powerpc/cpu/mpc5xx/start.S b/arch/powerpc/cpu/mpc5xx/start.S index 0af879e..560c706 100644 --- a/arch/powerpc/cpu/mpc5xx/start.S +++ b/arch/powerpc/cpu/mpc5xx/start.S @@ -464,10 +464,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: clear_bss: /* diff --git a/arch/powerpc/cpu/mpc5xxx/start.S b/arch/powerpc/cpu/mpc5xxx/start.S index 8b9f09b..b8c1cb5 100644 --- a/arch/powerpc/cpu/mpc5xxx/start.S +++ b/arch/powerpc/cpu/mpc5xxx/start.S @@ -680,10 +680,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: clear_bss: /* diff --git a/arch/powerpc/cpu/mpc8220/start.S b/arch/powerpc/cpu/mpc8220/start.S index 3d79d8e..6b63821 100644 --- a/arch/powerpc/cpu/mpc8220/start.S +++ b/arch/powerpc/cpu/mpc8220/start.S @@ -653,10 +653,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: clear_bss: /* diff --git a/arch/powerpc/cpu/mpc824x/start.S b/arch/powerpc/cpu/mpc824x/start.S index f3f595a..a32e68b 100644 --- a/arch/powerpc/cpu/mpc824x/start.S +++ b/arch/powerpc/cpu/mpc824x/start.S @@ -595,10 +595,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: clear_bss: /* diff --git a/arch/powerpc/cpu/mpc8260/start.S b/arch/powerpc/cpu/mpc8260/start.S index a435042..5c2e251 100644 --- a/arch/powerpc/cpu/mpc8260/start.S +++ b/arch/powerpc/cpu/mpc8260/start.S @@ -915,10 +915,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: clear_bss: /* diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S index c9bb0ea..e8b1ebc 100644 --- a/arch/powerpc/cpu/mpc83xx/start.S +++ b/arch/powerpc/cpu/mpc83xx/start.S @@ -986,10 +986,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: #endif
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index b3cb56a..19e9735 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -1025,10 +1025,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: clear_bss: /* diff --git a/arch/powerpc/cpu/mpc86xx/start.S b/arch/powerpc/cpu/mpc86xx/start.S index ed1e4ca..3f05e53 100644 --- a/arch/powerpc/cpu/mpc86xx/start.S +++ b/arch/powerpc/cpu/mpc86xx/start.S @@ -739,10 +739,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: /* clear_bss: */ /* diff --git a/arch/powerpc/cpu/mpc8xx/start.S b/arch/powerpc/cpu/mpc8xx/start.S index 7cf602f..1b729eb 100644 --- a/arch/powerpc/cpu/mpc8xx/start.S +++ b/arch/powerpc/cpu/mpc8xx/start.S @@ -595,10 +595,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: clear_bss: /* diff --git a/arch/powerpc/cpu/ppc4xx/start.S b/arch/powerpc/cpu/ppc4xx/start.S index c739deb..27709c4 100644 --- a/arch/powerpc/cpu/ppc4xx/start.S +++ b/arch/powerpc/cpu/ppc4xx/start.S @@ -1602,10 +1602,12 @@ in_ram: beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 + cmpwi r0,0 add r0,r0,r11 stw r10,0(r3) + beq- 5f stw r0,0(r4) - bdnz 3b +5: bdnz 3b 4: clear_bss: /*
Dear Joakim Tjernlund,
In message 1287049904-18917-1-git-send-email-Joakim.Tjernlund@transmode.se you wrote:
The fixup routine must not fixup NULL pointers. Problem can be seen by char *testfun(void) __attribute__((weak)); char *(*myfun)(void) = testfun;
Then add printf("myfun:%p, &myfun:%p\n", myfun, &myfun); before relocation and after relocation. myfun should be NULL in both cases but it is not.
Signed-off-by: Joakim Tjernlund Joakim.Tjernlund@transmode.se
arch/powerpc/cpu/74xx_7xx/start.S | 4 +++- arch/powerpc/cpu/mpc512x/start.S | 4 +++- arch/powerpc/cpu/mpc5xx/start.S | 4 +++- arch/powerpc/cpu/mpc5xxx/start.S | 4 +++- arch/powerpc/cpu/mpc8220/start.S | 4 +++- arch/powerpc/cpu/mpc824x/start.S | 4 +++- arch/powerpc/cpu/mpc8260/start.S | 4 +++- arch/powerpc/cpu/mpc83xx/start.S | 4 +++- arch/powerpc/cpu/mpc85xx/start.S | 4 +++- arch/powerpc/cpu/mpc86xx/start.S | 4 +++- arch/powerpc/cpu/mpc8xx/start.S | 4 +++- arch/powerpc/cpu/ppc4xx/start.S | 4 +++- 12 files changed, 36 insertions(+), 12 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
All,
Wolfgang Denk wd@denx.de hat am 18. Oktober 2010 um 22:39 geschrieben:
Dear Joakim Tjernlund,
In message 1287049904-18917-1-git-send-email-Joakim.Tjernlund@transmode.se you wrote:
The fixup routine must not fixup NULL pointers. Problem can be seen by char *testfun(void) __attribute__((weak)); char *(*myfun)(void) = testfun;
Then add printf("myfun:%p, &myfun:%p\n", myfun, &myfun); before relocation and after relocation. myfun should be NULL in both cases but it is not.
Signed-off-by: Joakim Tjernlund Joakim.Tjernlund@transmode.se
arch/powerpc/cpu/74xx_7xx/start.S | 4 +++- arch/powerpc/cpu/mpc512x/start.S | 4 +++- arch/powerpc/cpu/mpc5xx/start.S | 4 +++- arch/powerpc/cpu/mpc5xxx/start.S | 4 +++- arch/powerpc/cpu/mpc8220/start.S | 4 +++- arch/powerpc/cpu/mpc824x/start.S | 4 +++- arch/powerpc/cpu/mpc8260/start.S | 4 +++- arch/powerpc/cpu/mpc83xx/start.S | 4 +++- arch/powerpc/cpu/mpc85xx/start.S | 4 +++- arch/powerpc/cpu/mpc86xx/start.S | 4 +++- arch/powerpc/cpu/mpc8xx/start.S | 4 +++- arch/powerpc/cpu/ppc4xx/start.S | 4 +++- 12 files changed, 36 insertions(+), 12 deletions(-)
Applied, thanks.
has anybody ever tested this ? Although it looks obvious and correct this patch is somewhat intrusive and breaks at least two of our (MPC83xx) boards. I've asked Joakim already for some clarification : http://lists.denx.de/pipermail/u-boot/2010-October/080121.html Since I assume Wolfgang won't accept a board specific "add 4 nops after _start"-patch I'd like to solve this without trial and error. Of course digging into this is beyond my knowledge and any help would be appreciated. I simply can't think of being the only one having this issue... I'm running U-Boot TOT with ELDK-4.2 toolchain.
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Dear "Schwarz,Andre",
In message 1702240919.111.1287950899754.JavaMail.open-xchange@proteus you wrote:
Since I assume Wolfgang won't accept a board specific "add 4 nops after _start"-patch I'd like to solve this without trial and error.
To the best of my knowledge no board made use f this "warmboot" entry point. OK, I wasn't aware that Jocke obviously did something lioke this, so there might be other boards as well - but it's unlikely.
Of course digging into this is beyond my knowledge and any help would be appreciated. I simply can't think of being the only one having this issue...
Check how your board implements the "reset" command - I cannot see any specific code for that in your sources, so it looks mostly harmless to me.
Best regards,
Wolfgang Denk
Wolfgang,
Wolfgang Denk wd@denx.de hat am 24. Oktober 2010 um 22:18 geschrieben:
Dear "Schwarz,Andre",
In message 1702240919.111.1287950899754.JavaMail.open-xchange@proteus you wrote:
Since I assume Wolfgang won't accept a board specific "add 4 nops after _start"-patch I'd like to solve this without trial and error.
To the best of my knowledge no board made use f this "warmboot" entry point. OK, I wasn't aware that Jocke obviously did something lioke this, so there might be other boards as well - but it's unlikely.
Of course digging into this is beyond my knowledge and any help would be appreciated. I simply can't think of being the only one having this issue...
Check how your board implements the "reset" command - I cannot see any specific code for that in your sources, so it looks mostly harmless to me.
this is what I don't understand : The broken boards are *dead*, i.e. no single character on the serial line. To me this means even the initial code running from flash isn't executed properly. IMHO this doesn't look like something like a problem after relocation ... it's something more fundamental. The boards in question are using low boot, i.e. reset vector @ 0x100. There's normal power-on-reset sequencing and no such thing like a reboot or "warm" reset. Without that patch the boards are running fine.
I can see no obvious difference between working and broken boards.
I'd be happy to hear that the error is caused by something hidden within board specific code.
Reards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
"Schwarz,Andre" andre.schwarz@matrix-vision.de wrote on 2010/10/24 22:33:44:
Wolfgang,
Wolfgang Denk wd@denx.de hat am 24. Oktober 2010 um 22:18 geschrieben:
Dear "Schwarz,Andre",
In message 1702240919.111.1287950899754.JavaMail.open-xchange@proteus you wrote:
Since I assume Wolfgang won't accept a board specific "add 4 nops after _start"-patch I'd like to solve this without trial and error.
To the best of my knowledge no board made use f this "warmboot" entry point. OK, I wasn't aware that Jocke obviously did something lioke this, so there might be other boards as well - but it's unlikely.
Of course digging into this is beyond my knowledge and any help would be appreciated. I simply can't think of being the only one having this issue...
Check how your board implements the "reset" command - I cannot see any specific code for that in your sources, so it looks mostly harmless to me.
this is what I don't understand :
The broken boards are *dead*, i.e. no single character on the serial line. To me this means even the initial code running from flash isn't executed properly. IMHO this doesn't look like something like a problem after relocation ... it's something more fundamental.
Yes, like something is wrong with the reset code.
The boards in question are using low boot, i.e. reset vector @ 0x100.
Me too.
There's normal power-on-reset sequencing and no such thing like a reboot or "warm" reset.
Without that patch the boards are running fine.
I can see no obvious difference between working and broken boards.
I'd be happy to hear that the error is caused by something hidden within board specific code.
You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it.
Jocke
Jocke,
[snip]
You still haven't reported weather the 4 nop's helped or not, yet you
seek my help. I am just going to ignore you until you do test it.
of course. Will give it a try as soon as I'll be back to office and have a board at hand ... Just wanted to collect some more feedback. Cheers, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Jocke,
[snip]
You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it.
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- "in_flash" and "_start_of_vectors" adress increment = 0x10. - offset calculation for relative branch instruction also increases by 0x10.
Let me know if you need more information or something else tested.
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Andre Schwarz andre.schwarz@matrix-vision.de wrote on 2010/10/25 15:50:19:
Jocke,
[snip]
You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it.
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- "in_flash" and "_start_of_vectors" adress increment = 0x10.
- offset calculation for relative branch instruction also increases by 0x10.
Let me know if you need more information or something else tested.
I am not looking at this as I am busy but I have an idea or two
- CPU bug in 83xx CPUs which uses 0x110 as cold start vector.
- Misconfig of HRCW, don't know if you can change the reset vector that way but I guess you need to check.
I think a Freescale guy needs to look at this unless you can find something wrong with HRCW
Jocke
Jocke,
Andre Schwarzandre.schwarz@matrix-vision.de wrote on 2010/10/25 15:50:19:
Jocke,
[snip]
You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it.
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- "in_flash" and "_start_of_vectors" adress increment = 0x10.
- offset calculation for relative branch instruction also increases by 0x10.
Let me know if you need more information or something else tested.
I am not looking at this as I am busy but I have an idea or two
ok - thanks.
- CPU bug in 83xx CPUs which uses 0x110 as cold start vector.
This is indeed something FSL has to investigate. But at least *some* 83xx boards are running fine ... e300c2 though.
- Misconfig of HRCW, don't know if you can change the reset vector that way but I guess you need to check.
HRCW reset vector settings are high/low boot only.
I think a Freescale guy needs to look at this unless you can find something wrong with HRCW
Kim, Timur, can you give any information ? What about your boards ? Is everything running fine using Nor-Boot ?
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Andre Schwarz andre.schwarz@matrix-vision.de wrote on 2010/10/25 16:46:42:
Jocke,
Andre Schwarzandre.schwarz@matrix-vision.de wrote on 2010/10/25 15:50:19:
Jocke,
[snip]
You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it.
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- "in_flash" and "_start_of_vectors" adress increment = 0x10.
- offset calculation for relative branch instruction also increases by 0x10.
Let me know if you need more information or something else tested.
I am not looking at this as I am busy but I have an idea or two
ok - thanks.
- CPU bug in 83xx CPUs which uses 0x110 as cold start vector.
This is indeed something FSL has to investigate. But at least *some* 83xx boards are running fine ... e300c2 though.
I got a e300c2, mpc8321
Dear Andre Schwarz,
In message 4CC58B1B.8040005@matrix-vision.de you wrote:
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
This is probably completely unrelated - but check your CONFIG_SYS_GBL_DATA_SIZE setting and make sure it's still >= sizeof(struct global_data).
Best regards,
Wolfgang Denk
Wolfgang,
Dear Andre Schwarz,
In message4CC58B1B.8040005@matrix-vision.de you wrote:
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
This is probably completely unrelated - but check your CONFIG_SYS_GBL_DATA_SIZE setting and make sure it's still>= sizeof(struct global_data).
Having a look at include/asm/global_data.h gives some 40 ulongs for my MPC8377 system. Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
Nevertheless I doubled to 0x200.
The system is still dead after removing the 4 nops after _start.
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Dear Andre Schwarz,
In message 4CC5C226.8080202@matrix-vision.de you wrote:
Having a look at include/asm/global_data.h gives some 40 ulongs for my MPC8377 system. Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
Indeed. I was asking because I just discovered that most of the PowerPC boards are actually broken in this respect - 89 % of them, 170 out of 191 :-(
The system is still dead after removing the 4 nops after _start.
Sorry, but it was worth a try.
Best regards,
Wolfgang Denk
Wolfgang,
Dear Andre Schwarz,
In message4CC5C226.8080202@matrix-vision.de you wrote:
Having a look at include/asm/global_data.h gives some 40 ulongs for my MPC8377 system. Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
Indeed. I was asking because I just discovered that most of the PowerPC boards are actually broken in this respect - 89 % of them, 170 out of 191 :-(
understood - this should be easy to fix.
The system is still dead after removing the 4 nops after _start.
Sorry, but it was worth a try.
absolutely - so don't mind. I'm still happy to get any directions at all.
Still wondering why there's no comment from Kim etc. ...
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
All,
Having a look at include/asm/global_data.h gives some 40 ulongs for my MPC8377 system. Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
Indeed. I was asking because I just discovered that most of the PowerPC boards are actually broken in this respect - 89 % of them, 170 out of 191 :-(
The system is still dead after removing the 4 nops after _start.
actually I'm facing another issue and don't now whether this might be related to this thread or not.
Just before relocation in arch/powerpc/lib/board.c the CPU gets a "check stop" followed by reset during "memset()" in line 493.
[snip] DRAM: 256 MiB Top of RAM usable for U-Boot at: 10000000 Reserving 341k for U-Boot at: 0ffaa000 Reserving 512k for malloc() at: 0ff29f80
- reset -
U-Boot 2010.09-00488-g5edbadb-dirty (Oct 26 2010 - 14:16:00) MPC83XX
Reset Status: Check Stop, External/Internal Soft, External/Internal Hard
I know that DDR might not be 100% stable but it is basically set up properly. Removing the memset yields the next debug messages before resetting again while setting up SP.
Is the DDR required to work 100% for a simple write operation or might there be another problem ?
256MiB DDR is mapped by single BAT and there should be no overlapping BATs either.
Any ideas ?
Andre Schwarz andre.schwarz@matrix-vision.de wrote on 2010/10/26 14:34:57:
All,
Having a look at include/asm/global_data.h gives some 40 ulongs for my MPC8377 system. Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
Indeed. I was asking because I just discovered that most of the PowerPC boards are actually broken in this respect - 89 % of them, 170 out of 191 :-(
The system is still dead after removing the 4 nops after _start.
actually I'm facing another issue and don't now whether this might be related to this thread or not.
Just before relocation in arch/powerpc/lib/board.c the CPU gets a "check stop" followed by reset during "memset()" in line 493.
[snip] DRAM: 256 MiB Top of RAM usable for U-Boot at: 10000000 Reserving 341k for U-Boot at: 0ffaa000 Reserving 512k for malloc() at: 0ff29f80
- reset -
U-Boot 2010.09-00488-g5edbadb-dirty (Oct 26 2010 - 14:16:00) MPC83XX
Reset Status: Check Stop, External/Internal Soft, External/Internal Hard
I know that DDR might not be 100% stable but it is basically set up properly. Removing the memset yields the next debug messages before resetting again while setting up SP.
Is the DDR required to work 100% for a simple write operation or might there be another problem ?
Yes, DDR must be correct. You might get a bit further by turning off the data cache.
Andre Schwarz andre.schwarz@matrix-vision.de wrote on 2010/10/25 15:50:19:
Jocke,
[snip]
You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it.
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- "in_flash" and "_start_of_vectors" adress increment = 0x10.
- offset calculation for relative branch instruction also increases by 0x10.
Let me know if you need more information or something else tested.
How is this going? If nothing else I think you should send a patch for 83xx, adding the 4 nop's as your(and mine) board is broken otherwise. Freescale guys seems busy with other things so I think this is the best thing to do.
Jocke
Dear Joakim Tjernlund,
In message OF5324EC0A.37C044B2-ONC12577D1.0031F002-C12577D1.00326E3D@transmode.se you wrote:
4 nops after _start does the trick, i.e. the board is up and running fine.
...
How is this going? If nothing else I think you should send a patch for 83xx, adding the 4 nop's as your(and mine) board is broken otherwise. Freescale guys seems busy with other things so I think this is the best thing to do.
I don't like the idea of adding such code without any understanding why it would be needed for some boards, while it is not needed for others.
Is it really needed at _start? Or can these NOPs be anywhere, and are just needed to adjust some alignment?
When building for example for the MPC8315ERDB board, I see this strange alignment here:
-> grep _start_of_vectors System.map fe0001a8 T _start_of_vectors
Adding 4 NOPs will move this nicely to the next exception vector address at 0x200.
Eventually this is an alignment problem (but then, the "STD_EXCEPTION(0x200, ...)" is supposed to align the respective code to 0x200, and indeed we see
fe0001a8 T _start_of_vectors fe000200 t MachineCheck fe000300 t DataStorage fe000400 t InstStorage ...
Given the fact that _start_of_vectors is not used anywhere in the 83xx code, all this is a pretty big mystery to me.
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 The explanation requiring the fewest assumptions is the most likely to be correct. -- William of Occam
Wolfgang Denk wd@denx.de wrote on 2010/11/04 10:57:42:
Dear Joakim Tjernlund,
In message OF5324EC0A.37C044B2-ONC12577D1.0031F002-C12577D1.00326E3D@transmode.se you wrote:
4 nops after _start does the trick, i.e. the board is up and running fine.
...
How is this going? If nothing else I think you should send a patch for 83xx, adding the 4 nop's as your(and mine) board is broken otherwise. Freescale guys seems busy with other things so I think this is the best thing to do.
I don't like the idea of adding such code without any understanding why it would be needed for some boards, while it is not needed for others.
Sure, but until freescale or someone else with eq. and motivation researches it, we are stuck. I am not sure anyone else has tried 83xx based boards yet. If someone has please report. Also include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used.
Is it really needed at _start? Or can these NOPs be anywhere, and are just needed to adjust some alignment?
no, the nops has to be directly after _start: . = EXC_OFF_SYS_RESET
.globl _start _start: /* time t 0 */ nop nop nop nop
My theory is that e300c2(no FPU) CPUs configured for low boot vector, 0x100, really uses 0x110 instead.
When building for example for the MPC8315ERDB board, I see this strange alignment here:
-> grep _start_of_vectors System.map fe0001a8 T _start_of_vectors
Adding 4 NOPs will move this nicely to the next exception vector address at 0x200.
ehh no. It will just move _start_of_vectors 16 bytes as start_of_vectors doesn't have any alignment.
Eventually this is an alignment problem (but then, the "STD_EXCEPTION(0x200, ...)" is supposed to align the respective code to 0x200, and indeed we see
fe0001a8 T _start_of_vectors fe000200 t MachineCheck fe000300 t DataStorage fe000400 t InstStorage ...
Given the fact that _start_of_vectors is not used anywhere in the 83xx code, all this is a pretty big mystery to me.
It is probably some leftover. Either remove is for all ppc's. It only seems to be used by mpc85xx and ppc4xx so the majority doesn't use it.
Wolfgang Denk wd@denx.de wrote on 2010/11/04 10:57:42:
Dear Joakim Tjernlund,
In message OF5324EC0A.37C044B2-ONC12577D1.0031F002-C12577D1.00326E3D@transmode.se you wrote:
4 nops after _start does the trick, i.e. the board is up and running fine.
...
How is this going? If nothing else I think you should send a patch for 83xx, adding the 4 nop's as your(and mine) board is broken otherwise. Freescale guys seems busy with other things so I think this is the best thing to do.
I don't like the idea of adding such code without any understanding why it would be needed for some boards, while it is not needed for others.
Sure, but until freescale or someone else with eq. and motivation researches it, we are stuck. I am not sure anyone else has tried 83xx based boards yet. If someone has please report. Also include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used.
Is it really needed at _start? Or can these NOPs be anywhere, and are just needed to adjust some alignment?
no, the nops has to be directly after _start: . = EXC_OFF_SYS_RESET
.globl _start _start: /* time t 0 */ nop nop nop nop
My theory is that e300c2(no FPU) CPUs configured for low boot vector, 0x100, really uses 0x110 instead.
hmm, what if a board decides to do a soft reset anyway, perhaps by mistake. Would it not be a good thing if u-boot could handle that too?
Dear Joakim Tjernlund,
In message OF4390B64D.1FBD6276-ONC12577D1.003BB658-C12577D1.003BF18A@transmode.se you wrote:
hmm, what if a board decides to do a soft reset anyway, perhaps by mistake. Would it not be a good thing if u-boot could handle that too?
What exactly is a "soft reset" in U-Boot? And how would you perform one?
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 2010/11/04 12:16:31:
Dear Joakim Tjernlund,
In message OF4390B64D.1FBD6276-ONC12577D1.003BB658-C12577D1.003BF18A@transmode.se you wrote:
hmm, what if a board decides to do a soft reset anyway, perhaps by mistake. Would it not be a good thing if u-boot could handle that too?
What exactly is a "soft reset" in U-Boot? And how would you perform one?
Not in u-boot, but Linux or a privileged linux app. could.
Jocke
Dear Joakim Tjernlund,
In message OF18CA6215.DC3A539B-ONC12577D1.00439A8B-C12577D1.0043BB01@transmode.se you wrote:
What exactly is a "soft reset" in U-Boot? And how would you perform one?
Not in u-boot, but Linux or a privileged linux app. could.
Could do what? Modify the memory map such that the Flash is mapped as it was (eventually) when U-Boot is running, and then jump right in the middle of nowhere?
That would be invoking undefined behaviour in it's purest form.
Anything can happen then.
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 2010/11/04 13:46:17:
Dear Joakim Tjernlund,
In message OF18CA6215.DC3A539B-ONC12577D1.00439A8B-C12577D1.0043BB01@transmode.se you wrote:
What exactly is a "soft reset" in U-Boot? And how would you perform one?
Not in u-boot, but Linux or a privileged linux app. could.
Could do what? Modify the memory map such that the Flash is mapped
Issue an soft reset somehow. Don't know how but I guessing it is possible? If so the CPU would use reset vector 0x110 instead of 0x100(still guessing here)
as it was (eventually) when U-Boot is running, and then jump right in the middle of nowhere?
That would be invoking undefined behaviour in it's purest form.
Anything can happen then.
Dear Joakim Tjernlund,
In message OF51547B77.F521DBCE-ONC12577D1.0046EB0D-C12577D1.0047448E@transmode.se you wrote:
Could do what? Modify the memory map such that the Flash is mapped
Issue an soft reset somehow. Don't know how but I guessing it is possible? If so the CPU would use reset vector 0x110 instead of 0x100(still guessing here)
I wonder where this idea of a "reset vector" or any other entry point at 0x110 might come from?
AFAICT there is no such thing, and never has been one.
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 2010/11/04 14:07:50:
Dear Joakim Tjernlund,
In message OF51547B77.F521DBCE-ONC12577D1.0046EB0D-C12577D1.0047448E@transmode.se you wrote:
Could do what? Modify the memory map such that the Flash is mapped
Issue an soft reset somehow. Don't know how but I guessing it is possible? If so the CPU would use reset vector 0x110 instead of 0x100(still guessing here)
I wonder where this idea of a "reset vector" or any other entry point at 0x110 might come from?
AFAICT there is no such thing, and never has been one.
ah, I just assumed there was one as start.S was written like there was one. My problem appears to be something else then.
Jocke
Joakim wrote...
Sure, but until freescale or someone else with eq. and motivation researches it, we are stuck. I am not sure anyone else has tried 83xx based boards yet. If someone has please report. Also include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used.
I have a couple of Freescale reference boards here (8313ERDB and 8349-MITX-GP). I'm not a powerpc expert by any means but if there are some (simple) tests you would like me to run on them then I will see if I can find some time.
Andy.
Dear Joakim Tjernlund schrieb:
no, the nops has to be directly after _start: . = EXC_OFF_SYS_RESET
.globl _start _start: /* time t 0 */ nop nop nop nop
My theory is that e300c2(no FPU) CPUs configured for low boot vector, 0x100, really uses 0x110 instead.
How about a simple test:
_start: bra case1 org _start+0x10 bra case2 ... case1: "turn on red led" bra case1
case2: "turn on green led" bra case2
You get the idea :)
Best Regards Reinhard
Jocke,
[snip]
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- "in_flash" and "_start_of_vectors" adress increment = 0x10.
- offset calculation for relative branch instruction also increases by 0x10.
Let me know if you need more information or something else tested.
How is this going? If nothing else I think you should send a patch for 83xx, adding the 4 nop's as your(and mine) board is broken otherwise. Freescale guys seems busy with other things so I think this is the best thing to do.
currently I can see no light at the end of the tunnel so that I don't dare send any kind of patch.
Actually I got some time to analyze and further optimize the memory bus. During relocation the board hangs in flush_dcache. I can see the DDR-II signal levels change to a non-working state ... maybe this is caused by some internal reset - don't know.
But approx. 1 out of 20 tries (power cycles) U-Boot makes it past that point and continues working. Then there's a console and the system is memtesting for hours. PCI, LAN and Flash are also running fine. No issues after flush_dcache succeeded.
Second strange issue is that the serial line is dead again as soon as I #define USB functionality withing board config, i.e. U-Boot does not even run from flash. This is reproducable - removing the USB #defines makes U-Boot work again.
Removing the 4 "nop" doesn't help either.
I definitely need some time to dig a little deeper.
Any help or pointers are welcome.
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Dear Andre Schwarz,
In message 4CC58B1B.8040005@matrix-vision.de you wrote:
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- "in_flash" and "_start_of_vectors" adress increment = 0x10.
Hey, stop here.
How can _start_of_vectors shift? It i supposed to be at a fixed location, i. e. at 0x100.
Hmmm... seems 83xx does not use _start_of_vectors at all. We should either fix _start_of_vectors or remove it completely.
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 2010/11/04 10:50:38:
Dear Andre Schwarz,
In message 4CC58B1B.8040005@matrix-vision.de you wrote:
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- "in_flash" and "_start_of_vectors" adress increment = 0x10.
Hey, stop here.
How can _start_of_vectors shift? It i supposed to be at a fixed location, i. e. at 0x100.
_start_of_vectors isn't used on 83xx. It is just a pointless symbol as far as I can tell. 83xx uses _start and that symbol is fixed at 0x100
Hmmm... seems 83xx does not use _start_of_vectors at all. We should either fix _start_of_vectors or remove it completely.
Yes.
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 The price of curiosity is a terminal experience. - Terry Pratchett, _The Dark Side of the Sun_
Wolfgang Denk wd@denx.de wrote on 2010/10/24 22:18:32:
Dear "Schwarz,Andre",
In message 1702240919.111.1287950899754.JavaMail.open-xchange@proteus you wrote:
Since I assume Wolfgang won't accept a board specific "add 4 nops after _start"-patch I'd like to solve this without trial and error.
To the best of my knowledge no board made use f this "warmboot" entry point. OK, I wasn't aware that Jocke obviously did something lioke this, so there might be other boards as well - but it's unlikely.
I am not intentionally doing that and I am still not sure this is the case either. Our reset sequence is somewhat different that standard so I cannot be sure and I haven't had the time to look at this as some high prio stuff landed at my feet that I need to deal with 100% until done.
participants (7)
-
Andre Schwarz -
Andy Pont -
Joakim Tjernlund -
Joakim Tjernlund
-
Reinhard Meyer -
Schwarz,Andre
-
Wolfgang Denk