Imx6 SabreLite board ethernet troubles

[leonidandronov2]

Hello,

We have bought several imx6 sabrelite rev-2 boards (6-20-13) which we planned to use in our project replacing imx53 boards. But we have troubles to connect this boards to our ethernet devices (no link or unstable link) . There are also troubles to connect board to commonly used equipment . Some ethernet switches can be connected to sabrelite  boards fine in almost any cases with any cable, some switches work only with certain cables, some devices do not bring link up with any cable. Some gigabit switches can be connected succesfully to sabrelite only with disabled gigabit feature or autonegotiation on imx board but this configuration does not help to connect to other devices. And so on – no system was found yet. It is unpredictable. There was no troubles with ethernet connections on imx53 board…

Has anyone else seen such behavior? Is it a known issue?

[vincentchou]

Hi! 

Have you been able to fix the issue?  We came across the same issues on our custom design boards.  We found the gigabit connection is very inconsistent.  It does not connect to every gigabit switch.  In addition, we also discover that the switch can be connected if we use ethtool to reset it to a lower speed like from full duplex to half duplex.  Also, the same behavior happens to both FEC freescale Generic driver and AR8035 driver (We use AR8035).  Have you had any suggestion to fix it?

Vincent

[kasperholtze]

Hi,

We have around 500 of these boards, and have the exact same issue on all boards. I have tried a lot of different configurations - fixed link configuration, auto negotiation and so on. The best configuration, which solves the issue in 90-95% of the times, is to enable auto negotiation, but advertise no more than 100Mbit/full duplex:

ethtool -s eth0 autoneg on advertise 0x008

We are building a custom board, with the same PHY (KSZ9021), and see some of the same issues here. But, by changing the PHY with a KSZ9031, the link seems completely stable. KSZ9021 and KSZ9031 are pin compatible, so it should be possible to replace the PHY. KSZ9031 uses only half the power - I don't know if that is related, but a problem could be that the PHY doesn't get the power it needs. I haven't tried replacing it on a SabreLite board, but I guess it should be fairly straight forward.

Br,

Kasper

[florianpantalea]

Hi Kasper, hi leonid,

I also experienced some troubles with SabreLite Ethernet link. I use the board to stream data continuously at about 42 MiB/s, the maximum I have been able to obtain. For historical reasons, I work with Embest SabreLite (Farnell Element14, not Boundary Devices).

On one board, I had this Ethernet link up/down toggling. After adding a small fan, the problem was solved.

On another board, I have a random system crash, sometimes network related. Adding the fan doesn't solve the problem.

Those of you who use the network interface may have noticed the KSZ9021RN is very hot, making the USB/Ethernet connector warm. I think the issue is in the board thermal design or some chip settings which causes overheating. I am also investigating U23, the LDO regulator providing 1.2 V to the core: there is almost no copper plane for heatsink which might be also an issue at high transfer rates.

Best regards,

Florian

[ronbolts]

Experiencing same issue. Link up / link down toggling.  Using IMX53 with PHY SMSC Lan8720.  Resolution is to detect unstable link and force negotiating at 10M from 100M.  I truly believe this is a HW link problem between the PHYs, but have not determined the root cause.  Only occurs on two devices connected directly to my board out of 100 different devices tested.  Do not know the phy of the others devices.

[leonidandronov2]

Hi Kasper,

Thank you very much for reply. In our cases your solution does not help. Currently ethernet works good only with 10Mbit/AutonegOff half or full duplex.

ethtool -s eth0 speed 10 duplex half autoneg off

For now I do not know if it is enough for us. Thank you for information about transceiver replacement possibility. I think we could replace it as need.

Regards, Leonid

[igorpadykov]

Hi Leonid

seems you need to upgrade U-Boot to v2015.07.

Without this update, some functions will fail.

Please read this post:

https://boundarydevices.com/compiling-latest-u-boot-for-i-mx6-2015-edition/

https://lists.yoctoproject.org/listinfo/meta-freescale

Also suggest to post this to meta-fsl-arm mailing list

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[leonidandronov2]

Hi,

Thank you for reply. Upgrade of U-boot has not helped. Seems like it is not software issue. SabreLite board somehow is very sensitive to the cable, which is used. I have never seen before that a change in direction of cable could help to link ethernet devices... But I have one cable that connects only in one direction, maybe I have to draw an arrow on it... :smileysad:

There is same issue in https://boundarydevices.com/i-mx6-frequently-asked-questions-and-answers/#comment-392 with no solution.

[leonidandronov2]

Hi Gary,

We have several Sabre Lite rev2 (6-20-13), and I think all of them have same troubles (I tried 4-5 board).

Actually we are trying to use SabreLite boards with our custom designed boards based on Intel lxt921a transceiver and micrel KS8999 switch. We had no issues to connect our boards to other ethernet devices until now. Earlier we were using there imx53qsb without any ethernet issues. But with SabreLite I need to try several different cables before link goes stably up. At the same time SabreLite usually connects good to switches but not in all cases. With TP-LINK Gigabit ethernet switch(TL-SG1024DE) I found only one cable to reproduce issue. But there is almost same issue (less but exists) to connect SabreLite to some laptops so I think problem is not in our devices.

Сoncerning linux version, loading only U-boot is enough to see link goes up or not and cable dependance. Also there is 'mii' utility in uboot helpfull to write registers of Micrel ksz9021 ethernet transceiver (autoneg, 10/100/1000Speed, duplex and so on) and see link ok or not. We used Linux version 3.0.35-03057-g6e84b5a from SabreLite shipment, also we build linux from 3.10.53 branch. Ethernet issue exists in linux also. In linux we tried to configure ethernet PHY with ethtool and mii-tool and in some cases it was good to  disable gigabit features, autonegotiation and set 100Mbit only. But not always and not for all problem devices/cables.

When link  is up there are no problems with speed:

[  3]  0.0-10.0 sec   611 MBytes   513 Mbits/sec

[  3]  0.0-10.0 sec   597 MBytes   501 Mbits/sec

When connection is unstable there are such messages in linux

libphy: 2188000.ethernet:06 - Link is Up - 10/Half

libphy: 2188000.ethernet:06 - Link is Down

libphy: 2188000.ethernet:06 - Link is Up - 10/Half

libphy: 2188000.ethernet:06 - Link is Down

libphy: 2188000.ethernet:06 - Link is Up - 10/Half

libphy: 2188000.ethernet:06 - Link is Down

libphy: 2188000.ethernet:06 - Link is Up - 100/Full

libphy: 2188000.ethernet:06 - Link is Down

Regards, Leonid

[fabio_estevam]

Could this issue be related to the problem reported at?

https://www.mail-archive.com/netdev@vger.kernel.org/msg88626.html

Does that patch help?

Regards,

Fabio Estevam

[leonidandronov2]

Hi Fabio,

It looks related. But I am observing troubles with link in u-boot and in linux both. I have tried kernel patch but it does not help. I have used 3.14.xx kernel and there are some differences in fec_main.c compared to 4.2.5 kernel for which the patch was made. So I dont know, maybe patch is useful for latest kernel only...

Regards, Leonid

[fabio_estevam]

Hi Leonid,

Maybe you could test with the latest table kernel (4.3.5) and see if the issue happens there or not.

Regards,

Fabio Estevam

[leonidandronov2]

I am using linux releases from Boundary Devices boundarydevices/linux-imx6 · GitHub There are boundary-imx_3.0.35_4.1.0​

and boundary-imx_3.14.28_1.0.0_ga and there was 3.10.xx version somewhere. I have no idea is there a simple way to build latest 4.xx kernel for Sabrelite/Nitrogen6x and where I can get it.

Regards, Leonid

[fabio_estevam]

Just get the 4.3.3 kernel from kernel.org. It does support sabrelite.

[leonidandronov2]

OK, thank you. I have built 4.3.3 kernel with and without patch applied - no changes, issue happens.

Regards, Leonid

[fabio_estevam]

Ok, thanks. Please report this problem to the netdev@vger.kernel.org  mailing list.

[gary_bisson]

Hi Leonid,

I understand your use case but we would need the reference to commercial devices we could use to reproduce the issue because so far we haven't seen it.

I currently tried it on several laptops (2 Lenovo + 1 Dell with Intel Ethernet chips) and couldn't see that behavior. Please provide a laptop reference and more importantly its Ethernet controller so we can try to find a device to reproduce the bug.

Also, please try with with a latest 3.14.28 kernel image just in case.

Regards,

Gary

[leonidandronov2]

Hi Gary,

The issue exists with Asus X550C laptop (Realtek Gigabit PCIe Ethernet Controller).

I think an appropriate commercial device to reproduce the issue is another SabreLite board. I cannot connect two of them in any way with any cables in linux or u-boot. Same issue https://boundarydevices.com/i-mx6-frequently-asked-questions-and-answers/#comment-392 .

At the same time issue in a less degree appears with Raspberri Pi 2 rev B board, Freescale LS1021ATWR, rarely with Freescale imx53 QSB.

Regards, Leonid

[gary_bisson]

Hi Leonid,

I've tried here with two different setup and can always connect two boards together. Here is my procedure:

Hardware, platforms used:

- 1 BD-SL-i.MX6 (SabreLite) rev-2 connected to 1 BD-SL-i.MX6 rev-D (TapeOut 1.0)

- 1 BD-SL-i.MX6 (SabreLite) rev-2 connected to 1 Nitrogen6x (almost same design, same Ethernet PHY)

Hardware, Ethernet cables used:

- 1 crossover 4-pair cable: 24AWG CAT 5e STP cable

- 1 straight 4-pair cable: CAT 5 Patch cable UTP

Software images:

- Buildroot v2015.11, kernel 3.14.28

- Yocto Jethro, kernel 3.14.28

On board #1:

# ifconfig eth0 192.168.1.1

On board #2:

# ifconfig eth0 192.168.1.2

# ping 192.168.1.1

64 bytes from 192.168.1.1: seq=0 ttl=64 time=0.666 ms

64 bytes from 192.168.1.1: seq=1 ttl=64 time=0.299 ms

I've also let some iperf tests running with no issue. Please try to match the same setup and let us know if you get different results.

Regards,

Gary

[leonidandronov2]

Hi Gary,

Thank you for reply.

Using Yocto Jethro, kernel 3.14.28 and lates uboot there are no more issues connecting two SabreLite boards. But in other cases there are no differences. I can see no link sitiations with Asus X550C laptop (Realtek RTL8168C controller), Asus  eeePC 1101 Laptop (Atheros AR8132 controller), Raspberri Pi 2 (Microchip lan9514i-jzx chip), boards based on Intel lxt971a and Micrel KS8999 chips. I have sent you a little video in e-mail.

Linucx console output:

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

libphy: 2188000.ethernet:06 - Link is Up - 10/Half

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

libphy: 2188000.ethernet:06 - Link is Down

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

libphy: 2188000.ethernet:06 - Link is Up - 100/Full

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

libphy: 2188000.ethernet:06 - Link is Down

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

libphy: 2188000.ethernet:06 - Link is Up - 10/Half

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

libphy: 2188000.ethernet:06 - Link is Down

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

libphy: 2188000.ethernet:06 - Link is Up - 10/Half

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

libphy: 2188000.ethernet:06 - Link is Down

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

libphy: 2188000.ethernet:06 - Link is Up - 10/Half

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

libphy: 2188000.ethernet:06 - Link is Down

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

libphy: 2188000.ethernet:06 - Link is Up - 100/Full

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

libphy: 2188000.ethernet:06 - Link is Down

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

libphy: 2188000.ethernet:06 - Link is Up - 100/Full

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

libphy: 2188000.ethernet:06 - Link is Down

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

libphy: 2188000.ethernet:06 - Link is Up - 10/Half

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

libphy: 2188000.ethernet:06 - Link is Down

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

libphy: 2188000.ethernet:06 - Link is Up - 10/Half

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

libphy: 2188000.ethernet:06 - Link is Down

Regards, Leonid

[gary_bisson]

Hi Leonid,

I've found an old Raspberry Pi (v1.0) to test, it is using the Microchip LAN9512 chip and it works fine with both straight and cross-over cables. I'll send you a video, the rpi is running the latest archlinux available.

Then I've tried other devices, all of them are working:

- ARM-based board with a 10/100/1000 KSZ9031RNX PHY

- ARM-based board with a 10/100 KSZ8081RNB PHY

- x86 Dell Laptop with Atheros AR8152/8158 PCIe Ethernet Controller

At his point I think we need more information about your cables:

- Which category, 5, 5e or 6?

- How many pairs, 2 or 4?

- Straight or Cross-over?

Regards,

Gary