Hello Andy,
Except it's apparently not fine. The code is reporting that it is reading
0xffffffff as the value of the PHY identifier. That value is found by reading registers 2 and 3 >of the PHY. If the code is reporting that the value is 0xffffffff, then you have a series of possible culprits:
- The PHY's ID registers are programmed with 0xffff and 0xffff (unlikely)
- The Read command is not getting to the PHY
- The Read response is not getting to the MAC
- The PHY is not responding
- The bus is not properly conveying data (usually happens when the data
line is held high)
- The MIIM registers are corrupting the data
- The software is misreading the data
- The software is miswriting the command
You say that the scope saw the MDIO transactions. You should be able to
capture the read request for register 2 of PHY 0. Can you confirm
that:
Actually using the hard ware configuration pins P0_config0, P1_config0, P2_config0 and P3_config0 I have connected it to have an address 0x0, 0x1, 0x2 and 0x3. But, when I try to read the PHY_ID registers of these addresses I got the output as 0xFFFF.
Later, I tried scanning all expected PHY addresses (0 to 31), At that time I was able to read the PHY_ID from PHY register 0x12. Thus, only one PHY port got detected and I was able to read all the registers using miiphy utilities.
NOW, how could the port address change when I hard wired the addresses as 0,1,2 and 3??? Also, I could only read one port address. Why is it so???
Also, when initializing the Port (PHY address 0x12) with the below commands
static struct phy_info phy_info_M88E1145 = { 0x01410cd, "Marvell 88E1145", 4, (struct phy_cmd[]){ /* config */ /* Reset the PHY */ {MIIM_CONTROL, MIIM_CONTROL_RESET, NULL},
/* Errata E0, E1 */ {29, 0x001b, NULL}, {30, 0x418f, NULL}, {29, 0x0016, NULL}, {30, 0xa2da, NULL}, /* Errata END */ // {26, 0x000a, NULL}, /* disable signal detect input */
/*Configure the PHY*/ /*{29, 0x001b, NULL},*/ {MIIM_GBIT_CONTROL, MIIM_GBIT_CONTROL_INIT, NULL}, {MIIM_ANAR, MIIM_ANAR_INIT, NULL}, {MIIM_88E1011_PHY_SCR, MIIM_88E1011_PHY_MDI_X_AUTO, NULL}, {MIIM_88E1145_PHY_EXT_CR, 0, &m88e1145_setmode}, {MIIM_CONTROL, MIIM_CONTROL_RESET, NULL}, {MIIM_CONTROL, MIIM_CONTROL_INIT, NULL}, {miim_end,} }, (struct phy_cmd[]){ /* startup */ /* Status is read once to clear old link state */ {MIIM_STATUS, miim_read, NULL}, /* Auto-negotiate */ {MIIM_STATUS, miim_read, &mii_parse_sr}, {MIIM_88E1111_PHY_LED_CONTROL, MIIM_88E1111_PHY_LED_DIRECT, NULL}, /* Read the Status */ {MIIM_88E1011_PHY_STATUS, miim_read, &mii_parse_88E1011_psr}, {miim_end,} }, (struct phy_cmd[]){ /* shutdown */ {miim_end,} }, };
Even thought I am initializing the MIIM_ANAR(register number 0x4) register with a value 0x01e1, the value is not getting reflected. When I cross check the register using "mii read 0x12 4" I'm getting 0x0001.
Why is my initialization value not reflected???
I have difficulty imagining a situation where the software reads the wrong
value. Especially since you're using the same code that apparently worked before. The >thing that changed is the hardware, so the two most likely explanations are that your hardware has a bug which prevents communication with the PHY over >>
MDIO, or the POR strappings for the 8548 are not set up to enable MDIO.
If you're absolutely sure it's not the hardware, then the most likely cause
of this is some sort of bad pointer. 1.2 is several years old, so I wouldn't know where to >start, there.
What do you mean by "the POR strappings for the 8548 are not set up to enable MDIO." I dint understand... Also, I've a similar hard ware as EP8548A board, with marvel 88E1145 E1 version..
Please let me know if you have got any tricky idea to tackle this.
Thanks, Ajeesh Kumar
-----Original Message----- From: Andy Fleming [mailto:afleming@gmail.com] Sent: Wednesday, January 07, 2009 10:52 PM To: ajeesh@tataelxsi.co.in Cc: u-boot@lists.denx.de; raghut@tataelxsi.co.in; sibaprasad@tataelxsi.co.in Subject: Re: [U-Boot] MPC8548 not able to detect Marvell 88E1145 PHY
On Wed, Jan 7, 2009 at 3:54 AM, Ajeesh Kumar ajeesh@tataelxsi.co.in wrote:
Hi Andy,
Thanks for your info.
This points to a hardware problem. Do you have an oscilloscope? Take a
look at the MDIO pin, and see what's being sent, and what the reply is. The
protocol for MDIO is pretty simple. Make sure that the address on the
read request is good, and make sure that the reply is good. Yeah We do have a scope, when I probed MDIO I could find some transactions happening. Actually I was using the u-boot1.2 which was working fine with the EP8548A board. And I'm using the same code piece. So the protocol to read/write MII management interface will be
fine.
Except it's apparently not fine. The code is reporting that it is reading 0xffffffff as the value of the PHY identifier. That value is found by reading registers 2 and 3 of the PHY. If the code is reporting that the value is 0xffffffff, then you have a series of possible culprits:
* The PHY's ID registers are programmed with 0xffff and 0xffff (unlikely) * The Read command is not getting to the PHY * The Read response is not getting to the MAC * The PHY is not responding * The bus is not properly conveying data (usually happens when the data line is held high) * The MIIM registers are corrupting the data * The software is misreading the data * The software is miswriting the command
You say that the scope saw the MDIO transactions. You should be able to capture the read request for register 2 of PHY 0. Can you confirm that:
1) The read request comes out of the 8548, properly formatted 2) The read request arrives on the Marvell's MDIO pin properly formatted 3) The read response leaves the PHY with correct values from register 2 4) The read response arrives at the 8548 with correct values from register 2
I have difficulty imagining a situation where the software reads the wrong value. Especially since you're using the same code that apparently worked before. The thing that changed is the hardware, so the two most likely explanations are that your hardware has a bug which prevents communication with the PHY over MDIO, or the POR strappings for the 8548 are not set up to enable MDIO.
If you're absolutely sure it's not the hardware, then the most likely cause of this is some sort of bad pointer. 1.2 is several years old, so I wouldn't know where to start, there.
Andy
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.