[U-Boot] MPC8548 not able to detect Marvell 88E1145 PHY
Hi Sir/Madam,
We were working on EP8548A board (MPC8548E silicon revision 2.0) which had a u-boot 1.2.0. Also, MPC8548 eTSECn was connected to a Marvell PHY(D0 version) chip 88E1145(4 ports) and 2 ethernet ports are working fine.
Now we have a custom board which is similar to EP8548A. But with MPC8548E silicon revision 2.1 and Marvell PHY with E0 version. The eTSECn is conntected to Marvell PHY(4 ports) chip. I'm able to boot our custom board using the same u-boot 1.2.0 which was used for EP8548 board. But I'm not able to detect and configure my PHY chip. I have a board configuration file with TSEC related macros as below
#define CONFIG_MII 1 /* MII PHY management */ #define CONFIG_MPC85XX_TSEC1 1 #define CONFIG_MPC85XX_TSEC1_NAME "eTSEC0" #define CONFIG_MPC85XX_TSEC2 1 #define CONFIG_MPC85XX_TSEC2_NAME "eTSEC1" #define CONFIG_MPC85XX_TSEC3 1 #define CONFIG_MPC85XX_TSEC3_NAME "eTSEC2" #define CONFIG_MPC85XX_TSEC4 1 #define CONFIG_MPC85XX_TSEC4_NAME "eTSEC3"
#define TSEC1_PHY_ADDR 0 #define TSEC2_PHY_ADDR 1 #define TSEC3_PHY_ADDR 2 #define TSEC4_PHY_ADDR 3
#define TSEC1_FLAGS TSEC_GIGABIT | TSEC_REDUCED #define TSEC2_FLAGS TSEC_GIGABIT | TSEC_REDUCED #define TSEC3_FLAGS TSEC_GIGABIT | TSEC_REDUCED #define TSEC4_FLAGS TSEC_GIGABIT | TSEC_REDUCED
#define TSEC1_PHYIDX 0 #define TSEC2_PHYIDX 0 #define TSEC3_PHYIDX 0 #define TSEC4_PHYIDX 0
/* Options are: eTSEC[0-3] */ #define CONFIG_ETHPRIME "eTSEC0"
When the U-boot comes up i get the below display:
U-Boot 1.2.0 (Jan 5 2009 - 10:18:30)
CPU: 8548_E, Version: 2.1, (0x80390021) Core: E500, Version: 2.2, (0x80210022) Clock Configuration: CPU: 666 MHz, CCB: 266 MHz, DDR: 133 MHz, LBC: 33 MHz L1: D-cache 32 kB enabled I-cache 32 kB enabled Board: .......... I2C: ready DRAM: Initializing DDR: 512 MB SRIO: disabled FLASH: 128 MB L2 cache 512KB: enabled *** Warning - bad CRC, using default environment
PCIe: disabled In: serial Out: serial Err: serial Net: eTSEC0: PHY id ffffffff is not supported! eTSEC0: No PHY found eTSEC1: PHY id ffffffff is not supported! eTSEC1: No PHY found eTSEC2: PHY id ffffffff is not supported! eTSEC2: No PHY found eTSEC3: PHY id ffffffff is not supported! eTSEC3: No PHY found eTSEC0, eTSEC1, eTSEC2, eTSEC3 Hit any key to stop autoboot: 0 ## Booting image at fc000000 ... Bad Magic Number <board>=>
Later we scanned through all the PHY address(0 to 31) and only ONE port's PHY address(0x12) was successfully read.
Our queries are as follows
1. Why were we not able to detect and configure the PHY in the first attempt???
2. Why other PHY address are not set. We checked the Hardware its correct.
From MARVEL the PHY address is 0,1,2,3 - but MPC is reading PHY address as
0x12 but not others.
2. We connected LAN cable to the PORT 0x12, still its not getting pinged.
We have connected in RGMII mode (TSEC0) During POR the POR register are getting configured for default (GMII) mode, how can we change the PORT to RGMII, after Boot.
1. in Marvel - MDIO is selected in Configuration, and also in Four Independented Serial Management Mode.
Please help me in this regard.
Thanks, Ajeesh Kumar
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.
On Mon, Jan 5, 2009 at 2:57 AM, Ajeesh Kumar ajeesh@tataelxsi.co.in wrote:
Hi Sir/Madam,
Net: eTSEC0: PHY id ffffffff is not supported! eTSEC0: No PHY found eTSEC1: PHY id ffffffff is not supported! eTSEC1: No PHY found eTSEC2: PHY id ffffffff is not supported! eTSEC2: No PHY found eTSEC3: PHY id ffffffff is not supported! eTSEC3: No PHY found eTSEC0, eTSEC1, eTSEC2, eTSEC3 Hit any key to stop autoboot: 0
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.
- We connected LAN cable to the PORT 0x12, still its not getting pinged.
We have connected in RGMII mode (TSEC0) During POR the POR register are getting configured for default (GMII) mode, how can we change the PORT to RGMII, after Boot.
I don't believe you can change the data mode at runtime. You need to correctly configure the POR bits for RGMII if that's what you want to use. If you want to test your ethernet using port 0x12, you'll need to change your u-boot config, too, so that the driver knows which PHY to configure.
Andy
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.
Actually, We are configuring the PHY chip have an address 0,1,2 and 3 but I dunno why I could read only the address 0x12??
Could you help me in giving the MUST required hardware configuration that should be done so as to make the PHY chip come up.
Thanks, Ajeesh Kumar
-----Original Message----- From: Andy Fleming [mailto:afleming@gmail.com] Sent: Wednesday, January 07, 2009 12:02 AM To: ajeesh@tataelxsi.co.in Cc: u-boot@lists.denx.de; charlesniranjan@tataelxsi.co.in; raghut@tataelxsi.co.in; sibaprasad@tataelxsi.co.in Subject: Re: [U-Boot] MPC8548 not able to detect Marvell 88E1145 PHY
On Mon, Jan 5, 2009 at 2:57 AM, Ajeesh Kumar ajeesh@tataelxsi.co.in wrote:
Hi Sir/Madam,
Net: eTSEC0: PHY id ffffffff is not supported! eTSEC0: No PHY found eTSEC1: PHY id ffffffff is not supported! eTSEC1: No PHY found eTSEC2: PHY id ffffffff is not supported! eTSEC2: No PHY found eTSEC3: PHY id ffffffff is not supported! eTSEC3: No PHY found eTSEC0, eTSEC1, eTSEC2, eTSEC3 Hit any key to stop autoboot: 0
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.
- We connected LAN cable to the PORT 0x12, still its not getting pinged.
We have connected in RGMII mode (TSEC0) During POR the POR register are getting configured for default (GMII) mode, how can we change the PORT to RGMII, after Boot.
I don't believe you can change the data mode at runtime. You need to correctly configure the POR bits for RGMII if that's what you want to use. If you want to test your ethernet using port 0x12, you'll need to change your u-boot config, too, so that the driver knows which PHY to configure.
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.
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
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.
participants (2)
-
Ajeesh Kumar -
Andy Fleming