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>
2644302c14