debugging ppc4xx VM, part 2

debugging ppc4xx VM, part 2

[Mark Pilon]

I left out some of the things I've done:

I'm at the point of trying to bring a linux kernel (mvista
2.4.2 for ppc4xx) and am running into
a problem with debugging virtual memory:

per the BDI2000 user manual 'embedded linux MMU support` I've added
the entries to our bdi config file:

[INIT]
.
.
.
; zero out the page table base
WM32    0x000000f0  0x00000000

[TARGET]
.
.
.
MMU         XLAT        ; enable mmu translation, page table base @ 0xf0
PTBASE      0x000000f0

I've patched the kernel to spin in a simple loop, waiting on a var
to be set != 0 before continuing ... it's a way to get the kernel
uncompressed and started, but without proceeding.  this func is
called before doing the 'rfi' to get to the first thread.

I connect w/ gdb (hhl gdb 5.0) and set a breakpoint in start_kernel()
-- clear the above loop var, continue, and the breakpoint is hit.

however, if I step or next, gdb never comes back; if I break out
and 'where' it looks like I've taken a fault ...

I think I've set everything up for mmu support in the bdi --
there was 1 statement in the user's manual to:
'If not automatically done by the kernel, setup the page table pointers
for the BDI.' -- I don't know from this what to check or what to do.

a complete debug session:
(gdb) 1     <connect-to-target macro>
gdb_spin () at serial.c:5857
5857                 i++ ) {
(gdb) set gdb_spin_exit = 1
(gdb) p $pc
$1 = 0xc009b158
(gdb) b start_kernel
Breakpoint 1 at 0xc012f660: file init/main.c, line 534.
(gdb) c
Continuing.

Breakpoint 1, start_kernel () at init/main.c:534
534             printk(linux_banner);
(gdb) n
< I hit ctrl/C here>
Program received signal SIGSTOP, Stopped (signal).
panic (fmt=0x0) at panic.c:100
100             for(;;) {
(gdb) where
#0  panic (fmt=0x0) at panic.c:100
#1  0xc0016694 in do_exit (code=0xb) at exit.c:438
#2  0xc0002bb4 in _exception (signr=0xc00f16bc, regs=0x0) at traps.c:86
#3  0xc000ccc0 in bad_page_fault (regs=0xc011ef30, address=0x0, sig=0xb)
    at fault.c:235
#4  0xc000cb94 in do_page_fault (regs=0xc011ef30, address=0xc011ef30,
    error_code=0x1030) at fault.c:186
#5  0xc0002980 in ret_from_except () at init/main.c:801
#6  0xc000d7ac in ioremap (addr=0x9030, size=0x0) at ioremap.c:148
#7  0xc0002334 in start_here ()
(gdb)


--
Mark Pilon

Minolta-QMS
P.O. Box 37
Fallon, MT.  59326-0037

1-406-853-0433

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: debugging ppc4xx VM, part 2

[Mark Pilon]

Wolfgang Denk wrote:
>
> In message <3BD0616A.B5FE43C0@midrivers.com> you wrote:
> >
> > however, if I step or next, gdb never comes back; if I break out
> > and 'where' it looks like I've taken a fault ...
> >
> > I think I've set everything up for mmu support in the bdi --
> > there was 1 statement in the user's manual to:
> > 'If not automatically done by the kernel, setup the page table pointers
> > for the BDI.' -- I don't know from this what to check or what to do.
>
> Well, did you (a) follow the description in the  BDI2000  manual  and
> initialize  the  page  table  pointer  manually, or (b) did you use a
> kernel which has the necessary extension to do it automagically?
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> ######## This message was made from 100% recycled electrons. ########
>

yes.

it looks like I've either got a gdb/bdi problem or a kernel build
problem:

in start_kernel() I've added a call gdb_spin() which simply spins,
waiting for a var to be set != 0 by gdb -- it gives me time to start
gdb and break in.  I can step / next in this function, returning to
start_kernel().

the next call is:
printk(linux_banner);

-- if I si twice, rc becomes set w/ a pointer to the format string
which looks reasonable.

the 3'rd si is the bl      0xc0012da4 <printk>
-- when I si to enter this func, and 'where' I get:
(gdb) where
#0  printk (fmt=0x32f050 <Address 0x32f050 out of bounds>) at printk.c:255
#1  0xc0002330 in start_here ()

-- no mention of the call from start_here() to start_kernel() -- and
printk's format ptr has become unreasonable.

tools & environment:
hhl-20 gdb for ppc405, ppc compiler which I've built; the target is
a custom mercury-based controller (405+FPU) and the abatron software
has been changed to work w/ this processor, but not heavily tested.
the rev of the 405-core used in the mercury is akin to a 405GP rev. C
which has some issues of its own.

the kernel is hhl-2.0 [2.4.2] for ppc405 which I'm attempting to get
running on this target.

["other than that, Mrs. Lincoln, how did you like the play?"]

has anyone seen anything like this kind of stack foulup w/
a simple bl?

I've used this debugger quite a bit w/o trouble debugging the boot/diags
package in real mode -- mmu off, no addr translation.

Mark


has anyone seen a probl
Mark





--
Mark Pilon

Minolta-QMS
P.O. Box 37
Fallon, MT.  59326-0037

1-406-853-0433

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/