2376570_en-US

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

2376570_en-US

2376570_en-US

IMX8M Ethernet MAC to other Processor MAC

In our design we are using two processors. one is IMX8M Plus and another one is zynq APSoC. Can we connect ethernet MAC to MAC without external phy between APSoC and IMX via RGMII. what are the design constrains needs to consider?

Re: IMX8M Ethernet MAC to other Processor MAC

Hi 

We have tried with different speed and phy mode combinations. no improvements in behaviour. Can you confirm whether any MAC or PHY mode configuration need to be hanlded in software IMX8MP since our hardware ENET pins are phyless, so is there any method of configuration to enable MAC mode ?

Re: IMX8M Ethernet MAC to other Processor MAC

Step 1 — Check TX actually sending

Run:

ping

ethtool -S eth0

Look at:

  • tx_packets
  • tx_errors

If TX = 0 → MAC not transmitting → pinmux/clock issue
If TX > 0 but RX = 0 → skew/timing issue


Step 2 — Probe signals (critical)

Check with scope:

Signal

Expectation

TXC

clock toggling

TXD[0:3]

data activity

RXC

received clock

RXD[0:3]

data toggling

If TXD always static → MAC not sending (SW/pinmux issue)
If TX OK but RX empty → timing/skew problem


Step 3 — Validate phy-mode combination

Your DTS:

phy-mode = "rgmii-id";

Check BOTH sides:

Try:

  • Side A: "rgmii-id"
  • Side B: "rgmii"

or:

  • A: "rgmii-txid"
  • B: "rgmii-rxid"

This is the#1 fix in MAC-to-MAC RGMII


Step 4 — Force TX clock/output direction

On i.MX EQOS:

Check if you need:

  • TX_CLK generated internally
  • or external clock mapping

Some SoCs require explicit:

  • GPR register config
  • clock mux setting

Step 5 — Verify pinctrl completeness

For EQOS you MUST include:

  • TX:
    • TXC
    • TX_CTL
    • TXD[0..3]
  • RX:
    • RXC
    • RX_CTL
    • RXD[0..3]

If any RX pin missing → tcpdump empty


Step 6 — Check interface mapping (very common bug)

Verify:

ethernet0 = &eqos;

ethernet1 = &fec;

Ensure:

  • Only one MAC node enabled
  • Using correct pinctrl (eqos vs fec)

Step 7 — Different speed test

You configured:

speed = <10>;

  • 10 Mbps uses 2.5MHz clock
  • Signal margin smaller / unstable

Try:

speed = <100>;

or:

speed = <1000>;

Many MAC-to-MAC setups fail at 10 Mbps


Step 8 — Confirm both sides identical config

Both SoCs must match:

Parameter

Must match

speed

Match

duplex

Match

phy-mode

compatible

Re: IMX8M Ethernet MAC to other Processor MAC

Hi yiping,

From software side both sides fixed-phy link with speed of 10 mbps configured since there was no PHY chip mounted in hardware whether device drivers in bootloader affect the data integrity ? when we are verifying the link shows it is up, but unable to ping. could you please provide any debugging steps ? NOTE: Between 2 processors RGMII lines are hard wired with cable length matched. unable to capture any valid packets using tcpdump also. Attaching dts FYR

&eqos {

pinctrl-names = "default";
pinctrl-0 = <&pinctrl_eqos>;

phy-mode = "rgmii-id";
status = "okay";

fixed-link {
speed = <10>;
full-duplex;
};

};  Please suggest if there any other node / enet controller need to be enabled in pin muxing

Re: IMX8M Ethernet MAC to other Processor MAC

Yes, if both MACs can operate in fixed-link mode (no PHY auto-negotiation), the RGMII timing is engineered correctly, especially the TX/RX clock-to-data skew, which is normally handled by a PHY.

Hardware

  1. Ensure same I/O voltage on both ends. 
  2. Route very short traces between SoCs. 
  3. Intentionally implement the required clock-to-data skew:
    • preferably by internal MAC delay if truly supported, otherwise
    • by PCB delay on clock lines. 
  4. Match trace lengths carefully within each direction.
  5. Check that neither side expects a PHY reset or MDIO-managed strap configuration to exist.

Software

  1. Configure fixed-link on both ends. 
  2. Force the same speed/duplex on both MACs. 
  3. Disable PHY-specific initialization code if your BSP assumes MDIO/PHY presence. NXP’s Ethernet configuration documents focus heavily on PHY-oriented initialization flows, which is a reminder that you may need to bypass normal PHY handling in your bootloader/OS integration. 
  4. Validate with traffic tests (ping, iperf) and, ideally, oscilloscope timing verification.

Please refer to AN14149

Re: IMX8M Ethernet MAC to other Processor MACHi yiping,
For this direct MAC to MAC via RGMII, do we need to connect TXC to TXC of another MAC or TXC to RXC ?
Re: IMX8M Ethernet MAC to other Processor MAC
Yes — both ends must match.
For MAC‑to‑MAC (PHY‑less) connection, you must configure the same speed, duplex, and compatible phy‑mode on both sides, otherwise the link will not work (or will behave incorrectly).
Re: IMX8M Ethernet MAC to other Processor MAC

Hi yiping,

We have verified external loopback in IMX with cross connection, after changing the phy-mode to rgmii-txid now we are able to see the transmitted packets counts and received packet counts are properly updating. Still when trying to send or receive from zynq no ping is happening, im suspecting the other side link partner (MAC) itself is having some issue. 

Re: IMX8M Ethernet MAC to other Processor MAC

There is NO special “MAC-only mode enable” in i.MX8MP hardware

The correct method is:

  • Configure fixed-link in device tree
  • Select proper phy-mode (rgmii-txid recommended)
  • Ensure RGMII delay enabled in hardware registers
  • Disable all PHY-related logic

Mode

Meaning

rgmii

NO delay

rgmii-id

both TX & RX delay

rgmii-txid

TX delay only

rgmii-rxid

RX delay only

Re: IMX8M Ethernet MAC to other Processor MAC

TXC must connect to RXC (cross connection), NOT TXC–TXC.

i.MX8MP                        Zynq 
TXD[3:0] ---------> RXD[3:0]
TX_CTL ---------> RX_CTL
TXC ---------> RXC
 
RXD[3:0] <--------- TXD[3:0]
RX_CTL <--------- TX_CTL
RXC <--------- TXC
Re: IMX8M Ethernet MAC to other Processor MAC

Hi yiping,

Does other end MAC also need to have same phy-mode and same speed with fixed phy link?

タグ(1)
評価なし
バージョン履歴
最終更新日:
‎06-09-2026 02:40 AM
更新者: