u-boot: RGMII transmit fails at 1000 Mbps but works at 100 #76

New issue

Open

opened 2026-08-30 16:39:26 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-08-30 16:39:26 +00:00

Owner

Split out of #39, which is about getting a MAC driver and TFTP boot and is no longer blocked by
this.

What is established

u-boot transmits correctly at 100 Mbps and not at all at 1000 Mbps. Same board, same boot,
minutes apart:

=> ping 192.168.27.46
Speed: 1000, full duplex
ARP Retry count exceeded          <- nothing reaches the wire

=> mii write 1 9 0; mii write 1 4 0x0101; mii write 1 0 0x1200
=> ping 192.168.27.46
Speed: 100, full duplex
host 192.168.27.46 is alive       <- works

So the MAC, the descriptor rings, the DMA engine, the pinmux, the drive strength, the MDIO path
and the PHY are all sound. The fault is confined to the 1000 Mbps RGMII clock domain - the
125 MHz DDR transmit path.

Note this also retires the "put a scope on TXCK" step that #39 was parked on: at 100 Mbps that
same pin carries 25 MHz and works, so a clock is present and the pin drives.

Eliminated, with the method

candidate	how it was ruled out
descriptor format / DMA	frames complete with OWN cleared and zero error status; and 100 Mbps works with the identical rings
`gmac_tx_clk` `0x00800030`	reads `0x00000006` in both u-boot and a Linux carrying gigabit
clock write ordering	tested both orderings live at the prompt; no change
pinmux, drive strength	`PA CFG0/1/2` and `DRV0/1` identical to Linux
MAC configuration	`conf = 0x00202800`, full duplex, GMII/1000
CCU gates and resets	diffed the whole block against Linux; Linux sets bits u-boot does not (`0x584`, `0x588`, `0x590`, `0x594` and matching resets). Applied Linux's exact values with `mw` before the ping - no change
PHY page-0 registers	dumped all 32 from both; identical except ANAR pause bits, which the driver rewrites at autoneg
RGMII delay register	ext-page `0xa4` reg `0x1c` reads `0xBD75` in both

Linux drives the same MAC and the same PHY at a stable 1 Gbps continuously, so this is not a
hardware defect - it is something u-boot does differently that is not visible in any register
either side exposes.

Where to look next

The remaining candidate is RGMII transmit timing at 125 MHz rather than configuration.
Specifically worth testing, in rough order of cost:

Delay mode. The dtsi asks for rgmii-id, so both internal delays are on. A board that
actually wants rgmii-txid (or no internal TX delay, with the skew in the trace) would look
exactly like this: fine at 25 MHz where the timing budget is large, broken at 125 MHz where
it is not. Cheap to test - change the delay bits and ping, no rebuild.
Whether Linux's stmmac does something to the transmit path that u-boot's designware
driver does not, that is not a register either exposes - e.g. ordering around
CLK_BUS_GMAC/RST_BUS_GMAC relative to the PHY coming up.
Only then, a scope - and on the data lines with reference to TXC, not on TXC itself.

⚠️ Read this before touching the PHY

Writing the whole delay register, rather than read-modify-writing the delay bits, broke gigabit
autonegotiation until the board was physically power cycled. The RTL8211E's reserved field
(bits 10:0) holds Realtek test/debug settings that survive a warm reboot and a BMCR soft reset,
and there is no PHY reset GPIO in the device tree. Restoring the original value over MDIO did not
help.

Detail in #39. Rules: read-modify-write only, verify the page-select took before trusting a paged
access, and do this work while someone can reach the board - or after #5.

Split out of #39, which is about getting a MAC driver and TFTP boot and is no longer blocked by this. ## What is established u-boot **transmits correctly at 100 Mbps** and not at all at 1000 Mbps. Same board, same boot, minutes apart: ``` => ping 192.168.27.46 Speed: 1000, full duplex ARP Retry count exceeded <- nothing reaches the wire => mii write 1 9 0; mii write 1 4 0x0101; mii write 1 0 0x1200 => ping 192.168.27.46 Speed: 100, full duplex host 192.168.27.46 is alive <- works ``` So the MAC, the descriptor rings, the DMA engine, the pinmux, the drive strength, the MDIO path and the PHY are all sound. **The fault is confined to the 1000 Mbps RGMII clock domain** - the 125 MHz DDR transmit path. Note this also retires the "put a scope on TXCK" step that #39 was parked on: at 100 Mbps that same pin carries 25 MHz and works, so a clock is present and the pin drives. ## Eliminated, with the method | candidate | how it was ruled out | |---|---| | descriptor format / DMA | frames complete with OWN cleared and zero error status; and 100 Mbps works with the identical rings | | `gmac_tx_clk` `0x00800030` | reads `0x00000006` in both u-boot and a Linux carrying gigabit | | clock write ordering | tested both orderings live at the prompt; no change | | pinmux, drive strength | `PA CFG0/1/2` and `DRV0/1` identical to Linux | | MAC configuration | `conf = 0x00202800`, full duplex, GMII/1000 | | **CCU gates and resets** | diffed the whole block against Linux; Linux sets bits u-boot does not (`0x584`, `0x588`, `0x590`, `0x594` and matching resets). Applied Linux's exact values with `mw` before the ping - **no change** | | **PHY page-0 registers** | dumped all 32 from both; identical except ANAR pause bits, which the driver rewrites at autoneg | | **RGMII delay register** | ext-page `0xa4` reg `0x1c` reads `0xBD75` in both | Linux drives the same MAC and the same PHY at a stable 1 Gbps continuously, so this is not a hardware defect - it is something u-boot does differently that is not visible in any register either side exposes. ## Where to look next The remaining candidate is RGMII transmit **timing** at 125 MHz rather than configuration. Specifically worth testing, in rough order of cost: 1. **Delay mode.** The dtsi asks for `rgmii-id`, so both internal delays are on. A board that actually wants `rgmii-txid` (or no internal TX delay, with the skew in the trace) would look exactly like this: fine at 25 MHz where the timing budget is large, broken at 125 MHz where it is not. Cheap to test - change the delay bits and ping, no rebuild. 2. **Whether Linux's `stmmac` does something to the transmit path** that u-boot's `designware` driver does not, that is not a register either exposes - e.g. ordering around `CLK_BUS_GMAC`/`RST_BUS_GMAC` relative to the PHY coming up. 3. Only then, a scope - and on the data lines with reference to TXC, not on TXC itself. ## ⚠️ Read this before touching the PHY Writing the whole delay register, rather than read-modify-writing the delay bits, **broke gigabit autonegotiation until the board was physically power cycled**. The RTL8211E's reserved field (bits 10:0) holds Realtek test/debug settings that survive a warm reboot and a BMCR soft reset, and there is no PHY reset GPIO in the device tree. Restoring the original value over MDIO did not help. Detail in #39. Rules: read-modify-write only, verify the page-select took before trusting a paged access, and do this work while someone can reach the board - or after #5.

tiagoagueda added the

hardware

kernel

P3-normal

labels

2026-08-30 16:39:26 +00:00

tiagoagueda referenced this issue from a commit

2026-08-30 16:52:44 +00:00

TFTP boot works, at 100 Mbps (#39), and the gigabit fault is split out (#76)

tiagoagueda referenced this issue

2026-08-30 16:53:26 +00:00

U-Boot: no MAC driver is built — enable the GMAC to unlock TFTP boot #39