[U-Boot] Fw: TFTP fails when using network switch
Hi Everyone,
I am having an interesting problem with am m5282Lite Dev Kit. I had done all of the previous development work by connection the card directly to a spare ethernet card in my PC via a cross-over cable. This worked just fine and the tftp download was very fast. Now I have run a long Ethernet cable and can download the uClinux using u-boot, but the hub is 10Mbit. I get some "bad len" errors but eventually (seems to take a long time) the download completes and uClinux boots. I then tried to hook up a spare 100MBit switch i had running one Ethernet cable to the pC (tftp server) and one to the coldfire board (now using regular network cable) but the tftp just times out. The funny thing is i seem to be able to ping the coldfire from the PC side but not the PC from the coldfire side. Does anyone have an idea of what is wrong? Thanks in advance!
Alex
Hello Alex,
2009/1/6 Loren A. Linden Levy Alex.Lindenlevy@colorado.edu:
Hi Everyone,
I am having an interesting problem with am m5282Lite Dev Kit. I had done all of the previous development work by connection the card directly to a spare ethernet card in my PC via a cross-over cable. This worked just fine and the tftp download was very fast.
Seems network controller is working properly, so I would suggest to look into the settings.
Now I have run a long Ethernet cable and can download the uClinux using u-boot, but the hub is 10Mbit. I get some "bad len" errors but eventually (seems to take a long time) the download completes and uClinux boots. I then tried to hook up a spare 100MBit switch i had running one Ethernet cable to the pC (tftp server) and one to the coldfire board (now using regular network cable) but the tftp just times out. The funny thing is i seem to be able to ping the coldfire from the PC side but not the PC from the coldfire side. Does anyone have an idea of what is wrong? Thanks in advance!
The first things coming to my mind are: * conflicting IP-addresses or MAC addresses? * mismatch u-boot IP on the subnet? * missing netmask setting in U-boot environment?
Or else maybe try wireshark to detect what goes wrong exactly.
Kind regards,
Remy
tis 2009-01-06 klockan 08:41 +0100 skrev Remy Bohmer:
Hello Alex,
2009/1/6 Loren A. Linden Levy Alex.Lindenlevy@colorado.edu:
Hi Everyone,
I am having an interesting problem with am m5282Lite Dev Kit. I had done all of the previous development work by connection the card directly to a spare ethernet card in my PC via a cross-over cable. This worked just fine and the tftp download was very fast.
Seems network controller is working properly, so I would suggest to look into the settings.
I have some customers that has seen similar problems with "cheap" hubs/switches.
It was tracked down to the autoconfiguration of the Ethernet PHY, so one of the PHYs ended up in 100 Mbps Half Duplex (think that was the switch) while the other PHY ended up in 100 MBps Full Duplex.
Might be worth investigating.
Best Regards Ulf Samuelsson
Now I have run a long Ethernet cable and can download the uClinux using u-boot, but the hub is 10Mbit. I get some "bad len" errors but eventually (seems to take a long time) the download completes and uClinux boots. I then tried to hook up a spare 100MBit switch i had running one Ethernet cable to the pC (tftp server) and one to the coldfire board (now using regular network cable) but the tftp just times out. The funny thing is i seem to be able to ping the coldfire from the PC side but not the PC from the coldfire side. Does anyone have an idea of what is wrong? Thanks in advance!
The first things coming to my mind are:
- conflicting IP-addresses or MAC addresses?
- mismatch u-boot IP on the subnet?
- missing netmask setting in U-boot environment?
Or else maybe try wireshark to detect what goes wrong exactly.
Kind regards,
Remy _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Ulf Samuelsson,
In message 1231282371.32308.276.camel@elrond.atmel.com you wrote:
It was tracked down to the autoconfiguration of the Ethernet PHY, so one of the PHYs ended up in 100 Mbps Half Duplex (think that was the switch) while the other PHY ended up in 100 MBps Full Duplex.
That would most probably be a bug in the U-Boot ethernet driver, then.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Ulf Samuelsson,
In message 1231282371.32308.276.camel@elrond.atmel.com you wrote:
It was tracked down to the autoconfiguration of the Ethernet PHY, so one of the PHYs ended up in 100 Mbps Half Duplex (think that was the switch) while the other PHY ended up in 100 MBps Full Duplex.
That would most probably be a bug in the U-Boot ethernet driver, then.
Best regards,
Wolfgang Denk
If auto-negotiation fails, the default is half duplex (10 or 100 - the speed can be discovered independent of the autonegotiation by the encoding).
Ulf's recollection that the switch was half duplex would indicate that the cheap switch did not autonegotiate properly, but u-boot did. This could be a u-boot bug (not setting up the negotiation properly), but more likely would be a switch problem (not handling the u-boot auto-neg options properly).
gvb
Hi All,
Is there something like ethtool in U-boot that I can use to see what the network negotiated too. This is a fairly cheap netgear switch so I do not have any diagnostics on it.
I will also have a look with wireshark when i get back to the lab to see if I can identify what is happening.
Alex
On Wed, 07 Jan 2009 07:52:58 -0500 Jerry Van Baren gerald.vanbaren@ge.com wrote:
Wolfgang Denk wrote:
Dear Ulf Samuelsson,
In message 1231282371.32308.276.camel@elrond.atmel.com you wrote:
It was tracked down to the autoconfiguration of the Ethernet PHY, so one of the PHYs ended up in 100 Mbps Half Duplex (think that was the switch) while the other PHY ended up in 100 MBps Full Duplex.
That would most probably be a bug in the U-Boot ethernet driver, then.
Best regards,
Wolfgang Denk
If auto-negotiation fails, the default is half duplex (10 or 100 - the speed can be discovered independent of the autonegotiation by the encoding).
Ulf's recollection that the switch was half duplex would indicate that the cheap switch did not autonegotiate properly, but u-boot did. This could be a u-boot bug (not setting up the negotiation properly), but more likely would be a switch problem (not handling the u-boot auto-neg options properly).
gvb
Loren A. Linden Levy wrote:
Hi All,
Is there something like ethtool in U-boot that I can use to see what the network negotiated too. This is a fairly cheap netgear switch so I do not have any diagnostics on it.
I will also have a look with wireshark when i get back to the lab to see if I can identify what is happening.
Alex
I don't have the 802.3 spec in front of me, but IIRC there are a standard set of registers for autonegotiation status that display things like your PHY's capabilities, as well as those of its peer.
As others have pointed out, you can use the MII commands to do all sorts of things, such as running an AN cycle and looking at the results, and also turning off AN and forcing speed/duplex values.
I've had bad luck with cheap switches sometimes too, but ultimately this stuff is deterministic and there's a chance you can make our drivers more robust.
regards, Ben
Loren A. Linden Levy wrote:
On Wed, 07 Jan 2009 07:52:58 -0500 Jerry Van Baren gerald.vanbaren@ge.com wrote:
Wolfgang Denk wrote:
Dear Ulf Samuelsson,
In message 1231282371.32308.276.camel@elrond.atmel.com you wrote:
It was tracked down to the autoconfiguration of the Ethernet PHY, so one of the PHYs ended up in 100 Mbps Half Duplex (think that was the switch) while the other PHY ended up in 100 MBps Full Duplex.
That would most probably be a bug in the U-Boot ethernet driver, then.
Best regards,
Wolfgang Denk
If auto-negotiation fails, the default is half duplex (10 or 100 - the speed can be discovered independent of the autonegotiation by the encoding).
Ulf's recollection that the switch was half duplex would indicate that the cheap switch did not autonegotiate properly, but u-boot did. This could be a u-boot bug (not setting up the negotiation properly), but more likely would be a switch problem (not handling the u-boot auto-neg options properly).
gvb
Hi All,
Is there something like ethtool in U-boot that I can use to see what the network negotiated too. This is a fairly cheap netgear switch so I do not have any diagnostics on it.
I will also have a look with wireshark when i get back to the lab to see if I can identify what is happening.
Alex
Please don't top post.
Wireshark is a Very Good Program[tm], but I would not expect too much if this is an autonegotiation issue because autonegotiation uses a sideband control channel (link pulses) separate from the data transmission. Wireshark only sees the data transmissions.
Having said that, look for runt packets w/ Wireshark - that is a strong indicator of full/half duplex problems.
As mentioned by Ed, the u-boot "mii" commands will be more helpful if it is an autonegotiation issue. (Ethernet autonegotiation is a weird bugger: both sides send their capabilities, independently match them, and (hopefully) come to the same conclusion about what is the right configuration. It looks to me like something designed by three committees[1] simultaneously and then turned into a super-subset.)
gvb
[1] A horse is a camel designed by a committee: it looks really good and can run fast on an ideal surface, but quickly dies in conditions that just cause a camel to grin. http://en.wikipedia.org/wiki/Camel#Eco-behavioural_adaptations
ons 2009-01-07 klockan 07:52 -0500 skrev Jerry Van Baren:
Wolfgang Denk wrote:
Dear Ulf Samuelsson,
In message 1231282371.32308.276.camel@elrond.atmel.com you wrote:
It was tracked down to the autoconfiguration of the Ethernet PHY, so one of the PHYs ended up in 100 Mbps Half Duplex (think that was the switch) while the other PHY ended up in 100 MBps Full Duplex.
That would most probably be a bug in the U-Boot ethernet driver, then.
Best regards,
Wolfgang Denk
If auto-negotiation fails, the default is half duplex (10 or 100 - the speed can be discovered independent of the autonegotiation by the encoding).
Ulf's recollection that the switch was half duplex would indicate that the cheap switch did not autonegotiate properly, but u-boot did. This could be a u-boot bug (not setting up the negotiation properly), but more likely would be a switch problem (not handling the u-boot auto-neg options properly).
Don't remember all details, since it was 4 years ago. I talked to D-Link support and they claimed that the standard was to fall back to one of the options, if autonegotiation failed. The customer might have had a PHY without autonegotation which was hardwired to 100 Mbps full duplex.
With little communication, the packages were sent where this caused some problems.
gvb
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Ulf Samuelsson wrote:
ons 2009-01-07 klockan 07:52 -0500 skrev Jerry Van Baren:
Wolfgang Denk wrote:
Dear Ulf Samuelsson,
In message 1231282371.32308.276.camel@elrond.atmel.com you wrote:
It was tracked down to the autoconfiguration of the Ethernet PHY, so one of the PHYs ended up in 100 Mbps Half Duplex (think that was the switch) while the other PHY ended up in 100 MBps Full Duplex.
That would most probably be a bug in the U-Boot ethernet driver, then.
Best regards,
Wolfgang Denk
If auto-negotiation fails, the default is half duplex (10 or 100 - the speed can be discovered independent of the autonegotiation by the encoding).
Ulf's recollection that the switch was half duplex would indicate that the cheap switch did not autonegotiate properly, but u-boot did. This could be a u-boot bug (not setting up the negotiation properly), but more likely would be a switch problem (not handling the u-boot auto-neg options properly).
Don't remember all details, since it was 4 years ago. I talked to D-Link support and they claimed that the standard was to fall back to one of the options, if autonegotiation failed.
Autonegotiation enabled but fails => half duplex. It's in the spec.
The customer might have had a PHY without autonegotation which was hardwired to 100 Mbps full duplex.
Manually configured (autoneg disabled) is no problem, *AS LONG AS* both sides are manually configured to the same configuration. The problem is when one side is configured to autonegotiate and the other side is set to full duplex. The autonegotiation side is unable to negotiate with the manually configured side, so it falls back to half duplex at whatever rate is being used (10/100, determined from the encoding on the wire).
It sorta works until there is more than a few packets on the wire, at which time the half duplex end sees the full duplex packets as collisions and the error rate (and runt packets) skyrockets because the half duplex side keeps aborting packets.
It sounds like, in your case, the computer end was manually configured to be (100bT) full duplex but the (cheap unmanaged) switch was still running auto-negotiation. Recipe for disaster.
With little communication, the packages were sent where this caused some problems.
Oh yeah, in spades, but only when the wire gets busier.
gvb
Can someone tell me how to use the mii command? I have the following from a dump:
uBOOT=>> mii dump MII not complete 0. (ffff) -- PHY control register -- (8000:8000) 0.15 = 1 reset (4000:4000) 0.14 = 1 loopback (2040:2040) 0. 6,13 = b11 speed selection = ??? Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0800) 0.11 = 1 power-down (0400:0400) 0.10 = 1 isolate (0200:0200) 0. 9 = 1 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0080) 0. 7 = 1 collision test enable (003f:003f) 0. 5- 0 = 63 (reserved)
On Wed, Jan 7, 2009 at 12:58 PM, Jerry Van Baren gerald.vanbaren@ge.com wrote:
Ulf Samuelsson wrote:
ons 2009-01-07 klockan 07:52 -0500 skrev Jerry Van Baren:
Wolfgang Denk wrote:
Dear Ulf Samuelsson,
In message 1231282371.32308.276.camel@elrond.atmel.com you wrote:
It was tracked down to the autoconfiguration of the Ethernet PHY, so one of the PHYs ended up in 100 Mbps Half Duplex (think that was the switch) while the other PHY ended up in 100 MBps Full Duplex.
That would most probably be a bug in the U-Boot ethernet driver, then.
Best regards,
Wolfgang Denk
If auto-negotiation fails, the default is half duplex (10 or 100 - the speed can be discovered independent of the autonegotiation by the encoding).
Ulf's recollection that the switch was half duplex would indicate that the cheap switch did not autonegotiate properly, but u-boot did. This could be a u-boot bug (not setting up the negotiation properly), but more likely would be a switch problem (not handling the u-boot auto-neg options properly).
Don't remember all details, since it was 4 years ago. I talked to D-Link support and they claimed that the standard was to fall back to one of the options, if autonegotiation failed.
Autonegotiation enabled but fails => half duplex. It's in the spec.
The customer might have had a PHY without autonegotation which was hardwired to 100 Mbps full duplex.
Manually configured (autoneg disabled) is no problem, *AS LONG AS* both sides are manually configured to the same configuration. The problem is when one side is configured to autonegotiate and the other side is set to full duplex. The autonegotiation side is unable to negotiate with the manually configured side, so it falls back to half duplex at whatever rate is being used (10/100, determined from the encoding on the wire).
It sorta works until there is more than a few packets on the wire, at which time the half duplex end sees the full duplex packets as collisions and the error rate (and runt packets) skyrockets because the half duplex side keeps aborting packets.
It sounds like, in your case, the computer end was manually configured to be (100bT) full duplex but the (cheap unmanaged) switch was still running auto-negotiation. Recipe for disaster.
With little communication, the packages were sent where this caused some problems.
Oh yeah, in spades, but only when the wire gets busier.
gvb
L. A. Linden Levy wrote:
Can someone tell me how to use the mii command? I have the following from a dump:
uBOOT=>> mii dump MII not complete 0. (ffff) -- PHY control register -- (8000:8000) 0.15 = 1 reset (4000:4000) 0.14 = 1 loopback (2040:2040) 0. 6,13 = b11 speed selection = ??? Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0800) 0.11 = 1 power-down (0400:0400) 0.10 = 1 isolate (0200:0200) 0. 9 = 1 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0080) 0. 7 = 1 collision test enable (003f:003f) 0. 5- 0 = 63 (reserved)
Please don't top post.
U-Boot can tell you how to use the mii command: "help mii"
It has been a long time since I used mii, but it looks like you need to use "mii device" to find your PHY and then "mii dump <addr> <reg>" to dump the registers of that device.
HTH, gvb
Hi All,
I still have not found a solution and I am a bit desperate. I did not seem to be able to send any packets (using ping) from the FECO on the M5282Lite board to the tftp host, however pings from the host were answered and I saw packets going from the coldfire board to the host in wireshark. I also get a strange error when I ask for mii info:
uBOOT=>> mii device MII devices: 'FEC0' Current device: 'FEC0
uBOOT=>> mii info MII not complete MII not complete ...
a dump gives me:
uBOOT=>> mii dump MII not complete 0. (ffff) -- PHY control register -- (8000:8000) 0.15 = 1 reset (4000:4000) 0.14 = 1 loopback (2040:2040) 0. 6,13 = b11 speed selection = ??? Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0800) 0.11 = 1 power-down (0400:0400) 0.10 = 1 isolate (0200:0200) 0. 9 = 1 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0080) 0. 7 = 1 collision test enable (003f:003f) 0. 5- 0 = 63 (reserved)
I have tried a few other commands, but am not sure how to interpret the output. See below:
uBOOT=>> mii dump 0 1 MII not complete 1. (ffff) -- PHY status register -- (8000:8000) 1.15 = 1 100BASE-T4 able (4000:4000) 1.14 = 1 100BASE-X full duplex able (2000:2000) 1.13 = 1 100BASE-X half duplex able (1000:1000) 1.12 = 1 10 Mbps full duplex able (0800:0800) 1.11 = 1 10 Mbps half duplex able (0400:0400) 1.10 = 1 100BASE-T2 full duplex able (0200:0200) 1. 9 = 1 100BASE-T2 half duplex able (0100:0100) 1. 8 = 1 extended status (0080:0080) 1. 7 = 1 (reserved) (0040:0040) 1. 6 = 1 MF preamble suppression (0020:0020) 1. 5 = 1 A/N complete (0010:0010) 1. 4 = 1 remote fault (0008:0008) 1. 3 = 1 A/N able (0004:0004) 1. 2 = 1 link status (0002:0002) 1. 1 = 1 jabber detect (0001:0001) 1. 0 = 1 extended capabilities
uBOOT=>> mii dump 0 2 MII not complete 2. (ffff) -- PHY ID 1 register -- (ffff:ffff) 2.15- 0 = 65535 OUI portion
uBOOT=>> mii dump 0 3 MII not complete 3. (ffff) -- PHY ID 2 register -- (fc00:fc00) 3.15-10 = 63 OUI portion (03f0:03f0) 3. 9- 4 = 63 manufacturer part number (000f:000f) 3. 3- 0 = 15 manufacturer rev. number
uBOOT=>> mii dump 0 4 MII not complete 4. (ffff) -- Autonegotiation advertisement register -- (8000:8000) 4.15 = 1 next page able (4000:4000) 4.14 = 1 reserved (2000:2000) 4.13 = 1 remote fault (1000:1000) 4.12 = 1 reserved (0800:0800) 4.11 = 1 asymmetric pause (0400:0400) 4.10 = 1 pause enable (0200:0200) 4. 9 = 1 100BASE-T4 able (0100:0100) 4. 8 = 1 100BASE-TX full duplex able (0080:0080) 4. 7 = 1 100BASE-TX able (0040:0040) 4. 6 = 1 10BASE-T full duplex able (0020:0020) 4. 5 = 1 10BASE-T able (001f:001f) 4. 4- 0 = 31 selector = ???
I also tried to look at the tftp server side of things:
=>> sudo mii-tool -v eth1 eth1: negotiated 1000baseT-HD flow-control, link ok product info: vendor 00:60:51, model 0 rev 1 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
Any more advice on what could be wrong or how to debug it would be greatly appreciated.
Alex
On Fri, 16 Jan 2009 10:34:39 -0500 Jerry Van Baren gerald.vanbaren@ge.com wrote:
L. A. Linden Levy wrote:
Can someone tell me how to use the mii command? I have the following from a dump:
uBOOT=>> mii dump MII not complete 0. (ffff) -- PHY control register -- (8000:8000) 0.15 = 1 reset (4000:4000) 0.14 = 1 loopback (2040:2040) 0. 6,13 = b11 speed selection = ??? Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0800) 0.11 = 1 power-down (0400:0400) 0.10 = 1 isolate (0200:0200) 0. 9 = 1 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0080) 0. 7 = 1 collision test enable (003f:003f) 0. 5- 0 = 63 (reserved)
Please don't top post.
U-Boot can tell you how to use the mii command: "help mii"
It has been a long time since I used mii, but it looks like you need to use "mii device" to find your PHY and then "mii dump <addr> <reg>" to dump the registers of that device.
HTH, gvb
Hi Loren,
Please don't top post. It annoys us curmudgeons.
Loren A. Linden Levy wrote:
Hi All,
I still have not found a solution and I am a bit desperate. I did not seem to be able to send any packets (using ping) from the FECO on the M5282Lite board to the tftp host, however pings from the host were answered and I saw packets going from the coldfire board to the host in wireshark. I also get a strange error when I ask for mii info:
uBOOT=>> mii device MII devices: 'FEC0' Current device: 'FEC0
uBOOT=>> mii info MII not complete MII not complete ...
a dump gives me:
uBOOT=>> mii dump MII not complete 0. (ffff) -- PHY control register -- (8000:8000) 0.15 = 1 reset (4000:4000) 0.14 = 1 loopback (2040:2040) 0. 6,13 = b11 speed selection = ??? Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0800) 0.11 = 1 power-down (0400:0400) 0.10 = 1 isolate (0200:0200) 0. 9 = 1 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0080) 0. 7 = 1 collision test enable (003f:003f) 0. 5- 0 = 63 (reserved)
Note that ALL the bits are '1'. That is indicating your PHY is NOT DRIVING data on the MII data line (always idle high). Odds are really good that you are not driving your MII clock and data properly, your PHY isn't at the address you think it is at, or your hardware has problems. The only reason you are getting any ether activity is likely because your PHY is defaulting to a configuration that is mostly (not entirely) broken.
* Double-check your MII clock and data pin configurations. Are you initializing them correctly? Error probability: 87%.
* What address is your PHY strapped to? You need to know this. Error probability: 11% (your emails imply you don't know this - I bumped the probability up because of that impression).
* Use a logic analyzer (preferred), o-scope (good) or a logic probe on your PHY's MII clock and data lines and verify they are receiving the right sequence (or at least wiggling when you do the MII commands). With a logic analyzer you should be able to read the data you are sending and verify the bit pattern. You can do this with an o-scope (especially a digital one) too, but a little trickier. This is likely a software error (above 87% + 11%) - hardware error probability: 2%
* Oh yeah, you might be clocking the MII lines too fast. Pretty small probability, though.
[snip]
Good luck and happy probing, gvb
P.S. I used mostly odd percentages because I read somewhere that made up percentages are more believable when they are odd. ;-)
Hi Jerry,
On Mon, 19 Jan 2009 20:14:07 -0500 Jerry Van Baren gvb.uboot@gmail.com wrote:
Please don't top post. It annoys us curmudgeons.
Ack, that was an accident, I just replied to the last mail I received.
Loren A. Linden Levy wrote:
Hi All,
I still have not found a solution and I am a bit desperate. I did not seem to be able to send any packets (using ping) from the FECO on the M5282Lite board to the tftp host, however pings from the host were answered and I saw packets going from the coldfire board to the host in wireshark. I also get a strange error when I ask for mii info:
uBOOT=>> mii device MII devices: 'FEC0' Current device: 'FEC0
uBOOT=>> mii info MII not complete MII not complete ...
a dump gives me:
uBOOT=>> mii dump MII not complete 0. (ffff) -- PHY control register -- (8000:8000) 0.15 = 1 reset (4000:4000) 0.14 = 1 loopback (2040:2040) 0. 6,13 = b11 speed selection = ??? Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0800) 0.11 = 1 power-down (0400:0400) 0.10 = 1 isolate (0200:0200) 0. 9 = 1 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0080) 0. 7 = 1 collision test enable (003f:003f) 0. 5- 0 = 63 (reserved)
Note that ALL the bits are '1'. That is indicating your PHY is NOT DRIVING data on the MII data line (always idle high). Odds are really good that you are not driving your MII clock and data properly, your PHY isn't at the address you think it is at, or your hardware has problems. The only reason you are getting any ether activity is likely because your PHY is defaulting to a configuration that is mostly (not entirely) broken.
- Double-check your MII clock and data pin configurations. Are you
initializing them correctly? Error probability: 87%.
Where in the u-boot code is this set?
- What address is your PHY strapped to? You need to know this. Error
probability: 11% (your emails imply you don't know this - I bumped the probability up because of that impression).
Same Q, Where in the u-boot code is this set?
- Use a logic analyzer (preferred), o-scope (good) or a logic probe on
your PHY's MII clock and data lines and verify they are receiving the right sequence (or at least wiggling when you do the MII commands). With a logic analyzer you should be able to read the data you are sending and verify the bit pattern. You can do this with an o-scope (especially a digital one) too, but a little trickier. This is likely a software error (above 87% + 11%) - hardware error probability: 2%
- Oh yeah, you might be clocking the MII lines too fast. Pretty small
probability, though.
[snip]
Good luck and happy probing, gvb
P.S. I used mostly odd percentages because I read somewhere that made up percentages are more believable when they are odd. ;-)
nice...
Hi Jerry,
It looks to me like for the M%282 board the PHY address is determined by querying the MII interface:
include/configs/M5282EVB.h
#define CONFIG_MCFFEC #ifdef CONFIG_MCFFEC # define CONFIG_NET_MULTI 1 # define CONFIG_MII 1 # define CFG_DISCOVER_PHY ...
This cause the code in ./drivers/net/mcffec.c specifically mii_discover_phy to be run, I tried to enable the debugging in this code:
//#undef ET_DEBUG //#undef MII_DEBUG
but it does not seem to print anything (:(). One interesting feature is that once my uClinux image has booted I can talk to it over the switched network just fin. So the issue is really something in the setup of the MII PHY interface in u-boot. Is there any build target to allow me to try and debug this?
Thanks.
Alex
On Mon, 19 Jan 2009 20:14:07 -0500 Jerry Van Baren gvb.uboot@gmail.com wrote:
Hi Loren,
Please don't top post. It annoys us curmudgeons.
Loren A. Linden Levy wrote:
Hi All,
I still have not found a solution and I am a bit desperate. I did not seem to be able to send any packets (using ping) from the FECO on the M5282Lite board to the tftp host, however pings from the host were answered and I saw packets going from the coldfire board to the host in wireshark. I also get a strange error when I ask for mii info:
uBOOT=>> mii device MII devices: 'FEC0' Current device: 'FEC0
uBOOT=>> mii info MII not complete MII not complete ...
a dump gives me:
uBOOT=>> mii dump MII not complete 0. (ffff) -- PHY control register -- (8000:8000) 0.15 = 1 reset (4000:4000) 0.14 = 1 loopback (2040:2040) 0. 6,13 = b11 speed selection = ??? Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0800) 0.11 = 1 power-down (0400:0400) 0.10 = 1 isolate (0200:0200) 0. 9 = 1 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0080) 0. 7 = 1 collision test enable (003f:003f) 0. 5- 0 = 63 (reserved)
Note that ALL the bits are '1'. That is indicating your PHY is NOT DRIVING data on the MII data line (always idle high). Odds are really good that you are not driving your MII clock and data properly, your PHY isn't at the address you think it is at, or your hardware has problems. The only reason you are getting any ether activity is likely because your PHY is defaulting to a configuration that is mostly (not entirely) broken.
- Double-check your MII clock and data pin configurations. Are you
initializing them correctly? Error probability: 87%.
- What address is your PHY strapped to? You need to know this. Error
probability: 11% (your emails imply you don't know this - I bumped the probability up because of that impression).
- Use a logic analyzer (preferred), o-scope (good) or a logic probe on
your PHY's MII clock and data lines and verify they are receiving the right sequence (or at least wiggling when you do the MII commands). With a logic analyzer you should be able to read the data you are sending and verify the bit pattern. You can do this with an o-scope (especially a digital one) too, but a little trickier. This is likely a software error (above 87% + 11%) - hardware error probability: 2%
- Oh yeah, you might be clocking the MII lines too fast. Pretty small
probability, though.
[snip]
Good luck and happy probing, gvb
P.S. I used mostly odd percentages because I read somewhere that made up percentages are more believable when they are odd. ;-)
Loren A. Linden Levy wrote:
Hi Jerry,
It looks to me like for the M%282 board the PHY address is determined by querying the MII interface:
include/configs/M5282EVB.h
#define CONFIG_MCFFEC #ifdef CONFIG_MCFFEC # define CONFIG_NET_MULTI 1 # define CONFIG_MII 1 # define CFG_DISCOVER_PHY ...
This cause the code in ./drivers/net/mcffec.c specifically mii_discover_phy to be run, I tried to enable the debugging in this code:
//#undef ET_DEBUG //#undef MII_DEBUG
I am not familiar with the code, but I would change them to #defines rather than commenting out the #undefs, and look to see where they are used to see what to expect to be printed out.
but it does not seem to print anything (:(). One interesting feature is that once my uClinux image has booted I can talk to it over the switched network just fin. So the issue is really something in the setup of the MII PHY interface in u-boot. Is there any build target to allow me to try and debug this?
I still strongly suspect your hardware initialization isn't right (again, I'm not familiar with the MPC5282 processor nor your board) or your PHY is miswired (I'm assuming this is a custom board, not the eval board).
You need to verify your hardware is toggling the MII pins on the PHY. If it isn't, you need to verify your hardware is toggling the MII pins on the processor. If not, it's likely your software initialization/driver. If so, you have a hardware problem.
If the MII pins are not toggling, you are not going to get anywhere. Until you verify it (hands on, with some sort of hardware probe), you are shooting in the dark. While you can hit the target in the dark with enough rounds, the efficiency sucks.
Thanks.
Alex
Good luck, gvb
Hi Jerry,
Your gonna love this. I was setting the hardware MAC address to be FF:FF:FF:FF:FF:FF. When i changed this everything magically started working. I guess this MAC has some meaning like the device is a router. Anyway, i learned a lot while trying to figure this out. Thanks again!
Alex
On Tue, 20 Jan 2009 12:13:52 -0500 Jerry Van Baren gerald.vanbaren@ge.com wrote:
Loren A. Linden Levy wrote:
Hi Jerry,
It looks to me like for the M%282 board the PHY address is determined by querying the MII interface:
include/configs/M5282EVB.h
#define CONFIG_MCFFEC #ifdef CONFIG_MCFFEC # define CONFIG_NET_MULTI 1 # define CONFIG_MII 1 # define CFG_DISCOVER_PHY ...
This cause the code in ./drivers/net/mcffec.c specifically mii_discover_phy to be run, I tried to enable the debugging in this code:
//#undef ET_DEBUG //#undef MII_DEBUG
I am not familiar with the code, but I would change them to #defines rather than commenting out the #undefs, and look to see where they are used to see what to expect to be printed out.
but it does not seem to print anything (:(). One interesting feature is that once my uClinux image has booted I can talk to it over the switched network just fin. So the issue is really something in the setup of the MII PHY interface in u-boot. Is there any build target to allow me to try and debug this?
I still strongly suspect your hardware initialization isn't right (again, I'm not familiar with the MPC5282 processor nor your board) or your PHY is miswired (I'm assuming this is a custom board, not the eval board).
You need to verify your hardware is toggling the MII pins on the PHY. If it isn't, you need to verify your hardware is toggling the MII pins on the processor. If not, it's likely your software initialization/driver. If so, you have a hardware problem.
If the MII pins are not toggling, you are not going to get anywhere. Until you verify it (hands on, with some sort of hardware probe), you are shooting in the dark. While you can hit the target in the dark with enough rounds, the efficiency sucks.
Thanks.
Alex
Good luck, gvb
Loren A. Linden Levy wrote:
Hi Jerry,
Your gonna love this. I was setting the hardware MAC address to be FF:FF:FF:FF:FF:FF. When i changed this everything magically started working. I guess this MAC has some meaning like the device is a router. Anyway, i learned a lot while trying to figure this out. Thanks again!
Alex
That is a multicast (broadcast) address (the bit 0x01 in the first octet is set). Very wrong, as you now know. http://www.denx.de/wiki/view/DULG/EthernetDoesNotWork http://www.denx.de/wiki/DULG/WhereCanIGetAValidMACAddress More detailed explanation: http://en.wikipedia.org/wiki/MAC_address
Best regards, gvb
Hi Alex,
Loren A. Linden Levy wrote:
Hi Everyone,
I am having an interesting problem with am m5282Lite Dev Kit. I had done all of the previous development work by connection the card directly to a spare ethernet card in my PC via a cross-over cable. This worked just fine and the tftp download was very fast. Now I have run a long Ethernet cable and can download the uClinux using u-boot, but the hub is 10Mbit. I get some "bad len" errors but eventually (seems to take a long time) the download completes and uClinux boots. I then tried to hook up a spare 100MBit switch i had running one Ethernet cable to the pC (tftp server) and one to the coldfire board (now using regular network cable) but the tftp just times out.
This sounds like a marginal cabling issue, 10bT (slower, half duplex, simple encoding) works, 100bT switched (faster, full duplex, 4b5 encoding) doesn't.
How long is the cable in your new setup? What type of cable (patch cord, Cat3/Cat4/Cat5, lamp cord)? Are there any connectors/connections between the hub/switch and your Dev Kit?
The funny thing is i seem to be able to ping the coldfire from the PC side but not the PC from the coldfire side. Does anyone have an idea of what is wrong? Thanks in advance!
Pinging defaults to small packets at a very slow rate - not very stressful. Try flood pinging with large packets.
Were you able to ping both ways successfully with your original setup (short crossover cable)? Does pinging work differently with the 10bT hub vs. 100bT switch? Is your hardware autonegotiating the full/half duplex correctly? Running one side half and the other side full results in lots of "collisions" and runt packets when the full side sends while the half side is sending (the half side detects a "collision" and aborts the packet).
Alex
HTH, gvb
participants (9)
-
Ben Warren -
Jerry Van Baren -
Jerry Van Baren -
L. A. Linden Levy -
Loren A. Linden Levy
-
Remy Bohmer -
Swarthout Edward L -
Ulf Samuelsson -
Wolfgang Denk