[U-Boot] Fw: TFTP fails when using network switch

[U-Boot] Fw: TFTP fails when using network switch

[Loren A. Linden Levy]

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

-- 
 -- 
---------------------------------------------
Loren A. Linden Levy
Department of Physics 
390 UCB 
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY) 
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY) 
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: Loren.Lindenlevy at colorado.edu
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used 
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------


-- 
 -- 
---------------------------------------------
Loren A. Linden Levy
Department of Physics 
390 UCB 
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY) 
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY) 
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: Loren.Lindenlevy at colorado.edu
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used 
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090105/f9462915/attachment.pgp 

[U-Boot] Fw: TFTP fails when using network switch

[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.

> 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] Fw: TFTP fails when using network switch

[Jerry Van Baren]

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

[U-Boot] Fw: TFTP fails when using network switch

[Ulf Samuelsson]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Fw: TFTP fails when using network switch

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Es gibt immer genug fuer die Beduerfnisse aller, aber  niemals  genug
fuer die Gier einzelner.                                    -- Ghandi

[U-Boot] Fw: TFTP fails when using network switch

[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).

gvb

[U-Boot] Fw: TFTP fails when using network switch

[Loren A. Linden Levy]

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
Department of Physics 
390 UCB 
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY) 
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY) 
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: Loren.Lindenlevy at colorado.edu
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used 
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090107/2eed1ab3/attachment.pgp 

[U-Boot] Fw: TFTP fails when using network switch

[Swarthout Edward L]

From: Loren A. Linden Levy
> 
> Is there something like ethtool in U-boot that I can use to 
> see what the network negotiated too. 

If CONFIG_CMD_MII is set, there is "mii info" and "mii dump".

-Ed

[U-Boot] Fw: TFTP fails when using network switch

[Ben Warren]

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

[U-Boot] Fw: TFTP fails when using network switch

[Jerry Van Baren]

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>

[U-Boot] Fw: TFTP fails when using network switch

[Ulf Samuelsson]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Fw: TFTP fails when using network switch

[Jerry Van Baren]

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

[U-Boot] Fw: TFTP fails when using network switch

[L. A. Linden Levy]

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
>
>



-- 
 --
---------------------------------------------
Loren A. Linden Levy
Department of Physics
390 UCB
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY)
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY)
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: Loren.Lindenlevy at colorado.edu
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------

[U-Boot] Fw: TFTP fails when using network switch

[Jerry Van Baren]

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

[U-Boot] Fw: TFTP fails when using network switch

[Loren A. Linden Levy]

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


-- 
 -- 
---------------------------------------------
Loren A. Linden Levy
Department of Physics 
390 UCB 
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY) 
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY) 
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: Loren.Lindenlevy at colorado.edu
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used 
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090119/d951e66b/attachment.pgp 

[U-Boot] Fw: TFTP fails when using network switch

[Jerry Van Baren]

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.  ;-)

[U-Boot] Fw: TFTP fails when using network switch

[Loren A. Linden Levy]

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...

-- 
 -- 
---------------------------------------------
Loren A. Linden Levy
Department of Physics 
390 UCB 
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY) 
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY) 
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: Loren.Lindenlevy at colorado.edu
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used 
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090119/16d01c09/attachment.pgp 

[U-Boot] Fw: TFTP fails when using network switch

[Loren A. Linden Levy]

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
Department of Physics 
390 UCB 
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY) 
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY) 
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: Loren.Lindenlevy at colorado.edu
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used 
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090120/610c8b41/attachment.pgp 

[U-Boot] Fw: TFTP fails when using network switch

[Jerry Van Baren]

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

[U-Boot] Fw: TFTP fails when using network switch

[Loren A. Linden Levy]

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
Department of Physics 
390 UCB 
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY) 
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY) 
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: Loren.Lindenlevy at colorado.edu
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used 
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090120/21cc30ee/attachment-0001.pgp 

[U-Boot] Fw: TFTP fails when using network switch

[Jerry Van Baren]

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