Re: [U-Boot] U-Boot Crashes with Dumps
[Please keep the list on Cc]
On Wednesday 13 January 2010 08:21:32 anupbehare@gmail.com wrote:
I am using denali controller. Here we can not use 44x_spd_ddr.c as registers are complitly different, so we have implemented sdram.c for doing specific initialization...
This seems wrong. You are using the 440GX *and* the Denali SDRAM core? The 440GX doesn't use the Denali SDRAM controller. Only the 440EPx/GRx use Denali.
Please explain what you are doing here.
We have done ddr training, which was successfully completed I think that means DDR initialization is proper.
What exactly do you mean with "ddr training"? DDR setup is complex stuff. Many things can go wrong here.
But when the control enter into board_init_r() we get machine check exception and u-boot is in continuously reboot mode.
If you are sure that your SDRAM setup is correct, then you need to debug where exactly this crash happens. Either use the JTAG debugger (BDI2000/3000) or add printf's. But I still suspect SDRAM problems.
after that we are not able to access the flash with Crack monkey tool to flash the u-boot binary .
"Crack monkey tool"? What's that? You should be able to access the FLASH again after resetting the CPU.
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
I am using board having ppc440x5 core with customized chip and not a standard 440Gx.
Board is using Denali controller, as the register are completely different we can not use the standard u-boot initialization. We performed board specific initialization and training for DDR2.
When the code enter into board_init_r() console shows following messages:
Top of RAM usable for U-Boot at: 20000000 Reserving 178k for U-Boot at: 1ffd3000 Reserving 1040k for malloc() at: 1fecf000 Reserving 128 Bytes for Board Info at: 1fecef80 Reserving 64 Bytes for Global Data at: 1fecef40 New Stack Pointer is: 1fecef28
Now running in RAM - U-Boot at: 1ffd3000 Bus Fault @ 0x1ffd5764, fixup 0x00000000 Machine Check Exception.
NIP: 1FFD5764 XER: 00000000 LR: 1FFD5764 REGS: 1fecee20 TRAP: 0200 DEAR: 00000000 MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 1FFD5338 1FECEF10 1FECEF40 1FFD3000 1FFD6814 00000034 00000034 1FFD5764 GPR08: 00000600 00002098 00000030 2FAF07FE FFFFFFFF C000B330 20002A00 20013000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 1FECEF40 1FFD3000 1FED3000 1FFD3000 1FECEF80 20002B10 20013000 Call backtrace: 1FFD680C 1FFD56D8 A462C4EC machine check
We tried to debug it with BDI as per steps given @ http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.
We have verified by using BDI that uboot code is placed in DDR, but getting an exception and u-boot is in continuously reboot mode.
Will it ok if we disable the MSR for ME,EE,CE? Or still it looks DDR initialization issue ?
~Anup B
On Wednesday 13 January 2010 18:43:31 anupbehare@gmail.com wrote:
I am using board having ppc440x5 core with customized chip and not a standard 440Gx.
Board is using Denali controller, as the register are completely different we can not use the standard u-boot initialization.
OK, I see. So you have a customized non-440EPx/GRx chip with the Denali DDR(2) controller. You are aware that we have a full blown Denali DDR(2) controller setup routine with SPD detection? This one is only for 440EPx/GRx right now, since these were the only PPC4xx variants equipped with this core till now:
cpu/ppc4xx/denali_spd_ddr2.c cpu/ppc4xx/denali_data_eye.c
You should try to use this code as it is known to work on other PPC4xx platforms in various configurations.
We performed board specific initialization and training for DDR2.
When the code enter into board_init_r() console shows following messages:
Top of RAM usable for U-Boot at: 20000000 Reserving 178k for U-Boot at: 1ffd3000 Reserving 1040k for malloc() at: 1fecf000 Reserving 128 Bytes for Board Info at: 1fecef80 Reserving 64 Bytes for Global Data at: 1fecef40 New Stack Pointer is: 1fecef28
Now running in RAM - U-Boot at: 1ffd3000 Bus Fault @ 0x1ffd5764, fixup 0x00000000 Machine Check Exception.
NIP: 1FFD5764 XER: 00000000 LR: 1FFD5764 REGS: 1fecee20 TRAP: 0200 DEAR: 00000000 MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 1FFD5338 1FECEF10 1FECEF40 1FFD3000 1FFD6814 00000034 00000034 1FFD5764 GPR08: 00000600 00002098 00000030 2FAF07FE FFFFFFFF C000B330 20002A00 20013000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 1FECEF40 1FFD3000 1FED3000 1FFD3000 1FECEF80 20002B10 20013000 Call backtrace: 1FFD680C 1FFD56D8 A462C4EC machine check
We tried to debug it with BDI as per steps given @ http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.
We have verified by using BDI that uboot code is placed in DDR, but getting an exception and u-boot is in continuously reboot mode.
Did you try adding some printf's to board_init_r(), to see where exactly this crash occurs? That's what I would do.
Will it ok if we disable the MSR for ME,EE,CE? Or still it looks DDR initialization issue ?
Could be DDR, could be something else. You need to further debug this.
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
One update to you on debuging board_init_r().. We bypass the trap_init call, control enters into the flash_init() in cfi_flash.c
I am get following console o/p:
fwrite addr fc000000 cmd ff 000000ff000000ff 64 bit x 32 bit fwrite addr fc0002a8 cmd 98 0000009800000098 64 bit x 32 bit is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000005100000051 fwrite addr fc002aa8 cmd 98 0000009800000098 64 bit x 32 bit is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000005100000051 fwrite addr fc000000 cmd f0 00000000000000f0 64 bit x 64 bit fwrite addr fc000000 cmd ff 00000000000000ff 64 bit x 64 bit fwrite addr fc0002a8 cmd 98 0000000000000098 64 bit x 64 bit is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000051 fwrite addr fc002aa8 cmd 98 0000000000000098 64 bit x 64 bit is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000051 not found ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB *** failed *** ### ERROR ### Please RESET the board ###
to more debug we bypass the hang call for time being and we obtain u-boot prompt.
now as I am getting u-boot prompt that means DDR initilised properly. now I am debuging for trap_init and flash_init().
~Anup
On 14-Jan-2010 1:00pm, Stefan Roese sr@denx.de wrote:
On Wednesday 13 January 2010 18:43:31 anupbehare@gmail.com wrote:
I am using board having ppc440x5 core with customized chip and not a
standard 440Gx.
Board is using Denali controller, as the register are completely
different
we can not use the standard u-boot initialization.
OK, I see. So you have a customized non-440EPx/GRx chip with the Denali DDR(2)
controller. You are aware that we have a full blown Denali DDR(2) controller
setup routine with SPD detection? This one is only for 440EPx/GRx right now,
since these were the only PPC4xx variants equipped with this core till now:
cpu/ppc4xx/denali_spd_ddr2.c
cpu/ppc4xx/denali_data_eye.c
You should try to use this code as it is known to work on other PPC4xx
platforms in various configurations.
We performed board specific initialization and training for DDR2.
When the code enter into board_init_r() console shows following
messages:
Top of RAM usable for U-Boot at: 20000000
Reserving 178k for U-Boot at: 1ffd3000
Reserving 1040k for malloc() at: 1fecf000
Reserving 128 Bytes for Board Info at: 1fecef80
Reserving 64 Bytes for Global Data at: 1fecef40
New Stack Pointer is: 1fecef28
Now running in RAM - U-Boot at: 1ffd3000
Bus Fault @ 0x1ffd5764, fixup 0x00000000
Machine Check Exception.
NIP: 1FFD5764 XER: 00000000 LR: 1FFD5764 REGS: 1fecee20 TRAP: 0200 DEAR:
00000000
MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 1FFD5338 1FECEF10 1FECEF40 1FFD3000 1FFD6814 00000034 00000034
1FFD5764
GPR08: 00000600 00002098 00000030 2FAF07FE FFFFFFFF C000B330 20002A00
20013000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
GPR24: 00000000 1FECEF40 1FFD3000 1FED3000 1FFD3000 1FECEF80 20002B10
20013000
Call backtrace:
1FFD680C 1FFD56D8 A462C4EC
machine check
We tried to debug it with BDI as per steps given @
http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.
We have verified by using BDI that uboot code is placed in DDR, but
getting
an exception and u-boot is in continuously reboot mode.
Did you try adding some printf's to board_init_r(), to see where exactly this
crash occurs? That's what I would do.
Will it ok if we disable the MSR for ME,EE,CE? Or still it looks DDR
initialization issue ?
Could be DDR, could be something else. You need to further debug this.
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
Dear anupbehare@gmail.com,
In message 001636ed6c7e8c9189047d1cab86@google.com you wrote:
We bypass the trap_init call, control enters into the flash_init() in cfi_flash.c
...
to more debug we bypass the hang call for time being and we obtain u-boot prompt.
This is random hacking and will not take you anywhere.
The Golden Rule (TM) is to stop at the very first error, and analyze and _fix_ it before continuing.
I bet a case of beer that your RAM initialization is broken, and all your changes are just hushing up the problems, which will bite you later, harder.
Follow Stefan's advice and get your RAM setup working reliably and stable, before doing anything else.
Feel free to ignore the advice if you like wasting your time, but then please stop asking here so you not also waste our time, too.
Best regards,
Wolfgang Denk
Hi Wolfgnag,
I am apologize for debugging with by passing the previous exception. I was curious about u-boot prompt.
Now i have implemented the steps suggested by stefan, and debugging the same.
~Anup
On Thu, Jan 14, 2010 at 3:45 PM, Wolfgang Denk wd@denx.de wrote:
Dear anupbehare@gmail.com,
In message 001636ed6c7e8c9189047d1cab86@google.com you wrote:
We bypass the trap_init call, control enters into the flash_init() in cfi_flash.c
...
to more debug we bypass the hang call for time being and we obtain u-boot prompt.
This is random hacking and will not take you anywhere.
The Golden Rule (TM) is to stop at the very first error, and analyze and _fix_ it before continuing.
I bet a case of beer that your RAM initialization is broken, and all your changes are just hushing up the problems, which will bite you later, harder.
Follow Stefan's advice and get your RAM setup working reliably and stable, before doing anything else.
Feel free to ignore the advice if you like wasting your time, but then please stop asking here so you not also waste our time, too.
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 "Don't think; let the machine do it for you!" - E. C. Berkeley
On Thursday 14 January 2010 10:39:57 anupbehare@gmail.com wrote:
now as I am getting u-boot prompt that means DDR initilised properly. now I am debuging for trap_init and flash_init().
Could be that your DDR init code somehow generates an exception that is triggered once trap_init() is called. This is also know to happen in the common denali_data_eye code. See here:
#if defined(CONFIG_DDR_DATA_EYE) /* * Running denali_core_search_data_eye() when ECC is enabled * causes non-ECC machine checks. This clears them. */ print_mcsr(); mtspr(SPRN_MCSR, mfspr(SPRN_MCSR)); print_mcsr(); #endif
I suggest you analyse this and the Denali registers for any source/status of a generated exception.
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
Thanks Stenfan for your valuable inputs.
I have implemented the code suggested by you after completing the ddr initialization :
#if defined(CONFIG_DDR_DATA_EYE) /* * Running denali_core_search_data_eye() when ECC is enabled * causes non-ECC machine checks. This clears them. */ print_mcsr(); mtspr(SPRN_MCSR, mfspr(SPRN_MCSR)); print_mcsr(); #endif
before mtspr and after mtspr i am getting the same prints i.e EE,ME,CE disabled.
I am further debugging the same issue.
On Thu, Jan 14, 2010 at 3:54 PM, Stefan Roese sr@denx.de wrote:
On Thursday 14 January 2010 10:39:57 anupbehare@gmail.com wrote:
now as I am getting u-boot prompt that means DDR initilised properly. now I am debuging for trap_init and flash_init().
Could be that your DDR init code somehow generates an exception that is triggered once trap_init() is called. This is also know to happen in the common denali_data_eye code. See here:
#if defined(CONFIG_DDR_DATA_EYE) /* * Running denali_core_search_data_eye() when ECC is enabled * causes non-ECC machine checks. This clears them. */ print_mcsr(); mtspr(SPRN_MCSR, mfspr(SPRN_MCSR)); print_mcsr(); #endif
I suggest you analyse this and the Denali registers for any source/status of a generated exception.
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
On Saturday 16 January 2010 10:48:21 anup behare wrote:
Thanks Stenfan for your valuable inputs.
I have implemented the code suggested by you after completing the ddr initialization :
#if defined(CONFIG_DDR_DATA_EYE) /* * Running denali_core_search_data_eye() when ECC is enabled * causes non-ECC machine checks. This clears them. */ print_mcsr(); mtspr(SPRN_MCSR, mfspr(SPRN_MCSR)); print_mcsr(); #endif
before mtspr and after mtspr i am getting the same prints i.e EE,ME,CE disabled.
Please note that I am not referring to MSR, but to the MCSR register here. Not all PPC4xx variants have this register implemented. But most 44x ones should (SPR 0x23c).
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
participants (4)
-
anup behare -
anupbehare＠gmail.com
-
Stefan Roese -
Wolfgang Denk