On 9/19/07, Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
robert lazarski wrote:
Thanks for the help Jerry...
Is 0xfff896e8 actually board.c line 365 (gdb's symbols OK)? Low probability of error, but worth verifying.
In vim with line numbers enabled, editing lib_ppc/board.c I get:
364 void board_init_f (ulong bootflag) 365 {
You might want to telnet directly into the BDI and use the BDI breakpoint and go commands directly.
I see you told gdb to use hard breakpoints (good). Using the BDI command interface instead of gdb would eliminate one more piece of software to screw up.
Good idea, see below.
Did you dump flash (disassemble if you are using gcc), did it match what you programmed?
Will try that if I can't grab low hanging fruit.
I wouldn't switch to low boot until you've exhausted your current options. I would suspect you would work hard for no different results.
The first culprit is probably our memory - 1GB of DDR2 ram. The hardware guys tell me our DDR2 is exactly like the MPC8548CDS reference board. I have the memory mapped to 0x00000000 , and I can do this:
board_init_f is the flash-based board initialization, run before RAM is used. If you aren't getting there, it isn't RAM's fault.
ATUM>mmh 0x00000000 0xcafe ATUM>mdh 0x00000000 1 0_00000000 : 0xcafe -13570 .. ATUM>
It may be RAM's fault later, but not yet...
I looked at the code after you mentioned that - thanks for pointing that out.
I get the feeling that somehow that u-boot isn't being executed yet - how can I verify that? Maybe setting a breakpoint in start.S ?
YES! Set hardware breakpoints right at the start and see if you hit them (and I would do it directly with the BDI, since I'm paranoid).
I'm using the bdi now directly, and googling turned this up:
http://www.ultsol.com/faq_p304.htm
"For an MPC85xx family processor the MSR[DE] bit must be set. Breakpoints will only trigger if this bit is set."
So after reset, info shows:
ATUM>info Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0xfffffffc Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000
MSR[DE] in the 8548 manual at 6-12 says:
bit name description --------------------------------------------------------------------------------------------------------------------------- 54 DE Debug interrupt enable. See the description of the DBSR[UDE] in Section 6.13.2, "Debug Status Register (DBSR)." 0 Debug interrupts are disabled. 1 Debug interrupts are enabled if DBCR0[IDM] = 1.
I read this all as saying the MSR needs to be 0x00000220 - bit 54 off the MSR seems to be cleared by the bdi as shown above - seems odd to me.
Using gdb just to read the elf symbols and _not_ connected to the bdi, I get:
(gdb) b _start_e500 Breakpoint 1 at 0xfffff01c
So I do (ATUM> is my bdi prompt) :
ATUM>rm msr 0x00000220 ATUM>rd msr msr : 0x00000220 544 ATUM>bi 0xfffff01c Breakpoint identification is 0 ATUM>go
After waiting for minute or so, I do:
ATUM>halt Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0x00000000 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000
So the MSR bit I believe I need is getting cleared.
I would also check what your PC register is when you start out, perhaps you aren't even starting where you think you are.
When you go/continue and no breakpoints are hit, halt the CPU... where is the PC?
As shown above the PC is 0x00000000 - the start of my DDR2. What does that mean?
Your BDI config file is pretty complex, can you trim out all but the essentials? I see a lot of "moving" and "mapping" and "TLB"ing. Your memory map may be completely different from the normal power up configuration, which is what u-boot expects.
Will try that so that its easier to help me - was quite an effort to create that file.
Makes me ask my memory readback question again: can you read the flash holding u-boot at the memory location you think u-boot lives at???
This seems right to me:
ATUM>mdh 0xff800000 0_ff800000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30 '..VU-Boot 1.3.0
Yerwelcome. Hope it helps. gvb
Helping quite a bunch as I have plenty of ideas to try - thanks! Robert