PHY not connected !! MAC: error during MII initialization

Question

I am trying to download 'rfsNV.gz' and 'uImageNV' to an ARM board using 'TFTP' server and 'U-boot' menu. I'm using a board developed by deramCatcher, tftp server on windows 7 with 'tftp32.exe', Hyperterminal, a cross over etherenet cable and USB serial cable. I connect to the board using Hyperterminal and end up at the U-boot menu. I set my server ip as 192.168.0.123 and target board ip as 192.168.0.1. Then i launch 'tftp32.exe' to setup TFTP server and on Hyperterminal write

tftp 20410000 rfsNV.gz

but Hyperterminal responds with

    PHY not connected!!
    MAC: error during MII initialization
    TFTP from server 192.168.0.123; our IP address is 192.168.0.1
    Filename 'rfsNV.gz'.
    Load address: 0x20410000
    Loading: T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T
    Retry count exceeded; starting again

Does this mean i do not have my ethernet connection properly set up ? My Local area connection says No network access like this figure. But on the board ethernet connectiviy LED indicates cable is connected. I am totally new to Embedded Linux and can't figure out why i cannot download the files on the board. Can anyone figure out what is wrong ?

When U-boot starts console shows

Low Level Init performed


boot 1.0 (Nov 25 2003 - 23:08:05)

Uncompressing image...



U-Boot 2008.10.ARM9(NV) (Aug  6 2009 - 23:52:44)

DRAM:  32 MB
Atmel: AT49BV163D (16Mbit)
Flash:  2 MB
DataFlash:AT45DB161
Nb pages:   4096
Page Size:    528
Size= 2162688 bytes
Logical address: 0xC0000000
Area 0: C0000000 to C0007FFF (RO) ARM9 Bootstrap
Area 1: C0008000 to C001FFFF
Area 2: C0020000 to C0027FFF (RO)
Area 3: C0028000 to C020FFFF
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
U-Boot>

Output of 'mii info' is:

U-Boot> mii info
PHY 0x00: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x01: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x02: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x03: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x04: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x05: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x06: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x07: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x08: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x09: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x10: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x11: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x12: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x13: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x14: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x15: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x16: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x17: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x18: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x19: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
U-Boot>

Answer 1

Sounds like the Ethernet interface has not been initialised. Are there any commands in your version of U-Boot to enable the Ethernet interface? Has the U-Boot environment variable hwaddr been configured ("printenv hwaddr" to see) - this environment variable is the MAC address of the board's Ethernet interface. Does the board have any LEDs indicating the link status (these are typically next to the socket where the Ethernet is plugged in).

Answer 2

The only salient message from U-Boot seems to be

    PHY not connected!!

The Ethernet (EMAC) peripheral happens to be integrated into your Atmel ARM9 SoC.
So knowing that the SoC is the Atmel AT91RM9200, the Ethernet driver in U-Boot has to be cpu/arm920t/at91rm9200/ether.c, which is the code that generates that warning message:

if (!PhyOps.IsPhyConnected (p_mac))
    printf ("PHY not connected!!\n\r");

The Ethernet PHY peripheral is typically external to the SoC, and is connected to the EMAC through either the MII or RMII bus.
The Atmel AT91RM9200 reference design and evaluation board uses the Davicom DM9161 PHY.
One of the Davicom PHY drivers in U-Boot is cpu/arm920t/at91rm9200/dm9161.c, and contains

unsigned int dm9161_IsPhyConnected (AT91PS_EMAC p_mac)
{
    unsigned short Id1, Id2;

    at91rm9200_EmacEnableMDIO (p_mac);
    at91rm9200_EmacReadPhy (p_mac, DM9161_PHYID1, &Id1);
    at91rm9200_EmacReadPhy (p_mac, DM9161_PHYID2, &Id2);
    at91rm9200_EmacDisableMDIO (p_mac);

    if ((Id1 == (DM9161_PHYID1_OUI >> 6)) &&
        ((Id2 >> 10) == (DM9161_PHYID1_OUI & DM9161_LSB_MASK)))
        return TRUE;

    return FALSE;
}

This code is not that complicated. This routine should succeed regardless of anything plugged into the RJ45 port or the Ethernet link condition or the value of the MAC address. So the failure of this code sequence (that produces the PHY warning message) would seem to indicate that:

a) The hardware has failed or is damaged. (Have you observed proper anti-static precautions?) But

But on the board ethernet connectiviy LED indicates cable is connected.

would seem to indicate that the PHY is not totally dead.

b) Or the firmware does not match the hardware. You should verify the board number, revision number and serial number. Get a board schematic and/or BOM (bill of materials), and then confirm that the part number for the PHY matches (i.e. your board design may not use the DM9161 but some other PHY chip). You should obtain the U-Boot source code for your board. Verify that U-Boot is configured for the PHY that is actually installed on your board. Verify that the U-Boot binary that you are executing is the same version as the source code in hand.

If you are really adventurous, then you could "play computer" and manually perform the operations of the above IsPhyConnected()routine using the memory write and read or mii commands of U-Boot. If you were a professional engineer trying to bring-up your new board design, then that would be the next likely step.

U-Boot > mii
Usage:
mii - MII utility commands

U-Boot > help mii
mii device                     - list available devices
mii device <devname>           - set current device
mii info   <addr>              - display MII PHY info
mii read   <addr> <reg>        - read  MII PHY <addr> register <reg>
mii write  <addr> <reg> <data> - write MII PHY <addr> register <reg>
mii dump   <addr> <reg>        - pretty-print <addr> <reg> (0-5 only)
Addr and/or reg may be ranges, e.g. 0-31.
U-Boot >

UPDATE

In light of seeing the output of mii info, your board appears to be broken or damaged, i.e. the EMAC is not communicating with or is not connected to the PHY. You could try examining the board for damage with a magnifying glass under a bright light. I'd try exchanging the board for another one.

UPDATE II

Turns out that the output of mii info from your board is slightly bogus because there is a bug in U-Boot. The mii info command would use the following code to scan every possible PHY on the MII at each of the 32 possible addresses:

int  at91rm9200_miiphy_read(char *devname, unsigned char addr,
        unsigned char reg, unsigned short * value)
{
    at91rm9200_EmacEnableMDIO (p_mac);
    at91rm9200_EmacReadPhy (p_mac, reg, value);
    at91rm9200_EmacDisableMDIO (p_mac);
    return 0;
}

Note however that the addr argument (which holds the PHY address) is never used in this routine. The result is that this routine of the AT91RM9200 board always reads the PHY at address 0, and the mii info command does not report an accurate scan of all addresses.

One item gleaned is that the PHY is returning zeros, and that clarifies why dm9161_IsPhyConnected() fails the comparison test. The zeros should alleviate any concern that an alternate & unrecognizable PHY has been installed.

From my board (there is one PHY at address 1) (which does not have the aforementioned bug in U-Boot):

U-Boot> mii info
PHY 0x01: OUI = 0x80017, Model = 0x09, Rev = 0x00, 100baseT, FDX
U-Boot> mii dev
MII devices: 'at91phy' 
Current device: 'at91phy'
U-Boot>