Specifications

If this doesn't work, fix your TFTP server configuration and make sure it is running.
(2) If your TFTP server is working, run ethereal (or equivalent ethernet sniffing) to see what ethernet packets
are being sent by your development board. It usually works best to run ethereal on your TFTP server (if you
run it on a different machine and you use an ethernet switch, the third machine likely won't see the tftp
packets).
14.2.16. Why is my Ethernet operation not reliable?
Question:
My ethernet connection is not working reliable. On one switch it works fine, but on another one it
doesn't.
or:
Question:
I always see transmit errors or timeouts for the first packet of a download, but then it works well.
or:
Question:
I cannot mount the Linux root file system over NFS; especially not with recent Linux kernel versions
(older kernel versions work better). Specifying "proto=tcp" as mount option greatly improves the
situation.
etc.
Answer:
There are many possible explanations for such problems. After eliminating the obvious sources (like
broken cables etc.) you should check the configuration of your Ethernet PHY. One common cause of
problems is if your PHY is hard configured in duplex mode (for example 100baseTX Full Duplex or
10baseT Full Duplex). If such a setup is combined with a autonegotiating switch, then trouble is
ahead.
Jerry Van Baren explained this as follows:
Ignoring the configuration where both ends are (presumably correctly)
manually configured, you end up with five cases, two of them
misconfigured and WRONG:
1) Autonegotiation <-> autonegotiation - reliable.
2) 10bT half duplex <-> autonegotiation - reliable.
3) 100bT half duplex <-> autonegotiation - reliable.
4) 10bT *FULL* duplex <-> autonegotiation - *UNreliable*.
5) 100bT *FULL* duplex <-> autonegotiation - *UNreliable*.
The problem that I've observed is that the *humans* (the weak links)
that do the manual configuration don't understand that "parallel
detection" *must be* half duplex by definition in the spec (it is hard
to define a reliable algorithm to detect full duplex capability so the
spec writers punted). As a result, the human invariably picks "full
duplex" because everybody knows full duplex is better... and end up as
case (4) or (5). They inadvertently end up with a slower unreliable
link (lots of "collisions" resulting in runt packets) rather than the
faster better link they thought they were picking (d'oh!). The really
bad thing is that the network works fine in testing on an isolated LAN
with no traffic and absolutely craps its pants when it hits the real
world.
That is my reasoning behind my statement that we can generally ignore
14.2.16. Why is my Ethernet operation not reliable? 168