mirror of
https://github.com/openwrt/openwrt.git
synced 2026-10-13 06:48:43 +04:00
Zoltan Szalay
2644302c14
The u-boot-env0 partition on this board stores a redundant U-Boot environment (4-byte CRC32 + 1-byte flag + data), with the flag byte differing between the u-boot-env0/u-boot-env1 copies (0x00 vs 0x01). The actual environment size used by U-Boot for the CRC calculation is 0x1000 bytes, not the full 0x10000 byte partition. The DTS declared this as the plain, non-redundant "u-boot,env" layout with no env-size, so the kernel's u-boot-env nvmem-layout driver miscomputes the CRC and fails to probe: u-boot-env-layout ...nvmem-layout: Invalid calculated CRC32: 0xbc490a68 (expected: 0xfae56b95) u-boot-env-layout ...nvmem-layout: probe with driver u-boot-env-layout failed with error -22 Because the probe fails, the macaddr_uboot_ethaddr nvmem cell is never created, so eth0's nvmem-cells reference never resolves and the ag71xx-legacy platform device is stuck in "deferred probe pending" forever - the device boots with no functioning Ethernet interface at all. Switch to "u-boot,env-redundant-count" (matching the redundant-env layout already used on other boards from this vendor lineage, e.g. qca9557_extreme-networks_ws-ap3805i.dts) and set env-size to the verified 0x1000, which fixes CRC validation and lets eth0 probe successfully. Verified on real hardware: before the fix, eth0 never comes up (confirmed against the official 25.12.5 release, matching CRC values exactly); after the fix, eth0 links up normally and dmesg is free of any CRC/nvmem-layout errors. Signed-off-by: Zoltan Szalay <dealer@ddsweb.hu> Signed-off-by: Zoltan Szalay <szazo@halycomp.hu> Link: https://github.com/openwrt/openwrt/pull/24134 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>