* mpc8270 and fs_enet
@ 2009-01-29 22:41 James Black
2009-01-29 23:05 ` Scott Wood
0 siblings, 1 reply; 4+ messages in thread
From: James Black @ 2009-01-29 22:41 UTC (permalink / raw)
To: linuxppc-dev
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-------------------------------------------------------------------------
[root@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 5c00002a 0fa293c2 ...X.)8.\..*....
0e6e2130 : 5c00005a 0c42c202 5c00005a 0c42c802 \..Z.B..\..Z.B..
0e6e2140 : 1c00005a 0c42c602 5c00002a 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mpc8270 and fs_enet
2009-01-29 22:41 mpc8270 and fs_enet James Black
@ 2009-01-29 23:05 ` Scott Wood
2009-01-29 23:27 ` James Black
0 siblings, 1 reply; 4+ messages in thread
From: Scott Wood @ 2009-01-29 23:05 UTC (permalink / raw)
To: James Black; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mpc8270 and fs_enet
2009-01-29 23:05 ` Scott Wood
@ 2009-01-29 23:27 ` James Black
2009-02-19 16:18 ` James Black
0 siblings, 1 reply; 4+ messages in thread
From: James Black @ 2009-01-29 23:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
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 Parameters 0x8400 256
> FCC1 Temp buffer 0x9000 128
> SCC1 Parameters 0x8000 256
> SCC2 Parameters 0x8100 256
> SCC4 Parameters 0x8300 256
> SMC1 Parameters 0x0000 64
> SMC2 Parameters 0x0040 64
> SCC1 Buff Desc 0x0080 64
> SCC2 Buff Desc 0x00C0 64
> SCC4 Buff Desc 0x0100 64
> SPI Param Pointer 0x89FC 2
> SPI Parameters 0x9000 76
> MCC2 Global Param 0x8800 128
> MCC2 HDLC Param 0x2000 8192
> MCC2 Extra Param 0xB000 1024
On Thu, Jan 29, 2009 at 4:05 PM, Scott Wood <scottwood@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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mpc8270 and fs_enet
2009-01-29 23:27 ` James Black
@ 2009-02-19 16:18 ` James Black
0 siblings, 0 replies; 4+ messages in thread
From: James Black @ 2009-02-19 16:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
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 <jblack547@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 Parameters 0x8400 256
>> FCC1 Temp buffer 0x9000 128
>> SCC1 Parameters 0x8000 256
>> SCC2 Parameters 0x8100 256
>> SCC4 Parameters 0x8300 256
>> SMC1 Parameters 0x0000 64
>> SMC2 Parameters 0x0040 64
>> SCC1 Buff Desc 0x0080 64
>> SCC2 Buff Desc 0x00C0 64
>> SCC4 Buff Desc 0x0100 64
>> SPI Param Pointer 0x89FC 2
>> SPI Parameters 0x9000 76
>> MCC2 Global Param 0x8800 128
>> MCC2 HDLC Param 0x2000 8192
>> MCC2 Extra Param 0xB000 1024
>
>
>
> On Thu, Jan 29, 2009 at 4:05 PM, Scott Wood <scottwood@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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-02-19 16:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-29 22:41 mpc8270 and fs_enet James Black
2009-01-29 23:05 ` Scott Wood
2009-01-29 23:27 ` James Black
2009-02-19 16:18 ` James Black
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).