Set Ethernet Rate
James Westwell
card. We are using VxWorks 5.5.1 for development. Problem we have is that
both cards are autonegotiating to 100BaseT (both boards can support this)
our problem is that the cabling between the boards does not. We have found
that running at10BaseT we have no issue so have forced it there by sticking
a 10BaseT hub in the path. We have no control over the wiring between the
boards in the production environment and we can't fit in the the hub. Is
there a way for one of the boards be hard setto 10BaseT and ignore or not
auto negotiate? We have looked at the configNet.h for AITech board but
didn't see an obvious place to do this.
--
JWIII
nois...@gmail.com
wrote:
This is not a VxWorks issue. This is an ethernet issue. Unfortunately,
the exact method for solving the problem depends a little on just what
ethernet controllers you're using, and you have conveniently neglected
to describe your hardware in enough detail for us to easily discern
what they are.
By the way, you are not using a "Motorola PPC 5107." You're using an
MVME5107 _board_. Your description gives the mistaken impression that
"5107" is the CPU type: I spent a couple of minutes scratching my head
before I realized what you meant. Unfortunately, I don't know off the
top of my head just which PowerPC processor is on this board, or what
I/O devices (and, consequently, which ethernet controller) it uses.
There's a couple of different boards in the mv5100 it seems, and they
aren't all the same.
As for the "AITECH C103," from what I can find, that board has three
ethernet ports: one gigE which is apparently PCI, and two 10/100 ports
in the Discovery I/O controller. The documentation I found doesn't
explain just which Discovery chip is on the board though (there are
several in the family).
Oh, and I have no idea what "and we can't fit in the the hub" means.
In VxWorks 5.5.1, there is no common API for getting/setting ethernet
media parameters (speed, duplex mode). How it's done, or whether it's
even done at all, varies depending on which driver you're using and
how much functionality the driver developer decided to include in it.
And which driver you're using depends on what ethernet controller you
have.
Another important consideration is whether or not you have the source
for the drivers. If the BSP uses drivers that ship with VxWorks, then
you may have them, since I think you can install the source for the
files in target/src/drv/end off the CD (other source may require a
special source code license from Wind River). If the drivers are
supplied by the board vendors, then you may have a problem: very often
the only give you object code.
Forgetting VxWorks for a moment, solving your problem requires being
able to read/write the management registers on the PHY (transceiver)
connected to your ethernet controller. Typically, a driver will have
mdioRead()/mdioWrite() or miiRead()/miiWrite() methods for this
purpose.
Assuming you can find a way to access the PHY, there are two ways to
solve the problem you're having: either program the PHY to turn off
autonegotiation entirely, or leave autonegotiation on but program the
PHY so that it only advertises certain modes to its link partner.
If you're going to turn off autoneg entirely, you need to update the
control register (register 0) to clear the autoneg enable bit, and
clear the speed and duplex bits as well. This should force the PHY to
10Mbps half duplex. NOTE: you _MUST_ use half-duplex if you use this
approach!!! If autonegotiation is disabled, forcing full duplex mode
is the wrong thing to do: if plug the target into a switch, the switch
will still try to autoneg, but it will fail and fall back to half
duplex mode (on the assumption that if there's no autoneg support, the
link partner is a legacy device that doesn't support full duplex in
the first place). If you force full duplex on the target side, there
will be a duplex mismatch: the target will be in full duplex and the
switch will be in half duplex. The result will be tons of corrupted
frames and awful TCP performance.
I recommend instead that you leave autoneg on, but change the autoneg
advertisement register (register 4) so that the PHY does not advertise
100Mbps modes. By default, most 10/100 PHYs will advertise all modes:
10Mbps half duplex, 10Mbps full duplex, 100Mbps half duplex and
100Mbps full duplex. If you clear the 100FD and 100HD bits in the
autoneg advertisement register, the device will only advertise 10HD
and 10FD capabilities to its link partner. The autoneg process
requires that both link partners exchange capability information and
select the best common denominator between them. Since they usually
advertise 100Mbps ability, this is why the resolve a 100Mbps link by
default. (Unfortunately, the PHYs aren't smart enough to detect cable
quality too.) After clearing the two bits in the autoneg advertisement
register, you should also clear and set the 'restart autonegotiation'
bit in the control register to force the two link partners to resolve
the link correctly with the new capabilities. The reason I recommend
this approach is that it allows you to potentially resolve a 10Mbps
full duplex link where possible, which will give you a little better
throughput than 10Mbps half duplex (due to collisions on the half
duplex link, you may only get 800-900Mbps second TCP throughput,
whereas with a full duplex link you will consistently get 1.2MB/sec).
Again, this may be tricky without having the driver source code. Many
older VxWorks END drivers (including those written by Wind River and
those produced by 3rd parties) do a very poor job of link management:
they only check for link autonegotiation completion and resolution
status at startup and then never check the link again. This is a
problem, because the driver must program the ethernet controller's
duplex setting (and in some cases its speed too) to match that of the
PHY: this means that you must somehow check for link state changes in
case the user unplugs the cable from, say, a 100Mbps full duplex
switch port and replugs it to a 10Mbps half duplex port on the fly.
The implication for you is that you must set up the PHY very early on
during driver startup: if you try to change the link state later, you
will need to be sure the MAC will be updated to match the PHY, and if
the logic to do that is locked inside an object code module for which
you have no source code, that could be hard.
In rare cases, drivers will allow you to specify flags that affect
their link negotiation logic via their sysFooEnd.c files (or some
other file in the BSP). If this is the case, you should try to alter
the autoneg logic as I recommended above: let it autoneg, but don't
let it advertise 100Mbps modes.
-Bill
James Westwell
Thanks for the quick repsonsem your assumptions of both board are
correct its an MVME5107 all the boards are fundamentally the same the
dash numbers ususlly represent amount of memory on the board. We are
using the ethernet controllers provided by the MV51xx BSPs for those
boards. BAsed on the info you provided and checked our BSPs we have
Intel 82557 Ethernet network interface drivers for both boards and it
appears that we have full source code. Looking at the one for the
AITECH I have found an area that will revert to 10MBS Half Duplex on
an PHY_AUTO_FAIL. I intend to just use that setting and ignore the AUTO
setting.
Again thanks for the help
I will let you know how it goes.
sybe
>
> - Show quoted text -
Dear all,
I'm sorry if I re-write something but I've not enough time to read the
very very long post. But for your problem it seems to me you can avoid
to advertise 100Mb mode before starting autonegociation. (just a flag
is the phy reg). May be you should add a setting in your application
(default mode :10Base T, but for correct installation, wiring...
100base tx available).
Some PHY component have testing function. You can read the datasheet
to know what it can do (extended features).
If you need more details on how to advertise or not a mode
(10/100/1000, full or hal duplex) don't hesitate to post again (in
this forum).
regards.
James Westwell
Ultimately we had AITech modify their BSP to get this to work for us.
Anything we attempted either didn't work or caused problems elsewhere