On Tue, 6 Jul 2010 16:08:26 -0700 Shawn Jin <shawnx...@gmail.com> wrote:
> On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood <scottw...@freescale.com> > wrote: > > 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 serial driver. > (gdb) target remote bdi:2001 > Remote debugging using bdi:2001 > cpm_uart_initbd (pinfo=0x1032) > at > /home/rayan/wti/code/wti-linux-2.6.33.5/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). -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
