[U-Boot-Users] Hang after relocating u-boot code...
Hi,
The monitor port can work on my custom board but u-boot hang or crashes after relocation.I read the DULG FAQ about the answer.I,however,want to make sure about the fact why the same SDRAM init code does work on RPXlite but in vain on my custom board for the SDRAM hardware design are the same with these two boards.
I am sure that my UPMA RAM WORD is OK because of successful relocation.When I traced the code using BDI2000 and found that the code often went wrong after start.S:574.
/* * We are done. Do not return, instead branch to second part of board * initialization, now running from RAM. */
572 addi r0, r10, in_ram - _start + EXC_OFF_SYS_RESET 573 mtlr r0 574 blr
BDI>ci - TARGET: target has entered debug mode BDI>i Target state : debug mode Debug entry cause : entering check stop state Current PC : 0x00000200
Meanwhile,I checked the signal of SDRAM chip(MT48LC16M16)by WAVEFORM and noticed that A[20-29] & D[0-31] on RPXlite board have 1KHz plus whereas zero
level on my board after reset.
Is this realated with my hardware design or just software adjustment is enough?
Any hints is welcome!
Thanks in advance and Happy New Year!!!
SAM SONG
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
In message 20031230160114.3874.qmail@web15003.mail.bjs.yahoo.com you wrote:
The monitor port can work on my custom board but u-boot hang or crashes after relocation.I read the DULG FAQ about the answer.I,however,want to make sure about the fact why the same SDRAM init code does work on RPXlite but in vain on my custom board for the SDRAM hardware design are the same with these two boards.
Is it _exactly_ the same design, with the same types of SDRAM chips?
I am sure that my UPMA RAM WORD is OK because of successful relocation.When I traced the code using
This does not mean a thing. First, the UPM initialization is just a part of the required initialization sequence; second, the relocation uses simple read / write cycles, while your problems happen when accessing the SDRAM in burst mode.
Is this realated with my hardware design or just software adjustment is enough?
Do we know your hardware design? No. Do we know your modifications to the software? No. Will you get a useful answer? Guess...
Best regards, and a Happy New Year!
Wolfgang Denk
--- Wolfgang Denk wd@denx.de 的正文：> In message
20031230160114.3874.qmail@web15003.mail.bjs.yahoo.com
you wrote:
The monitor port can work on my custom board but u-boot hang or crashes after relocation.I read the DULG FAQ about the answer.I,however,want to make
sure
about the fact why the same SDRAM init code does
work
on RPXlite but in vain on my custom board for the SDRAM hardware design are the same with these two boards.
Is it _exactly_ the same design, with the same types of SDRAM chips?
Thanks you so much for your hints.I missed this key point.Yes,two chips of MT48LC16M16A2-75-B(1-1) on LITE_DW board with cs1 and two chips of MT48LC16M16A2-75-IT-C(2-2) on my board with cs1.I guess both are the same type.Am I right?
I am sure that my UPMA RAM WORD is OK because of successful relocation.When I traced the code using
This does not mean a thing. First, the UPM initialization is just a part of the required initialization sequence; second, the relocation uses simple read / write cycles, while your problems happen when accessing the SDRAM in burst mode.
Thanks for correcting my views on UPMA RAM WORD.I am studying on burst mode of SDRAM and hope it is the problem.
Is this realated with my hardware design or just software adjustment is enough?
Do we know your hardware design? No. Do we know your modifications to the software? No. Will you get a useful answer? Guess...
Sorry for posting such uncertain questions.For encountering the headache,I sometimes suspect that there are some defaults on my hardware layout.Is it possible that the same design with the same chips would have different results for technics reasons in some cases?
Best regards, and a Happy New Year!
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de I paid too much for it, but its worth it.
Happy new year to you!
Best regards,
SAM SONG
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hello,
in message 20040101035021.6532.qmail@web15001.mail.bjs.yahoo.com you wrote:
Is it _exactly_ the same design, with the same types of SDRAM chips?
Thanks you so much for your hints.I missed this key point.Yes,two chips of MT48LC16M16A2-75-B(1-1) on LITE_DW board with cs1 and two chips of MT48LC16M16A2-75-IT-C(2-2) on my board with cs1.I guess both are the same type.Am I right?
And the same CPU, same clock sources, etc. - all exactly the same?
Thanks for correcting my views on UPMA RAM WORD.I am studying on burst mode of SDRAM and hope it is the problem.
Usually (in 99% of all cases) it is.
encountering the headache,I sometimes suspect that there are some defaults on my hardware layout.Is it
Ther eit goes again. Please remember that we don't know your hardware design. Not the schematics, and neither the board layout.
possible that the same design with the same chips would have different results for technics reasons in some cases?
Of course this is possible. Poor production quality may make each board behave differently. It ain't much fun do debug such a system.
Best regards, and a Happy New Year!
Wolfgang Denk
--- Wolfgang Denk wd@denx.de 的正文：> Hello,
in message
20040101035021.6532.qmail@web15001.mail.bjs.yahoo.com
you wrote:
Is it _exactly_ the same design, with the same
types
of SDRAM chips?
Thanks you so much for your hints.I missed this
key
point.Yes,two chips of MT48LC16M16A2-75-B(1-1) on LITE_DW board with cs1 and two chips of MT48LC16M16A2-75-IT-C(2-2) on my board with cs1.I guess both are the same type.Am I right?
And the same CPU, same clock sources, etc. - all exactly the same?
I think so.The case of LITE_DW is XPC823EZT66B2 with 8MHz,mine is XPC823EZT75B2 with 8MHz.Our SDRAM part design base on LITE_DW. Also use same chips and hope we could go smoothly on development.In addition,I tested burst write with unreasonable configuration on LITE_DW and it could get through(I mean U-Boot booted normally on LITE_DW but not test further for possible results).So I focus my mind on six RAM WORD of UPMA BURST READ.
Best regards,
Sam Song
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi,Wolfgang,
After having tried some settings of UPM Burst Read with no obvious improvement on my custom board,I need to consult with you on this matter.
When using the UPM Burst Read settings whick worked on LITE_DW,I got the following best result by now.I wrote some UPMA Burst Read Words but without no better performance.
1.With "g" commands in BDI regardless of entering debugging mode,it ran again and was stopped immediately by using "halt":
1)In BDI console:
BDI>re - TARGET: processing user reset request - TARGET: resetting target passed - TARGET: processing target init list .... - TARGET: processing target init list passed BDI>g - TARGET: target has entered debug mode BDI>i Target state : debug mode Debug entry cause : entering check stop state Current PC : 0x00000200 BDI>g BDI>ha Target state : debug mode Debug entry cause : external breakpoint Current PC : 0x03ff5020 BDI>re - TARGET: processing user reset request - TARGET: resetting target passed - TARGET: processing target init list .... - TARGET: processing target init list passed BDI>g - TARGET: target has entered debug mode BDI>i Target state : debug mode Debug entry cause : entering check stop state Current PC : 0x00000200 BDI>g BDI>ha Target state : debug mode Debug entry cause : external breakpoint Current PC : 0x03ff501c BDI>
2)In minicom console:
U-Boot 1.0.0 (Jan 8 2004 - 20:24:19)
CPU: PPC823EZTnnB2 at 64 MHz: 16 kB I-Cache 8 kB D-Cache Board: My_Board DRAM: 64 MB Bus Fault @ 0x00000200, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 03fbce88 Unknown values in msr NIP: 00000200 XER: A000187F LR: 03FE3328 REGS: 03fbce88 TRAP: 0200 DAR: 00000040 MSR: 40000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
GPR00: 03FFB044 03FBCF78 00000000 03FFA0A4 03FFB400 03FFB400 00000010 03FFB3FC GPR08: FFF1A3FC 03FBCF94 03FE1000 040E1000 00000000 60C5DCB3 04001A00 040E1000 GPR16: 729C1A82 3AA8AFB6 DC8C92B7 8066A981 00001002 00000001 00000000 03FE309C GPR24: 03FE9170 00000040 00000001 03FE1000 03FBCF94 FA202EC0 04001BB4 03FBCF78 Call backtrace: machine check NIP: FFEFFFFC XER: 8000187F LR: 03FE875C REGS: 03fbccc8 TRAP: 1000 DAR: 30303430 MSR: 00000002 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
GPR00: FFEFFFFC 03FBCDB8 00000000 00000000 00000000 00000000 00000000 005EBEBA GPR08: 03FE99C8 FFFFEFCF FA202808 02000000 00000000 60C5DCB3 04001A00 040E1000 GPR16: 729C1A82 3AA8AFB6 DC8C92B7 8066A981 00001002 03FBCE78 00000000 03FE309C GPR24: 03FE8FE8 00000040 00000001 03FE1000 03FBCF94 FA202EC0 04001B60 03FBCE88 Call backtrace: Software Emulation Exception NIP: FFEFFFFC XER: 8000187F LR: 03FE875C REGS: 03fbcb08 TRAP: 1000 DAR: 33343330 MSR: 00000002 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
GPR00: FFEFFFFC 03FBCBF8 00000000 00000000 000
2.When I set DER
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi,Wolfgang,
Oop,I sent the same topic again for my carelessness.Pls forgive me this time.
After having tried some settings of UPM Burst Read with no obvious improvement on my custom board,I need to consult with you on this matter.
When using the UPM Burst Read settings whick worked on LITE_DW,I got the following best result by now.I wrote some UPMA Burst Read Words but without no better performance.
1.With "g" commands in BDI regardless of entering debugging mode,it ran again and was stopped immediately by using "halt":
1)In BDI console:
BDI>re - TARGET: processing user reset request - TARGET: resetting target passed - TARGET: processing target init list .... - TARGET: processing target init list passed BDI>g - TARGET: target has entered debug mode BDI>i Target state : debug mode Debug entry cause : entering check stop state Current PC : 0x00000200 BDI>g BDI>ha Target state : debug mode Debug entry cause : external breakpoint Current PC : 0x03ff5020 BDI>re - TARGET: processing user reset request - TARGET: resetting target passed - TARGET: processing target init list .... - TARGET: processing target init list passed BDI>g - TARGET: target has entered debug mode BDI>i Target state : debug mode Debug entry cause : entering check stop state Current PC : 0x00000200 BDI>g BDI>ha Target state : debug mode Debug entry cause : external breakpoint Current PC : 0x03ff501c BDI>
2)In minicom console:
U-Boot 1.0.0 (Jan 8 2004 - 20:24:19)
CPU: PPC823EZTnnB2 at 64 MHz: 16 kB I-Cache 8 kB D-Cache Board: My_Board DRAM: 64 MB Bus Fault @ 0x00000200, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 03fbce88 Unknown values in msr NIP: 00000200 XER: A000187F LR: 03FE3328 REGS: 03fbce88 TRAP: 0200 DAR: 00000040 MSR: 40000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
GPR00: 03FFB044 03FBCF78 00000000 03FFA0A4 03FFB400 03FFB400 00000010 03FFB3FC GPR08: FFF1A3FC 03FBCF94 03FE1000 040E1000 00000000 60C5DCB3 04001A00 040E1000 GPR16: 729C1A82 3AA8AFB6 DC8C92B7 8066A981 00001002 00000001 00000000 03FE309C GPR24: 03FE9170 00000040 00000001 03FE1000 03FBCF94 FA202EC0 04001BB4 03FBCF78 Call backtrace: machine check NIP: FFEFFFFC XER: 8000187F LR: 03FE875C REGS: 03fbccc8 TRAP: 1000 DAR: 30303430 MSR: 00000002 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
GPR00: FFEFFFFC 03FBCDB8 00000000 00000000 00000000 00000000 00000000 005EBEBA GPR08: 03FE99C8 FFFFEFCF FA202808 02000000 00000000 60C5DCB3 04001A00 040E1000 GPR16: 729C1A82 3AA8AFB6 DC8C92B7 8066A981 00001002 03FBCE78 00000000 03FE309C GPR24: 03FE8FE8 00000040 00000001 03FE1000 03FBCF94 FA202EC0 04001B60 03FBCE88 Call backtrace: Software Emulation Exception NIP: FFEFFFFC XER: 8000187F LR: 03FE875C REGS: 03fbcb08 TRAP: 1000 DAR: 33343330 MSR: 00000002 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
GPR00: FFEFFFFC 03FBCBF8 00000000 00000000 000
2.When setting DER as 0x51c7000f,I get the "good" results by over 70 continuing "go" commands:
1)In BDI console
- TARGET: processing user reset request - TARGET: resetting target passed - TARGET: processing target init list .... - TARGET: processing target init list passed BDI>rm der 0x51c7000f BDI>g - TARGET: target has entered debug mode BDI>i Target state : debug mode Debug entry cause : machine check interrupt Current PC : 0xfff106e0 Data address : 0x000420c0 DSISR value : 0x00400202 BDI>g - TARGET: target has entered debug mode BDI>i Target state : debug mode Debug entry cause : machine check interrupt Current PC : 0x03fe3340 Data address : 0x03ffa0d0 DSISR value : 0x00004003
BDI>g - TARGET: target has entered debug mode BDI>g - TARGET: target has entered debug mode ....... BDI>g - TARGET: target has entered debug mode
2)In minicom console
U-Boot 1.0.0 (Jan 8 2004 - 20:24:19)
CPU: PPC823EZTnnB2 at 64 MHz: 16 kB I-Cache 8 kB D-Cache Board: My_Board DRAM: 64 MB FLASH: 64 MB *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial Net: SCC ETHERNET u-boot>
It seems that one more step could succeed.However,the truth hurts.I trapped in settings of UPM RAM Words and want to figure it out.
So,which is perfer to between Burst Read with Auto Precharge and Burst Read without Auto Percharge or both OK?
Does it matter without hard reset configuration circuit on my board?Is it related with my UPM settings?
Thanks for reading!
Best regards,
Sam
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
In message 20040109021612.81164.qmail@web15208.mail.bjs.yahoo.com you wrote:
When using the UPM Burst Read settings whick worked on LITE_DW,I got the following best result by now.I wrote some UPMA Burst Read Words but without no better performance.
As I have pointed out a hundred times or more before: the culprit is usially NOT the UPM setting, but the initialization sequence of your SDRAM.
2.When setting DER as 0x51c7000f,I get the "good" results by over 70 continuing "go" commands:
This probably just hushes up the symptoms. Try runnign without the BDI attached. Does it work? No? You see... the problem was not fixed yet.
It seems that one more step could succeed.However,the truth hurts.I trapped in settings of UPM RAM Words and want to figure it out.
IT HAS NOTHING TO DO WITH THE UPM SETUP.
THE PROBLEM IS THE SDRAM INIT SEQUENCE.
[sorry for shouting]
Best regards,
Wolfgang Denk
participants (3)
-
SAM SONG -
Sam Song
-
Wolfgang Denk