edit SideBar

Main / Enet


  • DSA = distributed switch architecture (is this a Marvell original?)
  • TBI = ten bit interface, appears to be a chip management interface, perhaps an alternative to the MII family

MDIO is the standard for managing Ethernet PHY devices, using a simple two-wire interface consisting of bi-directional data and clock. Ethernet drivers use MDIO signals to read chip information and configure the device (MAC <-> PHY). But what's the difference between clause 22 and clause 45? This refers to the clause of the spec IEEE RFC802.3 and 22 was the original, and defines the format of the MDIO data frame. Clause 45 was added later to expand the capability of the interface. MDIO is one component of the MII set of interfaces. The MDC/MDIO pair is known as MIIM for MII Management. The interface has been compared to I2C, as it's multi-drop.

Media Independent Interface (MII) is the bus connecting MAC to PHY. MII includes a data path (with 4 lines each for TX/RX) and a management path (MDIO). RMII is the reduced (simplified) version, with RGMII being its Gigabit counterpart. MII is still preferred in a real-time network since RMII is a wrapper on MII and adds latency and variation. Looks like RMII is just for 10/100, not GigE.

RGMII is a 12-pin interface (whereas GMII is 24) as it has a clock, enable, and 4x data for each direction.

RMII requires a 50 MHz clock where MII requires a 25 MHz clock for faster data transfer and RMII has a reduced signal line count. Using RMII should reduce board space, but could increase cost (oscillator, supporting chip).

The T in 10baseT stands for twisted-pair.

SGMII is a serial variant, reducing to one TX pin each direction. Both SGMII and 1000Base-x are dual 1000Mbps SERDES pairs.

What if I have to fake out the MDIO pins?

Let's say you have a test board with an FPGA on which I/O pins are limited so the ethernet management MDIO pins were left out. This means we have to fake out the MDIO responses in the drivers for both u-boot and linux. The IF will operate fine despite this.

U-Boot Ethernet Magic (ARM)

Locate your board device config file (e.g. your *evm.h, such as TI's davinci_dvevm.h) Add a #define as needed to identify the Ethernet hack in the code.

Go to the vendor's ethernet driver file (e.g. cpu/arm926ehs/davinci/ether.c). In eth_phy_detect() fake out an active phy and also fake the ack in davinci_eth_phy_read(). For example, in the second instance, OR in MDIO_USERACCESS0_ACK. Force the status in gen_get_link_status() and also gen_auto_negotiate(). In davinci_emac_initialize() hardcode the phy ID.

Linux Ethernet Magic (ARM)

Go to the vendor's EMAC file (e.g. linux-*/drivers/net/davinci_emac.c). Add a #define as needed to identify the hack, return a hardcoded value from emac_mii_read() and force device selection to 0 in emac_dev_open()

What's the deal with Ethernet DMA on the iMX6?

When working on the drivers, keep an eye out for a nasty documentation disaster: Freescale doesn't let you know that the DMA requires two TxBDs to work. In the second, you don't need to set the ready bit, but you must set the SW ownership bit. Otherwise the first BD won't even transmit. Weird. And shame on those morons at Freescale for wasting my time.

Ethernet on the TriCore

It appears that only DMA mode is available on the TriCore, there is no other buffering provided besides RAM. This probably makes sense with the large size of Eth packets, and one wonders if this is true of all SoCs with an Eth peripheral.

Note that the MAC module will not come out of reset unless it is receiving a good clock from the PHY (or switch) on GREFCLK .

Linux Generic PHY Driver


How do you set the platform_device dev_id? Can't find where that struct is populated. In fec_enet_mii_probe there's logic to cycle through the array of 32 PHYs, but unless the dev_id is set it won't work. It's also strange that it checks for phy_id 0 instead of -1. phy_id is also used in different places as the PHY address (0-32) or the PHY vendor ID coming out of the on-chip registers. Files of interest include drivers/net/phy/phy.c, drivers/net/phy/phy_device.c, drivers/net/fec.c

Layer 2 Framing

The FCS/CRC at the end of the frame is typically added automatically by the NIC/adapter going out and checked and stripped by the receiving NIC/adapater so you won't see it in Wireshark without adjusting some settings. If the FCS check fails, switches and NICs will drop the packets and they won't be passed along or up the stack.


The TI TLK105 is similar enough to the Micrel KSZ9031 (not the 21) that the Uboot phy driver can be shared. It looks like many of the basic PHY registers are common or standardized, such as BMSR, which is part of why this works. Uboot has #defines for these.


The only good description I've found so far about the difference between Ethernet loopback tests.

PHY Address

It's important that the PHY address boot pins be stable on boot, so install all suggested pull-up resistors or what have you.


At least one switch datasheet I read, for the SGMII MAC to PHY connection, said AC coupling is required for the RX and TX lines so I wonder if that is the proper setting for an oscilloscope when probing those as well.

Page last modified on May 13, 2024, at 05:24 PM