staging/nbd/target, branch 5ed650acbfd9cfbfd6a381df7db060c9153bacfc

kernel: bump 6.12 to 6.12.63

2025-12-31T16:55:44Z

Changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.12.63 Manually rebased: qualcommax/patches-6.12/0113-remoteproc-qcom-Add-secure-PIL-support.patch qualcommax/patches-6.12/0116-remoteproc-qcom-Update-regmap-offsets-for-halt-regis.patch Removed upstreamed: airoha/patches-6.12/029-14-spi-airoha-snfi-en7523-workaround-flash-damaging.patch[1] All other patches automatically rebased. 1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.63&id=7be679104357439ff6eab076975f5f74368acd69 Build system: x86/64 Build-tested: flogic/glinet_gl-mt6000, ramips/tplink_archer-a6-v3, x86/64-glibc Run-tested: flogic/glinet_gl-mt6000, ramips/tplink_archer-a6-v3, x86/64-glibc Co-authored-by: Goetz Goerisch Signed-off-by: John Audia Link: https://github.com/openwrt/openwrt/pull/21329 Signed-off-by: Robert Marko

generic: add missing symbol

2025-12-31T16:55:44Z

Set SND_SOC_NAU8325 to no Signed-off-by: John Audia Link: https://github.com/openwrt/openwrt/pull/21329 Signed-off-by: Robert Marko

mediatek: filogic: fix supported_devices list for gl-mt2500

2025-12-30T21:59:44Z

The SUPPORTED_DEVICES sets for both Maxlinear (v1) and Airoha (v2) devices were identical, so sysupgrade was unable to detect when an incorrect image was being installed. This caused "soft bricking" of devices when a v1 image was installed on a v2 device, and vice versa. Fix this by making the supported_devices distinct for each device version, by renaming the devices with a version-specific name. This is reflected in the file name and the image metadata. Fixes: https://github.com/openwrt/openwrt/issues/20566 Fixes: https://github.com/openwrt/asu/issues/1525 Signed-off-by: Eric Fahlgren Link: https://github.com/openwrt/openwrt/pull/20632 Signed-off-by: Hauke Mehrtens

mediatek: add ubootmod layout for Cudy WBR3000UAX v1

2025-12-30T21:20:33Z

This allows us to use the full size of nand, which extends ubi size from 64Mb to 122.25Mb. If you are at factory firmware, please refer to [PR](https://github.com/openwrt/openwrt/pull/21141) to boot into OpenWrt first. 1. Log in to the device and backup all the partitions, especially unique `Factory` and `bdata` partitions from System -> Backup / Flash Firmware -> Save mtdblock contents. 2. Install kmod-mtd-rw to unlock mtd partitions for writing: ```bash apk update && apk add kmod-mtd-rw && insmod mtd-rw i_want_a_brick=1 ``` 3. Write new OpenWrt (U-Boot Layout) `BL2` and `FIP`: ```bash mtd write openwrt-mediatek-filogic-cudy_wbr3000uax-v1-ubootmod-preloader.bin BL2 mtd write openwrt-mediatek-filogic-cudy_wbr3000uax-v1-ubootmod-bl31-uboot.fip FIP ``` 4. Set static IP on your PC: `192.168.1.254`, gateway `192.168.1.1` 5. Serve openwrt-mediatek-filogic-cudy_wbr3000uax-v1-ubootmod-initramfs-recovery.itb using TFTP server. 6. Connect Router LAN with PC LAN. 7. Cut off the power and re-engage, wait for TFTP recovery to complete. 8. After OpenWrt initramfs recovery has booted, clean `/dev/mtd5` ubi partition to utilize maximum of free space & create ubootenvs: ```bash ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5 ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB ``` 4. Perform sysupgrade. Tested-by: 4pda users Signed-off-by: Fil Dunsky Link: https://github.com/openwrt/openwrt/pull/21225 Signed-off-by: Hauke Mehrtens

mediatek: add support for Cudy WBR3000UAX v1

2025-12-30T21:20:30Z

Another OEM variation of a Cudy WR3000 series device made for Russian market. Hardware: - SoC: MediaTek MT7981B - CPU: 2x 1.3 GHz Cortex-A53 - Flash: 128 MiB GigaDevice SPI NAND. Flash Model: F50L1G41LB, ID: C801 - RAM: DDR3, 512 MiB - WLAN: 2.4 GHz, 5 GHz (MediaTek MT7976CN, 802.11ax) - 1x WAN MT7531 (JXD 2531Z) 10/100/1000 Mbps - 4x LAN 2x MT7530 (JXD 2529S) 10/100/1000 Mbps - USB 3.0 port - Buttons: Reset, WPS - 8x LEDs: 2x Red, 6x Blue - Serial console: no need to solder, just open the case and unskrew the radiator, TX-RX, RX-TX, GND-GND, VCC do not connect, 115200 8n1 - Power: 12 VDC, 1.5 A +---------+-------------------+-----------+ | | MAC | Algorithm | +---------+-------------------+-----------+ | WAN | 80:AF:CA:xx:xx:x1 | label+1 | | LAN | 80:AF:CA:xx:xx:x0 | label | | WLAN 2g | 80:AF:CA:xx:xx:x0 | label | | WLAN 5g | 82:AF:CA:xx:xx:x1 | label+1 | +---------+-------------------+-----------+ Based on a factory layout with only 64mb partition for easier transition from factory to OpenWrt for users if the "intermediate" RSA signed firmware will be provided by Cudy. **Installation** The installation must be done via UART & TFTP by disassembling the router. On other occasions Cudy has distributed intermediate firmware and dts to make installation easier, but since this router is OEM special WB order for local RU market there is a possibility they will not provide it. **Install using UART & TFTP** 1. Connect to UART. 2. Since the factory BL is locked and the boot process can not be stopped, you have to use mtkuartboot, hold reset, engage the power, boot into your payloaded bl2 & fip. 3. Connect to LAN and set your IP to 192.168.1.254. 4. Configure a TFTP server to serve openwrt-mediatek-filogic-cudy_wbr3000uax-v1-initramfs-kernel.bin file. 5. Run these steps in u-boot using the name of your file: ``` setenv bootfile openwrt-mediatek-filogic-cudy_wbr3000uax-v1-initramfs-kernel.bin setenv ipaddr 192.168.1.1 setenv serverip 192.168.1.254 tftpboot bootm ``` 6. Router will boot into OpenWrt initramfs recovery, just open your browser `192.168.1.1` and sysupgrade with the `Keep settings` option turned off. Tested-by: many 4pda users Signed-off-by: Fil Dunsky Link: https://github.com/openwrt/openwrt/pull/21225 Signed-off-by: Hauke Mehrtens

arm-trusted-firmware-mediatek: add Cudy DDR3 target

2025-12-30T21:19:09Z

Since there are many similar devices from Cudy (TR3000 / WR3000E / WR3000P / WR3000S / WBR3000UAX) this will allow to create OpenWrt U-Boot layout for all of them using same DDR3 target. Tested-by: 4pda users Signed-off-by: Fil Dunsky Link: https://github.com/openwrt/openwrt/pull/21225 Signed-off-by: Hauke Mehrtens

ipq40xx: add support for Cisco Meraki MR20

2025-12-29T18:41:24Z

This commit adds support for the Cisco Meraki MR20/Go GR10. The Meraki MR20 is a Cisco 802.11ac/WiFi 5 AP with 1 Ethernet port. It can be powered by a 12V DC barrel jack (5.5x2.5mm, center positive) or via 802.3af POE. The Meraki Go GR10 (codename: Maggot) is identical to the MR20 (codename: Grub), so this document will refer to both devices as the MR20. MR20 hardware info: * CPU: Qualcomm IPQ4029 * RAM: 256MB DDR3 * Storage: 128 MB (MX30LF1G18AC) * Networking: 1 Gigabit Ethernet * WiFi: QCA4019 802.11b/g/n/ac * Serial: Internal header (J10, 2.54mm, unpopulated) This device ships with secure boot, and cannot be flashed without external programmers (TSOP48 NAND and I2C EEEPROM)! Disassembly: Remove the four rubber feet on the rear of the AP and the four Torx T8 screws under the feet. Using a guitar pick or similar plastic tool, insert it on the side along the seam around the edge. Push in gently while gently lifting the front of the housing to release the plastic retention clips. There are 15 clips in total. Once you have removed the plastic front (shown above already removed so you know where the clips are), remove the 4 Philips screws holding down the two metal WiFi antennas. Lift the PCB gently while pushing the Ethernet port into the housing to release it. The PCB should come free from the metal heat spreader. The TSOP48 NAND flash (U9, Macronix/MXIC MX30LF1G18AC) is located on the opposite side of the PCB. To flash, you need to desolder the TSOP48 or use a 360 clip. You also need to reprogram the I2C EEPROM (U20, Atmel 24c64). Installation: The dumps to flash can be found in this repository: https://github.com/halmartin/meraki-openwrt-docs/tree/main/mr20_gr10 The device has the following flash layout (offsets with OOB data): ``` 0x000000000000-0x000000100000 : "sbl1" 0x000000100000-0x000000200000 : "mibib" 0x000000200000-0x000000300000 : "bootconfig" 0x000000300000-0x000000400000 : "qsee" 0x000000400000-0x000000500000 : "qsee_alt" 0x000000500000-0x000000580000 : "cdt" 0x000000580000-0x000000600000 : "cdt_alt" 0x000000600000-0x000000680000 : "ddrparams" 0x000000700000-0x000000900000 : "u-boot" 0x000000900000-0x000000b00000 : "u-boot-backup" 0x000000b00000-0x000000b80000 : "ART" 0x000000c00000-0x000007c00000 : "ubi" ``` * Dump your original NAND (if using nanddump, include OOB data). * Decompress `u-boot.bin.gz` dump from the GitHub repository above (dump contains OOB data) and overwrite the `u-boot` portion of NAND from `0x738000`-`0x948000` (length `0x210000`). Offsets here include OOB data. * Decompress `ubi.bin.gz` dump from the GitHub repository above (dump contains OOB data) and overwrite the `ubi` portion of NAND from `0xc60000`-`0x8400000` (length `0x77a0000`). Offsets here include OOB data. * Dump your original EEPROM. Change the byte at offset `0x49` to `0x1e` (originally `0x2c` or `0x25`). Remember to re-write the EEPROM with the modified data. * This can be done on Linux via the following command: `printf "\x1e" | dd of=/tmp/eeprom.bin bs=1 seek=$((0x49)) conv=notrunc` **Note**: the device will not boot if you modify the board major number and have not yet overwritten the `ubi` and `u-boot` regions of NAND. * Resolder the NAND after overwriting the `u-boot` and `ubi` regions. OpenWrt Installation: * After flashing NAND and EEPROM with external programmers. Plug in an Ethernet cable and power up the device. * The new U-Boot build uses the space character `" "` (without quotes) to interrupt boot. * Interrupt U-Boot and `tftpboot` the OpenWrt initramfs image from your tftp server ``` dhcp setenv serverip tftpboot openwrt-ipq40xx-generic-meraki_mr20-initramfs-uImage.itb ``` * Once booted into the OpenWrt initramfs, created the `ART` ubivol with the WiFi radio calibration from the mtd partition: ``` cat /dev/mtd10 > /tmp/ART.bin ubiupdatevol /dev/ubi0_1 /tmp/ART.bin ``` * `scp` the `sysupgrade` image to the device and run the normal `sysupgrade` procedure: ``` scp -O openwrt-ipq40xx-generic-meraki_mr20-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/ ssh root@192.168.1.1 "sysupgrade -n /tmp/openwrt-ipq40xx-generic-meraki_mr20-squashfs-sysupgrade.bin" ``` * OpenWrt should now be installed on the device. Signed-off-by: Hal Martin Link: https://github.com/openwrt/openwrt/pull/20646 Signed-off-by: Robert Marko

ipq40xx/meraki: refactor common device tree

2025-12-29T18:41:24Z

qcom-ipq4029-insect-common.dtsi was common to the MR33 and MR74, but was no longer common with the other supported Meraki devices. I have refactored insect-common and wired-qca-common into qcom-ipq4029-meraki-common.dtsi which contains the actual common components (e.g. NAND partitions, ART nvmem). Individual devices reference qcom-ipq4029-meraki-insect.dtsi plus their own individual configuration. Signed-off-by: Hal Martin Link: https://github.com/openwrt/openwrt/pull/20646 Signed-off-by: Robert Marko

realtek: pcs: rtl931x: fix SerDes mode application

2025-12-29T16:06:19Z

The SerDes mode setting at the end of rtpcs_931x_setup_serdes is currently broken although it is mostly similar to what the SDK does [1]. It prevents several modes from being set, especially fiber modes. This seems to be one (if not the only) issue for currently missing SFP support. Add a small helper function which takes cares of setting the mode, to keep the still valid different procedure when using XSGMII mode. Only this helper is called in rtpcs_931x_setup_serdes to keep it clean there. As a functional change, call mode application in every case, not just for SGMII, QSGMII and USXGMII. We can assume the SDK is misleading in this case, either accidentially or on purpose. This makes SFP modules work in theory. In practice, there still seem to be device-specific issues which need to be fixed later. These issues may include no link detection or link flapping. [1] https://github.com/plappermaul/realtek-doc/blob/f7f85ffc14c6e575ad94f2b427106de533b888fe/sources/rtk-dms1250/src/dal/mango/dal_mango_construct.c#L2266 Signed-off-by: Jonas Jelonek Link: https://github.com/openwrt/openwrt/pull/20736 Signed-off-by: Robert Marko

realtek: pcs: rtl931x: streamline hardware mode setting

2025-12-29T16:06:19Z

The SDK and our code for finally applying the hardware mode are quite confusing. There are two different "places" where a mode can be set, in a SerDes register and in a global SerDes mode register. Neither the SDK nor any of the datasheet/documentation serve any explanation for that. The functions are just named "fiber_mode_set" and "mii_mode_set" which is basically as useless as it can be to understand it. Try to get rid off this confusion by naming the functions 'sds_set_mac_mode' and 'sds_set_ip_mode' to make clear where the mode is set. While at it, also clarify the naming of 'config_mode' by renaming it to 'config_hw_mode'. The naming is based on the following assumption: > Realtek uses an SerDes IP core design (probably from another vendor) > in their switch. This supports a variety of modes and must be > configured properly for each mode. Usually, changing the mode in the > MAC's registers triggers a proper configuration of the SerDes IP block > in the background. > However, for some modes this seems to be incomplete, at least missing > important parts so it doesn't work on its own in the end. In this > case, the SerDes IP block needs to be configured manually with the > missing bits to make it work. There are several places in the SDK that support this assumption, both for RTL931X and RTL930X (as they are somewhat similar), e.g. [1]. [1] https://github.com/plappermaul/realtek-doc/blob/f7f85ffc14c6e575ad94f2b427106de533b888fe/sources/rtk-dms1250/src/dal/longan/dal_longan_sds.c#L1746 Signed-off-by: Jonas Jelonek Link: https://github.com/openwrt/openwrt/pull/20736 Signed-off-by: Robert Marko