Thread (10 messages) flat view 10 messages, 2 authors, 2010-07-12

Re: kernel boot stuck at udbg_putc_cpm()

From: Scott Wood <hidden>
Date: 2010-07-06 20:21:15

On Mon, 5 Jul 2010 00:23:45 -0700
Shawn Jin [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help