i.MX Processors中的主题 Re: RMII on IMX6Q

RMII on IMX6Q

xray — Mon, 21 Jul 2014 23:50:26 GMT

I can't get ethernet RMII interface to work on custom hardware with an IMX6Q and a LAN8720A.

Here are my schematics:

I have made the following changes to u-boot and the kernel. (Following Fugan Duan's patches Re: iMX6 RGMII + ENET_REF_CLK/ENET_TX_CLK)

dtra3 is the name of my custom hardware.

Here I'll just show my changes to u-boot to make the RMII interface work. I'm using GPIO 16 as clock output for the phy.

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

u-boot/board/freescale/mx6q_dtra3/mx6q_dtra3.c

#define DTRA3_FEC_PHY_RESET IMX_GPIO_NR(6, 7)

#define ANATOP_PLL_LOCK 0x80000000 /*change 1*/

#define ANATOP_PLL_ENABLE_MASK 0x00002000

#define ANATOP_PLL_BYPASS_MASK 0x00010000 /*change 3*/

#define ANATOP_PLL_PWDN_MASK 0x00001000 /*change 2*/

#define ANATOP_PLL_HOLD_RING_OFF_MASK 0x00000800

#define ANATOP_SATA_CLK_ENABLE_MASK 0x00100000

#define ANATOP_FEC_PLL_ENABLE_MASK 0x00002000 /*change 4*/

static int setup_fec(void)

{

u32 reg = 0;

s32 timeout = 100000;

* get enet tx reference clk from internal clock from anatop

* GPR1[21] = 1

reg = readl(IOMUXC_BASE_ADDR + 0x4);

reg |= (0x1 << 21);

writel(reg, IOMUXC_BASE_ADDR + 0x4);

/* Enable PLLs */

reg = readl(ANATOP_BASE_ADDR + 0xe0); /* ENET PLL */

if ((reg & ANATOP_PLL_PWDN_MASK) || (!(reg & ANATOP_PLL_LOCK))) {

reg &= ~ANATOP_PLL_PWDN_MASK;

writel(reg, ANATOP_BASE_ADDR + 0xe0);

while (timeout--) {

if (readl(ANATOP_BASE_ADDR + 0xe0) & ANATOP_PLL_LOCK)

break;

}

if (timeout <= 0)

return -1;

}

/* Enable FEC clock */

reg |= ANATOP_FEC_PLL_ENABLE_MASK; //reg &= ~ANATOP_FEC_PLL_ENABLE_MASK;

reg &= ~ANATOP_PLL_BYPASS_MASK;

writel(reg, ANATOP_BASE_ADDR + 0xe0);

return 0;

}

iomux_v3_cfg_t enet_pads[] = {

MX6Q_PAD_ENET_MDIO__ENET_MDIO,

MX6Q_PAD_ENET_MDC__ENET_MDC,

MX6Q_PAD_ENET_CRS_DV__ENET_RX_EN,

MX6Q_PAD_ENET_RX_ER__ENET_RX_ER,

MX6Q_PAD_ENET_TX_EN__ENET_TX_EN,

MX6Q_PAD_ENET_RXD0__ENET_RDATA_0,

MX6Q_PAD_ENET_RXD1__ENET_RDATA_1,

MX6Q_PAD_ENET_TXD0__ENET_TDATA_0,

MX6Q_PAD_ENET_TXD1__ENET_TDATA_1,

MX6Q_PAD_NANDF_ALE__GPIO_6_8, /* wired to CPU_INT_B from the int/refclk0 pin on the LAN8720 */

MX6Q_PAD_NANDF_CLE__GPIO_6_7, /* output connected to RESET_B to the rst pin on the LAN8720 */

MX6Q_PAD_GPIO_16__ENET_ANATOP_ETHERNET_REF_OUT, /* wired to ENET_REF_CLK_50M to the clkin pin on the LAN8720 */

};

void enet_board_init(void){

...

gpio_direction_output(DTRA3_FEC_PHY_RESET, 0);

udelay(10000);

gpio_direction_output(DTRA3_FEC_PHY_RESET, 1);

mxc_iomux_set_gpr_register(1, 21, 1, 1);

...

}

include/asm-arm/arch-mxt6/mx6_pins.h

#define _MX6Q_PAD_GPIO_16__ENET_ANATOP_ETHERNET_REF_OUT \

IOMUX_PAD(0x0618, 0x0248, 2 | IOMUX_CONFIG_SION, 0x083C, 1, 0)

And finally set MUX_PADS_CTRL(MX6Q_ENET_PAD_CTRL) on all the ENET pads.

include/configs/mx6q_dtra3.h

#define CONFIG_FEC0_PHY_ADDR 1

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

Below I"ve pasted my Uboot output (with MII_DEBUG and ET_DEBUG set):

U-Boot 2009.08 (Jul 21 2014 - 15:23:54)

CPU: Freescale i.MX6 family TO1.2 at 792 MHz

Thermal sensor with ratio = 185

Temperature: 39 C, calibration data 0x5914e57d

mx6q pll1: 792MHz

mx6q pll2: 528MHz

mx6q pll3: 480MHz

mx6q pll8: 50MHz

ipg clock : 66000000Hz

ipg per clock : 66000000Hz

uart clock : 80000000Hz

cspi clock : 60000000Hz

ahb clock : 132000000Hz

axi clock : 264000000Hz

emi_slow clock: 132000000Hz

ddr clock : 528000000Hz

usdhc1 clock : 198000000Hz

usdhc2 clock : 198000000Hz

usdhc3 clock : 198000000Hz

usdhc4 clock : 198000000Hz

nfc clock : 24000000Hz

Board: i.MX6Q-DTRA-3: DTRA3 Board: 0x63e12 [POR]

Boot Device: SD (2)

I2C: ready

DRAM: 1 GB

MMC: FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3

In: serial

Out: serial

Err: serial

Net: FEC0: rxbd 27603020 txbd 27603060 ->276030a0

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

enet_board_init: dtra3

FEC0 [PRIME]

Hit any key to stop autoboot: 0

DTRA-3 U-Boot > ping 192.168.1.2

FEC: Link is Up 782d

100Mbps

Using FEC0 device

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

ping failed; host 192.168.1.2 is not alive

DTRA-3 U-Boot > mii dump

Error reading from the PHY addr=00 reg=00

Other observations:

The valid link LED and activity LED both come up and the activity LED blinks during the ping operation. ENET_REF_CLK_50M is up and looks good, and ENET_MDC comes up during the ping command. Otherwise it's not up. With a scope I can see activity on all the lines RXD0, RXD1, CRS_DV, ENET_MDIO, TX_EN, TXD0 and TXD1 during the ping command.

Can anybody help. Specifically why does the mii dump command throw and error?

Re: RMII on IMX6Q

xray — Tue, 22 Jul 2014 00:03:20 GMT

One more bit of information: The mii device command does work.

DTRA-3 U-Boot > mii device

MII devices: 'FEC0'

Current device: 'FEC0'

Re: RMII on IMX6Q

xray — Tue, 22 Jul 2014 00:16:23 GMT

If I change the config address I can get it to recognize the PHY, but still not talk to it.

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

include/configs/mx6q_dtra3.h

#define CONFIG_FEC0_PHY_ADDR 0xFF

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

DTRA-3 U-Boot > mii dump

Error reading from the PHY addr=00 reg=00

DTRA-3 U-Boot > ping 192.168.1.2

PHY indentify @ 0x1 = 0x0007c0f1

FEC: Link is Up 782d

100Mbps

Using FEC0 device

mxc_fec.c[614] fec_send: cycles: 1 status: c00 retry cnt: 0

mxc_fec.c[614] fec_send: cycles: 1 status: 2c00 retry cnt: 0

ping failed; host 192.168.1.2 is not alive

Re: RMII on IMX6Q

xray — Tue, 22 Jul 2014 17:21:47 GMT

I found the solution to the mii problem on this thread: mii commands do not work in u-boot

Now I can read from the PHY:

DTRA-3 U-Boot > mii device

MII devices: 'FEC0'

Current device: 'FEC0'

DTRA-3 U-Boot > mii dump

0. (ffff) -- PHY control register --

(8000:8000) 0.15 = 1 reset

(4000:4000) 0.14 = 1 loopback

(2040:2040) 0. 6,13 = b11 speed selection = ??? Mbps

(1000:1000) 0.12 = 1 A/N enable

(0800:0800) 0.11 = 1 power-down

(0400:0400) 0.10 = 1 isolate

(0200:0200) 0. 9 = 1 restart A/N

(0100:0100) 0. 8 = 1 duplex = full

(0080:0080) 0. 7 = 1 collision test enable

(003f:003f) 0. 5- 0 = 63 (reserved)

DTRA-3 U-Boot > mii info

PHY 0x01: OUI = 0x01F0, Model = 0x0F, Rev = 0x01, 100baseT, FDX

However I still can't ping. Any ideas?

Re: Re: RMII on IMX6Q

snowman — Wed, 23 Jul 2014 13:25:55 GMT

We are having a similar problem with our custom iMX6Q-LAN8720A board.

1) We can't ping a host connected to the twisted pair interface through a short CAT5e cable.

2) We are running QNX however, we have also tried a modified U-Boot image and have the same results (failed ping).

3) Our connections are similar to your schematic except we are trying to use the REFCLK OUT mode on the LAN8720A. We have modifed a board to use the REFCLK IN mode, and use the 50 MHz generated by the MX6 on GPIO16 (as in your schematic) but have the same results.

4) Here is a dump of our PHY registers, can you compare them to your PHY registers? Your last post has PHY control register = ffff. Are you sure you are accessing the 8720A SMI correctly?

phy[ 0]:0x1000 phy[ 1]:0x7809 phy[ 2]:0x0007 phy[ 3]:0xc0f1

phy[ 4]:0x0de1 phy[ 5]:0x0001 phy[ 6]:0x0000 phy[ 7]:0xffff

phy[ 8]:0xffff phy[ 9]:0xffff phy[10]:0xffff phy[11]:0xffff

phy[12]:0xffff phy[13]:0xffff phy[14]:0xffff phy[15]:0x0000

phy[16]:0x0040 phy[17]:0x0002 phy[18]:0x60e0 phy[19]:0xffff

phy[20]:0x0000 phy[21]:0x0000 phy[22]:0x0000 phy[23]:0x0000

phy[24]:0xffff phy[25]:0xffff phy[26]:0x0000 phy[27]:0x0000

phy[28]:0x0000 phy[29]:0x0090 phy[30]:0x0000 phy[31]:0x0040

5) Your mac address (00.00.00.00.00.00) seems wrong. Are you sure all zero's will work for a MAC address?

6) How far apart (physically) is the MX6 and LAN8720A on your board? On our board they are over 4 inches apart and we have concerns about timing margin.

7) The I/Os between the MX6 and LAN8720A on our board are 1.8V. This should work but I see all other designs use 3.3V I/Os.

Re: RMII on IMX6Q

xray — Wed, 23 Jul 2014 19:06:57 GMT

4) Here is a dump of our PHY registers, can you compare them to your PHY registers? Your last post has PHY control register = ffff. Are you sure you are accessing the 8720A SMI correctly?

Here is a printout of my registers between 0x0-0x31 (0-49) at address 0.

DTRA-3 U-Boot > mii read 0 0-31

addr=00 reg=00 data=FFFF

addr=00 reg=01 data=FFFF

addr=00 reg=02 data=FFFF

addr=00 reg=03 data=FFFF

addr=00 reg=04 data=FFFF

addr=00 reg=05 data=FFFF

addr=00 reg=06 data=FFFF

addr=00 reg=07 data=FFFF

addr=00 reg=08 data=FFFF

addr=00 reg=09 data=FFFF

addr=00 reg=0a data=FFFF

addr=00 reg=0b data=FFFF

addr=00 reg=0c data=FFFF

addr=00 reg=0d data=FFFF

addr=00 reg=0e data=FFFF

addr=00 reg=0f data=FFFF

addr=00 reg=10 data=FFFF

addr=00 reg=11 data=FFFF

addr=00 reg=12 data=FFFF

addr=00 reg=13 data=FFFF

addr=00 reg=14 data=FFFF

addr=00 reg=15 data=FFFF

addr=00 reg=16 data=FFFF

addr=00 reg=17 data=FFFF

addr=00 reg=18 data=FFFF

addr=00 reg=19 data=FFFF

addr=00 reg=1a data=FFFF

addr=00 reg=1b data=FFFF

addr=00 reg=1c data=FFFF

addr=00 reg=1d data=FFFF

addr=00 reg=1e data=FFFF

addr=00 reg=1f data=FFFF

addr=00 reg=20 data=3100

addr=00 reg=21 data=7829

addr=00 reg=22 data=0007

addr=00 reg=23 data=C0F1

addr=00 reg=24 data=01E1

addr=00 reg=25 data=4DE1

addr=00 reg=26 data=0001

addr=00 reg=27 data=FFFF

addr=00 reg=28 data=FFFF

addr=00 reg=29 data=FFFF

addr=00 reg=2a data=FFFF

addr=00 reg=2b data=FFFF

addr=00 reg=2c data=FFFF

addr=00 reg=2d data=FFFF

addr=00 reg=2e data=FFFF

addr=00 reg=2f data=0000

addr=00 reg=30 data=0040

addr=00 reg=31 data=0002

Clearly I have a problem here since all of the PHY registers between 0x00-0x1F (0-31) are 0xFFFF. Moreover, the OUI from mii info should be 0x0007 not 0x01F0.

DTRA-3 U-Boot > mii info

PHY 0x01: OUI = 0x01F0, Model = 0x0F, Rev = 0x01, 100baseT, FDX

Do you think this is a Uboot problem or a hardware problem?

5) Your mac address (00.00.00.00.00.00) seems wrong. Are you sure all zero's will work for a MAC address?

I manually set my mac address. Using

DTRA-3 U-Boot >set ethaddr 1e:ed:19:27:1a:b3

6) How far apart (physically) is the MX6 and LAN8720A on your board? On our board they are over 4 inches apart and we have concerns about timing margin.

The MX6 and the LAN8720A actually sit on two different boards connected with a 2'' FFC cable with a choke. The distance from the MX6 to the cable connector is about 4 inches and the distance from the LAN8720A to its cable connector is less than 1 inch. This makes the total distance about 7 inches. How do you test for timing margins?

Re: RMII on IMX6Q

snowman — Wed, 23 Jul 2014 20:27:25 GMT

Seems like you have some problem with the MDC/MDIO interface. The schematic connections look OK. Is the chip in RESET? Are the REFCLK timing and levels OK?

7 inches seems like a lot. The 8720A datasheet doesn't show a lot of margin for RX data hold (3.0 nsec min.). The MX6 wants 2.0 nsec at least.

We are able to ping but only small packets. Larger packets have errors. We think the TX side of the PHY is OK, we are focusing on the RX side.

Re: RMII on IMX6Q

xray — Wed, 23 Jul 2014 23:37:38 GMT

The chip is not in RESET. RESET is high.

REFCLK is 50MHz and about 4V pk-pk. It looks kind of sinusoidal rather than square, but I don't think this should be a problem.

The MDC/MDIO interface has a good clock at 2.3 MHz and a perfect 3.3V square wave. When I run mii read and mii write the read and write sequence on MDIO match the expected read and write structure (Lan8720A datasheet p 28), except there is no data from the PHY on a read for any of the status registers. The line just stays high, which explains why I'm reading 0xFFFF. I can read other registers successfully. For example

DTRA-3 U-Boot > mii read 1 0

3100

Do you still think there is a problem with my MDC/MDIO interface?

Re: RMII on IMX6Q

snowman — Thu, 24 Jul 2014 12:49:06 GMT

Your connections seem alright but the chip doesn't seem happy. Have you tried changing your PHYAD0 resistor from a pull-up to a pull-down to see if it responds on the MDC/MDIO port correctly?

Re: RMII on IMX6Q

xray — Thu, 24 Jul 2014 18:59:27 GMT

Changing the PHYAD0 to a pull down worked! Now I can read the registers.

DTRA-3 U-Boot > mii read 0 0-1f

addr=00 reg=00 data=3100

addr=00 reg=01 data=7829

addr=00 reg=02 data=0007

addr=00 reg=03 data=C0F1

addr=00 reg=04 data=01E1

addr=00 reg=05 data=4DE1

addr=00 reg=06 data=0003

addr=00 reg=07 data=FFFF

addr=00 reg=08 data=FFFF

addr=00 reg=09 data=FFFF

addr=00 reg=0a data=FFFF

addr=00 reg=0b data=FFFF

addr=00 reg=0c data=FFFF

addr=00 reg=0d data=FFFF

addr=00 reg=0e data=FFFF

addr=00 reg=0f data=0000

addr=00 reg=10 data=0040

addr=00 reg=11 data=0002

addr=00 reg=12 data=60E0

addr=00 reg=13 data=FFFF

addr=00 reg=14 data=0000

addr=00 reg=15 data=0000

addr=00 reg=16 data=0000

addr=00 reg=17 data=0000

addr=00 reg=18 data=FFFF

addr=00 reg=19 data=FFFF

addr=00 reg=1a data=0000

addr=00 reg=1b data=001A

addr=00 reg=1c data=0000

addr=00 reg=1d data=00C8

addr=00 reg=1e data=0000

addr=00 reg=1f data=1058

Many of these match your registers. Some are different. I still can't ping.

Re: RMII on IMX6Q

snowman — Thu, 24 Jul 2014 19:31:06 GMT

These values look reasonable. Have you tried to force operation at 10 Mb/sec? Tried pings with small payloads (ex., in winXP: ping -l 4 192.168.1.2)?

Re: RMII on IMX6Q

xray — Thu, 24 Jul 2014 22:28:49 GMT

I tried to force operation at 10 Mbps by pulling down the three Mode pins. If I read the registers before I ping they are set to the slow speed. However, as soon as I try a ping I get the message

DTRA-3 U-Boot > ping 192.168.1.2

PHY indentify @ 0x0 = 0x0007c0f1

FEC: Link is Up 782d

100Mbps

Using FEC0 device

ping failed; host 192.168.1.2 is not alive

Reading the registers again they are set to Autonegotiate which seems to be negotiating a speed of 100Mbps. How can I force operation of 10Mbps?

Does the limited ping (ping -l 4 192.168.1.2) work in u-boot?

I'm assuming in ubuntu the equivalent call is:

ping -s 4 192.168.1.103

-s packetsize

Specifies the number of data bytes to be sent. The default is

56, which translates into 64 ICMP data bytes when combined with

the 8 bytes of ICMP header data.

This didn't work, but I'm not sure the imx6 board is getting a valid IP address. I've set the IP address as a parameter in u-boot (ipddr=192.168.1.103 & serverip=192.168.1.2). I can't ping the server from u-boot nor can I ping the board from the server using the small packet ping.

Re: RMII on IMX6Q

xray — Fri, 25 Jul 2014 22:10:26 GMT

I was being a little stupid. My PHY works with either a pull-up or pull-down on the PHYAD0 line. If I use a pull-up my address is 0x1 so to read the registers use the command

DTRA-3 U-Boot > mii read 1 0-1f

If instead I use a pull-down then my address is 0x0 so to read the registers use the command:

DTRA-3 U-Boot > mii read 0 0-1f

When all my registers read FFFF I was setting my address to 0x1 but reading from 0x0.

Re: RMII on IMX6Q

snowman — Mon, 28 Jul 2014 13:21:07 GMT

The ping -l 4 192.168.1.2 command was executed from a Windows XP laptop connected to the target with an ethernet cable (it wasn't run on the target). This is a standard ping with the payload limited to 4 bytes. This ping is answered by the target without any errors. When we increase the payload size to 20, 24 or more (ex. ping -l 20 192.168.1.2) we find the packets start to timeout. Wireshark shows that the target can send larger packets correctly. The target starts to have problems with receive packets when the packets size starts to get above about 60 bytes (ex, ping -l 20 192.168.1.2). At this point we start to get 'aligment errors' from the MX6 MAC layer buffer descriptors (BDs). This is indicated by the statistics registers (UM sec. 23.4.43), offset 0x2d4, frames received with alignment errors.

We force operation at 10 Mbps with an option switch when we load the ethernet driver:

io-net -d mx6 rmii,speed=10,duplex=1,verbose=8

This is for QNX, not Linux.

Re: RMII on IMX6Q

snowman — Mon, 28 Jul 2014 14:39:56 GMT

We think we've identified our receive packet misalignment problem. We generate our 50 MHz reference with an on-board clock generator/PLL chip from IDT. It seems like the chip is generating excessive phase noise or jitter on our 50 MHz clock. When we bypass this chip and generate the 50 MHz clock with a clean source we can ping with large packets (> 1,000 bytes) at both 10 and 100 Mb/sec. This is not something you can really see on an oscilloscope. You may want to try changing your reference clock source to see if this helps your issue.

Tom

Re: RMII on IMX6Q

xray — Tue, 29 Jul 2014 17:38:07 GMT

I have never been able to ping, and I've tried both from the board to the server and the server to the board. I doubt we have the same issue.

Also I'm using a 50 MHz clock generated by the imx6 (GPIO 16) rather than an external chip. Do you think this clock could be bad? How do you replace it with an external source?

Re: RMII on IMX6Q

snowman — Tue, 29 Jul 2014 21:16:09 GMT

We found that our 50 MHz clock was off frequency by almost 1%. This was causing our recieve side to fail. This problem was not caused by the MX6 but by a PLL chip elsewhere in our system. If you have any doubts about your ethernet clock being within 50-100 ppm of 50 MHz I would check it with a frequency counter or spectrum analyzer.

Re: RMII on IMX6Q

ottob — Tue, 29 Jul 2014 23:24:34 GMT

Do you know if the problem is in the Tx or Rx direction ? Try using wireshark to see if something comes out of the board and add debug printouts for incoming packets

Re: RMII on IMX6Q

caoping — Sat, 20 Dec 2014 07:38:38 GMT

may be you can try :

u-boot-2009.08/drivers/net/mxc_fec.c: int fec_init(struct eth_device *dev, bd_t *bd),add:

/* set ENET tx at store and forward mode */

fecp->tfwr |= (0x1 << 8);

#endif

/* set rmii mode */

++ fecp->rcr &= ~(0x1 << 6); //disable RGMII_EN 2014-12-11 ,added code

++ fecp->rcr |= (0x1 << 8); //enable rmii mode 2014-12-11,added code

/* Now enable the transmit and receive processing */

fecp->ecr |= FEC_ECR_ETHER_EN;