[U-Boot-Users] Debugging 85xx eTSEC's
Hi all,
Using u-boot from the latest git, I'm trying to debug our phy's on our custom 8548 board. Our eTSEC0 / eTSEC1 are mavell 88E1121 and eTSEC2 / eTSEC3 are 88E1111 - I'm trying to debug eTSEC2 since the 88E1111 seems to be supported by u-boot. I get this output from the serial port in debug mode:
eTSEC1 is in sgmii mode. eTSEC2 is in sgmii mode. eTSEC3 is in sgmii mode. eTSEC4 is in sgmii mode.
Net: eTSEC0: PHY is Unknown/Generic PHY (ffffffff) eTSEC1: PHY is Unknown/Generic PHY (ffffffff) eTSEC2: PHY is Unknown/Generic PHY (ffffffff) eTSEC3: PHY is Unknown/Generic PHY (ffffffff) eTSEC0, eTSEC1, eTSEC2, eTSEC3
Where 'is in sgmii mode' comes from standard 85xx stuff: I can't ping when setting ethact to be eTSEC2, and I get this when running 'mii info' :
=> mii info PHY_PHYIDR2 @ 0x0 = 0xffff PHY_PHYIDR2 @ 0x1 = 0xffff PHY_PHYIDR2 @ 0x2 = 0xffff PHY_PHYIDR2 @ 0x3 = 0xffff Can't read PHY at address 4 ...
My defines are:
#if defined(CONFIG_TSEC_ENET)
#ifndef CONFIG_NET_MULTI #define CONFIG_NET_MULTI 1 #endif
#define CONFIG_MII 1 /* MII PHY management */ #define CONFIG_TSEC1 1 #define CONFIG_TSEC1_NAME "eTSEC0" #define CONFIG_TSEC2 1 #define CONFIG_TSEC2_NAME "eTSEC1" #define CONFIG_TSEC3 1 #define CONFIG_TSEC3_NAME "eTSEC2" #define CONFIG_TSEC4 1 #define CONFIG_TSEC4_NAME "eTSEC3" #undef CONFIG_MPC85XX_FEC
#define TSEC1_PHY_ADDR 0 #define TSEC2_PHY_ADDR 1 #define TSEC3_PHY_ADDR 2 #define TSEC4_PHY_ADDR 3
#define TSEC1_PHYIDX 0 #define TSEC2_PHYIDX 0 #define TSEC3_PHYIDX 0 #define TSEC4_PHYIDX 0 #define TSEC1_FLAGS TSEC_GIGABIT #define TSEC2_FLAGS TSEC_GIGABIT #define TSEC3_FLAGS TSEC_GIGABIT #define TSEC4_FLAGS TSEC_GIGABIT
/* Options are: eTSEC[0-3] */ #define CONFIG_ETHPRIME "eTSEC0" #define CONFIG_PHY_GIGE 1 /* Include GbE speed/duplex detection */ #endif /* CONFIG_TSEC_ENET */
Any ideas? Robert
robert lazarski wrote:
Hi all,
Using u-boot from the latest git, I'm trying to debug our phy's on our custom 8548 board. Our eTSEC0 / eTSEC1 are mavell 88E1121 and eTSEC2 / eTSEC3 are 88E1111 - I'm trying to debug eTSEC2 since the 88E1111 seems to be supported by u-boot. I get this output from the serial port in debug mode:
eTSEC1 is in sgmii mode. eTSEC2 is in sgmii mode. eTSEC3 is in sgmii mode. eTSEC4 is in sgmii mode.
Sorry, can't speak to this, except that there's typically a single register for each interface where you choose between GMII, SGMII, RGMII etc. Maybe the eTSEC defaults to serial gigabit. The code will tell you...
Net: eTSEC0: PHY is Unknown/Generic PHY (ffffffff) eTSEC1: PHY is Unknown/Generic PHY (ffffffff) eTSEC2: PHY is Unknown/Generic PHY (ffffffff) eTSEC3: PHY is Unknown/Generic PHY (ffffffff) eTSEC0, eTSEC1, eTSEC2, eTSEC3
Where 'is in sgmii mode' comes from standard 85xx stuff: I can't ping when setting ethact to be eTSEC2, and I get this when running 'mii info' :
=> mii info PHY_PHYIDR2 @ 0x0 = 0xffff PHY_PHYIDR2 @ 0x1 = 0xffff PHY_PHYIDR2 @ 0x2 = 0xffff PHY_PHYIDR2 @ 0x3 = 0xffff Can't read PHY at address 4 ...
Sorry if this seems like an obnoxious question, but are these the addresses your PHYs are wired to? Are you sure the PHYs are powered up properly? It looks like the MDIO controller doesn't see anything when it polls the devices. Double check your schematic and maybe probe the MDIO bus when you issue the 'mii info' command. MDIO is a lot like I2C (pretty low speed serial, easy to probe).
regards, Ben
robert lazarski schrieb:
Where 'is in sgmii mode' comes from standard 85xx stuff: I can't ping when setting ethact to be eTSEC2, and I get this when running 'mii info' :
=> mii info PHY_PHYIDR2 @ 0x0 = 0xffff PHY_PHYIDR2 @ 0x1 = 0xffff PHY_PHYIDR2 @ 0x2 = 0xffff PHY_PHYIDR2 @ 0x3 = 0xffff Can't read PHY at address 4 ... Any ideas?
As Ben mentioned already, check your hardware: Check the hw configured PHY addresses. Then you should see at least proper IDs when you do the mii info. PullUps on the MDC/MDIO lines? You should be able to see some traffic there with an oscilloscope.
Then, double-check the PHY configuration and it's host interface setting...(CONFIGx<->LEDy connections) The MV88E1111 should work with the generic PHY initialization since the Marvell PHYs have a quite compatible standard register set.
If you want, you can send me this part of the schematic for review. I have the MV88E1111 on the MPC85xx working fine using GMII.
Regards,
Hi Robert,
Check the MDIO and MDC lines on your custom board.
It seems like you are not able to read the PHY ID. And also check the phy address configuration in the u-boot board config file.
-Balakumar Chinnusamy
----- Original Message ----- From: "robert lazarski" robertlazarski@gmail.com To: u-boot-users@lists.sourceforge.net Sent: Friday, October 26, 2007 2:27 PM Subject: [U-Boot-Users] Debugging 85xx eTSEC's
Hi all,
Using u-boot from the latest git, I'm trying to debug our phy's on our custom 8548 board. Our eTSEC0 / eTSEC1 are mavell 88E1121 and eTSEC2 / eTSEC3 are 88E1111 - I'm trying to debug eTSEC2 since the 88E1111 seems to be supported by u-boot. I get this output from the serial port in debug mode:
eTSEC1 is in sgmii mode. eTSEC2 is in sgmii mode. eTSEC3 is in sgmii mode. eTSEC4 is in sgmii mode.
Net: eTSEC0: PHY is Unknown/Generic PHY (ffffffff) eTSEC1: PHY is Unknown/Generic PHY (ffffffff) eTSEC2: PHY is Unknown/Generic PHY (ffffffff) eTSEC3: PHY is Unknown/Generic PHY (ffffffff) eTSEC0, eTSEC1, eTSEC2, eTSEC3
Where 'is in sgmii mode' comes from standard 85xx stuff: I can't ping when setting ethact to be eTSEC2, and I get this when running 'mii info' :
=> mii info PHY_PHYIDR2 @ 0x0 = 0xffff PHY_PHYIDR2 @ 0x1 = 0xffff PHY_PHYIDR2 @ 0x2 = 0xffff PHY_PHYIDR2 @ 0x3 = 0xffff Can't read PHY at address 4 ...
My defines are:
#if defined(CONFIG_TSEC_ENET)
#ifndef CONFIG_NET_MULTI #define CONFIG_NET_MULTI 1 #endif
#define CONFIG_MII 1 /* MII PHY management */ #define CONFIG_TSEC1 1 #define CONFIG_TSEC1_NAME "eTSEC0" #define CONFIG_TSEC2 1 #define CONFIG_TSEC2_NAME "eTSEC1" #define CONFIG_TSEC3 1 #define CONFIG_TSEC3_NAME "eTSEC2" #define CONFIG_TSEC4 1 #define CONFIG_TSEC4_NAME "eTSEC3" #undef CONFIG_MPC85XX_FEC
#define TSEC1_PHY_ADDR 0 #define TSEC2_PHY_ADDR 1 #define TSEC3_PHY_ADDR 2 #define TSEC4_PHY_ADDR 3
#define TSEC1_PHYIDX 0 #define TSEC2_PHYIDX 0 #define TSEC3_PHYIDX 0 #define TSEC4_PHYIDX 0 #define TSEC1_FLAGS TSEC_GIGABIT #define TSEC2_FLAGS TSEC_GIGABIT #define TSEC3_FLAGS TSEC_GIGABIT #define TSEC4_FLAGS TSEC_GIGABIT
/* Options are: eTSEC[0-3] */ #define CONFIG_ETHPRIME "eTSEC0" #define CONFIG_PHY_GIGE 1 /* Include GbE speed/duplex detection */ #endif /* CONFIG_TSEC_ENET */
Any ideas? Robert
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
On 10/27/07, C Balakumar c.balakumar@gdatech.co.in wrote:
Hi Robert,
Check the MDIO and MDC lines on your custom board.
It seems like you are not able to read the PHY ID. And also check the phy address configuration in the u-boot board config file.
The MDIO and MDC lines had a jumper in the wrong place, thanks for the help everyone. This is what I get now as only eTSEC2 is currently mounted on the board:
eTSEC2: PHY is Marvell 88E1111S (1410cc2)
=> mii info PHY_PHYIDR2 @ 0x0 = 0xffff PHY_PHYIDR2 @ 0x1 = 0xffff PHY_PHYIDR2 @ 0x2 = 0x0cc2 PHY_PHYIDR[1,2] @ 0x2 = 0x01410cc2 PHY 0x02: OUI = 0x5043, Model = 0x0C, Rev = 0x02, 10baseT, HDX PHY_PHYIDR2 @ 0x3 = 0xffff
However, I still can't ping:
=> setenv ethact eTSEC2 => setenv netdev eth2 => ping 10.101.43.10 eTSEC2: No link. Speed: 1000, full duplex Using eTSEC3 device ping failed; host 10.101.43.10 is not alive
I have a feeling this may be because eTSEC2 is in sgmii mode and not rgmii - does that make sense? Do TSEC's in u-boot fall into sgmii by default? My code detects sgmii :
void pci_init_board(void) { volatile immap_t *immap = (immap_t *)CFG_IMMR; volatile ccsr_gur_t *gur = &immap->im_gur; uint devdisr = gur->devdisr; uint io_sel = (gur->pordevsr & MPC85xx_PORDEVSR_IO_SEL) >> 19; uint host_agent = (gur->porbmsr & MPC85xx_PORBMSR_HA) >> 16;
debug (" pci_init_board: devdisr=%x, io_sel=%x, host_agent=%x\n", devdisr, io_sel, host_agent);
if (io_sel & 1) { if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII1_DIS)) printf (" eTSEC1 is in sgmii mode.\n"); if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII2_DIS)) printf (" eTSEC2 is in sgmii mode.\n"); if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII3_DIS)) printf (" eTSEC3 is in sgmii mode.\n"); if (!(gur->pordevsr & MPC85xx_PORDEVSR_SGMII4_DIS)) printf (" eTSEC4 is in sgmii mode.\n"); } ... }
I've been looking at the tsec driver and the code for the 88E1111S in particular and its unclear to me so far how to ensure that all my TSEC's are in rgmii mode. Any ideas?
Thanks, Robert
robert lazarski schrieb:
I've been looking at the tsec driver and the code for the 88E1111S in particular and its unclear to me so far how to ensure that all my TSEC's are in rgmii mode. Any ideas?
Just for example: Datasheet of MV88E1111, Page 48, Chapter 2.2.1: The (MAC) interface is selected by setting the HWCFG_MODE[3..0]='xxxx'.......
Please RTFM or contact the board manufacturer regarding this stuff!
Regards,
Clemens Koller __________________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com
On 10/31/07, Clemens Koller clemens.koller@anagramm.de wrote:
robert lazarski schrieb:
I've been looking at the tsec driver and the code for the 88E1111S in particular and its unclear to me so far how to ensure that all my TSEC's are in rgmii mode. Any ideas?
Just for example: Datasheet of MV88E1111, Page 48, Chapter 2.2.1: The (MAC) interface is selected by setting the HWCFG_MODE[3..0]='xxxx'.......
In the rgmii mode case we were able to verify that once the u-boot tsec code runs, it places the pordevsr register of the 8548 into rgmii - which the hardware guys tells me is all we need. We still can't ping though, nor see any arp activity on the pinged host. To reiterate:
1) We see our phy with 'mii info' :
=> mii info 0x2 PHY_PHYIDR2 @ 0x2 = 0x0cc2 PHY_PHYIDR[1,2] @ 0x2 = 0x01410cc2 PHY 0x02: OUI = 0x5043, Model = 0x0C, Rev = 0x02, 10baseT, HDX
2) We can change our 8E1111 phy via 'mii write' which tells us the mdio lines and clock are working. Here's going from the default state after hw reset to loopback mode:
=> mii dump 0x2 0 0. (1140) -- PHY control register -- (8000:0000) 0.15 = 0 reset (4000:0000) 0.14 = 0 loopback (2040:0040) 0. 6,13 = b10 speed selection = 1000 Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0000) 0.11 = 0 power-down (0400:0000) 0.10 = 0 isolate (0200:0000) 0. 9 = 0 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0000) 0. 7 = 0 collision test enable (003f:0000) 0. 5- 0 = 0 (reserved)
=> mii write 0x2 0 0x5140 => mii dump 0x2 0 0. (5140) -- PHY control register -- (8000:0000) 0.15 = 0 reset (4000:4000) 0.14 = 1 loopback (2040:0040) 0. 6,13 = b10 speed selection = 1000 Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0000) 0.11 = 0 power-down (0400:0000) 0.10 = 0 isolate (0200:0000) 0. 9 = 0 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0000) 0. 7 = 0 collision test enable (003f:0000) 0. 5- 0 = 0 (reserved)
Incidently, this brings the link down so we are still determining the best way to use loopback to identify the problem.
3) We can't auto negotiate. However, we can change the data speed from 1000/100/10 and see the proper signals and frequencies from the processor to the phy.
4) Our problem is we can't see any activity from the phy to the RJ45, nor succeed with pings and arp.
There was an offer a few threads back to look at our schematic. Here's the link:
http://braziloutsource.com/random/atum_85xx_ethernet.pdf
Thanks all for the continuing help, Robert
robert lazarski schrieb:
There was an offer a few threads back to look at our schematic. Here's the link:
"403 - Forbidden"
You can send it directly to me if you want.
Regards,
Clemens Koller __________________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com
On Nov 5, 2007 2:59 PM, Clemens Koller clemens.koller@anagramm.de wrote:
robert lazarski schrieb:
There was an offer a few threads back to look at our schematic. Here's the link:
"403 - Forbidden"
You can send it directly to me if you want.
Oops, link fixed and I sent you the pdf as an attachment. Thanks alot, Robert
On Nov 5, 2007 5:57 PM, robert lazarski robertlazarski@gmail.com wrote:
On Nov 5, 2007 2:59 PM, Clemens Koller clemens.koller@anagramm.de wrote:
robert lazarski schrieb:
There was an offer a few threads back to look at our schematic. Here's the link:
"403 - Forbidden"
You can send it directly to me if you want.
Oops, link fixed and I sent you the pdf as an attachment. Thanks alot, Robert
Thanks Clemens for the kind review you gave us off list. In the case its might help someone else someday, we found the problem as our pinouts were wrong to the NET's
-PIN of the PHY- -NAME we gave to the NET- LED_LINK_10 LED_LINK_100 LED_LINK_100 LED_LINK_1000 LED_LINK_1000 LED_DUPLEX LED_LINK_DUPLEX LED_LINK_10
We can now ping, use tftp etc. Robert
robert lazarski schrieb:
Thanks Clemens for the kind review you gave us off list. In the case its might help someone else someday, we found the problem as our pinouts were wrong to the NET's
-PIN of the PHY- -NAME we gave to the NET- LED_LINK_10 LED_LINK_100 LED_LINK_100 LED_LINK_1000 LED_LINK_1000 LED_DUPLEX LED_LINK_DUPLEX LED_LINK_10
We can now ping, use tftp etc. Robert
Fine to hear it is working now! And thanks for the flowers. ;-) I also had to check the PHY configuration on my board many times to make sure everything is right. It's easy to make mistakes here. @:-]
There is propably a way to show and re-configure this at run-time with u-boot via the mdio interface, isn't it?
Regards,
participants (4)
-
Ben Warren -
C Balakumar -
Clemens Koller -
robert lazarski