Re: kernel boot stuck at udbg_putc_cpm()

[Scott Wood <scottwood@freescale.com>]

On Mon, 5 Jul 2010 00:23:45 -0700
Shawn Jin <shawnxjin@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