Network boot of Raspberry Pi 4 leads to unstable network in U-Boot

[André Althaus]

I'm trying to netboot a Raspberry Pi 4 B and use the U-Boot pxe bootflow to bring up a NixOS system (using the extlinux.conf file created by NixOS). When I do that the U-Boot DHCP process retries multiple times to get an IP and sometimes running out of retries. The TFTP transfers afterwards show many timeouts (T). I tried to boot the same firmware files and U-Boot binary from the SD card and then the pxe bootflow works without problems. Every time the dhcp fails or the tftp timeout occurs, I can see the crc error counter on the switch port increase.

/proc/cpuinfo:
Revision    : c03114
Serial        : 1000000057c90c1d
Model        : Raspberry Pi 4 Model B Rev 1.4

vcgencmd version:
May 21 2026 11:20:25
Copyright (c) 2012 Broadcom
version 288930ab4712b99596f32732664aaaeb881ef1e0 (clean) (release) (start)

rpi-eeprom-update:
BOOTLOADER: up to date
   CURRENT: So 17. Mai 19:13:18 UTC 2026 (1779045198)
    LATEST: Fr 9. Jan 16:12:13 UTC 2026 (1767975133)

            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138c0
    LATEST: 000138c0

rpi-eeprom-config:
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
ENABLE_SELF_UPDATE=1
BOOT_ORDER=0xf21
NET_INSTALL_AT_POWER_ON=1

u-boot master (ece349ade2973e220f524ce59e59711cc919263f):
make rpi_arm64_defconfig

Additional configs:
CONFIG_CMD_MII=y
CONFIG_BOOTSTD_FULL=y

CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="bootflow scan -lb pxe"

CONFIG_LOG=y
CONFIG_LOG_MAX_LEVEL=7
CONFIG_LOG_CONSOLE=y



mii write 1 0 0x8000        # PHY soft reset

1140
mii write 1 4 0x01E1        # advertise 10/100 F+H, pause (known-good value)
mii write 1 9 0x0300        # 1000T cap
mii write 1 0 0x1200        # AN enable + AN restart
mii read  1 1                      # expect 0x796D (link up) after ~2 s
7949

Afterwards the bootflow worked without problems.

It added the following patch which seems to fix the problems:
diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
index a0264dc386d..1c867e61dd2 100644
--- a/drivers/net/bcmgenet.c
+++ b/drivers/net/bcmgenet.c

     return mdio_register(bus);
 }

+static int bcmgenet_phy_soft_reset(struct bcmgenet_eth_priv *priv)
+{
+    int val;
+    int timeout = 100; /* ms */
+
+    /* Firmware may leave the internal GPHY in a state where MDIO
+     * auto-negotiation works but the RGMII data path corrupts frames,
+     * so force the PHY back to its defaults before attaching to it. */

+        return -EIO;
+
+    do {
+        udelay(1000);
+        val = bcmgenet_mdio_read(priv->bus, priv->phyaddr, 0, MII_BMCR);
+        if (val < 0)
+            return val;
+    } while ((val & BIT(15)) && --timeout);
+
+    if (!timeout)
+        return -ETIMEDOUT;
+
+    return 0;
+}
+
 /* We only support RGMII (as used on the RPi4). */
 static int bcmgenet_interface_set(struct bcmgenet_eth_priv *priv)
 {
@@ -665,6 +689,12 @@ static int bcmgenet_eth_probe(struct udevice *dev)
         return ret;

     priv->bus = miiphy_get_dev_by_name(name);
+    if (!priv->bus)
+        return -ENODEV;
+
+    ret = bcmgenet_phy_soft_reset(priv);
+    if (ret)
+        return ret;

     return bcmgenet_phy_init(priv, dev);
 }

Its explanation:








If you need more information or some register values, I can provide them.

--
André Althaus
TU Dortmund/DELTA/Beschleunigerphysik
Maria-Goeppert-Mayer-Str. 2a
D-44221 Dortmund
Tel.: 0231 755 5488

I suspect, that the firmware leaves the network peripherals in some state that is not completely reset/initialized by u-boot. I tried to debug it with Qwen AI 3.8 and actually got a seemingly working patch. Obviously I'm not confident this is the correct fix.    RELEASE: default (/nix/store/0a6v8w38pn6gfagyc5f0czz0jhhqpz40-raspberrypi-eeprom-2026.05.11-2712/lib/firmware/raspberrypi/bootloader-2711/default) During the debugging, Qwen told me to try the following manual reset of the PHY after the firmware started u-boot and before running the bootflow: mii read  1 0                      # repeat until bit15 clears (PHY reset done) @@ -601,6 +601,30 @@ static int bcmgenet_mdio_init(const char *name, struct udevice *priv) +    if (bcmgenet_mdio_write(priv->bus, priv->phyaddr, 0, MII_BMCR, BIT(15))) The Broadcom legacy firmware performs its own DHCP/TFTP over the same GENET before loading U-Boot, then shuts the MAC/PD down and hands off without re-initialising the embedded GPHY. At hand-off the GPHY's MDIO register file and IEEE auto-negotiation still function, so U-Boot's generic PHY machinery brings the link up cleanly — but the RGMII/PMA data path is left in a firmware-era state that corrupts frames on the wire (bad FCS, visible only as the switch's receive CRC errors under load). Two facts support this being an initialisation-missing problem rather than a driver bug in the normal path: - The identical binary is stable when booting from SD, i.e. when the firmware never used the network (a clean, default-like GPHY state reaches U-Boot). - A single PHY soft-reset at first use fully cures it; there is no other state difference between the two paths that was found (speed/duplex/advertise settings are identical once link is up).

smime.p7s
Description: Kryptografische S/MIME-Signatur