Re: kernel boot stuck at udbg_putc_cpm()
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. 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. BDIrd cpcr cpcr : 0x0090 144 BDIrd rccr rccr : 0x0001 1 BDIrd rmds rmds : 0x000 BDIrd rctr1 rctr1 : 0x 0 BDIrd rctr2 rctr2 : 0x 0 BDIrd rctr3 rctr3 : 0x802e -32722 BDIrd rctr4 rctr4 : 0x802c -32724 BDIrd rter rter : 0x 0 BDIrd rtmr rtmr : 0x 0 BDIrd brgc1 brgc1 : 0x00010618 67096 BDIrd smcmr1 smcmr1 : 0x4823 18467 BDIrd smce1 smce1 : 0x000 BDIrd smcm1 smcm1 : 0x000 Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
For some reason. This email was rejected. Resending... On Sun, Jul 11, 2010 at 11:26 PM, Shawn Jin shawnx...@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. 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. 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. BDIrd cpcr cpcr : 0x0090 144 BDIrd rccr rccr : 0x0001 1 BDIrd rmds rmds : 0x00 0 BDIrd rctr1 rctr1 : 0x 0 BDIrd rctr2 rctr2 : 0x 0 BDIrd rctr3 rctr3 : 0x802e -32722 BDIrd rctr4 rctr4 : 0x802c -32724 BDIrd rter rter : 0x 0 BDIrd rtmr rtmr : 0x 0 BDIrd brgc1 brgc1 : 0x00010618 67096 BDIrd smcmr1 smcmr1 : 0x4823 18467 BDIrd smce1 smce1 : 0x00 0 BDIrd smcm1 smcm1 : 0x00 0 Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
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?
6Using My MPC870 machine description
5Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.3.3 (GCC) )
#10 Mon Jul 5 22:58:30 PDT 2010
7Top of RAM: 0x800, Total RAM: 0x800
7Memory hole size: 0MB
4Zone PFN ranges:
...
snipped
...
7time_init: decrementer frequency = 3.75 MHz
7time_init: processor frequency = 120.00 MHz
6clocksource: timebase mult[42ab] shift[22] registered
7clockevent: decrementer mult[f5c28f] shift[32] cpu[0]
7 alloc irq_desc for 18 on node 0
7 alloc kstat_irqs on node 0
7irq: irq 4 on host /s...@fa20/c...@9c0/interrupt-control...@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=value optimized out,
s=0xc0174df3 console [ttyCPM0] enabled, bootconsole disabled\n, count=48)
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
1161while ((in_be16(bdp-cbd_sc) BD_SC_READY) != 0)
(gdb) next
154 DEF_MMIO_IN_BE(in_be16, 16, lhz);
(gdb) next
1161while ((in_be16(bdp-cbd_sc) BD_SC_READY) != 0)
(gdb) list
1156for (i = 0; i count; i++, s++) {
1157/* Wait for transmitter fifo to empty.
1158 * Ready indicates output is ready, and xmt is doing
1159 * that, not that it is ready for us to send.
1160 */
1161while ((in_be16(bdp-cbd_sc) BD_SC_READY) != 0)
1162;
1163
1164/* Send the character out.
1165 * If the buffer address is in the CPM DPRAM, don't
Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
On Fri, 9 Jul 2010 00:35:43 -0700 Shawn Jin shawnx...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
On Tue, 6 Jul 2010 17:17:16 -0700 Shawn Jin shawnx...@gmail.com wrote: That was it. The value @0xfa203bf8 is 0x2001. 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. 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. Memory - 0x0 0x800 (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 0x0040 (sp: 0x07d1ccd0) Allocating 0x186bdd bytes for kernel ... gunzipping (0x - 0x0040c000:0x00591c30)...done 0x173b18 bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x59e300 Here is the kernel log buf dump. Anything suspicious? Nope, looks normal. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
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 0xfa20. 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
Re: kernel boot stuck at udbg_putc_cpm()
On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood scottw...@freescale.com wrote: 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. That was it. The value @0xfa203bf8 is 0x2001. 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=0x1032) 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? Try 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
On Tue, 6 Jul 2010 16:08:26 -0700 Shawn Jin shawnx...@gmail.com wrote: On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood scottw...@freescale.com wrote: Hmm... try 0xfa203bf8 (assuming your muram/data node has reg = 0 0x1c00). It looks like commit 0x1c00c2dd3529f35de9e2f51eba9bbf9969f5dc8382d4 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 0x2001. 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=0x1032) 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? Try 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? 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 0xc000 if you're dealing with physical addresses). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
That was it. The value @0xfa203bf8 is 0x2001. 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. 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 0x800 (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 0x0040 (sp: 0x07d1ccd0) Allocating 0x186bdd bytes for kernel ... gunzipping (0x - 0x0040c000:0x00591c30)...done 0x173b18 bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x59e300 Here is the kernel log buf dump. Anything suspicious? 6Using My MPC870 machine description 5Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.3.3 (GCC) ) #10 Mon Jul 5 22:58:30 PDT 2010 7Top of RAM: 0x800, Total RAM: 0x800 7Memory hole size: 0MB 4Zone PFN ranges: 4 DMA 0x - 0x8000 4 Normal 0x8000 - 0x8000 4Movable zone start PFN for each node 4early_node_map[1] active PFN ranges 40: 0x - 0x8000 7On node 0 totalpages: 32768 7free_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 6MMU: Allocated 72 bytes of context maps for 16 contexts 4Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 5Kernel command line: root=/dev/ram 6PID hash table entries: 512 (order: -1, 2048 bytes) 6Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) 6Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) 6Memory: 128096k/131072k available (1420k kernel code, 2836k reserved, 68k data, 74k bss, 76k init) 6Kernel virtual memory layout: 6 * 0xfffdf000..0xf000 : fixmap 6 * 0xfde0..0xfe00 : consistent mem 6 * 0xfddfa000..0xfde0 : early ioremap 6 * 0xc900..0xfddfa000 : vmalloc ioremap 6SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 6Hierarchical RCU implementation. 6NR_IRQS:512 nr_irqs:512 7 alloc irq_desc for 16 on node 0 7 alloc kstat_irqs on node 0 7irq: irq 5 on host /s...@fa20/interrupt-control...@0 mapped to virtual irq 16 7 alloc irq_desc for 17 on node 0 7 alloc kstat_irqs on node 0 7irq: irq 0 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 17 7time_init: decrementer frequency = 3.75 MHz 7time_init: processor frequency = 120.00 MHz 6clocksource: timebase mult[42ab] shift[22] registered 7clockevent: decrementer mult[f5c28f] shift[32] cpu[0] 7 alloc irq_desc for 18 on node 0 7 alloc kstat_irqs on node 0 7irq: irq 4 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 18 Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
