[U-Boot-Users] Debugging u-boot on a custom 8548 board

[robert lazarski]

On 9/19/07, Jerry Van Baren <gerald.vanbaren at 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