All of lore.kernel.org
 help / color / mirror / Atom feed
* kernel boot stuck at udbg_putc_cpm()
@ 2010-07-05  7:23 Shawn Jin
  2010-07-06 20:21 ` Scott Wood
  0 siblings, 1 reply; 10+ messages in thread
From: Shawn Jin @ 2010-07-05  7:23 UTC (permalink / raw)
  To: ppcdev

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.

I did a few debugging sessions, observed some frustrating things.
Would anyone here more experienced shed some lights on potential
causes?

First I set breakpoint at machine_init(). Below is the debug session.

(gdb) target remote bdi:2001
Remote debugging using bdi:2001
machine_init (dt_ptr=5890816) at arch/powerpc/kernel/setup_32.c:121
121	{
(gdb) next
125		udbg_early_init();
(gdb) next
^C
Program received signal SIGSTOP, Stopped (signal).
udelay (usecs=<value optimized out>)
    at /home/rayan/wti/code/wti-linux-2.6.33.5/arch/powerpc/include/asm/time.h:78
78		return mftbl();
(gdb) li
73	#if defined(CONFIG_403GCX)
74		unsigned long tbl;
75		asm volatile("mfspr %0, 0x3dd" : "=r" (tbl));
76		return tbl;
77	#else
78		return mftbl();
79	#endif
80	}
81	
82	static inline unsigned int get_tbu(void)
(gdb) step
413			while (get_tbl() - start < loops)
(gdb) step
414				HMT_low();
(gdb) print start
No symbol "start" in current context.
(gdb) print loops
No symbol "loops" in current context.
(gdb)

Several observations regarding to the above debugging session.
1. The kernel seems not able to pass udbg_early_init(). However if
breakpoint was set at functions being executed later such as
probe_machine() or start_kernel(), the udbg_early_init() was executed
properly.
2. When the execution was interrupted, it stopped at __delay(). And
the kernel seems not able to get out of this __delay() function. 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.
2. Once the execution was interrupted, it stopped at __delay() again,
same as the previous gdb session.

(gdb) target remote bdi:2001
Remote debugging using bdi:2001
probe_machine () at arch/powerpc/kernel/setup-common.c:525
525	{
(gdb) step
535		for (machine_id = &__machine_desc_start;
(gdb) print __machine_desc_start
$1 = {name = 0xc013ea64 "My MPC870", pci_dma_dev_setup = 0,
  pci_dma_bus_setup = 0, probe = 0xc01544c4 <my870_probe>,
  setup_arch = 0xc015442c <my870_setup>, init_early = 0, show_cpuinfo = 0,
  show_percpuinfo = 0, init_IRQ = 0xc01541d4 <mpc8xx_pics_init>,
  get_irq = 0xc001344c <mpc8xx_get_irq>, pcibios_fixup = 0,
  pci_probe_mode = 0, pci_irq_fixup = 0, pci_setup_phb = 0,
  restart = 0xc0013f0c <mpc8xx_restart>, power_off = 0, halt = 0, panic = 0,
  cpu_die = 0, time_init = 0, set_rtc_time = 0xc0013fdc <mpc8xx_set_rtc_time>,
  get_rtc_time = 0xc0013f78 <mpc8xx_get_rtc_time>, get_boot_time = 0,
  rtc_read_val = 0, rtc_write_val = 0,
  calibrate_decr = 0xc0151e70 <generic_calibrate_decr>,
  progress = 0xc0153110 <udbg_progress>, log_error = 0, nvram_read_val = 0,
  nvram_write_val = 0, nvram_write = 0, nvram_read = 0, nvram_size = 0,
  nvram_sync = 0, system_reset_exception = 0, machine_check_exception = 0,
  feature_call = 0, pci_get_legacy_ide_irq = 0, phys_mem_access_prot = 0,
  idle_loop = 0, power_save = 0, enable_pmcs = 0, set_dabr = 0, init = 0,
  kgdb_map_scc = 0, pcibios_after_init = 0, pci_exclude_device = 0,
  pcibios_fixup_resources = 0, pcibios_fixup_bus = 0,
  pcibios_enable_device_hook = 0, machine_shutdown = 0}
(gdb) print __machine_desc_end
$2 = {name = 0x0, pci_dma_dev_setup = 0, pci_dma_bus_setup = 0, probe = 0,
  setup_arch = 0, init_early = 0, show_cpuinfo = 0, show_percpuinfo = 0,
  init_IRQ = 0, get_irq = 0, pcibios_fixup = 0, pci_probe_mode = 0,
  pci_irq_fixup = 0, pci_setup_phb = 0, restart = 0, power_off = 0, halt = 0,
  panic = 0, cpu_die = 0, time_init = 0, set_rtc_time = 0, get_rtc_time = 0,
  get_boot_time = 0, rtc_read_val = 0, rtc_write_val = 0, calibrate_decr = 0,
  progress = 0, log_error = 0, nvram_read_val = 0, nvram_write_val = 0,
  nvram_write = 0, nvram_read = 0, nvram_size = 0, nvram_sync = 0,
  system_reset_exception = 0, machine_check_exception = 0, feature_call = 0,
  pci_get_legacy_ide_irq = 0, phys_mem_access_prot = 0, idle_loop = 0,
  power_save = 0, enable_pmcs = 0, set_dabr = 0, init = 0, kgdb_map_scc = 0,
  pcibios_after_init = 0, pci_exclude_device = 0, pcibios_fixup_resources = 0,
  pcibios_fixup_bus = 0, pcibios_enable_device_hook = 0, machine_shutdown = 0}
(gdb) step
536		     machine_id < &__machine_desc_end;
(gdb) print machine_id
$3 = (struct machdep_calls *) 0x0
(gdb) step
525	{
(gdb) step
535		for (machine_id = &__machine_desc_start;
(gdb) step
525	{
(gdb) step
536		     machine_id < &__machine_desc_end;
(gdb) step
535		for (machine_id = &__machine_desc_start;
(gdb) step
525	{
(gdb) step
535		for (machine_id = &__machine_desc_start;
(gdb) list
530		 * Iterate all ppc_md structures until we find the proper
531		 * one for the current machine type
532		 */
533		DBG("Probing machine type ...\n");
534	
535		for (machine_id = &__machine_desc_start;
536		     machine_id < &__machine_desc_end;
537		     machine_id++) {
538			DBG("  %s ...", machine_id->name);
539			memcpy(&ppc_md, machine_id, sizeof(struct machdep_calls));
(gdb) list
540			if (ppc_md.probe()) {
541				DBG(" match !\n");
542				break;
543			}
544			DBG("\n");
545		}
546		/* What can we do if we didn't find ? */
547		if (machine_id >= &__machine_desc_end) {
548			DBG("No suitable machine found !\n");
549			for (;;);
(gdb) b 540
Breakpoint 1 at 0xc000cdb8: file arch/powerpc/kernel/setup-common.c, line 540.
(gdb) cont
Continuing.
^C
Program received signal SIGSTOP, Stopped (signal).
udelay (usecs=<value optimized out>) at arch/powerpc/kernel/time.c:414
414				HMT_low();
(gdb)

Finally I decided to set the breakpoint at start_kernel(). This time
where the kernel stuck was different from the previous two debugging
trials. The kernel was stuck before it reached the start_kernel(). And
I believe this udbg_put_cpm() was called when the kernel tried to
print "id mach(): done" inside machine_init().

 145        if (ppc_md.progress)
 146                ppc_md.progress("id mach(): done", 0x200);

The debug session is shown below. I also dump the cpm_udbg_txdesc from
BDI, which showed that the bit0 was always 1.

(gdb) target remote bdi:2001
Remote debugging using bdi:2001
0xc0012df8 in udbg_putc_cpm (c=105 'i')
    at /home/rayan/wti/code/wti-linux-2.6.33.5/arch/powerpc/include/asm/io.h:155
155	DEF_MMIO_IN_BE(in_be32, 32, lwz);
(gdb) next
48		while (in_be32(&cpm_udbg_txdesc[0]) & 0x80000000)
(gdb) next
48		while (in_be32(&cpm_udbg_txdesc[0]) & 0x80000000)
(gdb) next
48		while (in_be32(&cpm_udbg_txdesc[0]) & 0x80000000)
(gdb) b 51
Breakpoint 1 at 0xc0012e2c: file arch/powerpc/sysdev/cpm_common.c, line 51.
(gdb) cont
Continuing.
^C
Program received signal SIGSTOP, Stopped (signal).
udbg_putc_cpm (c=105 'i') at arch/powerpc/sysdev/cpm_common.c:48
48		while (in_be32(&cpm_udbg_txdesc[0]) & 0x80000000)
(gdb) frame
#0  udbg_putc_cpm (c=105 'i') at arch/powerpc/sysdev/cpm_common.c:48
48		while (in_be32(&cpm_udbg_txdesc[0]) & 0x80000000)
(gdb)

BDI>md 0xfa202000 4
fa202000 : 0xffffffff  -         1  ....
fa202004 : 0xffffffff  -         1  ....
fa202008 : 0xffffffff  -         1  ....
fa20200c : 0xffffffff  -         1  ....

Thanks a lot,
-Shawn.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kernel boot stuck at udbg_putc_cpm()
  2010-07-05  7:23 kernel boot stuck at udbg_putc_cpm() Shawn Jin
@ 2010-07-06 20:21 ` Scott Wood
  2010-07-06 23:08   ` Shawn Jin
  0 siblings, 1 reply; 10+ messages in thread
From: Scott Wood @ 2010-07-06 20:21 UTC (permalink / raw)
  To: Shawn Jin; +Cc: ppcdev

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kernel boot stuck at udbg_putc_cpm()
  2010-07-06 20:21 ` Scott Wood
@ 2010-07-06 23:08   ` Shawn Jin
  2010-07-06 23:18     ` Scott Wood
  0 siblings, 1 reply; 10+ messages in thread
From: Shawn Jin @ 2010-07-06 23:08 UTC (permalink / raw)
  To: Scott Wood; +Cc: ppcdev

On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood <scottwood@freescale.com> wrote:
> Hmm... try 0xfa203bf8 (assuming your muram/data node has reg =3D <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=3D0x1032)
    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? =A0Try 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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kernel boot stuck at udbg_putc_cpm()
  2010-07-06 23:08   ` Shawn Jin
@ 2010-07-06 23:18     ` Scott Wood
  2010-07-07  0:17       ` Shawn Jin
  0 siblings, 1 reply; 10+ messages in thread
From: Scott Wood @ 2010-07-06 23:18 UTC (permalink / raw)
  To: Shawn Jin; +Cc: ppcdev

On Tue, 6 Jul 2010 16:08:26 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:

> On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood <scottwood@freescale.com>
> wrote:
> > Hmm... try 0xfa203bf8 (assuming your muram/data node has reg =3D <0
> > 0x1c00>). It looks like commit
> > 0x1c00>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.
>=20
> 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.

Do you get any output from the serial port?  I'd have expected
something by the time you get to cpm_uart_initbd() -- in fact, the
early output will have been shut down by then to make room for the real
serial driver.

> (gdb) target remote bdi:2001
> Remote debugging using bdi:2001
> cpm_uart_initbd (pinfo=3D0x1032)
>     at /home/rayan/wti/code/wti-linux-2.6.33.5/arch/powerpc/include/asm/i=
o.h:161
> 161     DEF_MMIO_OUT_BE(out_be32, 32, stw);
>=20
>=20
> > Could the kernel have crashed, and is waiting the 180 seconds to
> > reboot? =A0Try doing a stack trace, and/or dumping the kernel's log
> > buffer.
>=20
> It sounds like that. gdb showed there was only one level of function
> in the stack, which was udelay(). Strange?

Might be related to it not dealing with effective addresses.

> How to dump the kernel log buffer?

Find the address of __log_buf, and dump the memory there (subtract
0xc0000000 if you're dealing with physical addresses).

-Scott

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kernel boot stuck at udbg_putc_cpm()
  2010-07-06 23:18     ` Scott Wood
@ 2010-07-07  0:17       ` Shawn Jin
  2010-07-07 15:42         ` Scott Wood
  2010-07-09  7:35         ` Shawn Jin
  0 siblings, 2 replies; 10+ messages in thread
From: Shawn Jin @ 2010-07-07  0:17 UTC (permalink / raw)
  To: Scott Wood; +Cc: ppcdev

>> 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.
>
> Do you get any output from the serial port? =A0I'd have expected
> something by the time you get to cpm_uart_initbd() -- in fact, the
> early output will have been shut down by then to make room for the real
> serial driver.

Nothing new on the serial port. :-( Is the interrupt enabled during
the early debug stage? I'm not sure if the interrupt controller is set
properly in DTS. The same MPC875 settings are copied from the
adder875-uboot.dts.

    Memory <- <0x0 0x8000000> (128MB)
    ENET0: local-mac-address <- 00:09:9b:01:58:64
    CPU clock-frequency <- 0x7270e00 (120MHz)
    CPU timebase-frequency <- 0x393870 (4MHz)
    CPU bus-frequency <- 0x3938700 (60MHz)

    zImage starting: loaded at 0x00400000 (sp: 0x07d1ccd0)
    Allocating 0x186bdd bytes for kernel ...
    gunzipping (0x00000000 <- 0x0040c000:0x00591c30)...done 0x173b18 bytes

    Linux/PowerPC load: root=3D/dev/ram
    Finalizing device tree... flat tree at 0x59e300

Here is the kernel log buf dump. Anything suspicious?

<6>Using My MPC870 machine description
<5>Linux version 2.6.33.5 (shawn@ubuntu) (gcc version 4.3.3 (GCC) )
#10 Mon Jul 5 22:58:30 PDT 2010
<7>Top of RAM: 0x8000000, Total RAM: 0x8000000
<7>Memory hole size: 0MB
<4>Zone PFN ranges:
<4>  DMA      0x00000000 -> 0x00008000
<4>  Normal   0x00008000 -> 0x00008000
<4>Movable zone start PFN for each node
<4>early_node_map[1] active PFN ranges
<4>    0: 0x00000000 -> 0x00008000
<7>On node 0 totalpages: 32768
<7>free_area_init_node: node 0, pgdat c016c5b0, node_mem_map c0189000
<7>  DMA zone: 256 pages used for memmap
<7>  DMA zone: 0 pages reserved
<7>  DMA zone: 32512 pages, LIFO batch:7
<6>MMU: Allocated 72 bytes of context maps for 16 contexts
<4>Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 325=
12
<5>Kernel command line: root=3D/dev/ram
<6>PID hash table entries: 512 (order: -1, 2048 bytes)
<6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
<6>Memory: 128096k/131072k available (1420k kernel code, 2836k
reserved, 68k data, 74k bss, 76k init)
<6>Kernel virtual memory layout:
<6>  * 0xfffdf000..0xfffff000  : fixmap
<6>  * 0xfde00000..0xfe000000  : consistent mem
<6>  * 0xfddfa000..0xfde00000  : early ioremap
<6>  * 0xc9000000..0xfddfa000  : vmalloc & ioremap
<6>SLUB: Genslabs=3D12, HWalign=3D16, Order=3D0-3, MinObjects=3D0, CPUs=3D1=
, Nodes=3D1
<6>Hierarchical RCU implementation.
<6>NR_IRQS:512 nr_irqs:512
<7>  alloc irq_desc for 16 on node 0
<7>  alloc kstat_irqs on node 0
<7>irq: irq 5 on host /soc@fa200000/interrupt-controller@0 mapped to
virtual irq 16
<7>  alloc irq_desc for 17 on node 0
<7>  alloc kstat_irqs on node 0
<7>irq: irq 0 on host /soc@fa200000/cpm@9c0/interrupt-controller@930
mapped to virtual irq 17
<7>time_init: decrementer frequency =3D 3.750000 MHz
<7>time_init: processor frequency   =3D 120.000000 MHz
<6>clocksource: timebase mult[42aaaaab] shift[22] registered
<7>clockevent: decrementer mult[f5c28f] shift[32] cpu[0]
<7>  alloc irq_desc for 18 on node 0
<7>  alloc kstat_irqs on node 0
<7>irq: irq 4 on host /soc@fa200000/cpm@9c0/interrupt-controller@930
mapped to virtual irq 18

Thanks,
-Shawn.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kernel boot stuck at udbg_putc_cpm()
  2010-07-07  0:17       ` Shawn Jin
@ 2010-07-07 15:42         ` Scott Wood
  2010-07-09  7:35         ` Shawn Jin
  1 sibling, 0 replies; 10+ messages in thread
From: Scott Wood @ 2010-07-07 15:42 UTC (permalink / raw)
  To: Shawn Jin; +Cc: ppcdev

On Tue, 6 Jul 2010 17:17:16 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:

> >> 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.
> >
> > Do you get any output from the serial port? =A0I'd have expected
> > something by the time you get to cpm_uart_initbd() -- in fact, the
> > early output will have been shut down by then to make room for the
> > real serial driver.
>=20
> Nothing new on the serial port. :-( Is the interrupt enabled during
> the early debug stage? I'm not sure if the interrupt controller is set
> properly in DTS. The same MPC875 settings are copied from the
> adder875-uboot.dts.

Interrupts are not used for the early serial output.

>=20
>     Memory <- <0x0 0x8000000> (128MB)
>     ENET0: local-mac-address <- 00:09:9b:01:58:64
>     CPU clock-frequency <- 0x7270e00 (120MHz)
>     CPU timebase-frequency <- 0x393870 (4MHz)
>     CPU bus-frequency <- 0x3938700 (60MHz)
>=20
>     zImage starting: loaded at 0x00400000 (sp: 0x07d1ccd0)
>     Allocating 0x186bdd bytes for kernel ...
>     gunzipping (0x00000000 <- 0x0040c000:0x00591c30)...done 0x173b18
> bytes
>=20
>     Linux/PowerPC load: root=3D/dev/ram
>     Finalizing device tree... flat tree at 0x59e300
>=20
> Here is the kernel log buf dump. Anything suspicious?

Nope, looks normal.

-Scott

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kernel boot stuck at udbg_putc_cpm()
  2010-07-07  0:17       ` Shawn Jin
  2010-07-07 15:42         ` Scott Wood
@ 2010-07-09  7:35         ` Shawn Jin
  2010-07-09 15:59           ` Scott Wood
  1 sibling, 1 reply; 10+ messages in thread
From: Shawn Jin @ 2010-07-09  7:35 UTC (permalink / raw)
  To: Scott Wood; +Cc: ppcdev

I changed my toolchain and rebuilt the kernel image. This time all the
messages below magically displayed on the serial port. :-D Are all
these the early debugging messages?

> Here is the kernel log buf dump. Anything suspicious?
>
> <6>Using My MPC870 machine description
> <5>Linux version 2.6.33.5 (shawn@ubuntu) (gcc version 4.3.3 (GCC) )
> #10 Mon Jul 5 22:58:30 PDT 2010
> <7>Top of RAM: 0x8000000, Total RAM: 0x8000000
> <7>Memory hole size: 0MB
> <4>Zone PFN ranges:
...
<snipped>
...
> <7>time_init: decrementer frequency =3D 3.750000 MHz
> <7>time_init: processor frequency =A0 =3D 120.000000 MHz
> <6>clocksource: timebase mult[42aaaaab] shift[22] registered
> <7>clockevent: decrementer mult[f5c28f] shift[32] cpu[0]
> <7> =A0alloc irq_desc for 18 on node 0
> <7> =A0alloc kstat_irqs on node 0
> <7>irq: irq 4 on host /soc@fa200000/cpm@9c0/interrupt-controller@930
> mapped to virtual irq 18

Now the kernel stuck at the while loop that waits for transmitter fifo
to be empty. It seems that the CPM UART stopped working in the middle
of printing a message. I'm using minicom to connect to the serial
port. I heard minicom is problematic. Will it be the cause here?

(gdb) target remote ppcbdi:2001
Remote debugging using ppcbdi:2001
0xc00f348c in cpm_uart_console_write (co=3D<value optimized out>,
    s=3D0xc0174df3 "console [ttyCPM0] enabled, bootconsole disabled\n", cou=
nt=3D48)
    at /home/rayan/wti/code/wti-linux-2.6.33.5/arch/powerpc/include/asm/io.=
h:154
154     DEF_MMIO_IN_BE(in_be16, 16, lhz);
(gdb) next
1161                    while ((in_be16(&bdp->cbd_sc) & BD_SC_READY) !=3D 0=
)
(gdb) next
154     DEF_MMIO_IN_BE(in_be16, 16, lhz);
(gdb) next
1161                    while ((in_be16(&bdp->cbd_sc) & BD_SC_READY) !=3D 0=
)
(gdb) list
1156            for (i =3D 0; i < count; i++, s++) {
1157                    /* Wait for transmitter fifo to empty.
1158                     * Ready indicates output is ready, and xmt is doin=
g
1159                     * that, not that it is ready for us to send.
1160                     */
1161                    while ((in_be16(&bdp->cbd_sc) & BD_SC_READY) !=3D 0=
)
1162                            ;
1163
1164                    /* Send the character out.
1165                     * If the buffer address is in the CPM DPRAM, don't

Thanks,
-Shawn.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kernel boot stuck at udbg_putc_cpm()
  2010-07-09  7:35         ` Shawn Jin
@ 2010-07-09 15:59           ` Scott Wood
  2010-07-12  6:26             ` Shawn Jin
  0 siblings, 1 reply; 10+ messages in thread
From: Scott Wood @ 2010-07-09 15:59 UTC (permalink / raw)
  To: Shawn Jin; +Cc: ppcdev

On Fri, 9 Jul 2010 00:35:43 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:

> I changed my toolchain and rebuilt the kernel image. This time all the
> messages below magically displayed on the serial port. :-D Are all
> these the early debugging messages?

Yes, it's an alternate output for the regular console (there are
sometimes more messages, if you hook up .progress in your ppc_md, but
that's mainly of interest if you don't get this far).

> Now the kernel stuck at the while loop that waits for transmitter fifo
> to be empty. It seems that the CPM UART stopped working in the middle
> of printing a message. I'm using minicom to connect to the serial
> port. I heard minicom is problematic. Will it be the cause here?

I doubt it...

You're probably getting to the point where udbg is disabled because the
real serial driver is trying to take over -- and something's going
wrong with the real serial port driver.  Check to make sure the brg
config is correct (both the input clock and the baud rate you're trying
to switch to).  Commenting out the call to cpm_set_brg can be
a quick way of determining if that's the problem.

-Scott

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kernel boot stuck at udbg_putc_cpm()
  2010-07-09 15:59           ` Scott Wood
@ 2010-07-12  6:26             ` Shawn Jin
  2010-07-12 18:23               ` Shawn Jin
  0 siblings, 1 reply; 10+ messages in thread
From: Shawn Jin @ 2010-07-12  6:26 UTC (permalink / raw)
  To: Scott Wood; +Cc: ppcdev

> You're probably getting to the point where udbg is disabled because the
> real serial driver is trying to take over -- and something's going
> wrong with the real serial port driver. =A0Check to make sure the brg
> config is correct (both the input clock and the baud rate you're trying
> to switch to). =A0Commenting out the call to cpm_set_brg can be
> a quick way of determining if that's the problem.

It seems that the last CP command RESTART_TX never completes in the
cpm_uart_console_setup(). I commented out the writes to brgc1 in
cpm_setbrg() in cpm1.c so that the brgc1 value stays the same as
previously set.

The registers related to SMC1 are dumped below before the last
RESTART_TX command. The CPCR was 0x0090. But after issuing the
RESTART_TX command the CPCR kept at 0x0691. Is there any other obvious
reason for CPM not completing the command? It got to be something
related to the settings.

BDI>rd cpcr
cpcr           : 0x0090      144
BDI>rd rccr
rccr           : 0x0001      1
BDI>rd rmds
rmds           : 0x00        0
BDI>rd rctr1
rctr1          : 0x0000      0
BDI>rd rctr2
rctr2          : 0x0000      0
BDI>rd rctr3
rctr3          : 0x802e      -32722
BDI>rd rctr4
rctr4          : 0x802c      -32724
BDI>rd rter
rter           : 0x0000      0
BDI>rd rtmr
rtmr           : 0x0000      0
BDI>rd brgc1
brgc1          : 0x00010618  67096
BDI>rd smcmr1
smcmr1         : 0x4823      18467
BDI>rd smce1
smce1          : 0x00        0
BDI>rd smcm1
smcm1          : 0x00        0

Thanks,
-Shawn.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: kernel boot stuck at udbg_putc_cpm()
  2010-07-12  6:26             ` Shawn Jin
@ 2010-07-12 18:23               ` Shawn Jin
  0 siblings, 0 replies; 10+ messages in thread
From: Shawn Jin @ 2010-07-12 18:23 UTC (permalink / raw)
  To: Scott Wood; +Cc: ppcdev

For some reason. This email was rejected. Resending...

On Sun, Jul 11, 2010 at 11:26 PM, Shawn Jin <shawnxjin@gmail.com> wrote:
> You're probably getting to the point where udbg is disabled because the
> real serial driver is trying to take over -- and something's going
> wrong with the real serial port driver. =A0Check to make sure the brg
> config is correct (both the input clock and the baud rate you're trying
> to switch to). =A0Commenting out the call to cpm_set_brg can be
> a quick way of determining if that's the problem.

It seems that the last CP command RESTART_TX never completes in the
cpm_uart_console_setup(). I commented out the writes to brgc1 in
cpm_setbrg() in cpm1.c so that the brgc1 value stays the same as
previously set.

The registers related to SMC1 are dumped below before the last
RESTART_TX command. The CPCR was 0x0090. But after issuing the
RESTART_TX command the CPCR kept at 0x0691. Is there any other obvious
reason for CPM not completing the command? It got to be something
related to the settings.

BDI>rd cpcr
cpcr =A0 =A0 =A0 =A0 =A0 : 0x0090 =A0 =A0 =A0144
BDI>rd rccr
rccr =A0 =A0 =A0 =A0 =A0 : 0x0001 =A0 =A0 =A01
BDI>rd rmds
rmds =A0 =A0 =A0 =A0 =A0 : 0x00 =A0 =A0 =A0 =A00
BDI>rd rctr1
rctr1 =A0 =A0 =A0 =A0 =A0: 0x0000 =A0 =A0 =A00
BDI>rd rctr2
rctr2 =A0 =A0 =A0 =A0 =A0: 0x0000 =A0 =A0 =A00
BDI>rd rctr3
rctr3 =A0 =A0 =A0 =A0 =A0: 0x802e =A0 =A0 =A0-32722
BDI>rd rctr4
rctr4 =A0 =A0 =A0 =A0 =A0: 0x802c =A0 =A0 =A0-32724
BDI>rd rter
rter =A0 =A0 =A0 =A0 =A0 : 0x0000 =A0 =A0 =A00
BDI>rd rtmr
rtmr =A0 =A0 =A0 =A0 =A0 : 0x0000 =A0 =A0 =A00
BDI>rd brgc1
brgc1 =A0 =A0 =A0 =A0 =A0: 0x00010618 =A067096
BDI>rd smcmr1
smcmr1 =A0 =A0 =A0 =A0 : 0x4823 =A0 =A0 =A018467
BDI>rd smce1
smce1 =A0 =A0 =A0 =A0 =A0: 0x00 =A0 =A0 =A0 =A00
BDI>rd smcm1
smcm1 =A0 =A0 =A0 =A0 =A0: 0x00 =A0 =A0 =A0 =A00

Thanks,
-Shawn.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2010-07-12 18:23 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-05  7:23 kernel boot stuck at udbg_putc_cpm() Shawn Jin
2010-07-06 20:21 ` Scott Wood
2010-07-06 23:08   ` Shawn Jin
2010-07-06 23:18     ` Scott Wood
2010-07-07  0:17       ` Shawn Jin
2010-07-07 15:42         ` Scott Wood
2010-07-09  7:35         ` Shawn Jin
2010-07-09 15:59           ` Scott Wood
2010-07-12  6:26             ` Shawn Jin
2010-07-12 18:23               ` Shawn Jin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.