As mkits.sh only generates the relevant DTS for mkimage and is
specific for the building image, we can move it outside the locked
section as it doesn't do any operation that can be used concurrently by
others.
This won't have any real impact but clean the code making it clear what
needs to be protected and what can be executed concurrently.
image: fix race between mkits.sh and mkimage in .itb squashfs generation
With further investigation it was found a race in generating .itb images
that include a RootFS caused by the mkits.sh and the mkimage.
Due to the fact that mkits.sh generates a .pagesync image of the passed
rootfs, it can happen that, concurrently, mkimage can be called at the
same time mkits.sh is creating another .pagesync for the same rootfs.
This cause mkimage to use an half made rootfs.pagesync creating a
corrupted image.
To address this, also protect the mkimage with the same lock used for
mkits.sh preventing any kind of concurrent usage/generation of the
rootfs.pagesync blob
e2fsprogs: add pending patch that improve reproducibility
Add pending patch that disable libmagic support as this cause
reproducibility issue due to timing of presence of libmagic library at
times e2fsprogs gets compiled.
The new patch adds control on libmagic inclusion and we add the
--without-libmagic to the configure args by default.
Drop redundant patch for host build as this has been fixed in 1.44.1
but for some reason it wasn't notice with the patch directly refreshed
(with the fix right up)
airoha: backport additional upstream patch for NPU support for AN7583
Backport additional patch required for NPU support of Airoha AN7583.
These are specific for the NPU module with some minor fixes and to adds
upport for loading the specific Airoha AN7583 NPU firmware.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
airoha: an7583: drop bootloader artifacts entry and add default pkg
Fix the current image Makefile for Airoha AN7583 by dropping the
artifacts entry for bootloader and add default PKG for the PHY mounted
on the RFB boards.
The artifacts for the bootloader will be readded later once ATF-A
support will be pushed mainline.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
airoha: an7583: add additional comments on EVB board
On the Airoha AN7583 EVB there are 2 Aeonsemi AS21xxx PHY but only the
one connected to Serdes Ethernet is usable as the other connected to
Serdes PON is not actually HW connected (as the serdes is connected to
the BOSA port)
Add comments and disable the relevant PHY.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
0d0fac30075f dhcpv4: bump problem scenario up to warn bf6137092346 config: properly set log level from uci 7956f4271b4e dhcpv6: RFC4833 timezones 7000557cd8f6 dhcpv6-ia: respect prefix assigned to interface (>= /64) e1e60601ffeb odhcpd: improve odhcpd_urandom() c2eb4b59f107 config: fix erroneous clamp message if clamp value == max 54b9e729b00d dhcpv4: bail earlier on release/decline 417f4b11d352 dhcpv4: don't hardcode options array length d63fa3c3612c dhcpv4: shrink struct dhcpv4_message 9653b43617e3 dhcpv4: use iovec for forcereconf messages, fix hash bf41f4edfbe3 dhcpv4: fix padding of iovec message in dhcpv4_handle_msg() be68f423c528 dhcpv4: some minor cleanups post-iovec e24a371ef714 dhcpv4: use iovec for forcerenew opts bd353e891ae6 dhcpv4: use iovec for router and DNS server b81cfaa7859e dhcpv4: use iovec for DNS search and MTU 578a9289440b dhcpv4: use iovec for netmask/hostname/broadcast 5bafc17b79d8 dhcpv4: use iovec for leasetime/renew/rebind b63448ffe447 dhcpv4: introduce a reply_opts array 0533eaea0a94 dhcpv4: use iovec for DNR 6329e37d595d dhcpv4: use iovec for NTP 87fee619205d dhcpv4: use iovec for message and serverid 2f97bf0b56de dhcpv4: reorder some more variables in dhcpv4_handle_msg() 18c1b02bdc20 dhcpv4: remove one more variable from dhcpv4_handle_msg() 6fd691ff29cd dhcpv4: move dest handling from dhcpv4_handle_msg() 1f803caf9a1f dhcpv4: don't copy reqopts around b1be3984ebf8 dhcpv4: more refactoring of dhcpv4_handle_msg() 85717bedf8ce dhcpv4: clarify variable names in dhcpv4_handle_msg() be864ccf9919 dhcpv4: some more cleanups to dhcpv4_handle_msg() f87464520564 dhcpv4: preparations for iovec usage f48e1c205af3 odhcdp: use a more suitable clock 7e78caac4eae dhcpv6: change dhcpv6 message type check in relay 288abd9c4046 dhcpv6: move dhcpv6 message type check for early exit d504458ef515 odhcpd: add a simple build script 4ee309a54011 github: improve CI ff3a241ccc98 odhcpd: shrink binary size by creating a logging function e2ecf7ba6d72 odhcpd: support stderr logging 5de3b0d5b509 odhcpd: add log helpers 398d03a1a236 config: cap dhcpv6_pd_min_len to max instead of only logging error 4f54738d3ae7 config: clamp dhcpv6_hostid_len instead of only logging an error 465f19c9c2e3 config: clamp ra_mtu into 1280-65535 range 434b06133997 config: cap ra_retranstime and warn instead of only logging an error e5f58a90a147 config: cap ra_hoplimit to maximum and warn instead of logging an error 208eb10307c1 config: cap ra_reachabletime to RFC maximum instead of logging error 93449f1513b4 config: drop double size lease times; they are all UINT32_MAX; 439c0ceab131 router: redefine ra_mininterval and ra_maxinterval as uint32_t 84b4dfe81363 config: clamp ra_mininterval, ra_maxinterval, ra_lifetime at load time aa4f26232e05 router: refactor calc_ra_lifetime; redefine ra_lifetime as uint32_t 6ece28ffd475 config: do MaxRtrAdvInterval init at (ra_maxinterval) init time dc03e02d973e router: Apply updated values from RFC9096 (updates RFC4861) to RA/ND cc7766c12abe router: Apply updated values from RFC8319 (updates RFC4861) to RA/ND 964da13e758c config: refactor parse_leasetime() - branch amount remains same 9646c749467b github: fix CMAKE_SYSTEM_PROCESSOR copy&paste 288206c9a2ed github: add CI build 30780debd691 odhcpd: fix a compilation error e0b2c3cf9476 odhcpd: allow assignments to be reassigned 01e5e311b0db odhcpd: support multiple per-client DUIDs aebc647a6b7b odhcpd: support assignments on the basis of IAID cc3ec9c20c61 odhcpd: support IAIDs for static DHCPv6 leases e42c62725942 odhcpd: break up complex matching logic e1123906a4bc odhcpd: document the ubus interface c69200195263 dhcpv4: generate dbus events on lease expiry dd7a2d474d0d dhcpv4: fix ubus events 22481d848e0d odhcpd: remove mac_len argument to ubus_bcast_dhcp_event() d31d64efd56c odhcpd: fix ubus support flag in help msg 9bc1b4e26e10 odhcpd: reduce use of WITH_UBUS defines in code d402cdae4316 ndp: fix macOS IPv6 compatibility by using link-local source addresses
77e1ae21e67f odhcp6c: set server address from Information-request reply e24ac1cf8c27 dhcpv6: use a per-interface IAID for IA_NA requests 053e6c4b3863 github: improve CI b65ff293a969 dhcpv6: Check status code for IA_ADDR operations 3c7e425169e1 dhcpv6: Add error checking to handle renew failure for IA_PD operations 8de25373a860 dhcpv6: dhcpv6_parse_ia refactor to switch case ca3cd525f447 odhcp6c: fix deamon raw buffer inc d7afeea2b965 dhcpv6c: fix illegal DHCPV6_OPT_FQDN 70f7467db301 script: don't ignore RA with zero router lifetime 6ca1552cb3fe odhcp6c: sync and accumulate RA & DHCPv6 events as fast as possible 29b58cfb4711 odhcp6c: update cmake file ee6d4a82bbeb github: add CI build
Gain telnet access:
1. Login into web interface, and download the configuration.
2. Uncompress the configuration:
* Enter fakeroot if you are not login as root.
tar -zxf <filename>.tar.gz
3. Edit 'etc/passwd', remove root password: 'root::1:0:99999:7:::'.
4. Edit 'etc/rc.local', insert telnetd command before 'exit 0':
( sleep 3s; telnetd; ) &
5. Repack the configuration:
tar -zcf backup.tar.gz etc/
6. Upload new configuration via web interface, now you can connect to
KOMI A31 via telnet.
Flash instructions:
1. Connect to KOMI A31, backup everything, especially 'Factory' part.
2. Write new BL2:
mtd write openwrt-mediatek-filogic-konka_komi-a31-preloader.bin BL2
3. Write new FIP:
mtd write openwrt-mediatek-filogic-konka_komi-a31-bl31-uboot.fip FIP
4. Set static IP on your PC:
IP 192.168.1.254/24, GW 192.168.1.1
5. Serve OpenWrt initramfs image using TFTP server.
6. Cut off the power and re-engage, wait for TFTP recovery to complete.
7. After OpenWrt has booted, perform sysupgrade.
generic: backport phylink patches for PCS/PHY caps OPs
Backport phylink patches for PCS/PHY caps OPs. This makes it easier to
align future generic PCS patch and permit supporting special PHY that
needs specific tune if "in-band" mode is enabled (for example Aeonsemi
PHYs)
This is also mainly using the upstream version of the Mediatek patch
739-net-add-negotiation-of-in-band-capabilities.
Christoph Krapp [Thu, 25 Sep 2025 10:26:45 +0000 (12:26 +0200)]
ath79: add calibration variant for TP-Link Archer C60 v2
Now that we have a board file, add calibration variant for TP-Link
Archer C60 v2 and add ipq-wifi package for it.
Tested-by: Semih Baskan <strstgs@gmail.com> Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20496 Signed-off-by: Robert Marko <robimarko@gmail.com>
L3 Offloading caused DHCP packets to be dropped at hardware level
And potentially buggy route implementation can cause a crash
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Co-developed-by: Sven Eckelmann <se@simonwunderlich.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20208 Signed-off-by: Robert Marko <robimarko@gmail.com>
realtek: rtl931x: Disable callbacks for l3 hw routing
The RTL931x is not supporting L3 offloading at the moment. To avoid crashes
when using this switch, simply disable L3 offloading completely.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Co-developed-by: Sven Eckelmann <se@simonwunderlich.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20208 Signed-off-by: Robert Marko <robimarko@gmail.com>
Add more explict guards around the unsupported generation of the initramfs
images and suppress requirement for certain others.
Fixes: https://github.com/openwrt/openwrt/issues/20151 Fixes: https://github.com/openwrt/asu/issues/1499 Signed-off-by: Eric Fahlgren <ericfahlgren@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20460 Signed-off-by: Robert Marko <robimarko@gmail.com>
Felix Fietkau [Tue, 21 Oct 2025 05:24:46 +0000 (07:24 +0200)]
netifd: update to Git HEAD (2025-10-20)
df2f5c9a30f8 veth: delete device before creation to handle stale state b6d371f30770 system-linux: handle RTM_DELLINK events for device state tracking 777f5942fa7d system-linux: only parse device status for AF_UNSPEC link messages
Rework the package SOURCE entry handling to account for the --root feeds
script feature.
Move the SOURCE entry string manipulation logic outside package-defaults.mk
in package.mk and limit only to non DUMP scenario to not pollute the .mk
too much.
Restructure the previous logic and add a new additional condition.
If we detect the package comes from a feed, replace any feed path that
have the _root prefix to the feed name with the non-root variant (the
feeds script create a symbolic link to it) and point the package SOURCE
entry to what the symbolic link points to.
Mark Mentovai [Mon, 20 Oct 2025 03:30:11 +0000 (23:30 -0400)]
ipq806x: restore recent changes made to 6.6 dts files
a33d59f7af8f (2025-10-14) restored dts files for kernel 6.6 to files-6.6
after the preceding 15fa59c41f0d moved files-6.6 to files-6.12 to be
used by the new testing kernel, 6.12. This restoration omitted 1a3f05eb2b8e (2025-10-08), which fixed important aspects of the wifi
device definitions in qcom-ipq8064-eax500.dtsi and
qcom-ipq8064-unifi-ac-hd.dts.
The 1a3f05eb2b8e fix persisted into the 6.12 dts files. This change now
restores it for 6.6. Note that ipq806x is currently using kernel 6.6 for
most purposes, as 6.12 is only in testing status for this target.
This change was prepared with `git diff a33d59f7af8f:target/linux/ipq806x/files-6.6 15fa59c41f0d^:target/linux/ipq806x/files-6.6`. This identified c186d17fa518 (2025-10-08) as another change that was not present in the
restored files-6.6, but it has since been superseded by 2a709d108e80
(2025-10-20), so no action is necessary to restore it. There were no
diffs present between these revisions in config-6.6 or patches-6.6,
which were also moved and restored in the 6.12 bring-up.
Signed-off-by: Mark Mentovai <mark@mentovai.com> Cc: Shiji Yang <yangshiji66@outlook.com> Cc: Rosen Penev <rosenp@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20464 Signed-off-by: Robert Marko <robimarko@gmail.com>
3. Download the sysupgrade firmware at openwrt.bin.
4. The firmware size should be 7995392 bytes. Fix the size of your firmware putting zeros to the end, with:
wifi-scripts: ucode: export HE and EHT operation in scan results
Export WiFi 6E (HE) and WiFi 7 (EHT) operation data in scan results.
These additional data can be useful to check wifi channel utilization
by nearby stations.
Example:
Cell 32 - Address: xx:xx:xx:xx:xx:xx
Mode: Master Frequency: 6.115 GHz Band: 6 GHz Channel: 33
Signal: -14 dBm Quality: 70/70
Encryption: SAE (CCMP)
HE Operation:
Center Frequency 1: 39
Center Frequency 2: 47
Channel Width: 160 MHz
EHT Operation:
Center Frequency 1: 47
Center Frequency 2: 63
Channel Width: 320 MHz
The SPI chip select GPIO polarity is active low by default. We must
use "spi-cs-high" dts property to toggle the polarity. The polarity
on "cs-gpios" won't take effect at all[1]. Fix these incorrect GPIO
polarities to silence the kernel warnings.
[1] Refer to Linux/Documentation/devicetree/bindings/spi/spi-controller.yaml
```
device node | cs-gpio | CS pin state active | Note
================+===============+=====================+=====
spi-cs-high | - | H |
- | - | L |
spi-cs-high | ACTIVE_HIGH | H |
- | ACTIVE_HIGH | L | 1
spi-cs-high | ACTIVE_LOW | H | 2
- | ACTIVE_LOW | L |
Notes:
1) Should print a warning about polarity inversion.
Here it would be wise to avoid and define the gpio as
ACTIVE_LOW.
2) Should print a warning about polarity inversion
because ACTIVE_LOW is overridden by spi-cs-high.
Should be generally avoided and be replaced by
spi-cs-high + ACTIVE_HIGH.
```
These devices only have one SPI peripheral. And the chip select pin is
directly controlled by the SPI host hardware. Hence we don't need to
assign empty GPIO phandle for them. This patch also adjust the reg
address of the SPI peripheral node to follow the cs-gpios changes.
Shiji Yang [Sun, 24 Aug 2025 12:57:18 +0000 (20:57 +0800)]
ipq806x: dts: fix SPI chip select GPIO polarity
The SPI chip select GPIO polarity is active low by default. We must
use "spi-cs-high" dts property to toggle the polarity. The polarity
on "cs-gpios" won't take effect at all[1]. Fix these incorrect GPIO
polarities to silence the kernel warnings.
[1] Refer to Linux/Documentation/devicetree/bindings/spi/spi-controller.yaml
```
device node | cs-gpio | CS pin state active | Note
================+===============+=====================+=====
spi-cs-high | - | H |
- | - | L |
spi-cs-high | ACTIVE_HIGH | H |
- | ACTIVE_HIGH | L | 1
spi-cs-high | ACTIVE_LOW | H | 2
- | ACTIVE_LOW | L |
Notes:
1) Should print a warning about polarity inversion.
Here it would be wise to avoid and define the gpio as
ACTIVE_LOW.
2) Should print a warning about polarity inversion
because ACTIVE_LOW is overridden by spi-cs-high.
Should be generally avoided and be replaced by
spi-cs-high + ACTIVE_HIGH.
```
Shiji Yang [Sun, 24 Aug 2025 12:56:54 +0000 (20:56 +0800)]
ipq40xx: dts: fix SPI chip select GPIO polarity
The SPI chip select GPIO polarity is active low by default. We must
use "spi-cs-high" dts property to toggle the polarity. The polarity
on "cs-gpios" won't take effect at all[1]. Fix these incorrect GPIO
polarities to silence the kernel warnings.
[1] Refer to Linux/Documentation/devicetree/bindings/spi/spi-controller.yaml
```
device node | cs-gpio | CS pin state active | Note
================+===============+=====================+=====
spi-cs-high | - | H |
- | - | L |
spi-cs-high | ACTIVE_HIGH | H |
- | ACTIVE_HIGH | L | 1
spi-cs-high | ACTIVE_LOW | H | 2
- | ACTIVE_LOW | L |
Notes:
1) Should print a warning about polarity inversion.
Here it would be wise to avoid and define the gpio as
ACTIVE_LOW.
2) Should print a warning about polarity inversion
because ACTIVE_LOW is overridden by spi-cs-high.
Should be generally avoided and be replaced by
spi-cs-high + ACTIVE_HIGH.
```
Shiji Yang [Sun, 24 Aug 2025 12:56:32 +0000 (20:56 +0800)]
ath79: dts: remove SPI num-cs property
This is a useless property on ath79 target. Both spi-ar934x and
spi-ath79 drivers don't check num-cs property. They always set
chip select number to 3.
Agustin Lorenzo [Mon, 13 Oct 2025 00:03:51 +0000 (02:03 +0200)]
mac80211: ath11k: backport of the latest changes applied for ath11k in 6.16.12
This includes the following commits from upstream Linux between 6.16 and 6.16.12:
wifi: ath11k: clear initialized flag for deinit-ed srng lists
wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()
wifi: ath11k: fix dest ring-buffer corruption
wifi: ath11k: fix source ring-buffer corruption
wifi: ath11k: fix dest ring-buffer corruption when ring is full
wifi: ath11k: fix group data packet drops during rekey [1]
wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()
[1] The patch "940-ath11k-Revert-clear-the-keys-properly-when-DISABLE_K.patch" has been removed, as it has been fixed upstream in "wifi: ath11k: fix group data packet drops during rekey" and is added in 945 patch.
Related: https://github.com/openwrt/openwrt/pull/18705
Related: https://github.com/openwrt/openwrt/issues/9555
Related: https://github.com/openwrt/openwrt/issues/14117
Christoph Krapp [Mon, 13 Oct 2025 19:41:36 +0000 (21:41 +0200)]
ramips: mt7621: add support for D-Link DIR-X1860 B1 / DIR-X1550 A1
Both devices seem to be completely identical and D-Link doesnt even
mention the DIR-X1550 A1 in the GPL source. Furthermore the supported
devices header also just contains DIR-X1860 B1. The cherry on top is the
FCC filing, which features the manual for DIR-X1550 A1 but the label
info for DIR-X1860 B1. I guess someone at D-Link was just as confused as
me.
MAC addresses
-------------
LAN Label MAC (stored in config2 partition as ASCII (entry
factory_mac=xx:xx:xx:xx:xx:xx))
WAN LAN + 3
2.4G LAN + 1
5G LAN + 2
Installation
------------
Vendor UI
---------
1. Browse to http://192.168.0.1 and login.
2. Navigate to "Management" -> "Upgrade".
3. Press the "Select File" button and upload
openwrt-ramips-mt7621-dlink_dir-x1860-b1-squashfs-factory.bin
4. Confirm the security questions, wait for a reboot and enjoy OpenWrt.
Recovery UI
-----------
1. Set your IP address to 192.168.0.101, subnet 255.255.255.0.
2. Power on the device while holding reset.
3. Release reset once the status led starts to blink orange.
4. Open a chrome- or firefox based browser and browse to
https://192.168.0.1
5. Upload openwrt-ramips-mt7621-dlink_dir-x1860-b1-squashfs-recovery.bin
wait for a reboot and enjoy OpenWrt.
Back to stock
-------------
1. Set your IP address to 192.168.0.101, subnet 255.255.255.0.
2. Power on the device while holding reset.
3. Release reset once the status led starts to blink orange.
4. Open a chrome- or firefox based browser and browse to
https://192.168.0.1
5. Upload a decrypted vendor image, wait for a reboot and regret your
decision.
Decrypt vendor image
--------------------
1. Download dlink-sge-image.c and dlink-sge-image.h from the
firmware-utils openwrt repository.
2. Compile a binary from the downloaded file
e.g. gcc dlink-sge-image.c -lcrypto -o dlink-sge-image
3. Run
./dlink-sge-image DIR-X1860-B1 <vendor_image> <decrypted_image> -d
Jonas Jelonek [Wed, 8 Oct 2025 19:07:06 +0000 (19:07 +0000)]
realtek: dsa: rtl931x: remove enabling MAC from phylink_mac_config
Originally, phylink_mac_config first disabled the MAC, then triggered
the SerDes setup and then re-enabled MAC. SerDes setup has been moved to
the PCS driver now but pcs_config is called AFTER phylink_mac_config by
phylink subsystem.
Thus, just disable the MAC in phylink_mac_config. After PCS has setup
the SerDes, the MAC should be properly brought up in a mac_link_up call
coming from the phylink subsystem.
Jonas Jelonek [Wed, 8 Oct 2025 14:21:57 +0000 (14:21 +0000)]
realtek: dsa,pcs: rtl931x: let PCS driver setup SerDes
Remove SerDes initialization/configuration calls from the DSA driver in
'rtl931x_phylink_mac_config' and let our PCS driver setup the SerDes now
that the driver is able to do that.
pcs_config of the PCS driver is automatically called by phylink, thus
there's no need to call it on our own.
Note that in rtl931x_phylink_mac_config the MAC is enabled before
pcs_config is called. While this seems to work, it isn't good and needs
to be fixed.
Jonas Jelonek [Wed, 8 Oct 2025 19:44:31 +0000 (19:44 +0000)]
realtek: pcs: rtl931x: quit setup_serdes early on USXGMII mode
In rtpcs_931x_setup_serdes, quit early on USXGMII mode. This restores
the behaviour introduced in c18476d0c5 to prevent the current buggy
procedure to destroy a working configuration established by U-Boot
before.
Also include the valuable comment from the code to keep the information.
Jonas Jelonek [Fri, 10 Oct 2025 09:40:26 +0000 (09:40 +0000)]
realtek: pcs: rtl931x: adjust SerDes page numbers
Adjust the SerDes page numbers to account for the different mapping used
by 'mdio-realtek-otto' and 'mdio-realtek-otto-serdes' drivers.
While importing the SerDes configuration code from PHY driver to PCS
driver, all helper calls to access the SerDes registers had to be
adjusted to use the proper helpers within the PCS driver. However, there
is one important implication of this: 'mdio-realtek-otto' and
'mdio-realtek-otto-serdes' use a slightly different page mapping.
While the old helpers in 'mdio-realtek-otto' used a page mapping of
0x00/0x100/0x200, 'mdio-realtek-otto-serdes' uses a mapping of
0x00/0x40/0x80 to provide consumers with the ability to only operate on
frontend SerDes. Thus, all page numbers > 63/0x3f have to be adjusted
like the following:
Jonas Jelonek [Thu, 16 Oct 2025 16:51:23 +0000 (16:51 +0000)]
realtek: pcs: rtl931x: use regmap for register access calls
Replaces the "old" way of accessing registers using the macros
sw_r32/sw_w32 from mach-rtl83xx.h. The "new" way to access register is
through the regmap API.
Jonas Jelonek [Wed, 8 Oct 2025 11:11:10 +0000 (11:11 +0000)]
realtek: pcs: rtl931x: import SerDes setup code from PHY driver
Let's start this transition with RTL931X.
Import all functions starting with 'rtl931x_' or 'rtsds_931x' from PHY
driver into the PCS driver, rename all functions to match a common
naming scheme and adjust signature, helper calls and function calls
accordingly to make it work within the PCS driver.
This is just copy&paste and tries to do only mandatory adjustments. The
code will be refactored in succeeding commits.
Also remove 'unused' attribute from helpers as they are used now.
Shiji Yang [Sun, 2 Feb 2025 08:50:25 +0000 (16:50 +0800)]
ramips: drop unsupported fit image option with-initrd
This option will only take effect when the "separate_ramdisk"
feature was enabled. However, this target does not support
this feature. It is an obvious copy and paste issue.
Shiji Yang [Sun, 2 Feb 2025 08:50:04 +0000 (16:50 +0800)]
airoha: drop unsupported fit image option with-initrd
This option will only take effect when the "separate_ramdisk"
feature was enabled. However, this target does not support
this feature. It is an obvious copy and paste issue.
ramips: add support for Zyxel NWA90AX access point
The NWA90AX is hardware-wise identical to the NWA50AX which is
already supported.
The NWA90AX magic model code bytes are `77 E1`,
and they are added to the DTS to mark the NWA50AX firmware
as being compatible with the 90 model.
Without the compat-models change, uploading the OpenWrt NWA50AX
firmware with the official Zyxel web interface yields an error:
> errno: -25007
> errmsg: Firmware content error!
As described on the NWA50AX firmware page[1] on the wiki, the
"current image" slot for firmware updates has to be "1".
If it is 0, flashing will fail.
Vendor support page stating that the hardware is identical:
https://support.zyxel.eu/hc/en-us/articles/4416989548178-Access-Point-NWA50-55AXEE-90AX-110AX-210AX-Differences-in-Hardware-and-Features
> NWA90AX: Identical hardware as in NWA50AX, but with added features
> like Captive portal for Guest access and WPA Enterprise for
> AD/Radius (Credential) authentication.
econet: Add Nokia G-240G-E and EN751221 recovery image
The Nokia G-240G-E is an xPON device with an EN7526G, 256M of
memory and 128M of flash. It has 1 USB2 port as well as phone and
ethernet but no wifi. Flashing instructions are per the typical
process using xmodem in the bootloader. This and other things
are described here: https://openwrt.org/inbox/toh/bt/g-240g-e_1
In addition, a generic image is offered, this image can be loaded
into memory from within the bootloader and launched directly. It
is recommended on the wiki of G-240G-E and other EcoNet devices
to be used for backing up the flash before flashing OpenWRT.
Shiji Yang [Mon, 19 May 2025 13:56:58 +0000 (21:56 +0800)]
mvebu: dts: fix unit name leading 0s warnings
Trim unnecessary 0s from the node name to fix the dtc warnings:
cn9131-puzzle-m901.dts:43.18-46.4: Warning (unit_address_format): /memory@00000000: unit name should not have leading 0s
cn9130-clearfog-pro.dts:33.18-36.4: Warning (unit_address_format): /memory@00000000: unit name should not have leading 0s
cn9132-puzzle-m902.dts:50.18-53.4: Warning (unit_address_format): /memory@00000000: unit name should not have leading 0s
armada-385-wd_cloud-mirror-gen2.dts:148.26-152.9: Warning (unit_address_format): /soc/internal-regs/nand-controller@d0000/nand@0/partitions/partition@00000000: unit name should not have leading 0s
armada-385-wd_cloud-mirror-gen2.dts:154.26-157.9: Warning (unit_address_format): /soc/internal-regs/nand-controller@d0000/nand@0/partitions/partition@00500000: unit name should not have leading 0s
armada-385-wd_cloud-mirror-gen2.dts:159.26-163.9: Warning (unit_address_format): /soc/internal-regs/nand-controller@d0000/nand@0/partitions/partition@00a00000: unit name should not have leading 0s
armada-385-wd_cloud-mirror-gen2.dts:165.26-168.9: Warning (unit_address_format): /soc/internal-regs/nand-controller@d0000/nand@0/partitions/partition@00f00000: unit name should not have leading 0s
David Härdeman [Fri, 10 Oct 2025 09:43:11 +0000 (11:43 +0200)]
odhcp6c: use the global DHCP DUID for DHCPv6
odhcp6c already supports custom DUIDS on a per-interface basis. When no client
identifier has been set, odhcp6c will generate one on the basis of the MAC
address of the given interface.
This is contrary to how DUIDs are meant to be used, as the client identifier
will vary from interface to interface, while it is meant to remain stable for a
given host, no matter how the network hardware changes (see RFC8415, §11).
Fix this by letting odhcp6c use the global DHCP DUID, if configured.
David Härdeman [Thu, 9 Oct 2025 14:16:53 +0000 (16:16 +0200)]
base-files: generate a global DHCP DUID
odhcp6c and odhcpd currently generate custom DUIDS on a per-interface basis
using the MAC address of the given interface.
This is contrary to how DUIDs are meant to be used, as the client identifier
will vary from interface to interface, while it is meant to remain stable for a
given host, no matter how the network hardware changes (see RFC8415, §11).
The same problem exists in odhcpd, which also generates server-side DUIDs on a
per-interface basis.
In order to support a stable per-device DUID, generate one on first boot and
store it via uci.
Currently, a DUID-UUID style clientid is generated. This is mostly meant as an
RFC, and we might consider using a different kind of DUID instead (DUID-LLT,
DUID-EN).
One drawback is that this will typically change the DUID used on existing
OpenWrt devices when upgrading to a new release. However, that seems
unavoidable and is a one-time pain in order to have stable DUIDs (and in many
cases, it shouldn't cause any issues).
v2: move the uci cfg generation outside of an IPv6-only block since this
is relevant to the DHCPv4 client as well
realtek: add xgs1210-12 b1 and switch to rt-loader
rev B1 is identical to rev A1 except for different PHYs on the 2.5gbps ports (lan9 and lan10)
Both revisions of xgs1210-12 are also switched to use rt-loader to avoid
problems due to overwriting the compressed image in memory when flashing
with the oem firmware (and also to save flash space with respect to gzip
compression)
Christoph Krapp [Sun, 19 Oct 2025 11:52:31 +0000 (13:52 +0200)]
ipq40xx: add device alias for Linksys VLP01
Both devices, the Linksys WHW01 and the VLP01, are essentially the same
device. Even Linksys provides only one image for both devices which uses
the WHW01 identifier in the image header.
Paul Donald [Fri, 17 Oct 2025 19:33:13 +0000 (21:33 +0200)]
lldpd: bump to 1.0.20
Also implemented the med fast-start -> lldp fast-start change.
lldpd includes a backwards compat handler for the older med command,
but it's better to make these changes so they align with documentation.
Changes:
Enable fast start unconditionally (and move its configuration in "configure lldp")
Make VLAN advertisements configurable
Fix:
Do not break zero-copy traffic on Linux
Fix crash on rapid addition/removal of interfaces
Fix management address selection when pattern is a negative IP address
LAN5 (rear) is for POE input. LAN4 has POE output (802.3af) when powered
by an 802.3at source.
The LAN4 port is used for tftp booting in U-Boot.
This device does not have secure boot, but cannot be flashed without
external programmers (TSOP48 NAND) as Meraki disabled interrupting U-Boot
for any device that updated after ~2017.
Disassembly:
* Remove the two T10 screws on the rear of the AP.
* Using a guitar pick or similar plastic tool, insert it on the side between
the grey metal plate and the white plastic body and pry up gently.
* The rubberised border on the metal plate does not need to be removed.
* The metal back plate has several latches around the perimeter (but none on
the bottom by the Ethernet ports).
* Once you have removed the metal back plate, push up gently on the bottom
Ethernet ports while pulling gently on the rear-mounted Ethernet port to remove
the PCB.
* The PCB should come free from the plastic housing, pull the bottom
(4 Ethernet ports) up as if you are opening a book.
* If done carefully, there is no need to remove the WiFi antenna connectors
to access the NAND flash.
* The TSOP48 NAND flash (U30, Spansion S34ML01G200TFV00) is located on the
opposite side of the PCB.
* To flash, you need to desolder the TSOP48 or use a 360 clip.
Installation:
The dumps to flash can be found in this repository:
https://github.com/halmartin/meraki-openwrt-docs/tree/main/mr30h
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.
* Resolder the NAND after overwriting the `u-boot` regions.
OpenWrt Installation:
* After flashing NAND with the external programmer. Plug an Ethernet
cable into port 4. 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 <your_tftp>
tftpboot openwrt-ipq40xx-generic-meraki_mr30h-initramfs-uImage.itb
```
* Once booted into the OpenWrt initramfs, `scp` the `sysupgrade` image to
the device and run the normal `sysupgrade` procedure:
```
scp -O openwrt-ipq40xx-generic-meraki_mr30h-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/
ssh root@192.168.1.1 "sysupgrade -n /tmp/openwrt-ipq40xx-generic-meraki_mr30h-squashfs-sysupgrade.bin"
```
* OpenWrt should now be installed on the device.
Alternative installation steps if your device has U-Boot older than:
`U-Boot 2017.07-RELEASE-g78ed34f31579 (Sep 29 2017 - 07:43:44 -0700)`
**BIG FAT WARNING BEGIN**
Attmping to interrupt boot on a newer U-Boot release may permanently
brick your device! See: riptidewave93/LEDE-MR33#13
**BIG FAT WARNING END**
* Use `ubootwrite.py` from the above GitHub repository to transfer the
`u-boot.itb`
image to the router.
```
./ubootwrite.py --serial=/dev/ttyUSB0 --write u-boot.itb
```
* To avoid bricking your router, it is highly recommended at this point that
you flash the unlocked U-Boot to the `part.safe` ubi volume.
```
run set_ubi && ubi write $loadaddr part.safe 0x2fd48
```
* Power cycle the router. The stock Meraki U-Boot will boot `part.safe` which
is now the unlocked U-Boot.
* Use the new U-Boot build (`" "` to interrupt boot) to
`tftpboot` the OpenWrt initramfs image:
```
dhcp
setenv serverip <tftp_server_addr>
tftpboot openwrt-ipq40xx-generic-meraki_mr30h-initramfs-uImage.itb
bootm
```
* It is only recommended to flash U-Boot to the `u-boot` NAND region from
Linux:
```
insmod mtd-rw i_want_a_brick=1
```
* Copy `u-boot.elf` to the router:
```
scp -O u-boot.elf root@192.168.1.1:/tmp/
```
Note: If any of the below commands fails, YOU WILL HAVE A BRICK IF YOU
REBOOT OR LOSE POWER. Only a hardware programmer can recover the device.
```
flash_erase /dev/mtd8 0 0
nandwrite -p /dev/mtd8 /tmp/u-boot.elf
```
Note: ONLY use `u-boot.elf` when flashing the `u-boot` region (`/dev/mtd8`);
`u-boot.bin` or `u-boot.itb` will BRICK YOUR DEVICE
* `scp` the `sysupgrade` image to the device and run the normal `sysupgrade`
procedure:
```
scp -O openwrt-ipq40xx-generic-meraki_mr30h-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/
ssh root@192.168.1.1 "sysupgrade -n /tmp/openwrt-ipq40xx-generic-meraki_mr30h-squashfs-sysupgrade.bin"
```
Hal Martin [Sun, 19 Oct 2025 10:13:54 +0000 (12:13 +0200)]
ipq40xx: add support for Cisco Meraki Go GX20
This commit adds support for the Cisco Meraki Go GX20. The Go GX20 is a wired
router with 5 port Gigabit switch. It shares the same PCB as the Meraki Z3,
but without the WiFi radios.
Port 5 has POE output (802.3af). The Internet/WAN port is used for tftp booting
in U-Boot.
This device ships with secure boot, and cannot be flashed without
external programmers (TSOP48 NAND and I2C EEEPROM)!
Disassembly:
* Remove the four T8 screws on the bottom of the device under the rubber feet.
* Using a guitar pick or similar plastic tool, insert it on the side between
the bottom case and the side, pry up gently. The plastic bottom has several
latches around the perimeter (but none on the rear by the Ethernet ports).
* The TSOP48 NAND flash (U30, Spansion S34ML01G200TFV00) is located on the
bottom side of the PCB (facing you as you remove the bottom plastic).
To flash, you will need to desolder the TSOP48. Attempts to flash in-circuit
using a 360 clip were unsuccessful.
* The SOIC8 I2C EEPROM (U32, Atmel 24C64) is located on the bottom side of
the PCB (facing you as you remove the bottom plastic). It can be flashed in
circuit using a SOIC8 chip clip.
Installation:
The dumps to flash can be found in this repository:
https://github.com/halmartin/meraki-openwrt-docs/tree/main/z3_gx20
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 `0x2b`). 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 an Ethernet
cable into the Internet/WAN port. 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 <your_tftp>
tftpboot openwrt-ipq40xx-generic-meraki_gx20-initramfs-uImage.itb
```
* Once booted into the OpenWrt initramfs, `scp` the `sysupgrade` image to
the device and run the normal `sysupgrade` procedure:
```
scp -O openwrt-ipq40xx-generic-meraki_gx20-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/
ssh root@192.168.1.1 "sysupgrade -n /tmp/openwrt-ipq40xx-generic-meraki_gx20-squashfs-sysupgrade.bin"
```
Port 5 has POE output (802.3af). The Internet/WAN port is used for tftp booting
in U-Boot.
This device ships with secure boot, and cannot be flashed without
external programmers (TSOP48 NAND and I2C EEEPROM)!
Disassembly:
* Remove the four T8 screws on the bottom of the device under the rubber feet.
* Using a guitar pick or similar plastic tool, insert it on the side between
the bottom case and the side, pry up gently. The plastic bottom has several
latches around the perimeter (but none on the rear by the Ethernet ports).
* The TSOP48 NAND flash (U30, Spansion S34ML01G200TFV00) is located on the
bottom side of the PCB (facing you as you remove the bottom plastic).
To flash, you will need to desolder the TSOP48. Attempts to flash in-circuit
using a 360 clip were unsuccessful.
* The SOIC8 I2C EEPROM (U32, Atmel 24C64) is located on the bottom side of
the PCB (facing you as you remove the bottom plastic). It can be flashed in
circuit using a SOIC8 chip clip.
Installation:
The dumps to flash can be found in this repository:
https://github.com/halmartin/meraki-openwrt-docs/tree/main/z3_gx20
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 `0x24`). 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 an Ethernet
cable into the Internet/WAN port. 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 <your_tftp>
tftpboot openwrt-ipq40xx-generic-meraki_z3-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
ubimkvol /dev/ubi0 -N ART -s 524288
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_z3-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/
ssh root@192.168.1.1 "sysupgrade -n /tmp/openwrt-ipq40xx-generic-meraki_z3-squashfs-sysupgrade.bin"
```
projects / thirdparty / openwrt.git / log
