On Mon, 5 Jul 2010 00:23:45 -0700 Shawn Jin <shawnx...@gmail.com> wrote:
> Hi, > > I'm debugging the kernel (2.6.33.5) ported for a MPC870 board. The > changes are mostly based on the board adder875. The first thing I want > to test is the serial port. So I enabled CONFIG_PPC_EARLY_DEBUG and > CONFIG_PPC_EARLY_DEBUG_CPM, and changed > CONFIG_PPC_EARLY_DEBUG_CPM_ADDR to 0xfa202008. My IMMR is 0xfa200000. > However the kernel seems to stuck at udbg_putc_cpm(). The most > significant bit at 0xfa202008 never changed to zero. 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. > 2. When the execution was interrupted, it stopped at __delay(). And > the kernel seems not able to get out of this __delay() function. 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. > There was even no symbols for local variables. Why? Optimized away. > Next I set the breakpoint at probe_machine(). The gdb session is shown > below. Again a couple of frustrating observations. > 1. The kernel seems not able to get into the for loop. The breakpoint > set inside the for loop never got hit. Check the actual assembly code, see if the breakpoint is at an address that makes sense. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
