kernel boot stuck at udbg_putc_cpm()
scottwood at freescale.com
Wed Jul 7 09:18:11 EST 2010
On Tue, 6 Jul 2010 16:08:26 -0700
Shawn Jin <shawnxjin at gmail.com> wrote:
> On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood <scottwood at freescale.com>
> > Hmm... try 0xfa203bf8 (assuming your muram/data node has reg = <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.
> 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
> (gdb) target remote bdi:2001
> Remote debugging using bdi:2001
> cpm_uart_initbd (pinfo=0x1032)
> at /home/rayan/wti/code/wti-linux-18.104.22.168/arch/powerpc/include/asm/io.h:161
> 161 DEF_MMIO_OUT_BE(out_be32, 32, stw);
> > Could the kernel have crashed, and is waiting the 180 seconds to
> > reboot? Try doing a stack trace, and/or dumping the kernel's log
> > buffer.
> 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).
More information about the Linuxppc-dev