Poor SMSC911x (GPMC) performance on AM3517

So we've learned a LOT more about this issue...

First off, several of our comments above regarding the LAN9221 vs LAN9220 are definitely incorrect.  Further reading has shown that the LAN9221 and LAN9220 are very different parts.  The parts do not share a datasheet as we initially thought, and though they appear to be pin compatible and the basic reference design looks identical, from a timing perspective they are very different chips.  The LAN9221 is MUCH faster than the LAN9220.  We finally stumbled across this post (http://lists.denx.de/pipermail/u-boot/2010-January/065941.html) from Scott Ellis, and that cleared things up quite a bit for us regarding timings.  That explains why we're seeing these "default" timings as we call them spreading throughout u-boot as it matures.  However, it does not explain fully why our performance is still so poor, particularly with regards to dropped RX packets.

We also played around with several of the timings and debugging options, and were quickly able to see the kernel oops move on and start blaming other processes.  We suspected that would likely be the case, but since it was so repetitive before we tweaked the debugging, we thought it worth mentioning at the time.

Once we enabled enough debugging, with the LAN9221 settings enabled by u-boot, we saw several

[    1.175872] smsc911x smsc911x.0: eth0: smsc911x_phy_check_loopbackpkt: Failed to transmit during loopback test

print before the driver finally gave up.  Googles on that gave us:  http://www.spinics.net/lists/netdev/msg186609.html.  The post refers to a completely different SMSC part (a LAN9215 this time), but the patch did "work" - as much as crippling prints can "work".

We've settled on the notion that these "default" timings are likely fine for the LAN9220 on our hardware based on what we've learned.  However, that does not address why we're dropping packets on RX when we use these "recommended" timings.  As noted in the first post, that's the core issue for us.

We've went clear back to the 2.6.37 kernel supported by the TI-PSP, but found that having the same dropped packets / performance issue.  I have to believe that even if performance is relatively poor, say 45Mbps, it is possible to get a LAN9220 to function without dropping packets.

Is anyone out there seeing this as well, or have any thoughts on the subject?  Any help would be greatly appreciated.

First a quick update:

We have substituted a LAN9221 for the LAN9220.  With the new chip, we used the GPMC timings we found for the Gumstix Overo (http://lists.denx.de/pipermail/u-boot/2011-September/100752.html) that were shown in the original message and pasted below for quick reference.  Granted, these are for an OMAP35xx, not our AM3517, but we gave them a try...

+/* GPMC CS configuration for an SMSC LAN9221 ethernet controller */
+#define NET_LAN9221_GPMC_CONFIG1 0x00001000
+#define NET_LAN9221_GPMC_CONFIG2 0x00060700
+#define NET_LAN9221_GPMC_CONFIG3 0x00020201
+#define NET_LAN9221_GPMC_CONFIG4 0x06000700
+#define NET_LAN9221_GPMC_CONFIG5 0x0006090A
+#define NET_LAN9221_GPMC_CONFIG6 0x87030000
+#define NET_LAN9221_GPMC_CONFIG7 0x00000f6c

We've run with these for a while now, and have been very satisfied with the performance.  It runs around the >80Mbps mark with 0% packet loss.  However, we're experiencing a nagging "slab error" that we think could be attributed to our GPMC configuration.  Does that sound reasonable?  We've reached out directly to the linux-omap community for support (http://www.spinics.net/lists/linux-omap/index.html#71227), but felt it good try here as well.

To be honest, we've never fully figured out how these values should be calculated, or even how our clocks are configured.  Should the OMAP35x GPMC timings work with our AM3517?  Moreover, we've seen a few different options for the LAN9221.  The timings above come from the patch referenced above, but here are a few more for the LAN9221 from another patch (http://git.isee.biz/?p=pub/scm/u-boot-arm.git;a=blobdiff;f=board/isee/igep0020/igep0020.h;h=0f2b43f5a8a8331d6db4dee9fc77d6890551662f;hp=2573bdcafcb7a13de47680288962ff4623954118;hb=672483216626693485c9285672186333591fcdb3;hpb=e4a8d18d53558ce80b242276d05ea9dbb5570f5f):

+/* OMAP35x GPMC CS 5 connected to an SMSC LAN9221 ethernet controller */
+#define NET_35X_LAN9221_GPMC_CONFIG1    0x00001000
+#define NET_35X_LAN9221_GPMC_CONFIG2    0x00080701
+#define NET_35X_LAN9221_GPMC_CONFIG3    0x00020201
+#define NET_35X_LAN9221_GPMC_CONFIG4    0x08030703
+#define NET_35X_LAN9221_GPMC_CONFIG5    0x00060908
+#define NET_35X_LAN9221_GPMC_CONFIG6    0x87030000
+#define NET_35X_LAN9221_GPMC_CONFIG7    0x00000f6c
+
+/* DM37x GPMC CS 5 connected to an SMSC LAN9221 ethernet controller */
+#define NET_37X_LAN9221_GPMC_CONFIG1    0x00001000
+#define NET_37X_LAN9221_GPMC_CONFIG2    0x00090901
+#define NET_37X_LAN9221_GPMC_CONFIG3    0x00080300
+#define NET_37X_LAN9221_GPMC_CONFIG4    0x09010901
+#define NET_37X_LAN9221_GPMC_CONFIG5    0x03080a0a
+#define NET_37X_LAN9221_GPMC_CONFIG6    0x880002c7
+#define NET_37X_LAN9221_GPMC_CONFIG7    0x00000f6c
 

We've not tried any of these, but why the difference between "OMAP35x" settings?  Is one set right and the other wrong, or does this have to do with clocking or other differences?

For that matter, can the AM3517's GPMC even support the 9221?  I note the slower 9220 is used on several dev. kits.  Is there a reason for that rather than the 9221?

Any help would be greatly appreciated.

Thanks!

CFAdad said:

To be honest, we've never fully figured out how these values should be calculated, or even how our clocks are configured.  Should the OMAP35x GPMC timings work with our AM3517?  Moreover, we've seen a few different options for the LAN9221.  The timings above come from the patch referenced above, but here are a few more for the LAN9221 from another patch (http://git.isee.biz/?p=pub/scm/u-boot-arm.git;a=blobdiff;f=board/isee/igep0020/igep0020.h;h=0f2b43f5a8a8331d6db4dee9fc77d6890551662f;hp=2573bdcafcb7a13de47680288962ff4623954118;hb=672483216626693485c9285672186333591fcdb3;hpb=e4a8d18d53558ce80b242276d05ea9dbb5570f5f):

+/* OMAP35x GPMC CS 5 connected to an SMSC LAN9221 ethernet controller */
+#define NET_35X_LAN9221_GPMC_CONFIG1    0x00001000
+#define NET_35X_LAN9221_GPMC_CONFIG2    0x00080701
+#define NET_35X_LAN9221_GPMC_CONFIG3    0x00020201
+#define NET_35X_LAN9221_GPMC_CONFIG4    0x08030703
+#define NET_35X_LAN9221_GPMC_CONFIG5    0x00060908
+#define NET_35X_LAN9221_GPMC_CONFIG6    0x87030000
+#define NET_35X_LAN9221_GPMC_CONFIG7    0x00000f6c
+
+/* DM37x GPMC CS 5 connected to an SMSC LAN9221 ethernet controller */
+#define NET_37X_LAN9221_GPMC_CONFIG1    0x00001000
+#define NET_37X_LAN9221_GPMC_CONFIG2    0x00090901
+#define NET_37X_LAN9221_GPMC_CONFIG3    0x00080300
+#define NET_37X_LAN9221_GPMC_CONFIG4    0x09010901
+#define NET_37X_LAN9221_GPMC_CONFIG5    0x03080a0a
+#define NET_37X_LAN9221_GPMC_CONFIG6    0x880002c7
+#define NET_37X_LAN9221_GPMC_CONFIG7    0x00000f6c

 

After a chunk more Googling, I found this patch (http://lists.denx.de/pipermail/u-boot/2011-September/100683.html) which apparently corrects the values from the quoted section above to match the set we've been using all this time...

OK, back to the central questions:  Is there any reason why a LAN9221 cannot be supported on an AM3517?  Assuming not, should these GPMC timings from an OM35xx work directly?  From what I've been able to dig up, it looks like the L3 is ~166MHz for both.  So it would appear so to me.

The GPMC is the same for both the AM35x and the OMAP35x and they are running at the same speed, so you should be good with the same timing if the board layout is the same. Here are a few things I would try:

1) verify that the connections are the same to the GPMC and if there are other things attached to the GPMC which could cause more loading.

2) if the connections are the same check to make sure the routing is similar.

3) Try relaxing the timings on the GPMC to see if the dropped packets go away

4) check to make sure there isn't a signal integrity issue on the LAN chip side. 

5) check to make sure the clock is stable. 

Hi Lawrence,

Thanks for following up, and thanks for the suggestions.  On our board, the only 2 things connected to the GPMC are some Micron NAND (MT29F4G16ABBDAH4-IT:D) and that LAN9221.  The 9221 is using the timings above that we borrowed, with great appreciation, from our friends in the Gumstix community for the OMAP35x.  The NAND timings are set by x-loader in include/asm/arch-omap3/mem.h, and we're using some defaults we saw there for other AM35x board.  The relevant segment of code from there can be seen at the bottom of this message.

In our case, we discovered that defining CONFIG_OMAP34XX, and using those SMNAND timings created problems.  The timings set instead by the AM35xx defines stabilized things dramatically.  In fact, with this combination of LAN9221 timings and NAND timings, we were able to run nandtest against the NAND while running the OS from an SD card, and could run iperf against the SMSC9221 simultaneously without crashing or failing either test.

Once again, we're FAR from GPMC timing experts, so I won't even pretend have a full grasp of why.   Can anyone shed some light on this for us?  And likewise, do you agree these timings should play nicely with each other?  Our hardware engineer scoped them and felt that the timings were running tight, but did not appear to be conflicting.  We're just looking for verification since again, we're not the GPMC experts.  At least not yet.  :-)

Thanks again!

#if defined (L3_165MHZ)
# define SMNAND_GPMC_CONFIG1 0x00000800
# define SMNAND_GPMC_CONFIG2 0x00141400
# define SMNAND_GPMC_CONFIG3 0x00141400
# define SMNAND_GPMC_CONFIG4 0x0F010F01
# define SMNAND_GPMC_CONFIG5 0x010C1414
# define SMNAND_GPMC_CONFIG6 0x1F0F0A80
# define SMNAND_GPMC_CONFIG7 0x00000C44

#if defined (CONFIG_OMAP34XX)

# define M_NAND_GPMC_CONFIG1 0x00001800
# define M_NAND_GPMC_CONFIG2 SMNAND_GPMC_CONFIG2
# define M_NAND_GPMC_CONFIG3 SMNAND_GPMC_CONFIG3
# define M_NAND_GPMC_CONFIG4 SMNAND_GPMC_CONFIG4
# define M_NAND_GPMC_CONFIG5 SMNAND_GPMC_CONFIG5
# define M_NAND_GPMC_CONFIG6 SMNAND_GPMC_CONFIG6
# define M_NAND_GPMC_CONFIG7 SMNAND_GPMC_CONFIG7

#elif defined (CONFIG_AM3517EVM) || defined (CONFIG_AM3517TEB) \
   || defined (CONFIG_CM_T3X) || defined (CONFIG_TAM3517)

#ifdef NAND_16BIT
# define M_NAND_GPMC_CONFIG1 0x00001800
#else
# define M_NAND_GPMC_CONFIG1 0x00000800
#endif
# define M_NAND_GPMC_CONFIG2 0x00080800
# define M_NAND_GPMC_CONFIG3 0x00080800
# define M_NAND_GPMC_CONFIG4 0x06000600
# define M_NAND_GPMC_CONFIG5 0x00070808
# define M_NAND_GPMC_CONFIG6 0x000003cf
# define M_NAND_GPMC_CONFIG7 0x00000848

#endif

Hi,

I am facing similar issue on my setup.

Iam using SMSC9215 and AM3703. I am trying to upgrade to linux 2.6.37 kernel. Though it is working on 2.6.32.

I find the packets are dropped.

Any inputs are welcome.

Thanks.