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 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. I cannot get more info from gdb now since my BDI2000's fw
is too old to get MMU translation work for 2.6.x kernel. I'm waiting
for the new firmware upgrade.
(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? How to dump the kernel log
buffer?
Thanks a lot for your continuous help!
-Shawn.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
