MVME162/167 BSP Networking

Sun Nov 20 22:22:26 UTC 2011

Victor, 

I wrote the initial driver for 82596CA for SCG (pSOS). Check with Wind River guys. They have that driver. Good luck.
I don't know off hand how to identify the step. If I find that, I will post here.

Subodh

-----Original Message-----
From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] On Behalf Of Hoover, Victor P CTR NAVAIR, AIR 4.1.3.3
Sent: Sunday, November 20, 2011 5:07 PM
To: rtems-users at rtems.org
Subject: MVME162/167 BSP Networking

Okay, I'm currently trying to get the network module working for the
MVME162 BSP (it uses the module from the MVME167 BSP).  I was going to ask if anyone else is using the network interfaces for these BSPs.  Based on what I've run into so far, I don't think it's likely.

Background

The network chip on these boards is an Intel 82596CA chip.  Since the chip was made by Intel, it was originally all Little Endian architecture.

For the A1 stepping of the chip, support was added for Big Endian byte ordering.

The B stepping removed some of this support but modified the chip so that in Linear Mode all 32 bit address pointers were treated as Big Endian. 
However, there was a caveat to that; the upper and lower halves of the address were in Big Endian byte order however the two halves themselves were swapped from the normal Big Endian byte order (on a Big Endian machine you have to swap the words around for any addresses that the 82596 will use).

The C stepping added a New Enhanced Big Endian mode where the 32 bit address pointers were in true Big Endian mode.  However, the address of the System Control Block that is written to the control port still needs the two halves of its address swapped before writing to the 82596 port.

All I have to work from is 77 page document on the 82596CA C step version of the chip dated October 1995.  This document keeps referring me to the "32-bit LAN Component's User's Manual".  This I can't seem to find online; the only versions seem to be as books that the developers needed to buy (I did see one or two at Amazon and on EBay; I'll be trying to track a copy down after Thanksgiving).

One thing I don't see is how to identify the stepping number of any specific chip.  I've never worked with this chip before so I'm not up on its history.  Does the 'C' in the 82596CA part number indicate that it's a C stepping or is there some other indicator?

Progress to Date

I started out by just compiling in the network support to see what would happen.  My first program displayed a message, initialized the network, displayed a message, called rtems_task_wake_after(100), printed a message and then called rtems_shutdown_executive(0).

Initially the board kept hanging during the network initialization.  I went into the network module, enabled a lot of debug display macros and tried again.

The output from the printk calls was displaying bad data and in some cases not displaying at all.  I assumed that I had problems with the printk support I had just added to the 162 BSP.  I went back into that code and tried debugging it.  I eventually reached the point where I had the system console going out to the second serial port and all printk messages were going to the first port via calls to 162bug.  This didn't fix anything.
I switched back all of my console code and started taking a look at the network module.

As noted above in the background section, the 82596 did not originally support Big Endian addresses and when it was initially added didn't do it quite correctly.  Examining the network code showed that it did have support for the address low/high word swaps.  My concern was that there may have been some bugs and something didn't get swapped or got swapped when it shouldn't have.

The first thing I did was added a #define macro to the network code to identify whether or not the chip was a C step chip.  I used this flag to enable/disable the word swap code and to set the New Enhanced Big Endian flag in the SYSBUS configuration byte.  When I tested this version I managed to make it all the way through the network initialization (although there are some polled command tests in the initialization that all time out; something's still not right).

I was able to display my route information and network statistics after the initialization completed.  This indicates to me that there are issues with were and how the word swapping is being done that have to be researched and fixed.

However, there is one additional problem.  After initializing the network subsystem my call to rtems_task_wake_after(100) hangs and never returns. 
There must still be some addressing issues with the network code that's corrupting memory.

Further examination of the code showed that a couple of the structure definitions had been built with some words out of order.  I've been trying to sort these out by using the 82596 docs, an MVME16X Linux network driver and whatever internet chatter I can Google.  Ultimately I may disassemble the 162Bug code to see what it actually does.

I've built a simple application that initializes the network, opens a socket, binds the socket, calls listen and then waits for an accept.
Unfortunately the board doesn't respond to pings or to a telnet connection to the bound port.

Another strange thing is that the debugging code shows that when I call the accept function, the network code attempts to send a packet from the boards MAC address to a destination MAC of ff:ff:ff:ff:ff:ff.  Something is still backwards.

*sigh*

I'll be off the grid until the 29th but I will be getting back to all of this at that point.

If anyone has done any work on the network driver for these BSPs, actually has one working or has any suggestions, I'd like to hear back from you.

Thanks.

	- Vic Hoover