[U-Boot-Users] Debugging 85xx eTSEC's

[U-Boot-Users] Debugging 85xx eTSEC's

[robert lazarski]

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

[U-Boot-Users] Debugging 85xx eTSEC's

[Ben Warren]

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

[U-Boot-Users] Debugging 85xx eTSEC's

[Clemens Koller]

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,
-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19

[U-Boot-Users] Debugging 85xx eTSEC's

[C Balakumar]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
> 

[U-Boot-Users] Debugging 85xx eTSEC's

[robert lazarski]

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

[U-Boot-Users] Debugging 85xx eTSEC's

[Clemens Koller]

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

[U-Boot-Users] Debugging 85xx eTSEC's

[robert lazarski]

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

[U-Boot-Users] Debugging 85xx eTSEC's

[Clemens Koller]

robert lazarski schrieb:
 >
 > 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

"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

[U-Boot-Users] Debugging 85xx eTSEC's

[robert lazarski]

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:
>  >
>  > http://braziloutsource.com/random/atum_85xx_ethernet.pdf
>
> "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

[U-Boot-Users] Debugging 85xx eTSEC's

[robert lazarski]

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:
> >  >
> >  > http://braziloutsource.com/random/atum_85xx_ethernet.pdf
> >
> > "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

[U-Boot-Users] Debugging 85xx eTSEC's

[Clemens Koller]

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,

-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19