uboot-at91: fix wrong BUILD_DEVICES for sama5d4_xplained_nandflash
The sama5d4_xplained_nandflash target incorrectly references microchip_sama5d3-xplained as its BUILD_DEVICES value.
This appears to be a copy-paste error, as all other SAMA5D4 Xplained targets (e.g. mmc and spiflash) correctly use microchip_sama5d4-xplained. The target name itself also clearly refers to the SAMA5D4 platform.
In addition, the SAMA5D3 Xplained and SAMA5D4 Xplained boards use different NAND flash hardware and configurations, so pointing the nandflash target to a SAMA5D3 device is incorrect and may lead to invalid builds or runtime issues.
Fix the inconsistency by updating BUILD_DEVICES to microchip_sama5d4-xplained, aligning the nandflash target with the rest of the SAMA5D4 definitions and ensuring the correct device mapping.
Daniel Pawlik [Mon, 20 Apr 2026 11:29:29 +0000 (13:29 +0200)]
generic: 6.18: drop stale hunk of Filogic SerDes patch
Daniel Pawlik figured out that a stale patch hunk breaks one of the
two 10G SerDes PCS ports of MT7988. Remove the hunk to make 10G
Ethernet work on both SerDes PCS with Linux 6.18.
Testing was done using a Aquantia AQR113C SFP+ module.
Signed-off-by: Daniel Pawlik <pawlik.dan@gmail.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The console port is a 4-pin header reachable without opening case.
Looking at the front port-side of the device, turn the device 90 degrees
clockwise. On this side, there's a rectangular opening in the honeycomb
structure. Pinout is (from left/front to right/back): GND RX TX VCC
Hardware quirks
===============
* The SFP signals RX_LOS, MOD_ABS and TX_FAULT do not have dedicated GPIO
lines each. Instead, there's a multiplexer (using GPIO12 and GPIO14)
which - depending on its state - connect this single GPIO line to RX_LOS,
MOD_ABS or TX_FAULT (GPIO19 for SFP1, GPIO27 for SFP2). This requires
a special adapter driver (which is backed by a gpio-mux) that makes
this hardware design and Linux' SFP core work together.
* SFP slots are disabled by default. GPIO6 and GPIO7 seems to be gates
for SFP1 and SFP2 respectively. The need to be pulled low to make SFP
modules work (i.e. respond to I2C requests and pass GPIO signals).
* Fan can only be set to SLOW or FAST mode, no real speed/PWM control.
Disclaimer
==========
PoE not yet supported.
Flashing OpenWrt will overwrite BootExtension + ZyNOS. BootExtension
functionality (e.g. initramfs boot as mentioned below) is not available
anymore then. The U-boot/Bootbase still has some limited functionality
which can be used in emergency cases.
Installation
============
Simple web upgrade:
1. Take the OpenWrt factory.bin image generated by the build.
2. In the ZyNOS web UI, login and go to Maintenance -> Firmware Upgrade.
3. Under "Boot Image", make sure the Config Boot Image is set to 1. In
other words, make sure the switch booted from firmware image 1 or it
will do so on next reboot.
This is crucial, otherwise OpenWrt cannot boot.
4. Below, select and upload the factory.bin image. After clicking
upgrade, the image will be flashed.
5. After flashing has finished, reboot the switch. It will now boot into
OpenWrt.
Initramfs boot
==============
NOTE: You need to use Xmodem transfer, the bootloader doesn't support
Ymodem nor any networking.
This only works as long as the default ZyNOS firmware is
installed.
1. Connect to the switch using serial and interrupt the boot process
to enter debug/recovery mode.
2. You need to unlock the bootloader. Use known methods [1] and [2] to
obtain the unlock code and unlock the bootloader with:
> ATEN 1,<unlock_code>
3. Upload the initramfs image using Xmodem:
> ATUP <address>,<file_length>
<address>: you may use any RAM address >= 0x80300000
<file_length>: length of image in bytes
4. After the transfer has finished, boot the image with:
> ATGO <address>
5. Wait for OpenWrt to boot. At this stage, it might be wise to create a
backup/dump of the Flash partitions.
Return to stock firmware
========================
1. Download the firmware for the switch from Zyxel website.
2. Unzip the download, there should be a .bin file with a alphanumeric
name.
3. Upload this file to running OpenWrt.
4. Run (use -F since the image doesn't have image metadata):
> sysupgrade -F <stock-firmware>.bin
5. Wait for the sysupgrade to succeed and the switch reboot. At the next
boot, ZyNOS should come up again.
Recovery
========
The Bootbase loader is actually a modified U-Boot variant. You can enter
it by spamming $ during the DRAM test.
The U-Boot shell can be unlocked with [1] and [2]. Note that the command
is slightly different, using a space instead of a comma, and lowercase:
> aten 1 <unlock_code>
You should now have more-or-less a standard RTK-U-boot shell from where
you can upload and write a new image to flash. Use e.g.:
The console port is a 4-pin header reachable without opening case.
Looking at the front port-side of the device, turn the device 90 degrees
clockwise. On this side, there's a rectangular opening in the honeycomb
structure. Pinout is (from left/front to right/back): GND RX TX VCC
Hardware quirks
===============
* SFP slots are disabled by default. Several GPIO lines on the PM555
GPIO expander need to be pulled low to activate SFPs, one for each SFP
slot. Otherwise modules cannot respond to I2C requests and GPIO signals
do not reach the SoC.
* Fan can only be set to SLOW or FAST mode, no real speed/PWM control.
Disclaimer
==========
Flashing OpenWrt will overwrite BootExtension + ZyNOS. BootExtension
functionality (e.g. initramfs boot as mentioned below) is not available
anymore then. The U-boot/Bootbase still has some limited functionality
which can be used in emergency cases.
Installation
============
Simple web upgrade:
1. Take the OpenWrt factory.bin image generated by the build.
2. In the ZyNOS web UI, login and go to Maintenance -> Firmware Upgrade.
3. Under "Boot Image", make sure the Config Boot Image is set to 1. In
other words, make sure the switch booted from firmware image 1 or it
will do so on next reboot.
This is crucial, otherwise OpenWrt cannot boot.
4. Below, select and upload the factory.bin image. After clicking
upgrade, the image will be flashed.
5. After flashing has finished, reboot the switch. It will now boot into
OpenWrt.
Initramfs boot
==============
NOTE: You need to use Xmodem transfer, the bootloader doesn't support
Ymodem nor any networking.
This only works as long as the default ZyNOS firmware is
installed.
1. Connect to the switch using serial and interrupt the boot process
to enter debug/recovery mode.
2. You need to unlock the bootloader. Use known methods [1] and [2] to
obtain the unlock code and unlock the bootloader with:
> ATEN 1,<unlock_code>
3. Upload the initramfs image using Xmodem:
> ATUP <address>,<file_length>
<address>: you may use any RAM address >= 0x80300000
<file_length>: length of image in bytes
4. After the transfer has finished, boot the image with:
> ATGO <address>
5. Wait for OpenWrt to boot. At this stage, it might be wise to create a
backup/dump of the Flash partitions.
Return to stock firmware
========================
1. Download the firmware for the switch from Zyxel website.
2. Unzip the download, there should be a .bin file with a alphanumeric
name.
3. Upload this file to running OpenWrt.
4. Run (use -F since the image doesn't have image metadata):
> sysupgrade -F <stock-firmware>.bin
5. Wait for the sysupgrade to succeed and the switch reboot. At the next
boot, ZyNOS should come up again.
Recovery
========
The Bootbase loader is actually a modified U-Boot variant. You can enter
it by spamming $ during the DRAM test.
The U-Boot shell can be unlocked with [1] and [2]. Note that the command
is slightly different, using a space instead of a comma, and lowercase:
> aten 1 <unlock_code>
You should now have more-or-less a standard RTK-U-boot shell from where
you can upload and write a new image to flash. Use e.g.:
The console port is a 4-pin header reachable without opening case.
Looking at the front port-side of the device, turn the device 90 degrees
clockwise. On this side, there's a rectangular opening in the honeycomb
structure. Pinout is (from left/front to right/back): GND RX TX VCC
Hardware quirks
===============
* The SFP signals RX_LOS, MOD_ABS and TX_FAULT do not have dedicated GPIO
lines each. Instead, there's a multiplexer (using GPIO12 and GPIO14)
which - depending on its state - connect this single GPIO line to RX_LOS,
MOD_ABS or TX_FAULT (GPIO19 for SFP1, GPIO27 for SFP2). This requires
a special adapter driver (which is backed by a gpio-mux) that makes
this hardware design and Linux' SFP core work together.
* SFP slots are disabled by default. GPIO6 and GPIO7 seems to be gates
for SFP1 and SFP2 respectively. The need to be pulled low to make SFP
modules work (i.e. respond to I2C requests and pass GPIO signals).
* Fan can only be set to SLOW or FAST mode, no real speed/PWM control.
Disclaimer
==========
Flashing OpenWrt will overwrite BootExtension + ZyNOS. BootExtension
functionality (e.g. initramfs boot as mentioned below) is not available
anymore then. The U-boot/Bootbase still has some limited functionality
which can be used in emergency cases.
Installation
============
Simple web upgrade:
1. Take the OpenWrt factory.bin image generated by the build.
2. In the ZyNOS web UI, login and go to Maintenance -> Firmware Upgrade.
3. Under "Boot Image", make sure the Config Boot Image is set to 1. In
other words, make sure the switch booted from firmware image 1 or it
will do so on next reboot.
This is crucial, otherwise OpenWrt cannot boot.
4. Below, select and upload the factory.bin image. After clicking
upgrade, the image will be flashed.
5. After flashing has finished, reboot the switch. It will now boot into
OpenWrt.
Initramfs boot
==============
NOTE: You need to use Xmodem transfer, the bootloader doesn't support
Ymodem nor any networking.
This only works as long as the default ZyNOS firmware is
installed.
1. Connect to the switch using serial and interrupt the boot process
to enter debug/recovery mode.
2. You need to unlock the bootloader. Use known methods [1] and [2] to
obtain the unlock code and unlock the bootloader with:
> ATEN 1,<unlock_code>
3. Upload the initramfs image using Xmodem:
> ATUP <address>,<file_length>
<address>: you may use any RAM address >= 0x80300000
<file_length>: length of image in bytes
4. After the transfer has finished, boot the image with:
> ATGO <address>
5. Wait for OpenWrt to boot. At this stage, it might be wise to create a
backup/dump of the Flash partitions.
Return to stock firmware
========================
1. Download the firmware for the switch from Zyxel website.
2. Unzip the download, there should be a .bin file with a alphanumeric
name.
3. Upload this file to running OpenWrt.
4. Run (use -F since the image doesn't have image metadata):
> sysupgrade -F <stock-firmware>.bin
5. Wait for the sysupgrade to succeed and the switch reboot. At the next
boot, ZyNOS should come up again.
Recovery
========
The Bootbase loader is actually a modified U-Boot variant. You can enter
it by spamming $ during the DRAM test.
The U-Boot shell can be unlocked with [1] and [2]. Note that the command
is slightly different, using a space instead of a comma, and lowercase:
> aten 1 <unlock_code>
You should now have more-or-less a standard RTK-U-boot shell from where
you can upload and write a new image to flash. Use e.g.:
Jonas Jelonek [Tue, 23 Dec 2025 12:08:12 +0000 (12:08 +0000)]
realtek: add generic support for Zyxel XS1930 lineup
Add generic support for Zyxel's XS1930 10G switch lineup. This will be
used by subsequent patches to share common behavior/settings.
Common specs:
- Realtek RTL9313 switch SoC
- 256MB RAM
- 32MB Flash with shared layout
- different 10G copper/SFP port configurations
The devices use a proprietary software chain from Zyxel, consisting of:
- stripped-down, heavily modified U-boot masked as "Bootbase"
- BootExtension stage2 loader
- Thread-X based ZyNOS
Those devices require to add some symbols to the kernel config, i.e.
CONFIG_AQUANTIA_PHY for the used PHYs and symbols for GPIO peripherals
and muxes due to the hardware design.
Jonas Jelonek [Fri, 10 Apr 2026 11:39:21 +0000 (11:39 +0000)]
realtek: image: add recipe for ZyNOS-based Zyxel devices
Add a new recipe 'zyxel-zynos' which contains common
behavior/definitions for ZyNOS-based Zyxel devices which requirea
special image to be built using 'zynos-firmware' recipe.
Jonas Jelonek [Tue, 7 Apr 2026 16:55:57 +0000 (16:55 +0000)]
realtek: image: add zynos-firmware recipe
Add a build recipe to build a ZyNOS firmware image using mkzynfw from
firmware-utils to produce an image that can be flashed with the web
interface of ZyNOS vendor firmware.
Jonas Jelonek [Wed, 15 Apr 2026 09:05:16 +0000 (09:05 +0000)]
realtek: pcs: replace various SerDes range checks
The whole driver often does some range checks of the SerDes ID to
restrict some functionality to a group of SerDes. However, having these
open-coded checks everywhere is rather confusing because it's not
obvious what it actually means.
Luckily, those checks give a good picture of what SerDes types we have:
- 5G: RTL838x, RTL839x (0-7, 10, 11), RTL930x (0, 1)
- 10G: RTL839x (8, 9, 12, 13), RTL930x (2-9), RTL931x (2-13)
- unknown: RTL930x (10, 11), RTL931x (0, 1)
Add a new enum and field in rtpcs_serdes for the type of a SerDes we
have. This is filled during SerDes probe, making use of the stub
implementations for that hook.. All SerDes ID range checks related to
this are replaced with corresponding checks of the SerDes type.
Jonas Jelonek [Tue, 14 Apr 2026 18:22:08 +0000 (18:22 +0000)]
realtek: pcs: add SerDes probe hook
Add a per-SerDes probe hook to rtpcs_config, called once for each SerDes
during driver probe. This provides a place for variant-specific, one-time
per-SerDes initialization that doesn't fit into the existing controller-
level init hook — such as allocating per-lane regmap fields or assigning
per-SerDes metadata.
Add stub implementations for all variants for now. They will be used by
all variants in a subsequent comment. For RTL839x, reuse the existing
rtl839x_sds_init hook and move its call out of the global init.
Nick Hainke [Sat, 18 Apr 2026 08:03:54 +0000 (10:03 +0200)]
xdp-tools: fix musl build issues
Add patches to fix build failures on musl-based toolchains:
0002-xdpsock-fix-struct-ethhdr-redefinition-on-musl.patch:
xdpsock.c included <net/ethernet.h> and <netinet/ether.h> alongside
<linux/if_ether.h>, triggering a struct ethhdr redefinition on musl.
Replace BSD-style ether_header/ether_addr with struct ethhdr and drop
the conflicting includes.
0003-build-use-gnu2x-to-avoid-stdbool.h-dependency.patch:
Switch CFLAGS and BPF_CFLAGS from -std=gnu11 to -std=gnu2x. In C23,
bool is a native keyword, fixing "stdbool.h: No such file or directory"
errors with a clang lacking its resource directory (e.g. llvm-bpf built
with LLVM_INSTALL_TOOLCHAIN_ONLY=ON on musl targets).
Paul Spooren [Sat, 18 Apr 2026 13:26:39 +0000 (21:26 +0800)]
treewide: use HTTPS for PKG_SOURCE_URL where possible
Switch http:// (and redundant ftp://) PKG_SOURCE_URL entries to https://
across tools/ and package/. PKG_HASH alone does not protect against an
attacker tampering with insecure downloads when a maintainer regenerates
the hash via `make ... FIXUP=1`: HTTPS authenticates the upstream so the
captured hash reflects real upstream content.
Replaced with @OPENWRT (HTTPS-only mirror) where the upstream HTTPS host
is dead or has a broken certificate:
- package/libs/popt (ftp.rpm.org cert mismatch)
- package/firmware/ixp4xx-microcode (was http://downloads.openwrt.org)
- package/boot/imx-bootlets (trabant.uid0.hu cert mismatch)
- package/boot/kobs-ng (freescale.com URL is dead, redirects to nxp.com root)
Backport upstream commit 9ba0b4add39e ("bpftool: Allow explicitly skip
llvm, libbfd and libcrypto dependencies") to fix a linker error. The
bpftool only needs skeleton generation, not program signing, so pass
SKIP_CRYPTO=1 to drop the libcrypto dependency entirely.
OpenWrt changes:
- rearrange configure options and variables
- provide variables for both configure and build stages (binutils has more than one ./configure script in source tree)
OpenWrt changes:
- adjust patch manually:
- 500-Change-default-emulation-for-mips64-linux.patch
- rearrange configure options and variables
- provide variables for both configure and build stages (binutils has more than one ./configure script in source tree)
Konstantin Demin [Fri, 17 Apr 2026 20:47:11 +0000 (23:47 +0300)]
toolchain: binutils: simplify patch management
Take in account only first two version components to lookup patch directory.
Hovewer, computed "BASE_VERSION" may be overridden (if necessary).
This change should prevent further issues with binutils being unpatched, see commits adad973a9c34 and 525a1e94b343.
Also drop obsolete "BIN_VERSION" variable (not used anywhere).
Nick Hainke [Fri, 17 Apr 2026 21:03:40 +0000 (23:03 +0200)]
x86: add support for DFI ADN553
The DFI ADN553 is a 3.5" SBC based on Intel Atom Alder Lake-N
processors with three Intel I226V 2.5GbE ports.
Specs:
* CPU: Intel Atom x7425E (4C, 12W) / x7213E (2C, 10W) /
x7211E (2C, 6W)
* RAM: 1x DDR5 SO-DIMM, up to 16GB
* Storage: 1x M.2 M key 2242/2280 (PCIe Gen3 x1/SATA3),
1x SATA 3.0
* Ethernet: 3x 2.5GbE RJ-45 (Intel I226V)
* USB: 4x USB 3.2 (rear), 2x USB 2.0 (internal)
* Expansion: 1x M.2 B key 3052 (USB3/USB2, opt. PCIe x1, SIM),
1x M.2 E key 2230 (USB/PCIe x1, CNVi)
* Display: 1x HDMI, 1x Type-C DP Alt. Mode, 1x LVDS/eDP
* Power: 9-36V DC wide range input
* TPM: dTPM 2.0 (NPCT750AADYX)
* Form factor: 3.5" SBC (146mm x 102mm)
Installation:
1. Write the combined-efi.img to a USB drive:
dd if=combined-efi.img of=/dev/sdX conv=fdatasync
2. Boot the ADN553 from the USB drive via the UEFI boot menu.
3. For permanent installation, write the image to the M.2 or
SATA storage device.
The board uses "Default string" as DMI sys_vendor and product_name
placeholders, so board detection is fixed by filtering these out and
falling through to board_vendor (DFI Inc.) and board_name (ADN553).
The three I226V NICs are pinned to their PCIe paths to ensure
consistent interface ordering matching the physical left-to-right
port layout. eth0 is assigned as WAN and eth1/eth2 as LAN.
Robert Marko [Wed, 15 Apr 2026 10:58:58 +0000 (12:58 +0200)]
generic: 6.12: backport EMC2305 changes
Backport the Microchip EMC2305 driver changes up to current linux-next.
These are required in order to actually be able to use the driver with
DTS support to drive fans as cooling devices.
Replace the bcm27xx RPi patch with the one from RPi kernel 7.0 that was
already adapted to all of these backports.
Zoltan HERPAI [Sun, 29 Mar 2026 14:47:12 +0000 (14:47 +0000)]
kernel/sifiveu: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Daniel Golle [Fri, 10 Apr 2026 20:00:29 +0000 (21:00 +0100)]
mediatek: build driver for built-in 2.5GE PHY as module
The by-now-upstream driver for the built-in 2.5GE PHY of the MediaTek
MT7988 and MT7987 SoC loads firmware at probe time.
Build the driver as a module in order to make sure the driver only
attempts to load the firmware by the time the rootfs with the firmware
file has become available.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Daniel Golle [Fri, 10 Apr 2026 19:58:57 +0000 (20:58 +0100)]
mediatek: fix Arioha AN8855 DSA driver for Linux 6.18
Upstream changes to phylink require to make some small changes to our
downstream Airoha AN8855 DSA driver, so it build with Linux 6.18.
The efuse driver is upstream by now and can be dropped.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Daniel Golle [Fri, 10 Apr 2026 19:58:19 +0000 (20:58 +0100)]
mediatek: fix patches for Linux 6.18
Delete patches merged upstream and refresh the remaining patches.
Import pending patchset to fix read-out-of-bounds bug in clk driver
while at it, as it makes maintaining the downstream clk driver for
MT7987 easier.
Replace downstream patch for Fidelix FM35X1GA SPI-NAND chip with
upstream commit replacing it (Dosilicon DS35Q1GA is indentical).
Several additional fixes were needed for MT7623N, especially to get
HDMI and the Mali-450 GPU working again...
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Daniel Golle [Fri, 10 Apr 2026 13:03:10 +0000 (14:03 +0100)]
kernel/mediatek: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Jonas Jelonek [Tue, 14 Apr 2026 11:17:43 +0000 (11:17 +0000)]
realtek: pcs: rtl93xx: extend USXGMII config
Our USXGMII config only covers one single register of which kind there
are actually more. We only set a value for 'CFG_QHSG_TXCFG_MAC_CH0' but
there are additional registers for CH1-CH3. Those refer to the 4
USXGMII 'channels'. While the RTL930x part of the SDK doesn't set them
explicitly, from RTK setup SerDes dumps we can see they are usually
similarly set.
The RTL931x part of the SDK actually writes those register explicitly
during USXGMII. We just haven't implemented that so far. Thus, add this
to the USXGMII config for both RTL93xx.
Jonas Jelonek [Tue, 14 Apr 2026 11:10:38 +0000 (11:10 +0000)]
realtek: pcs: rtl931x: use generic USXGMII config
Since the USXGMII config was made generic before, we can use it now for
the RTL931x setup too. This brings it closer to what the SDK configures
(see _dal_mango_construct_init_usxgmii), fixes some deviations in our
previous settings and makes clearer what is actually done.
Jonas Jelonek [Tue, 14 Apr 2026 11:05:16 +0000 (11:05 +0000)]
realtek: pcs: rtl93xx: make USXGMII config generic
The USXGMII config setting specific options currently is only
implemented for RTL930x. Looking at the SDK one can see that RTL931x
shares a lot of these configuration options. Additionally, several dumps
from RTK setups have shown that values which aren't set yet by us for
RTL930x but for RTL931x, also apply for RTL930x. Thus, both can be
merged. Start this by making the current function generic for RTL93xx.
USXGMII autoneg setting is currently hardcoded for RTL930x and not even
handled explicitly for RTL931x. This should be handled via neg_mode from
phylink subsystem too. Thus, move it over to rtpcs_93xx_sds_set_autoneg
as generic implementation for RTL93xx and set it depending on the
provided negotiation mode.
1. Prepare a TFTP server with 192.168.11.2
2. Rename initramfs image to "linux.ubi-recovery" and put it to the TFTP
directory
3. Hold the "AOSS" button and power on WSR-3000AX4P, release after 7~
seconds
4. The bootloader automatically downloads the initramfs image and boots
with it
5. After booting, upload a sysupgrade image to the device and perform
sysupgrade with it
6. Wait ~100 seconds to complete flashing
Reverting to stock image:
1. Download a official firmware and decrypt it by buffalo-enc
INAGAKI Hiroshi [Sun, 22 Mar 2026 13:15:04 +0000 (22:15 +0900)]
mediatek: filogic: enable ascii-env NVMEM driver
Enable ascii-env NVMEM driver (CONFIG_NVMEM_LAYOUT_ASCII_ENV) on
mediatek/filogic subtarget, to handle ascii-based MAC addresses
in key-value format stored to the mtd partition.
Zoltan HERPAI [Tue, 31 Mar 2026 12:36:53 +0000 (14:36 +0200)]
kernel/pistachio: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Jörg Seitz [Sun, 24 Aug 2025 04:51:11 +0000 (06:51 +0200)]
mediatek: filogic: Add new Router model ZBT-Z8106AX-T
Device support for zbt-z8106ax-t
Vendor Zbtlink advertizes this device as model Z8106AX-M2-T
on their website www.zbtlink.com. Device label sticked on
enclosure however states this is model Z8106AX version -T.
I made firmware selector to show this device as
- ZBT-Z8106AX-T to match information printed on the label and
- ZBT-Z8106AX-M2-T to match information found on vendors web pages.
Specifications:
SoC: MediaTek MT7981B
RAM: 256MiB
Flash: Winbond SPI-NAND 128 MiB
Switch: 1 WAN, 4 LAN (Gigabit) MediaTek MT7531
Buttons: Reset
Power: DC 12V-32V 1A
WiFi: MT7981B 2.4Ghz & 5Ghz
USB 3
M2 slot to hold LTE modem
2x nano SIM slots (user controllable)
Router comes in a flat metal box with all antennas detachable.
- 4 antennas for LTE 4G/5G communication
- 2 antennas for Wifi 2.4 GHz
- 2 antennas for Wifi 5 GHz
Power supply could be between 12V and 32V.
This serves both cars equipped with 12V batteries
and trucks equipped with 24V batteries.
Led Layout:
Power (green, user controllable, default set to OpenWrt Status)
Mobile (green, user controllable)
WLAN 2.4G (green, user controllable)
WLAN 5G (green, user controllable)
WAN (amber, user controllable, set to show eth1)
LAN1 (amber, hardware controlled)
LAN2 (amber, hardware controlled)
LAN3 (amber, hardware controlled)
LAN4 (amber, hardware controlled)
Slot SIM2 is set as default and matches label on Router enclosure
---
Installation:
A. Through U-Boot menu:
- Prepare your connecting computer to use a static IP in
network 192.168.1.0/24 like
a) 192.168.1.10 netmask 255.255.255.0 (legacy notation)
b) 192.168.1.10/24 (CIDR notation)
- Power down the router and hold in the Reset button.
- While holding in the button power up the router again.
- Hold the button in for 10 seconds and then release.
- Use your browser to go to 192.168.1.1
- If you see a GUI allowing for flashing firmware then you got the right spot.
- Upload the **Factory** image file.
Note: U-Boot GUI it can be used to recover from an incorrect firmware flash.
B. Through OpenWrt Dashboard:
If your router comes with OpenWrt preinstalled (modified by vendor),
you can easily upgrade by going to the dashboard (192.168.1.1) and
then navigate to "System" -> "Backup/Flash firmware"
Flash OpenWRT firmware and take care to deselect (untick) option
"keep settings". Settings done by vendor are incompatible with
versions 24.10 or 25.12.
Device features a GPIO controlled hardware watchdog.
Verfied by removing procd controlled watchdog and
seeing device rebooting.
---
Notes:
The zbt-z8106ax-t could be ordered from vendor with a variety of modems.
Mine came with a Quectel RM520N-GL. Quectel firmware was at RM520NGLAAR01A07M4G.
This level of firmware made some trouble connecting with some of my
SIM cardproviders.
Newer firmware level RM520NGLAAR01A08M4G_01.205.01.205 was available searching
github repositories. Upgrading my RM520-GL allowed to get successful connects
that did fail with older Quectel firmware.
Modem communication is set to ethernet control mode (ECM) by vendor.
Vendor takes advantage of ECM by wiring modem to internal switch port WWAN.
OpenWRT network configuration wants to define two network interfaces
- Network interface covering USB0 set with high metric
- Network interface covering WWAN set with low metric
Network interface covering WWAN would be preferred default route.
Please take note that internal switch port wired to LTE modem is named LAN5
in vendor provided firmwares. OpenWRT however names port as WWAN to better
describe purpose of port. WWAN is suggested to be assigned to firewall zone WAN.
Did use package qmodem from github repository FUjR/QModem to manage RM520N-GL LTE modem.
layerscape: armv8_64b: traverse ten64-mtd fix ASU support
The profiles.json[1] in generated and used during ASU sysupgrades takes
DEVICE_NAME as profile name which break ASU sysupgrades, use BOARD_NAME
which serves the same goal as overwriting DEVICE_NAME, allowing
sysupgrade-tar's checks be succesfully passed using the old name used in
older installations. Without affecting the generated profiles.json, thus
recovering ASU support.
*Keep the non-stardand device name with suffix "-mtd"(replaced underscore
by hyphen) to remark that this device is also supported in the armsr
(armvirt) target as originally intented[2].
*I think I have fully checked the sysupgrade path to confirm this change
does not have side effects.
Works:
------
- 2 SFP+ cages either 1G/10G or 2.5G
- 8*2.5G Ethernet ports
- Switch function
- LEDs
- Boot from flash
- Assigning MAC addresses from flash
Ethernet ports:
---------------
The 8x 2.5Gbps ethernet ports are provided by two RTL8224 chips. The
ports are supported by the upstream realtek PHY driver plus a local
initialization patch for the 10g-qxgmii mode.
Installation:
-------------
This device uses ZyNOS instead of Linux which makes the installation a
bit cumbersome. OpenWRT will be installed on the slot of the second
firmware image, thus the switch original firmware can be booted with a
little change. The serial console is required.
1. Set the switch to boot from the first image. This is required to
be sure not to be blocked in the middle of the installation
procedure.
2. Connect to the switch using the serial adapter and interrupt the boot
process by pressing "Enter" repeatedly.
3. Load the OpenWRT initramfs image using xmodem. From bootext console
(use ATHE to get the list of commands):
6. Reboot the switch and from the stock firmware set the configuration
to boot from the second image (Maintenance > Firmware upgrade > Boot
image).
7. Reboot again and enjoy OpenWRT.
Recovery/Return to stock:
-------------------------
1. Connect the switch using the serial adapter and interrupt the boot
process during the "DRAM POST: Testing:" sequence by pressing '$'
until the "XMG1915$" prompt appears.
2. Start an ymodem upgrade using the following command and use an xmodem
upload tool to send the .bin file provided in an OEM upgrade package.
XMG1915$ upgradeY image2 81000000 115200
## Ready for binary (ymodem) download to 0x081000000 at 115200 bps...
3. Wait for the upgrade process to finish and reboot the switch.
realtek: eth: normalize ring counter/size register access
This refactoring is a little bit of all ...
For access to the ring counter and size registers there exist currently
separate helpers. These are only for the register number but not the
bit position inside the register. Register definitions still use the
old prefix. Resolve this mix by
- Changing the prefixes of the register defines
- replacing the helpers with the register addresses
- just calculating register & offset manually where needed.
This might be a little step back but at least aligns with the rest of
the register access code. A future commit might bring an even better
version.
While we are here convert the main consumer rteth_93xx_hw_reset() to
regmap and fix a bug. Until now this function only clears the first
counter in a register because of a missing bit shift during writeback.
Brian Norris [Thu, 16 Apr 2026 01:58:59 +0000 (18:58 -0700)]
chromium: Add #{address,size}-cells to /firmware
Commit b4d7263bc3b6 ("kernel: of: avoid some unnecessary bad cell count
warnings") backported Linux commit 6e5773d52f4a ("of/address: Fix WARN
when attempting translating non-translatable addresses"), which started
requiring #address-cells for a device's parent if we want to use the
reg resource in a device node.
Many Chromium devices use a /firmware/coreboot device node that is
patched in by the boot firmware. These structures look something like:
There are currently two header files for the dsa driver. rtl83xx.h
and rtl838x.h. It is unclear for what reason they are separated.
Especially as one always includes the other. Merge those two files
into one.
ltq_atm.c: In function 'ltq_atm_probe':
ltq_atm.c:1840:36: error: passing argument 2 of 'platform_set_drvdata' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
1840 | platform_set_drvdata(pdev, ops);
| ^~~
In file included from ltq_atm.c:40:
/workspaces/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xway/linux-6.18.21/include/linux/platform_device.h:276:47: note: expected 'void *' but argument is of type 'const struct ltq_atm_ops *'
276 | void *data)
| ~~~~~~^~~~
Fixes: c1fa85f65931 ("treewide: use of_device_get_match_data") Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/22921 Signed-off-by: Robert Marko <robimarko@gmail.com>
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
projects / thirdparty / openwrt.git / log
