[U-Boot] PPC + NatSemi dp83640 phy?

[U-Boot] PPC + NatSemi dp83640 phy?

[Nathan French]

Hi all,

I've been tasked with bringing up a new board next week for my company
that is essentially a Kilauea with a National Semiconductor DP83640
ethernet phy.  We have U-Boot working on our previous board rev which
used the Marvell 88E1111 ethernet phy which U-Boot supports.

I'm new to ethernet devices.  I see that both the 88E1111 and the
DP83xxx devices use MII.  Does this mean the DP83640 may just work as
is?

Thanks,

Nathan French

[U-Boot] PPC + NatSemi dp83640 phy?

[Jerry Van Baren]

Hi Nathan,

Nathan French wrote:
> Hi all,
> 
> I've been tasked with bringing up a new board next week for my company
> that is essentially a Kilauea with a National Semiconductor DP83640
> ethernet phy.  We have U-Boot working on our previous board rev which
> used the Marvell 88E1111 ethernet phy which U-Boot supports.
> 
> I'm new to ethernet devices.  I see that both the 88E1111 and the
> DP83xxx devices use MII.  Does this mean the DP83640 may just work as
> is?

Maybe.  My impression of and experience with the MII standard is that it 
has lots of room for different "standard" implementations as well as 
non-standard behavior.  Maybe things are better now.  Or not.

Theoretically, you should be able to drop in any PHY, use just the 
standardized registers and behavior, and have it work.  In practice, 
maybe, maybe not.  My (somewhat dated) experience is that I ended up 
twiddling with "implementation extension" registers to get the behavior 
I wanted.

If you look at the u-boot and linux PHY drivers, you will see a lot of 
manufacturer's names.  Not a good sign.  On the other hand, there is 
also a concept of a "generic" PHY.  If "generic" works, that is great.

BTW, it is helpful to enable the MII command so that you can poke around 
in your PHY's registers.

> Thanks,
> 
> Nathan French

Have fun,
gvb

[U-Boot] PPC + NatSemi dp83640 phy?

[Nathan French]

Just thought I'd mention what I did to get this working in case anyone
else tries to integrate this phy into their system.  Basic idea is set
the right phy address and set the PPC MII register for 1 MII port
instead of 2 RGMII ports.

SVN diffs follow.  Thanks for the support.


--- include/configs/ap_rev3.h	(revision 2955)
+++ include/configs/ap_rev3.h	(working copy)
@@ -223,10 +223,9 @@
 #define CONFIG_DP83640_PHY 1 /* National Semiconductor DP83640 MII-compliant ethernet phy */
 #define CONFIG_IBM_EMAC4_V4	1
 #define CONFIG_MII		1	/* MII PHY management		*/
-#define CONFIG_PHY_ADDR		1	/* PHY address, See schematics	*/
+#define CONFIG_PHY_ADDR		0x11	/* PHY address, See schematics	*/
 
 #define CONFIG_PHY_RESET	1	/* reset phy upon startup	*/
-#define CONFIG_PHY_GIGE		1	/* Include GbE speed/duplex detection */
 
 #define CONFIG_HAS_ETH0		1


--- cpu/ppc4xx/4xx_enet.c       (revision 2955)
+++ cpu/ppc4xx/4xx_enet.c       (working copy)
@@ -431,10 +431,21 @@
         */
        switch (1) {
        case 1:
+        // ONRAMP_MOD
+#if defined(CONFIG_APREV3)
+               /* 1x MII ports */
+               out_be32((void *)RGMII_FER, 0x00000007);
+               bis->bi_phymode[0] = BI_PHYMODE_MII;
+               bis->bi_phymode[1] = BI_PHYMODE_NONE;
+#else
+        // ONRAMP_MOD
                /* 2 x RGMII ports */
                out_be32((void *)RGMII_FER, 0x00000055);
                bis->bi_phymode[0] = BI_PHYMODE_RGMII;
                bis->bi_phymode[1] = BI_PHYMODE_RGMII;
+        // ONRAMP_MOD
+#endif
+        // ONRAMP_MOD



On Wed, 2009-04-15 at 21:24 -0400, Jerry Van Baren wrote:
> Hi Nathan,
> 
> Nathan French wrote:
> > Hi all,
> > 
> > I've been tasked with bringing up a new board next week for my company
> > that is essentially a Kilauea with a National Semiconductor DP83640
> > ethernet phy.  We have U-Boot working on our previous board rev which
> > used the Marvell 88E1111 ethernet phy which U-Boot supports.
> > 
> > I'm new to ethernet devices.  I see that both the 88E1111 and the
> > DP83xxx devices use MII.  Does this mean the DP83640 may just work as
> > is?
> 
> Maybe.  My impression of and experience with the MII standard is that it 
> has lots of room for different "standard" implementations as well as 
> non-standard behavior.  Maybe things are better now.  Or not.
> 
> Theoretically, you should be able to drop in any PHY, use just the 
> standardized registers and behavior, and have it work.  In practice, 
> maybe, maybe not.  My (somewhat dated) experience is that I ended up 
> twiddling with "implementation extension" registers to get the behavior 
> I wanted.
> 
> If you look at the u-boot and linux PHY drivers, you will see a lot of 
> manufacturer's names.  Not a good sign.  On the other hand, there is 
> also a concept of a "generic" PHY.  If "generic" works, that is great.
> 
> BTW, it is helpful to enable the MII command so that you can poke around 
> in your PHY's registers.
> 
> > Thanks,
> > 
> > Nathan French
> 
> Have fun,
> gvb