MVME162/167 BSP Networking

Sun Nov 20 22:07:07 UTC 2011

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5218 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20111120/2ebdae0c/attachment.bin>