Re: VxWorks 6.6 - Ethernet interface driver support

On Sep 17, 8:45 am, ulrik <u.wilh...@xxxxxx> wrote:
On Sep 16, 8:45 pm, noiset...@xxxxxxxxx wrote:



On Sep 16, 3:46 am, ulrik <u.wilh...@xxxxxx> wrote:

Dear Readers

I am currently working on the porting of a board system from VxWorks
5.5.1 to VxWorks 6.6. One of the issues is to get DSS Ethernet
interface PMC cards working in conjunction with system/node boards
from CCT, Concurrent Technologies.

So far I have been successful only with the electrical DSS PMC
Ethernet interface cards, deploying the "Intel PRO/1000 VxBus Enhanced
Network Driver" in conjunction with the "Generic PHY driver", both
standard VxWorks 6.6 components.

However, I have the impression that it should be possible to
successfully drive also the optical DSS PMC Ethernet interface cards
with a suitable set of correct configured VxWorks 6.6 standard
components, not having to integrate any driver from DSS.

In the VxWorks 6.6 Workbench help, searching for the keyword TBI, the
following is said:

Generic TBI Driver Support

Many fiber optic controllers use a ten bit interface (TBI) as their
MAC/PHY media connection. The TBI management interface is similar to
that of an ordinary 10/100 copper PHY. However, a TBI PHY supports
only 1000 Mb/s. A MAC driver can be written such that the routines in
the MII bus library (see the reference documentation for miiBus) can
discover the TBI management interface and manage the link just like
that of an ordinary PHY. Most devices that implement TBI use the same
management interface, therefore a genericTbiPhy driver is also
provided to handle these cases.
Unlike the genericPhy driver, the genericTbiPhy driver only attaches
to a MAC driver that reports the correct vendor and device ID values.
The genericTbiPhy.h header defines two values, TBI_ID1 and TBI_ID2. If
a MAC driver's {miiBusRead}( ) method returns these values when a
caller reads the ID registers, the genericTbiPhy driver successfully
attaches to the TBI PHY instance.
The genericTbiPhy driver is included using the INCLUDE_GENERICTBIPHY
component.

I activated the "Generic TBI driver" and/or the "Intel PRO/1000 TBI/
SERDES pseudo driver" components, but the resulting VxWorks image
doesn’t boot with any combination of these components.

Both the electrical and optical PMC card versions from DSS are
equipped with the Intel device 82546EB (PCI device id 0x1010).
However, a distinction between the two card versions can be made by
checking the content of the serial EEPROM (external to the 82546
device), which differs.

Hopefully anyone have an idea what can be wrong!

Many thanks in advance and best regards

Ulrik

The GEI VxBus driver in 6.6 uses a special driver for fiber optic
support. In order to use both copper and fiber optic PRO/1000 cards in
the same image, you need the following components:

INCLUDE_GEI825XX_VXB_END
INCLUDE_MII_BUS
INCLUDE_GENERICPHY
INCLUDE_GEITBIPHY

You do *NOT* need INCLUDE_GENERICTBIPHY.

The GEITBIPHY driver is a pseudo driver designed to attach to the GEI
driver specifically. The PRO/1000 doesn't provide a generic set of TBI
management registers, so using the generic TBI PHY driver would be
cumbersome. Instead the GEI driver exports access to its custom
registers, and there's a custom geiTbiPhy driver designed exclusively
for use with it. The geiTbiPhy driver isn't generally included by
default since most people tend to use copper PRO/1000 cards (scaling
out the fiber optic support saves a little bit of code space).

The GEI driver detects the presence of a fiber optic NIC by checking
to see if the TBIMODE bit is set in the status register. The state of
this bit is controlled by the contents of the EEPROM. For copper
cards, the bit is always clear.

Unfortunately, you have not described your actual problem in detail.
All you said was "the resulting VxWorks image doesn’t boot with any
combination of these components." What do you mean by "doesn't boot?"
Be more specific. Show us an example. You could mean "once I download
the image into the target, it just freezes and I never see any output"
or you could mean "I'm expecting some network connectivity as part of
the boot process, but I'm not getting any." But we can't know for sure
what you mean until you tell us.

If the image does start up, you really ought to do the following:

- Make sure you have INCLUDE_VXBUS_SHOW included in your configuration
- At the shell prompt, do:

-> vxBusShow (1)

- Show us the output. (*ALL* of the output.)

You should see a geiTbi instance for each fiber optic network port. If
you don't, your configuration is wrong.

You should also look at the link indicator LEDs on the ports
themselves. Assuming the ports have live fiber connections, you should
see the link LED light up, and I think it should flash briefly (this
indicates the transceiver was reset during initialization).

I have personally tested the GEI driver with a couple of different
fiber optic PRO/1000 cards, but sadly there are plenty of different
ones out there that I can't get my hands on for testing. I have
successfully used an 82545EM fiber optic card, which is similar enough
to the 82546 in my opinion that it ought to work.

-Bill

Hello Bill

Very many thanks for your detailed and swift response!

The reboot problem turned out to be caused by some log statement that
I had added in the file "/cc/vobs/buildtools/WindRiver/vxworks-6.6/
target/src/hwif/mii/geiTbiPhy.c" (file now reverted to the original
version). I would like to excuse for not telling in the first place
that I had done some code change and through that, as it turned out,
actually caused the reboot problem myself.

The situation that I am now facing is that the system boots and the
optical interfaces are up but not running (checked with command
"ifconfig"), which means that I can't send or receive any traffic over
these interfaces (e.g. by pinging these interfaces).

If you (or someone else) have any further ideas, I would be most
thankful!

Best regards

Ulrik


In my previous message, I said for you to add the INCLUDE_VXBUS_SHOW
component (along with the shell, which you already have) and do
"vxBusShow(1)" so that we could see the target setup. This is
important, because it would confirm that the right drivers are
actually present, and that the GEI driver has actually been able to
figure out that the two fiber ports are actually fiber and attached
the geiTbiPhy driver correctly (instead of genericPhy). Please, do
this like I asked, and show us the results.

Similarly, you should show us the output of the "ifconfig" command so
that we can see for ourselves what it reports. In particular, it would
show just how many interfaces are in the system.

Assuming you do have your image configured correctly, I think the
RUNNING flag may only show up in ifconfig once a good link is
established on the interface. The driver usually makes a callback to
the TCP/IP stack when there's a link up or link down event. If the
flag isn't set on your interface, then maybe there's no link
established. (You can confirm this by unplugging and replugging the
cable on one of the copper ports and using ifconfig to examine the
RUNNING flag in each case.)

You said "the interfaces are up." Does this mean you actually looked
at the link LEDs and saw that they were lit? Also, what kind of device
do you have the ports cabled to? Is it a switch of some kind? Are you
sure the fiber connection is good? Have you tried unplugging and
replugging the fiber? With my 82545EM fiber card, there is only one
LED and it stays dark until the driver loads. Then it flashes to
indicate traffic activity. (The same is true with my 82572 card, which
is a PCIe fiber optic NIC.)

-Bill
.

Relevant Pages

  • Re: VxWorks 6.6 - Ethernet interface driver support
    ... Ethernet interface cards, deploying the "Intel PRO/1000 VxBus Enhanced ... Network Driver" in conjunction with the "Generic PHY driver", ... out the fiber optic support saves a little bit of code space). ...
    (comp.os.vxworks)
  • Re: VxWorks 6.6 - Ethernet interface driver support
    ... Ethernet interface cards, deploying the "Intel PRO/1000 VxBus Enhanced ... Network Driver" in conjunction with the "Generic PHY driver", ... standard VxWorks 6.6 components. ...
    (comp.os.vxworks)
  • Re: newbus questions
    ... I maintain a driver for SAA7134 cards which does the same. ... SAA7134 cards interface with the PC using PCI and have an onboard ... was very specific regarding tuner that must be present on card. ...
    (freebsd-hackers)
  • Re: Tascam US-122 vs. MBox Interfaces
    ... problems seemed to be a conflict with Soundmax cards; ... I didn't even have to install a driver for it and it would ... I still stand by my UA-25 recommendation, ... >>> Tascam Interface is good enough. ...
    (rec.music.makers.guitar.jazz)
  • Re: Linux Firewall/LoadBalancer
    ... The bonding driver originally came from Donald Becker's beowulf patches for ... Build kernel with the bonding driver ... "Bonding driver support" in the "Network device support" section. ... so the bonding driver will automatically load when the bond0 interface is ...
    (Security-Basics)
Loading