i.mx6 ethernet bare metal

[ElijahImx6]

I am trying to get the ethernet working on an i.mx6 board and am having issues TXing/RXing data. The PHY management interface works fine, I can read and write registers in the Atheros AR8035 PHY. The phy can auto negotiate and a link is established as expected. However when I send a packet, the i.mx6 TX buffer descriptor indicates it was successfully sent out and the MIB TX counters increment. However, I don't see anything come out the port (have it connected to a PC running wireshark). I have also tried enabling the internal loopback to rule out any issues with the PHY, and that has a similar result - MIB counters indicates successful TX but nothing shows up in the RX buffers and there are no RX events. 

Code is based on the bare metal SDK enet loopback test. I have double checked the IOMUX configuration and believe it to be correct. The ENET clock is enabled in the CCM. What else am I missing, is there some power thing that has to be enabled for the enet mac? To me it seems like some low level hardware layer is not actually TXing/RXing. I'll post a dump of the enet registers below, thanks for any advice. This was after an attempted send of a packet 0x100 in length to MAC address FF:FF:FF:FF:FF:FF

ENET_EIR: 0xC000000
ENET_EIMR: 0x0
ENET_RDAR: 0x0
ENET_TDAR: 0x0
ENET_ECR: 0xF0000122
ENET_MMFR: 0x62467C1C
ENET_MSCR: 0x1A
ENET_MIBC: 0x40000000
ENET_RCR: 0x5EE006C
ENET_TCR: 0x4
ENET_PALR: 0x49F00
ENET_PAUR: 0x18808
ENET_OPD: 0x10020
ENET_IAUR: 0x0
ENET_IALR: 0x0
ENET_GAUR: 0x0
ENET_GALR: 0x0
ENET_TFWR: 0x102
ENET_RDSR: 0x20E00100
ENET_TDSR: 0x20E00180
ENET_MRBR: 0x7F0
ENET_RSFL: 0x0
ENET_RSEM: 0x0
ENET_RAEM: 0x4
ENET_RAFL: 0x4
ENET_TSEM: 0x0
ENET_TAEM: 0x4
ENET_TAFL: 0x8
ENET_TIPG: 0xC
ENET_FTRL: 0x7FF
ENET_TACC: 0x0
ENET_RACC: 0x0
ENET_RMON_T_DROP: 0x0
ENET_RMON_T_PACKETS: 0x1
ENET_RMON_T_BC_PKT: 0x1
ENET_RMON_T_MC_PKT: 0x0
ENET_RMON_T_CRC_ALIGN: 0x0
ENET_RMON_T_UNDERSIZE: 0x0
ENET_RMON_T_OVERSIZE: 0x0
ENET_RMON_T_FRAG: 0x0
ENET_RMON_T_JAB: 0x0
ENET_RMON_T_COL: 0x0
ENET_RMON_T_P64: 0x0
ENET_RMON_T_P65TO127: 0x0
ENET_RMON_T_P128TO255: 0x0
ENET_RMON_T_P256TO511: 0x1
ENET_RMON_T_P512TO1023: 0x0
ENET_RMON_T_P1024TO2047: 0x0
ENET_RMON_T_P_GTE2048: 0x0
ENET_RMON_T_OCTETS: 0x104
ENET_IEEE_T_DROP: 0x0
ENET_IEEE_T_FRAME_OK: 0x1
ENET_IEEE_T_1COL: 0x0
ENET_IEEE_T_MCOL: 0x0
ENET_IEEE_T_DEF: 0x0
ENET_IEEE_T_LCOL: 0x0
ENET_IEEE_T_EXCOL: 0x0
ENET_IEEE_T_MACERR: 0x0
ENET_IEEE_T_CSERR: 0x0
ENET_IEEE_T_SQE: 0x0
ENET_IEEE_T_FDXFC: 0x0
ENET_IEEE_T_OCTETS_OK: 0x104
ENET_RMON_R_PACKETS: 0x0
ENET_RMON_R_BC_PKT: 0x0
ENET_RMON_R_MC_PKT: 0x0
ENET_RMON_R_CRC_ALIGN: 0x0
ENET_RMON_R_UNDERSIZE: 0x0
ENET_RMON_R_OVERSIZE: 0x0
ENET_RMON_R_FRAG: 0x0
ENET_RMON_R_JAB: 0x0
ENET_RMON_R_RESVD_0: 0x0
ENET_RMON_R_P64: 0x0
ENET_RMON_R_P65TO127: 0x0
ENET_RMON_R_P128TO255: 0x0
ENET_RMON_R_P256TO511: 0x0
ENET_RMON_R_P512TO1023: 0x0
ENET_RMON_R_P1024TO2047: 0x0
ENET_RMON_R_P_GTE2048: 0x0
ENET_RMON_R_OCTETS: 0x0
ENET_IEEE_R_DROP: 0x0
ENET_IEEE_R_FRAME_OK: 0x0
ENET_IEEE_R_CRC: 0x0
ENET_IEEE_R_ALIGN: 0x0
ENET_IEEE_R_MACERR: 0x0
ENET_IEEE_R_FDXFC: 0x0
ENET_IEEE_R_OCTETS_OK: 0x0

[ElijahImx6]

Hi Sinan,

I should clarify, the register dump in my original post is from no loopback of any kind configured, the PHY is connected to a network card on my PC running wireshark - I don't see anything in wireshark. 

I have tried the PHY internal loopback options, both "digital loopback" and "external cable loopback". In both of those cases, the PHY sees the link come up but I don't get any data in the RX buffers in the i.mx6

I have also tried the internal loopback in the i.mx6 by setting the LOOP bit in RCR (I referenced this post https://community.nxp.com/t5/i-MX-Processors/How-to-do-Ethernet-internal-loop-back-test-in-IMX6dl/m-...) I would think this is the easiest option to get working since it bypasses all the external circuitry, however I had the same result - successful TX but no bytes in the RX buffers. 

[sinanakman]

Is this your custom board or sabre ? I can try here if it is the eval board. If it is your custom board you would prefer checking the clock and other pins with a scope.

Hope this helps.

Sinan Akman

[ElijahImx6]

It is a custom board, however the internal loopback (setting the RCR[LOOP] bit) doesn't really depend on any external circuitry as I understand it, so I don't think it will matter which board is used for this test? Thank you for your help. 

[ElijahImx6]

In the datasheet in the loopback section, there is this note: In MII internal loopback, MII_TXCLK and MII_RXCLK must be provided with a clock signal (2.5 MHz for 10 Mbit/s, and 25 MHz for 100 Mbit/s))

I don't know what that means, MII_RXCLK/MII_TXCLK are not external pins on the package, what does it mean to provide them a clock signal?

Is the ENET_REF_CLK signal required? I was under the impression that is not needed for a phy running in RGMII mode, however do we have the PHY clock output connected to it (currently it's driving 25 MHz into ENET_REF_CLK). 

[JosephAtNXP]

Hi,

It refers to ENET_TX_CLK and ENET_RX_CLK, found in V22 and P6 pins respectively.

ENET_REF_CLK is used in RMII only. The CLK TX and RXing are its replacement in MII and RGMII.

Have you tried receiving packages from outside of the device and checking if they're counted?

Regards

[ElijahImx6]

Ok thanks for clarifying that the ENET_REF_CLK is not used for RGMII.

So, for internal loopback to work we would need a clock signal on ENET_TX_CLK and ENET_RX_CLK? I am probing those clock lines and when I set it up for internal loopback, I get a 50 MHz clock coming out of ENET_TX_CLK but nothing is coming into ENET_RX_CLK.

As far as receiving, no I have not been able to receive any packets from outside the device. 

[sinanakman]

Hi Elijahl

I haven't used that code for a long while but just to verify, isn't that the loopback essentially loopbacks from within phy so no output from the phy is expected ? 

Here is what AR8035 datasheet mentions on Section 4.1.1 Control :

"When loopback is active, the transmitter data on TXD loops back to
RXD internally. The link breaks when loopback is enabled."

Perhaps you can verify how the loopback is implemented in that sdk.

Hope this helps.

Sinan Akman