kernel boot stuck at udbg_putc_cpm()
scottwood at freescale.com
Wed Jul 7 06:21:10 EST 2010
On Mon, 5 Jul 2010 00:23:45 -0700
Shawn Jin <shawnxjin at gmail.com> wrote:
> I'm debugging the kernel (22.214.171.124) 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
> There was even no symbols for local variables. Why?
> 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.
More information about the Linuxppc-dev