staging/stintel/target, branch master

layerscape: make T40 SYSA bootfs reproducible

2026-11-05T09:05:52Z

mkfs.ext2 picks a random UUID and directory hash seed for the SYSA boot partition of the WatchGuard Firebox T40 sdcard image. The hash seed also decides the readdir order of the single block root directory, so the rebuilder sees both the UUID and the file order change: -Linux rev 1.0 ext2 filesystem data, UUID=0c77d998-0c7a-4958-ab70-b5bdc157e8ef, volume name "SYSA" +Linux rev 1.0 ext2 filesystem data, UUID=d49bc495-9c93-455a-b31e-aa92e044359c, volume name "SYSA" Derive both from IMG_PART_DISKGUID like apm821xx and gemini do, using the partition number 3 as the last byte. Link: https://github.com/openwrt/openwrt/pull/26376 Signed-off-by: Paul Spooren

mvebu: ripe_atlas-v5: build initramfs as FIT with DTB

2026-11-05T09:05:06Z

The initramfs is a bare arm64 Image without a device tree, so booting it via tftpboot requires fetching the DTB separately. Falling back to U-Boot's control DT ($fdtcontroladdr) is not an option: it lacks clocks and interrupts, and mvneta/sdhci fail to probe, leaving no network. Wrap the initramfs into a FIT with the board DTB, as done for the Turris Omnia and Methode uDPU, so it boots with a single `tftpboot $kernel_addr_r ; bootm $kernel_addr_r`. The vendor U-Boot (turris_mox) supports FIT; tested with a FIT built from the 25.12.6 initramfs and DTB: eth0 links at 1Gbps. Link: https://github.com/openwrt/openwrt/pull/26456 Signed-off-by: Paul Spooren

qoriq: fix IFC probing on CoreNet platforms

2026-11-05T08:34:47Z

CoreNet platforms use a separate device ID table which does not match IFC nodes after the invalid "simple-bus" compatible was removed. As a result, the IFC platform device and its flash children are not probed. Add the fix submitted upstream. This restores NOR and NAND probing on the T4240RDB and avoids the need for a device tree workaround on the WatchGuard Firebox M200. This also restores the switch ports on the WatchGuard Firebox M300. Their MAC addresses come from NVMEM cells in NOR flash, so the missing flash device causes the switch probe to defer indefinitely. Signed-off-by: Pawel Dembicki [use 100 as patch prefix; document M300 switch fix in commit message] Signed-off-by: Stijn Tintel

realtek: rtl930x: force FCS recalculation for CPU frames

2026-11-05T06:28:34Z

rteth hands frames to the switch with an uncomputed layer 2 FCS. On RTL930x they only reach the link partner intact while CRC_CPU_RC_EN (MAC_L2_GLOBAL_CTRL0, bits 24:23) is set. With 0 the link partner receives none of them and counts receive errors instead; 1, 2 and 3 work (see #26463). Nothing in the tree writes the field; it reads 1 as booted. Set it to 1 in rteth_930x_hw_en_rxtx(), as already done for RTL838x. RX_CHK_CRC_EN (bit 4 of the CPU port) stays as it is: the CPU's traffic also got out with it cleared. Other families are not touched. Tested on Hasivo S1100W-8XGT-SE (RTL9303), RAM-booted, host on a lan port: - After boot the field reads 1. The host gets the CPU's ARP requests (3/3) and its ping replies (5/5). - Field cleared by hand: none of them reach the host (0/3, 0/5) and its NIC counts receive errors. - With the field still cleared, eth0 down and up: a kprobe and a kretprobe on rteth_930x_hw_en_rxtx() read MAC_L2_GLOBAL_CTRL0 as 0xc254014a at entry and 0xc2d4014a at return, i.e. the field goes from 0 to 1. Once a network restart has brought the ports back up, traffic is back (3/3, 5/5). Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Gennaro Cimmino Link: https://github.com/openwrt/openwrt/pull/26483 Signed-off-by: Markus Stockhausen

ath79: engenius,esrxxxx: use nvmem for WAN MAC address

2026-11-04T21:34:59Z

When the u-boot-env layout driver probes successfully, all of the variables are available as NVMEM cells in sysfs, not just the ones used with a phandle in devicetree. Use the new function mtd_get_mac_nvmem() over the older deprecated mtd_get_mac_ascii(), to avoid an unnecessary read of MTD devices. Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24866 Signed-off-by: Robert Marko

ath79: engenius,esrxxxx: fix u-boot environment NVMEM usage

2026-11-04T21:34:59Z

Similar to a psychopath, the bootloader of the ESR series demands to check the CRC of the u-boot environment and replace it with a CRC based on its own calculation on every boot cycle if it differs, even if it is replaced with a correct and working one after boot. When these boards were moved to using the u-boot-env layout driver instead of userspace scripts for setting the MAC address, some alternatives were discussed on how to handle this. - a general fix to ignore the CRC would be inappropriate. - upstream kernel would reject a method for ignoring the CRC. - a kernel patch series to make NVMEM devices optional causes random MACs. - a userspace fix to allow using the NVMEM driver as intended afterward. After a deep investigation, it was discovered that the environment partitions are 4k sector size despite being reported as 64k block size in bootloader console. Therefore these other extreme measures are not necessary, however, the method for fixing the CRC in userspace is provided by parent commits, and a helper function to determine the correct size that represents an existing CRC is added afterward. Thanks to recent kernel patches that added the env-size property we can inform the layout driver of the true range to calculate the CRC with. NVMEM detection with env-size is also supported in u-boot tools since version v2026.10. In the uboot-tools scripts, we make sure to delete the "ubootenv" config file, so that u-boot tools uses the NVMEM device instead of any previous uci settings. Reviewed-by: Tomasz Maciej Nowak Tested-by: Tomasz Maciej Nowak Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24866 Signed-off-by: Robert Marko

generic: backport adding deferred_probe_timeout to Kconfig

2026-11-04T21:34:59Z

Support for changing the probe defer timeout in Kconfig was recently added. This allows for using Kconfig to extend the time in which devices are expected to be able to probe since the last probe before the kernel declares an error and stops trying. This helps all devices probe in rare cases where a device takes an exceedingly long time to probe and has a dependent (consumer) device, or, if an action in userspace is required to allow the device to probe, the device will be given a chance to probe past late_initcall() during init. In this case for Openwrt, it is possible to attempt userspace fixes in preinit where otherwise the probe attempts would not occur again after preinit starts. Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24866 Signed-off-by: Robert Marko

generic: nvmem: u-boot-env: allow probe defer for corrupted CRC

2026-11-04T21:34:59Z

For the rare case in which a u-boot environment CRC is corrupted and must be fixed in userspace during init in the boot cycle, allow the associated NVMEM cells to defer their probe. This allows userspace enough time to fix the CRC and make other changes or migrate the environment before the last probe attempt, or to allow debugging attempts during preinit where otherwise the probe would not be attempted again after preinit starts, so that dependent devices like ethernet drivers can successfully probe. This also avoids the need to reboot the device after a fix during preinit in order to have a working network and with a non-random MAC address. Use a new devicetree property "allow-probe-defer" to make this hack more upstream friendly and device optional, whether or not it is acceptable. Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24866 Signed-off-by: Robert Marko

generic: nvmem: u-boot-env: process numbered RADIOADDR variables

2026-11-04T21:34:59Z

Similar to variable names with the pattern eth[0-9]addr, some vendors have used variable names with the pattern RADIOADDR[0-9] in order to store MAC addresses in the environment variables. Because this variable name pattern is not documented, processing them as binary addresses automatically may not be upstreamable and the patch may need to be moved to hacks. Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24866 Signed-off-by: Robert Marko

generic: nvmem: u-boot-env: process numbered ethaddr variables

2026-11-04T21:34:59Z

Variable names with the pattern eth[0-9]addr is documented by u-boot in a README file doc/README.enetaddr as being the preferred way to store MAC addresses in the environment variables, so process them as a binary address automatically. Suggested-by: Tomasz Maciej Nowak Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24866 Signed-off-by: Robert Marko