Re: kernel boot stuck at udbg_putc_cpm()

[Scott Wood <scottwood@freescale.com>]

On Tue, 6 Jul 2010 16:08:26 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:

> On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood <scottwood@freescale.com>
> wrote:
> > 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
> > 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