KSZ9031 on a SabreSD based board

[durmus]

Hello all,

I'm working on a custom i.MX6 board based on SabreSD.

I've been struggling with making the ethernet connection work for a couple of days now.

We're using KSZ9031RNX from Micrel as the PHY.

Schematics:

- Pin configuration is the same: RGMII, nRST, INT, CLK, etc.

- AVDDH = 3.3V, DVDDH = 2.5V, core = 1.2V using external regulator (MMPF0100 actually)

- Strappings:

     PHY_ADD = 1

     Mode = 1111: RGMII - advertise all capabilities

     CLK125_EN: enabled

     LED_MODE: tri-color dual mode

In U-Boot;

- I removed AR8031 related "mx6_rgmii_rework" lines and modified it for KSZ9031 using

the skew settings from another board with more or less the same length RGMII signals.

The link does not come up.

Then I tested the PHY in local loopback mode. After setting up the necessary registers (using mii

commands) and setting valid ipaddr and ethaddr parameters, I pinged my own address and it

seems to be OK.

=> mii write 1 9 1300

=> mii write 1 0 4140

=> ping 192.168.0.254

Using FEC device

host 192.168.0.254 is alive

So, does that mean RGMII interface is OK?

In kernel;

- I enabled Micrel PHY driver support from menuconfig and compiled that way. Other than that,

no changes really. No link again.

The following lines comes up in the console:

Configuring network interfaces... fec 2188000.ethernet eth0: Freescale FEC PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet:01, irq=-1)

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

And the following is the ifconfig output:

root@imx6qdlsolo:/# ifconfig

eth0      Link encap:Ethernet  HWaddr BA:74:F7:68:38:76

          inet addr:192.168.0.254  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:65536  Metric:1

          RX packets:10 errors:0 dropped:0 overruns:0 frame:0

          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:700 (700.0 B)  TX bytes:700 (700.0 B)

Also, one funny thing is that when I make the PHY enter reset state, it says the link is up.

root@imx6qdlsolo:/# cd sys/class/gpio/

root@imx6qdlsolo:/sys/class/gpio# echo 25 > export

root@imx6qdlsolo:/sys/class/gpio# cd gpio25

root@imx6qdlsolo:/sys/class/gpio/gpio25# echo out > direction        (the value seems to 0 by default)

root@imx6qdlsolo:/sys/class/gpio/gpio25# libphy: 2188000.ethernet:01 - Link is Up - 1000/Full

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

Of course, actually it does not come up. What's up with that?

I can't locate the problem. Any help is appreciated.

Thanks in advance.

Durmus

[deepakbhagat]

Hi Durmuş Kurtuluş,

     Even our custom board is based on Sabre sd IMX6 and even our custom board contain the same micrel phy KSZ9031RNX. Can you help me where and what all changes are required in uboot and kernel. We are using Ltib as build system and uboot version is 2009.08 and linux version is 3.0.35.

     It would be great help in bringing up the phy on our custom board.

Regards,

Deepak Bhagat.

[durmus]

Hi Deepak,

If the track lengths of RGMII interface in your PCB do not match, you can introduce ±delays for them in U-Boot.

You have to modify mx6_rgmii_rework() function in board/freescale/mx6q_sabresd/mx6q_sabresd.c for that purpose.

Please refer to the datasheet of KSZ9031 for the registers, their values and how to write to extended registers.

For example, as explained in the datasheet the following piece of code adds 0.96ns delay to both TX_CLK and RX_CLK lines.

phy_write(phydev, 1, 0xd, 0x2);

phy_write(phydev, 1, 0xe, 0x8);

phy_write(phydev, 1, 0xd, 0x4002);

phy_write(phydev, 1, 0xe, 0x3ff);

However, if your PCB does not need any delay (as in my case), you may want to exclude this function since the present values for SabreSD may not be suitable for you.

You can also use mii or mdio commands in U-Boot console (if 2009.08 has them), to access KSZ9031.

In kernel, you have to enable Micrel PHY driver support.

Also in arch/arm/mach-mx6/board-mx6q_sabresd.c there is a function called mx6q_sabresd_fec_phy_init().

It seems they are doing some stuff there (enabling 125MHz clock, etc.). But that's a different PHY.

Since I'm using Linux 3.10.53, I don't have it and I actually don't need it. Because I'm doing all configuration I need related to PHY with power-up. KSZ9031 allows you to do that. Maybe you won't be needing it either.

One last thing comes into mind is of course hardware connections. My problem was related to ethernet magnetics center tap pins.

They should not be connected to 3.3V when using KSZ9031.

So if you think you may have a hardware related issue, you can post your schematics of KSZ9031 and we can check it.

Hope this helps.

Durmus

[deepakbhagat]

Hi Durmuş Kurtuluş,

I am facing problem in interfacing ksz9031 with imx6solo for uboot. i am getting following log for nfs boot.

Net:   got MAC address from IIM: 00:00:00:00:00:00

FEC0 [PRIME]

Hit any key to stop autoboot:  0

FEC: Link is Up ffff

Using FEC0 device

TFTP from server 192.168.1.113; our IP address is 192.168.1.16

Filename 'uImage'.

Load address: 0x10800000

Loading: TX timeout packet at 2786c2c0

TX timeout packet at 2786c2c0

TX not ready

TX timeout packet at 2786c2c0

i am not able to understand where i am going wrong. why I am getting mac address as 00:00:00:00:00:00? I had confirmed that when i boot the kernel i am able to transfer data to and fro using Ethernet and able to view the mac address too, as I have enable the micrel support in kernel.

Regards,

Deepak

[durmus]

Hi Deepak,

I am not an expert on this, but 00:00:00:00:00:00 is not a valid MAC address and that may be the cause.

One thing that comes to mind is that you can specify "ethaddr" (MAC) and "ipaddr" parameters for U-boot manually and try to boot that way.

Durmus

[deepakbhagat]

Hi

I have already done it.

here is my printenv -->

MX6Solo SABRESD U-Boot > printenv

bootdelay=3

baudrate=115200

netmask=255.255.255.0

loadaddr=0x10800000

rd_loadaddr=(0x1300000)

netdev=eth0

ethprime=FEC0

uboot=u-boot.bin

bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp

ethact=FEC0

bootargs_base=console=ttymxc0,115200

bootcmd_msd=run bootargs_msd; mmc dev 2; fatload mmc 2 ${loadaddr} ${kernel}; bootm

bootargs_msd=setenv bootargs ${bootargs_base} root=/dev/mmcblk1p2 rootfstype=ext4 rw rootwait maxcpus=1

bootcmd_mmc=run bootargs_mmc; mmc dev 0; fatload mmc 0 ${loadaddr} ${kernel}; bootm

bootargs_mmc=setenv bootargs ${bootargs_base} root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait

serverip=192.168.1.113

ipaddr=192.168.1.16

kernel=uImage

nfsroot=/home/Deepak/target_board/ltib_nfs/rootfs

ethaddr=00:04:9F:02:E2:D3

fec_mac=00:04:9F:02:E2:D3

bootargs=console=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=192.168.1.113:/home/Deepak/target_board/ltib_nfs/rootfs,v3,tcp

bootcmd_net=tftpboot ${loadaddr} ${kernel}; bootm

bootcmd=run bootcmd_net

stdin=serial

stdout=serial

stderr=serial

can you help me and guide me where to look further.

regards,

Deepak

[durmus]

Hi Deepak,

I came across with this topic:

Unable to mount root fs via NFS (imx287 - u-boot)

In the end, instead of ip=dhcp option, they seem to set ip explicitly.

Maybe you could try that.

Durmus

[durmus · Accepted solution]

I want to update the thread, in case anyone encounters the same situation.

After trying out everything, the problem came down to ethernet magnetics center tap pins.

We had first designed the board according to KSZ9021 PHY. Along the way, we decided to switch to KSZ9031.

And in their "KSZ9021RN to KSZ9031RNX Migration Guide", Micrel fails to mention the fact that magnetics center taps

should NOT be connected to 3.3V power supply when KSZ9031 is used.

Anyways, ethernet now works perfectly.

[lordcape]

Hi Durmus. I have done the same thing, connect to 3.3V the center of magnetics transformers. Can this burned the output stages of my KSZ9031? Because I never seen the leds of the connector ON, so I think that auto-negotiation never happened. They always been in off state. When you connected the center of transformers to 3.3, you see the LEDs of connector ON? I'm using magjack magnetics+rj45. If you want, I can post my schematic.

Regards

[durmus]

Hi,

In my experience, when I separated center tap pins from 3.3V power rail, ethernet worked properly. Therefore, I doubt that KSZ9031 is damaged that way. And no there was no LED activity when 3.3V was connected.

From KSZ9031RNX datasheet:

"With the voltage-mode implementation, the transmit drivers supply the common-mode voltages to the four differential

pairs. Therefore, the four transformer center tap pins on the KSZ9031RNX side should not be connected to any power

supply source on the board; rather, the center tap pins should be separated from one another and connected through

separate 0.1µF common-mode capacitors to ground. Separation is required because the common-mode voltage could be

different between the four differential pairs, depending on the connected speed mode."

Have you tried this already?

Regards,

Durmus

[lordcape]

Thanks for your answer Dormus. I'm trying it now but with a new board, because the one that ethernet not work is being used by my team. I ask you about chip damage because when I connected a rj45 cable to magjack connector I see important alternate changes in the consumption of my board. For example, when I connected the ethernet cable the boar in current changes from 400 mA to 750 mA. And this situation happened for a while, and then the current consumption returned to 400mA if the cable was connected or not....so I thought that the chip burned up. I will try this scheme (disconnect 3.3V from CT) in a new board, only with ethernet components and I'll connect the cable and expect to see LEDs activity. If this happens, I'll be happy. What do you think of my explanation about the probable broken (differential pair output stage) chip? Regards.

Santi

[igorpadykov]

Hi Durmuş

you can recheck driver's code with one on link below, which seems is working

Micrel KSZ8091 drivers for i.MX6 platform. Any leads appreciated.

Best regards

igor

[durmus]

Hi Igor,

I've checked the driver

/drivers/net/phy/micrel.c

and it is exactly the same one.

No progress in there.

Regards,

Durmus

[jayaramks]

Hiu,

In kernel, we need to update "mx6q_sabresd_fec_phy_init" function.

Regards,

Jayaram