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>

Why don't you provide an actual link to your board's product page or a datasheet, instead of the home page of the organization that builds it? Please provide the console output from when U-Boot starts, rather than just when you realize you cannot tftp. — sawdust, Mar 13 '13 at 01:48
I have edited the question to include the console output when U-boot starts. I am trying to follow this [pdf](https://www.dropbox.com/s/nzhvljiwgar1u1q/ME2100%20Embedded%20Linux%20Setup%20Guide%20v1-00.pdf). I have [this](https://www.dropbox.com/s/7q72g7l6ao0ku5r/ME2100%20Data%20Sheet.pdf) datasheet but its not useful. — croc, Mar 13 '13 at 07:53
Please read the update to my answer. Turns out that only the first line of the `mii info` report is real, and the rest is simply replicated data from the first line. — sawdust, Mar 15 '13 at 00:02

sawdust · Answer 1 · 2013-03-14T23:58:46.403

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>

Thank you for your thoughts and patiently listening to me. I have contacted with the technical engineer of the vendor and confirmed that the board appears to be damaged. Thanks. — croc, Mar 14 '13 at 09:44
About examining the board with magnifying glass. Exactly where should i look and what damage should i look for ? — croc, Mar 14 '13 at 09:45
You could look for bad solder joints and broken traces. The inspection is very limited; you cannot look under BGA chips or check inner circuit board layers. Please update this question when you test the replacement board; i.e. compare the `mii info` results. If you found my answer useful, then I would appreciate an upvote and/or an "accepted" answer. — sawdust, Mar 14 '13 at 09:57
Hello @sawdust, could you please point out how and where "addr" argument(PHY addr) is initialized ? — Amit Singh Tomar, Apr 19 '16 at 09:03
@AmitSinghTomar -- The (R)MII bus connects multiple PHYs to the EMAC. This PHY address is the address to which the PHY will respond on the MII bus. The address of the PHY is typically hardwired. You cannot initialize it by SW because the PHY is on a bus (you can't access a device unless you already have its address). Note that some PHYs default to address `0`, whereas other may default to `1`. Check the datasheet for the PHY that you're using and the board schematics. — sawdust, Apr 19 '16 at 18:33
Ok Thanks.Is this RMII Bus controller part of EMac chip.Also how can I confirm that PHY has initialized well and ok? In other question that I have posted , I am struggling to know whether my PHY and EMAC clocks are enabled ok? — Amit Singh Tomar, Apr 19 '16 at 19:19
@AmitSinghTomar -- Yes, a (R)MII controller is part of the EMAC. Linux is a poor environment for checking out hardware, Use U-Boot for that. — sawdust, Apr 20 '16 at 08:18

score 0 · Answer 2 · answered Mar 11 '13 at 12:23

0

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

answered Mar 11 '13 at 12:23

pav

226
3
7

'printenv hwaddr' shows ## Error: "hwaddr" not defined. but 'printenv' shows 'bootdelay=3 baudrate=115200 netmask=255.255.255.0 ethaddr=22.33.44.55.66.77 loadboot=cp.b 10100000 21000000 dffff loadram=cp.b C0000000 20410000 8ffff bootcmd=run loadram; run loadboot; bootm ipaddr=192.168.0.1 serverip=192.168.0.123 stdin=serial stdout=serial stderr=serial Environment size: 275/65532 bytes'. The board has 3 LEDs and all three stays ON. I am trying to follow this pdf https://www.dropbox.com/s/nzhvljiwgar1u1q/ME2100%20Embedded%20Linux%20Setup%20Guide%20v1-00.pdf and its not working as described there – croc Mar 12 '13 at 05:46
by the way, in the pdf(of previous comment) the 'ethaddr' is set to be '22.33.44.55.66.77'. Should i replace this address with the MAC address of the host PC ? When i issue 'setenv ethaddr xx:xx:xx:xx:xx:xx' hyperterminal shows 'Can't overwrite 'ethaddr''. How can i change the 'ethaddr' ? – croc Mar 12 '13 at 07:04
The MAC address is a unique address [wikipedia](http://en.wikipedia.org/wiki/MAC_address). Your PC must have a different MAC address to your board. Looking on u-boot's website [here](http://www.denx.de/wiki/DULG/UBootEnvVariables) 'ethaddr' can only be setup once, so you can't change it without reprogramming u-boot. Looking in your pdf file it says the link and activity LED on connector CN6 should light up and blink (page 3/14), are you sure you have a crossover ethernet cable plugged into the board and the back of your PC? Your PC should also show there is a device plugged into it's ethernet. – pav Mar 12 '13 at 08:27
Ignore my comments about hwaddr, it sounds like ethaddr is the right environment variable for your build of UBoot. The MAC address 22.33.44.55.66.77 should work for now (to change it you will have to go through your instructions for reprogramming uboot). I think the problem you are experiencing is that the Ethernet hardware is failing to detect a link up, please try different ethernet cables (cross over and straight), what cables are plugged in to what equipment? Are you using an Ethernet switch? – pav Mar 12 '13 at 08:44
I am using a cross over ethernet cabel plugged into the back of my PC and board. When cable is connected to the board Windows 7 'network and sharing Center' show an undefined public network 'Local Area Connection'. With the cable plugged with the board all three LEDs lit up, blink for a few seconds then stays ON. 'Link LED' blinks when hyperterminal dysplays 'TTTTTTT.....'. But 'Local Area Connection' shows ['No Network access'](http://i.stack.imgur.com/TRx0J.png). So the problem may be the ethernet connection. I have tried both straight and cross over cable but results were the same. – croc Mar 12 '13 at 10:21
The fact that Windows is detecting a Local area connection is good, this sounds like the Ethernet is O.K. Do you have your PC and board configured to be in the same IP network, e.g., board IP address is 192.16.8.0.1 and PC address is something like 192.168.0.2 - if they are in the same network then you should be able to ping from the board to the PC to see if it is alive or not by typing ping 192.168.0.2. – pav Mar 12 '13 at 11:15
U-boot does not have a 'ping' command. How do i configure the PC and board to be in the same IP network ? PC and board IP is 192.168.0.123 and 192.168.0.1 respectively already. – croc Mar 12 '13 at 11:32
They might already be in the same IP network, depends on the subnet mask for both of them, uboot environment variable netmask defines this, check your PC's subnet mask is configured to the same value (255.255.255.0), please follow the instructions [here](http://windows.microsoft.com/en-us/windows7/change-tcp-ip-settings) to change your subnet mask under Windows. Unfortunately your version of UBoot hasn't been configured to provide the ping command (this is down to how Uboot was built). – pav Mar 12 '13 at 11:54
Yes, i have already done it. Subnet mask is 255.255.255.0 as can be seen [here](http://i.stack.imgur.com/TRx0J.png). But 'DHCP Enabled'=No and 'IPv4 Connectivity = No network access'. Is this why hyperterminal is showing 'PHY not connected !!' ? – croc Mar 12 '13 at 12:26
DHCP should be disabled when using a static IP address on your PC, this is OK. Can you show the output of the 'help' command in Uboot to show what commands are available? I am wondering if there is a Uboot command to enable or initialise the board's Ethernet interface. The PHY errors imply the Ethernet isn't up and working on the board. The 'TTTTT' you see being printed out is because of timeouts, as explained [here](http://www.denx.de/wiki/DULG/TFTPTimeout). – pav Mar 12 '13 at 12:42
Sure i can. But please wait until tomorrow when i have access to the board again. I left it in the lab. – croc Mar 12 '13 at 15:36
*"U-boot does not have a 'ping' command"* -- U-Boot does have a `ping` command, but you have to configure it in the source code before you build U-Boot. – sawdust Mar 13 '13 at 01:42
@pav: [Here](https://www.dropbox.com/s/fla3obvwt1cbn9o/uboot_help.txt) is the output of 'help' command in Uboot you were looking for. – croc Mar 13 '13 at 04:19
@sawdust: I am a newbie at using ARM board and Embedded Linux. I didn't know what commands are available there aside from U-boot show with the 'help' command. I was following the instructions from this [pdf](https://www.dropbox.com/s/nzhvljiwgar1u1q/ME2100%20Embedded%20Linux%20Setup%20Guide%20v1-00.pdf) and got stuck at my problem. It is very frustrating when one is provided with a given set of instructions and it does not work the way it is described. :(. Such as with 'setenv ethaddr 22.33.44.55.66.77' they configured ethernet address of the board but i get 'Can't overwrite "ethaddr"' ! – croc Mar 13 '13 at 05:53
Looking at the output from U-Boot's help there don't appear to be any network setup commands. Can you please try the following (1) Power off the board, wait a minute, power it on and try to TFTP the file as normally, then show us all the output, I am hoping this might give us some clues. (2) The [MII](http://en.wikipedia.org/wiki/Media_Independent_Interface) is another name for PHY, there should be a command such as "mii info" to list MII devices, "help mii" should show what MII commands are available, can you show the output from this too. – pav Mar 13 '13 at 08:52
(1) Powering the board off disconnects the Hyperterminal connection with the board via COM port. So when i turn the board ON i have to connect via Hyperterminal again. And sending the file with TFTP showed the same errors shown [here](https://www.dropbox.com/s/dtoi8juih08081h/tftp.txt). (2) Output with 'mii info' and 'help mii' are [here](https://www.dropbox.com/s/np5fcjam6o8vbou/mii.txt). – croc Mar 13 '13 at 09:13
I personally never use Hyperterminal, it always causes problems for me. Can I suggest you use an alternative terminal emulator such as [putty](http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html), it's much easier to use and [setup](http://www.omnisecu.com/cisco-certified-network-associate-ccna/how-to-use-putty-to-configure-or-monitor-a-cisco-router-or-switch.htm) and won't disconnect on you so we can then get the full output from power-on. Sorry about the "help mii", I probably should have said "mii help", oops :-) – pav Mar 13 '13 at 09:55
'mii help' shows same output as 'mii help'. With 'putty' the situation is also the same. When i turn the board off putty shows 'error reading from serial device' window and connection is to be made again when board is turned ON. By 'Power off the board' you meant switching off the board, right ? When the board is switched off the COM port will also be gone from windows. So after power ON i have to connect it again with putty/Hyperterminal. One other thing. I have to press the 'reset' button to get to the U-boot every time after making connection. – croc Mar 13 '13 at 11:04
Do you think the problem 'PHY not connected' might be because of faulty ethernet cable ? I mean faulty cross over connection. – croc Mar 13 '13 at 11:32
Ok, I now realise the serial port vanishes because it's USB. Are there any other MII commands such as "mii device" to list MII devices or just "mii" on it's own. The output from mii info looks like it's uninitialised. Yes, the ethernet cable could be a problem. On a good system you usually plug in the Ethernet and the PHY detects link up and negotiates with the other end to work out link speed and then prints out some kind of link up message - so try a different crossover ethernet cable as well as a straight through ethernet cable to see if this makes a difference. – pav Mar 13 '13 at 12:40
Thank you for your thoughts and patiently listening to me. I have contacted with the technical engineer of the vendor and confirmed that the board appears to be damaged. Thanks. – croc Mar 14 '13 at 09:45

PHY not connected !! MAC: error during MII initialization

2 Answers2