Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready
On Fri, 16 Jul 2010 17:30:01 -0700 Shawn Jin shawnx...@gmail.com wrote: My RCCR=0x1, meaning the first 512B is for microcode. So the data and the TxBD should really be starting at 0xfa202200? Then my muram data's reg should be 0x200 ?? What size shall I specify? After the muram data's reg is changed to 0x200 0x1a00, the cpm_uart driver works properly and the kernel messages are printed on the serial port. The muram node is supposed to show the portions of DPRAM that are usable by the OS. If some portion has been taken up by microcode (or anything else not under the OS's control) before the OS has started, then it must be excluded from the muram node. It would be nicer that the initialization code could query the RCCR value and adjust the base address. Is that the only thing that could possibly conflict with OS usage of DPRAM? It seemed simpler to just specify the usable chunks. Before the kernel supported allocating CPM2 SMC parameter RAM, that was another thing that firmware allocated that had to be kept out of the muram node. It took me quite a while to understand the design. Sorry... This constraint is described in the MURAM section of Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt, though. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready
Why would the TxBD be filled with all 0xF? Would it be possible that the bdbase actually points somewhere else other than the TxBD? The virtual address 0xfddfa000 is mapped to 0xfa202000. I suspect that the TxBD of my MPC870 may not start at 0xfa202020. I notice that for adder875, ep88xc and mpc885ads, the muram data's reg = 0 0x1c00 but for mgsuvd, its reg = 0x800 0x1800. How does the kernel use muram for 885 family SoCs? How much muram should be reserved for data? My RCCR=0x1, meaning the first 512B is for microcode. So the data and the TxBD should really be starting at 0xfa202200? Then my muram data's reg should be 0x200 ?? What size shall I specify? After the muram data's reg is changed to 0x200 0x1a00, the cpm_uart driver works properly and the kernel messages are printed on the serial port. -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready
On Fri, 16 Jul 2010 00:12:21 -0700 Shawn Jin shawnx...@gmail.com wrote: Why would the TxBD be filled with all 0xF? Would it be possible that the bdbase actually points somewhere else other than the TxBD? The virtual address 0xfddfa000 is mapped to 0xfa202000. I suspect that the TxBD of my MPC870 may not start at 0xfa202020. I notice that for adder875, ep88xc and mpc885ads, the muram data's reg = 0 0x1c00 but for mgsuvd, its reg = 0x800 0x1800. How does the kernel use muram for 885 family SoCs? How much muram should be reserved for data? My RCCR=0x1, meaning the first 512B is for microcode. So the data and the TxBD should really be starting at 0xfa202200? Then my muram data's reg should be 0x200 ?? What size shall I specify? After the muram data's reg is changed to 0x200 0x1a00, the cpm_uart driver works properly and the kernel messages are printed on the serial port. The muram node is supposed to show the portions of DPRAM that are usable by the OS. If some portion has been taken up by microcode (or anything else not under the OS's control) before the OS has started, then it must be excluded from the muram node. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready
My RCCR=0x1, meaning the first 512B is for microcode. So the data and the TxBD should really be starting at 0xfa202200? Then my muram data's reg should be 0x200 ?? What size shall I specify? After the muram data's reg is changed to 0x200 0x1a00, the cpm_uart driver works properly and the kernel messages are printed on the serial port. The muram node is supposed to show the portions of DPRAM that are usable by the OS. If some portion has been taken up by microcode (or anything else not under the OS's control) before the OS has started, then it must be excluded from the muram node. It would be nicer that the initialization code could query the RCCR value and adjust the base address. It took me quite a while to understand the design. Without your help it could take much much longer. So thanks a lot for your help. My project hasn't been done yet, so I may bother you again. :) Thanks again, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready
The problem is that after/when the kernel switches to the real console from the boot console, printk() calls cpm_uart_console_write() to print the first (?) message using the cpm_uart driver. But the transmitter buffer never becomes ready. It's shown below with the gdb session. Program received signal SIGSTOP, Stopped (signal). 0xc00f3510 in cpm_uart_console_write (co=value optimized out, s=0xc017703e console [ttyCPM0] enabled, bootconsole disabled\n, count=0x30) at /home/code/linux-2.6.33.5/arch/powerpc/include/asm/io.h:154 (gdb) next (gdb) x/4h bdbase 0xfddfa020: 0x 0x 0x 0x (gdb) Why would the TxBD be filled with all 0xF? Would it be possible that the bdbase actually points somewhere else other than the TxBD? The virtual address 0xfddfa000 is mapped to 0xfa202000. I suspect that the TxBD of my MPC870 may not start at 0xfa202020. I notice that for adder875, ep88xc and mpc885ads, the muram data's reg = 0 0x1c00 but for mgsuvd, its reg = 0x800 0x1800. How does the kernel use muram for 885 family SoCs? How much muram should be reserved for data? My RCCR=0x1, meaning the first 512B is for microcode. So the data and the TxBD should really be starting at 0xfa202200? Then my muram data's reg should be 0x200 ?? What size shall I specify? Scott, you instructed (http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/083788.html) me to change the buffer address to 0xfa203fb8 from 0xfa202008 for the bootwrapper's cpm-serial driver, assuming reg=0 0x1c00. If I need to change to the reg not starting at 0x0, how should I accordingly change this buffer address? Thanks a lot, -Shawn. I went back to 2.4.18 kernel and noticed that the ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
cpm_uart_console_write() stuck in waiting for transmitter fifo ready
Hi Gurus, Please give me some hints and directions to debug this problem. I've been scratching my head for quite a while. The problem is that after/when the kernel switches to the real console from the boot console, printk() calls cpm_uart_console_write() to print the first (?) message using the cpm_uart driver. But the transmitter buffer never becomes ready. It's shown below with the gdb session. Program received signal SIGSTOP, Stopped (signal). 0xc00f3510 in cpm_uart_console_write (co=value optimized out, s=0xc017703e console [ttyCPM0] enabled, bootconsole disabled\n, count=0x30) at /home/code/linux-2.6.33.5/arch/powerpc/include/asm/io.h:154 (gdb) next (gdb) x/4h bdbase 0xfddfa020: 0x 0x 0x 0x (gdb) Why would the TxBD be filled with all 0xF? Would it be possible that the bdbase actually points somewhere else other than the TxBD? The kernel boot messages are copied below. My target is MPC870, using SMC1 as UART. I'm porting the kernel based on adder875 board. = bootm 100 ## Booting image at 0100 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:706700 Bytes = 690.1 kB Load Address: 0040 Entry Point: 00400554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0040 (sp: 0x07d1cbd0) Allocating 0x186be5 bytes for kernel ... gunzipping (0x - 0x0040c000:0x005c1b78)...done 0x173b10 bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x5ce300 Probing machine type ... My MPC870 ... match ! id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit Using My MPC870 machine description Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.2.2) #17 Wed Jul 14 01:24:03 PDT 2010 bootconsole [udbg0] enabled setup_arch: bootmem arch: exit Top of RAM: 0x800, Total RAM: 0x800 Memory hole size: 0MB Zone PFN ranges: DMA 0x - 0x8000 Normal 0x8000 - 0x8000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x8000 On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c016b5b0, node_mem_map c0189000 DMA zone: 256 pages used for memmap DMA zone: 0 pages reserved DMA zone: 32512 pages, LIFO batch:7 MMU: Allocated 72 bytes of context maps for 16 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/ram PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128096k/131072k available (1416k kernel code, 2836k reserved, 72k data, 74k bss, 76k init) Kernel virtual memory layout: * 0xfffdf000..0xf000 : fixmap * 0xfde0..0xfe00 : consistent mem * 0xfddfa000..0xfde0 : early ioremap * 0xc900..0xfddfa000 : vmalloc ioremap SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:512 nr_irqs:512 irq: Allocated host of type 2 @0xc7804000 irq: irq_create_mapping(0xc7804000, 0x5) irq: - using host @c7804000 alloc irq_desc for 16 on node 0 alloc kstat_irqs on node 0 irq: irq 5 on host /s...@fa20/interrupt-control...@0 mapped to virtual irq 16 irq: Allocated host of type 2 @0xc7804200 irq: irq_create_mapping(0xc7804200, 0x0) irq: - using host @c7804200 alloc irq_desc for 17 on node 0 alloc kstat_irqs on node 0 irq: irq 0 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 17 Decrementer Frequency = 0x7270e0 irq: irq_create_mapping(0xc7804000, 0xf) irq: - using host @c7804000 alloc irq_desc for 18 on node 0 alloc kstat_irqs on node 0 irq: irq 15 on host /s...@fa20/interrupt-control...@0 mapped to virtual irq 18 time_init: decrementer frequency = 7.50 MHz time_init: processor frequency = 120.00 MHz clocksource: timebase mult[2155] shift[22] registered clockevent: decrementer mult[1eb851e] shift[32] cpu[0] irq: irq_create_mapping(0xc7804200, 0x4) irq: - using host @c7804200 alloc irq_desc for 19 on node 0 alloc kstat_irqs on node 0 irq: irq 4 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 1� Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
