Re: CPM UART on MPC8270
I couldn't get the echo /dev/xxx to work. I had to write a small app
that opened the device and write and read characters for testing.
Start there and you may find it is actually working.
JB
On Wed, Jun 9, 2010 at 8:37 AM, Martyn Welch martyn.we...@ge.com wrote:
Hi All,
I'm attempting to get an SCC port on an MPC8270 working with Linux. I'm
not overly familiar with the CPM and am having a bit of trouble.
Linux is booting natively on the 8270. I have access to the 8270 via a
set of PCI windows from a second core (includes one setup over the main
memory and one over the IMMR) and SMC1 is up and working with a console.
The SCCs seem to be detected correctly at boot:
f011a80.serial: ttyCPM0 at MMIO 0xc3014a80 (irq = 16) is a CPM UART
f011a00.serial: ttyCPM1 at MMIO 0xc3018a00 (irq = 40) is a CPM UART
f011a20.serial: ttyCPM2 at MMIO 0xc3020a20 (irq = 41) is a CPM UART
f011a40.serial: ttyCPM3 at MMIO 0xc3028a40 (irq = 42) is a CPM UART
With the DTS reading:
smc1: ser...@11a80 {
device_type = serial;
compatible = fsl,mpc8270-smc-uart,
fsl,cpm2-smc-uart;
reg = 0x11a80 0x20 0x87fc 2;
interrupts = 4 8;
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 0x1d00;
};
scc1: ser...@11a00 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a00 0x20 0x8000 0x100;
interrupts = 40 8;
interrupt-parent = PIC;
fsl,cpm-brg = 3;
fsl,cpm-command = 0x80;
};
scc2: ser...@11a20 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a20 0x20 0x8100 0x100;
interrupts = 41 8;
interrupt-parent = PIC;
fsl,cpm-brg = 6;
fsl,cpm-command = 0x4a0;
};
scc3: ser...@11a40 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a40 0x20 0x8200 0x100;
interrupts = 42 8;
interrupt-parent = PIC;
fsl,cpm-brg = 1;
fsl,cpm-command = 0x8c0;
};
I believe that I have the pins setup correctly and the BRGs connected
correctly in the setup_arch function.
At the moment I have SCC3 wired out. If I attempt to echo data out of
the SCC (echo Hello /dev/ttyCPM3) I get the prompt sits waiting.
Rebooting and turning on the debug yields the following output on the
console (but nothing out of the SCC port):
CPM uart[3]:startup
Interrupt attached
CPM uart[3]:set_termios
CPM uart[3]:start tx
CPM uart[3]:stop tx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:stop rx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:shutdown
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
...
It seemed to be waiting for ready bit of the Transmit Buffer Descriptor
to be cleared (which it never seems to be), prodding this bit through
the pci window did cause the process to continue, no data out but I did
get back to the prompt on the console.
I'm sure I'm just missing something really basic - can anyone enlighten me?
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square,
Manchester,
E martyn.we...@ge.com | M2 3AB VAT:GB 927559189
___
Linuxppc-dev mailing
kexec for powerpc
Are there efforts in this area or is it already working for powerpc? I cross compiled kexec and tried it on an old kernel with kexec support compiled in. /var # ./kexec -t elf -l zImage.elf get_memory_ranges(): Unsupported platform Could not get memory layout Any comments? -- Jim Black ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kexec for powerpc
powerpc32 for processors like the freescale 82xx, 83xx machines. Thanks, JB On Thu, Nov 12, 2009 at 4:31 PM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Nov 12, 2009 at 04:08:07PM -0700, James Black wrote: Are there efforts in this area or is it already working for powerpc? I cross compiled kexec and tried it on an old kernel with kexec support compiled in. 'powerpc' is a bit too vague. It works on lots of ppc64 machines already. What class of hardware are you talking about? josh -- Jim Black Senior Software Engineer Aztek Networks, Inc. 2477 55th Street, Suite 202 Boulder, CO 80301 www.azteknetworks.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc8270 and fs_enet
Turns out the problem was with the PSDMR register. We had a cas latency of 3 and the memory stick required 2. Also, the MPTPR register had a value of 0x1e00 and we changed it to 0x1f00. We use ECC memory sticks. Those 2 changes got rid of the error in the buffer descriptor ready/empty bits. The interesting thing was that our SDRAM memory test passes and there are no errors logged in the TESCR1, TESCR2 or the SDSR registers. Strange problem, and difficult to find. Thought I'd get this out for future reference. On Thu, Jan 29, 2009 at 4:27 PM, James Black jblack...@gmail.com wrote: I thought the same thing. So I verified the memory map. We did have a conflict with the SPI stomping the FCC temp so we moved that. An interesting note is that we drop packets from time to time on the MCC as well due to a similar ready bit problem. The CPM never clears the bit. -- IMMR memory map -- FCC1 Parameters0x8400256 FCC1 Temp buffer 0x9000128 SCC1 Parameters0x8000256 SCC2 Parameters0x8100256 SCC4 Parameters0x8300256 SMC1 Parameters0x 64 SMC2 Parameters0x0040 64 SCC1 Buff Desc 0x0080 64 SCC2 Buff Desc 0x00C0 64 SCC4 Buff Desc 0x0100 64 SPI Param Pointer 0x89FC 2 SPI Parameters0x9000 76 MCC2 Global Param 0x8800128 MCC2 HDLC Param0x2000 8192 MCC2 Extra Param 0xB000 1024 On Thu, Jan 29, 2009 at 4:05 PM, Scott Wood scottw...@freescale.com wrote: James Black wrote: I've got an mpc8270 running the fs_enet v1.0 driver and we are having problems with randomly corrupted tx buffer descriptor ready bits. The CPM never clears the bit. This is a 2.6.19.2 kernel. We have the same kernel with the 8260_io driver (kernel is from the denx ELDK4.2) running on the mpc8250 that works perfect. Is it possible that some other CPM block is configured to use the same DPRAM area that the descriptors are in? -Scott -- Jim Black Senior Software Engineer Aztek Networks, Inc. 2477 55th Street, Suite 202 Boulder, CO 80301 www.azteknetworks.com -- Jim Black Senior Software Engineer Aztek Networks, Inc. 2477 55th Street, Suite 202 Boulder, CO 80301 www.azteknetworks.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mpc8270 and fs_enet
I've got an mpc8270 running the fs_enet v1.0 driver and we are having problems with randomly corrupted tx buffer descriptor ready bits. The CPM never clears the bit. This is a 2.6.19.2 kernel. We have the same kernel with the 8260_io driver (kernel is from the denx ELDK4.2) running on the mpc8250 that works perfect. I've been through the clock tree in u-boot and the kernel with both processors and they are configured corrected. I've checked all the pins and they are configured correctly. I back ported some spin_lock tx issues from 2.6.27.xx and still it is not working on the mpc8270. These are the tests I am failing. nmap -sS -v target ip mpc8270 Target Output ~ # fs_enet: eth0 FS_ENET ERROR(s) 0xe fs_enet: eth0 FS_ENET ERROR(s) 0xe fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0x4 fs_enet: eth0 FS_ENET ERROR(s) 0x4 fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0x4 fs_enet: eth0 FS_ENET ERROR(s) 0x4 Host output- [r...@localhost linux]# nmap -sS -v 172.22.250.113 Starting Nmap 4.52 ( http://insecure.org ) at 2009-01-29 14:59 MST Initiating Ping Scan at 14:59 Scanning 172.22.250.113 [2 ports] Completed Ping Scan at 14:59, 0.00s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 14:59 Completed Parallel DNS resolution of 1 host. at 14:59, 0.27s elapsed Initiating SYN Stealth Scan at 14:59 Scanning 172.22.250.113 [1714 ports] Discovered open port 23/tcp on 172.22.250.113 Discovered open port 80/tcp on 172.22.250.113 Discovered open port 21/tcp on 172.22.250.113 eventually times out telnet target ip ftpput -u user name -p password host ip big file big file The telnet session hangs. Below is a BDI dump of the buffer descriptors for the tx side. Notice the BDs with a leading 0xd such as the ones at address 0x0e6e2100 and 0x0efe21d0. I can go in and clear the ready bit by hand with the BDI and everything starts working again without a reboot. The BDs on the rx side look text book perfect. 0e6e2100 : dc0005ea 0df8709e 1c0005ea 0df5f89e ..p. 0e6e2110 : 5c0005ea 0e29e89e 5c0005ea 0e29609e \)..\)`. 0e6e2120 : 1c000358 0e29389e 5c2a 0fa293c2 ...X.)8.\..* 0e6e2130 : 5c5a 0c42c202 5c5a 0c42c802 \..Z.B..\..Z.B.. 0e6e2140 : 1c5a 0c42c602 5c2a 0fa292c2 ...Z.B..\..* 0e6e2150 : 5c0005ea 0df8909e 1c0005ea 0df8c09e \... 0e6e2160 : 5c0005ea 0e29a09e 1c0005ea 0e29a89e \)...).. 0e6e2170 : 5c0005ea 0e29989e 5c0005ea 0e29189e \)..\).. 0e6e2180 : 1c0005ea 0df8989e 5c0005ea 0e29789e \)x. 0e6e2190 : 1c0005ea 0df8189e 5c0005ea 0df8109e \... 0e6e21a0 : 1c0005ea 0d86c09e 1c0005ea 0d86c89e 0e6e21b0 : 5c0005ea 0e29d89e 1c0005ea 0e29d09e \)...).. 0e6e21c0 : 5c0005ea 0e2bd89e 5c0005ea 0e2bd09e \+..\+.. 0e6e21d0 : dc0005ea 0e29289e 5c0005ea 0df8689e .)(.\.h. 0e6e21e0 : 1c0005ea 0e29f09e 5c0005ea 0e29909e .)..\).. 0e6e21f0 : dc0005ea 0df8609e 3c0005ea 0df6109e ..` Anyone have any experience about what could make such a difference between the two processors? -- Jim Black Senior Software Engineer Aztek Networks, Inc. 2477 55th Street, Suite 202 Boulder, CO 80301 www.azteknetworks.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8270 and fs_enet
I thought the same thing. So I verified the memory map. We did have a conflict with the SPI stomping the FCC temp so we moved that. An interesting note is that we drop packets from time to time on the MCC as well due to a similar ready bit problem. The CPM never clears the bit. -- IMMR memory map -- FCC1 Parameters0x8400256 FCC1 Temp buffer 0x9000128 SCC1 Parameters0x8000256 SCC2 Parameters0x8100256 SCC4 Parameters0x8300256 SMC1 Parameters0x 64 SMC2 Parameters0x0040 64 SCC1 Buff Desc 0x0080 64 SCC2 Buff Desc 0x00C0 64 SCC4 Buff Desc 0x0100 64 SPI Param Pointer 0x89FC 2 SPI Parameters0x9000 76 MCC2 Global Param 0x8800128 MCC2 HDLC Param0x2000 8192 MCC2 Extra Param 0xB000 1024 On Thu, Jan 29, 2009 at 4:05 PM, Scott Wood scottw...@freescale.com wrote: James Black wrote: I've got an mpc8270 running the fs_enet v1.0 driver and we are having problems with randomly corrupted tx buffer descriptor ready bits. The CPM never clears the bit. This is a 2.6.19.2 kernel. We have the same kernel with the 8260_io driver (kernel is from the denx ELDK4.2) running on the mpc8250 that works perfect. Is it possible that some other CPM block is configured to use the same DPRAM area that the descriptors are in? -Scott -- Jim Black Senior Software Engineer Aztek Networks, Inc. 2477 55th Street, Suite 202 Boulder, CO 80301 www.azteknetworks.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
