Re: kernel boot stuck at udbg_putc_cpm()

On Tue, 6 Jul 2010 16:08:26 -0700
Shawn Jin [off-list ref] wrote:

On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood [off-list ref]
wrote:

quoted

Hmm... try 0xfa203bf8 (assuming your muram/data node has reg =3D <0
0x1c00>). It looks like commit
0x1c00>c2dd3529f35de9e2f51eba9bbf9969f5dc8382d4
changed the bootwrapper's cpm-serial driver to allocate from the
end of MURAM instead of the beginning, but updated
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR to match only on CPM2, not CPM1.

=20
That was it. The value @0xfa203bf8 is 0x20000001. The kernel certainly
moved forward till it stuck at the new place cpm_uart_initbd() as
shown below.

Do you get any output from the serial port?  I'd have expected
something by the time you get to cpm_uart_initbd() -- in fact, the
early output will have been shut down by then to make room for the real
serial driver.

(gdb) target remote bdi:2001
Remote debugging using bdi:2001
cpm_uart_initbd (pinfo=3D0x1032)
    at /home/rayan/wti/code/wti-linux-2.6.33.5/arch/powerpc/include/asm/i=

o.h:161

161     DEF_MMIO_OUT_BE(out_be32, 32, stw);
=20
=20

quoted

Could the kernel have crashed, and is waiting the 180 seconds to
reboot? =A0Try doing a stack trace, and/or dumping the kernel's log
buffer.

=20
It sounds like that. gdb showed there was only one level of function
in the stack, which was udelay(). Strange?

Might be related to it not dealing with effective addresses.

How to dump the kernel log buffer?

Find the address of __log_buf, and dump the memory there (subtract
0xc0000000 if you're dealing with physical addresses).

-Scott