Erik Karlsson [Mon, 6 Oct 2025 13:46:36 +0000 (15:46 +0200)]
rules.mk: do not set CCACHE_NOHASHDIR
Not hashing CWD is potentially unsafe since it involves deliberately
poisoning the cache in certain situations in exchange for performance
gain. It can lead to debug information pointing out either no longer
existing or much worse incorrect source files, possibly leading
developers onto a false track and wasting a lot of time.
If one wishes to save build time by sharing the cache between multiple
source trees, this can be achieved safely by enabling reproducible
debug information, like this:
Note that CWD hashing gets disabled implicitly when reproducible debug
information is enabled. The CCACHE_NOHASHDIR option is only for
disabling CWD hashing in cases where it is not safe to do so.
Thomas Martitz [Wed, 24 Sep 2025 12:49:07 +0000 (14:49 +0200)]
realtek: rtl930x: add XGS1250-12 B1 device
The A1 and B1 devices are largely the same. The differences
seem to be:
- RTL8218D (A1) vs RTL8218E (B1) PHY for the eight 1 Gbps TP ports
- Aquantia (A1) vs RTL8261N (B1) PHY for the three 10 Gbps TP ports
RTL8218D/E share the same driver and support was added already by
commit c8c187f0f0 ("realtek: add support for RTL8218E").
The RTL8261N is also already supported but it's located at
different addresses compared to the A1 device. This requires
the device tree to be split. As a result, the devices are require
different images.
I found the smi addresses on the forum:
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/3622
And I can conform on my B1 device that this is working.
There are switches which share the same overall hardware design but remove
just a couple of components for the low cost variant. For example, a 8+2
(ethernet+SFP) switch might have a low cost variant which only has 8
ethernet ports. In this case, the PCB will be shared but components for SFP
will just be dropped.
The LED shift registers will be the same between the two switches but the
ports are different. But since the rtl930x_led_init code is trying to
calculate the number of LEDs using the LED ports, the ethernet status ports
will then suddenly be shifted by two ports.
It is therefore necessary to have a mechanism to overwrite the detection of
the ethernet ports in the LED initialization and force some ports to
"virtually there" for the LED controller.
This functionality was already implemented for Plasma Cloud PSX8 (RTL930x)
but some devices using RTL931x might also benefit from a similar feature.
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/20300 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The LED sets must be configured before per-port LEDs are actually assigned.
At the same time, the LED set configuration was basically unreadable and
the RTL930x from commit 2cfb1ecf1035 ("rtl930x: Rework per port LED
configuration") does a better job. Instead of moving the old implementation
around, just adopt the one from RTL930x.
Sven Eckelmann [Tue, 15 Jul 2025 17:53:07 +0000 (19:53 +0200)]
realtek: rtl931x: Add support for active-low LEDs
RTL930x received support for specifying active low/high LEDs in commit bec9e79a99ad ("realtek: dsa: support active-high LEDs"). But this was
completely forgotten on RTL931x.
Sven Eckelmann [Tue, 15 Jul 2025 17:53:07 +0000 (19:53 +0200)]
realtek: rtl930x: Fix out-of-bounds check in LED set configuration
of_property_count_u32_elems returns the number of u32 and not the number of
bytes. It must therefore be checked against the number of u32 in set_config
and not the bytes in set_config.
Fixes: 2cfb1ecf1035 ("rtl930x: Rework per port LED configuration") Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20300 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
There are switches which share the same overall hardware design but remove
just a couple of components for the low cost variant. For example, a 8+2
(ethernet+SFP) switch might have a low cost variant which only has 8
ethernet ports. In this case, the PCB will be shared but components for SFP
will just be dropped.
The LED shift registers will be the same between the two switches but the
ports are different. But since the rtl930x_led_init code is trying to
calculate the number of LEDs using the LED ports, the ethernet status ports
will then suddenly be shifted by two ports.
It is therefore necessary to have a mechanism to overwrite the detection of
the ethernet ports in the LED initialization and force some ports to
"virtually there" for the LED controller.
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/20300 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
iproute2: enable automatic color output by default
Support for color output has existed in iproute2 since forever and we
never compile it out, even in tiny variants. As such, not requiring
people to constantly add -c to their ip commands is a nice QoL feature.
iproute2: split iproute2 configure and compile logic
Previously we relied on the iproute2 makefile automatically running the
configure script on first run. This does not allow control of some
configure options, or of when the configure script is re-run.
The motivating usecase here is ./configure --color=auto, though that is
not implemented in this commit.
iproute2: stop writing unused snapshot information
iproute2 already generates and uses a proper version string based off
of git since 2020 [1]. Since the aforementioned commit has already
removed the include for SNAPSHOT.h, this bit of code has had no effect
since then other than disabling the built-in configure script invocation.
Til Kaiser [Fri, 22 Nov 2024 14:20:10 +0000 (15:20 +0100)]
base-files: add ucidef_set_interface_netdev_range function
The ucidef_set_interface* functions can be used to
add network interfaces to a default network configuration.
Such network interfaces often have the same base interface
name (e.g., eth* or lan*). On devices with many network ports,
adding all ports to the default config can become inconvenient.
This commit adds a new uci function ucidef_set_interface_netdev_range,
which adds network interfaces for a specific port range to a given
OpenWrt interface. The first parameter is the OpenWrt interface, the
second is the base interface name, the third is the port start, and
the fourth is the port end range.
Currently, the interfaces of the Mellanox Spectrum Switch QSFP ports
are all labeled eth*. Their order doesn't match the faceplate and is
different for each model.
They could be named during boot, but this isn't sufficient because they
support port splitting. After such ports are split, their port naming
begins again with eth*, and the same is true after they are unsplit again.
A hotplug script is used here that reads from the sysfs file
phys_port_name, which contains p1, p2, p3, ... for unsplit ports
and p1s0, p1s1, p1s2 for split ports.
Til Kaiser [Sat, 12 Oct 2024 16:32:08 +0000 (18:32 +0200)]
kernel: modules: load e1000e driver during pre-init stage
Set the pre-init boot flag for the e1000e network device
driver so that it is loaded during the early pre-init
stage of the boot process instead of later.
Then, it is possible to rename its network ports via the
ucidef_set_network_device_path function from the
02_network script while booting.
Zoltan HERPAI [Fri, 30 May 2025 21:30:38 +0000 (21:30 +0000)]
sunxi: add F1C100 (arm926ej-s) support
This is Allwinner's ARM926EJ-S core, which is one of its early
products, reappearing in recent compact designs. The SoC includes
32/64Mb memory in the same physical package, and has display and USB
interfaces, allowing for very small footprint boards.
The target consists of basic 6.12 support, with u-boot. Instead of creating
a separate suniv target, as both the kernel and u-boot supports enough of
this SoC by now with minimal patching, add it into sunxi as a subtarget.
b14cf98 router: log “Sending a RA on lan” at LOG_DEBUG c2810fe odhcpd: update cmake file 8c2c065 odhcpd: convert README to markdown 3b96480 odhcpd: allow the use of an alternative cfg file 7328bfe odhcpd: remove confusing #defines cdb9e5b odhcpd: improve RFC9096 § 3.5 SLAAC compliance
RFC9096 § 3.5 SLAAC compliance introduces a new config option (odhcpd
piofolder), which may wear out the flash under certain conditions (for
example: ISPs with dynamic IPv6 prefixes which disconnect the clients
every X hours).
Therefore, setting "dhcp.odhcpd.piofolder" to persistent storage in the
router flash is not advisable and should be set to other kinds of
persistent storage such as USBs, SDs, NVMEs...
In order to prevent wearing out the router flash it's set to ephemeral
storage by default (tmp):
uci set dhcp.odhcpd.piofolder="/tmp/odhcpd-piofolder"
The first RTL931x devices make their way into OpenWrt. Their copper
ports are driven by different interfaces modes like 10G_QXGMII or
Realtek proprietary XSGMII. The DSA driver has no proper handling
for theses modes implemented yet. So a lot is auto-mapped to USXGMII
internally. As soon as the SerDes setup activates this (wrong) mode
the PHY connectivity breaks.
Disable this mode for now and rely on the proper U-Boot setup.
The upstream commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/smb?h=linux-6.6.y&id=fa1c47af4ff641cf9197ecdb1f8240cbb30389c1
and the extended for ipv6 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/smb?h=linux-6.6.y&id=d9e157fcfebc126cd19b2333a6417a840c24e529
cause a regression if you try to get a connection on nautilus by a double click on share name.
When you do a double click on share name Nautilus try to connect two times, and ksmbd refusing it.
An issue is opened here https://github.com/namjaejeon/ksmbd/issues/512, at the moment, until we don't have a fix upstream I suggest to revert these two commits.
Markus Gothe [Thu, 25 Sep 2025 08:32:58 +0000 (10:32 +0200)]
base-files: commit and sync before removing defaults script.
Improve the resilence against power failures during
boot-up by trying to sync the file system before
removing the script. The order of the operations
are important.
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console (115200 8N1) must be used to access the u-boot shell
during bootup. It can then be used to first boot up the initramfs image
from a TFTP server (here with the IP 192.168.1.21):
mt76 as support for generic rates power limits in the devicetree. But the
mt7915 supports beamforming and has another table for configuring the
backoff limits. These can be configured in the DT with the paths-*
properties. The path-*-bf are the ones relevant for beamforming and the
ones without -bf suffix for "traditional" path backoff.
mt76: Fix DTS power-limits on little endian systems
The power-limits for ru and mcs and stored in the devicetree as bytewise
array (often with sizes which are not a multiple of 4). These arrays have a
prefix which defines for how many modes a line is applied. This prefix is
also only a byte - but the code still tried to fix the endianness of this
byte with a be32 operation. As result, loading was mostly failing or was
sending completely unexpected values to the firmware.
Since the other rates are also stored in the devicetree as bytewise arrays,
just drop the u32 access + be32_to_cpu conversion and directly access them
as bytes arrays.
Coia Prant [Wed, 1 Oct 2025 07:55:57 +0000 (15:55 +0800)]
ramips: Fix Hongdian H7920 v40 pinctrl default state
According to the MT7628 hardware datasheet:
- GPIO/4 was originally used for I2C, but is now used as the Modem Power.
- GPIO/5 was originally used for I2C, but is now used as the SIM card select. (n/a for this device)
- GPIO/6 was originally used for SPI CS1, but is now used as the Serial mode switch.
- GPIO/36 was originally used for PERST, but is now used as the GPS OE. (n/a for this device)
- GPIO/38 was originally used for WDT, but is now used as the Modem2 Power. (n/a for this device)
- GPIO/44 was used for WLED_AN, but is now controlled by `gpio-leds`.
Corrected pinctrl to ensure it works properly in the future.
Fix Timing side-channel in SM2 algorithm on 64 bit ARM.
(CVE-2025-9231)
Fix Out-of-bounds read in HTTP client no_proxy handling.
(CVE-2025-9232)
Reverted the synthesised OPENSSL_VERSION_NUMBER change for the release
builds, as it broke some exiting applications that relied on the previous
3.x semantics, as documented in OpenSSL_version(3).
realtek: rtl931x: Add support for Plasma Cloud ESX28 Switch
The Plasma Cloud ESX28 Switch is a 24 + 4 port multi-GBit switch with
24x 10/100/1000/2500BaseT Ethernet ports and 4x SFP+ module slot.
Hardware:
- RTL9312C SoC
- Macronix MX25L25645G (32MB flash)
- 512MB DDR3 SDRAM
- RTL8231 GPIO extender to control the port LEDs
- 6x RTL8224 4x 10m/100m/1/2.5 Gigabit PHY
- SFP+ 4x 10GBit slot
The switch is powered directly via AC.
The external RS232 serial connector (RJ45, Cisco pinout) can be used to
access the terminal. Serial connection is via 115200 baud, 8N1.
A reset button is accessible through a hole in the front panel.
Installation
------------
* The device can be flashed by using sysupgrade command. Either from the
original vendor firmware or using an initramfs (see "Debug")
* Connect serial on front panel. Connection parameters: 115200 8N1
* The image must be copied using scp to /tmp of the device
scp openwrt-realtek-rtl931x-plasmacloud_esx28-squashfs-sysupgrade.bin root@[IP address of the device]:/tmp/
* start sysupgrade without saving the original vendor configuration
* Connect serial on front panel. Connection parameters: 115200 8N1.
* A tftp server is required, tftpd-hpa works well.
* Power the device, at U-Boot start rapidly hit Esc key to stop autoboot
* Enter passwords: "1234" or "plasmapsx"
* Enable network:
realtek: rtl931x: Add support for Plasma Cloud PSX28 Switch
The Plasma Cloud PSX28 Switch is a 24 + 4 port multi-GBit switch with
24x 10/100/1000/2500BaseT Ethernet ports and 4x SFP+ module slot.
Hardware:
- RTL9312C SoC
- Macronix MX25L25645G (32MB flash)
- 512MB DDR3 SDRAM
- RTL8231 GPIO extender to control the port LEDs
- 6x RTL8224 4x 10m/100m/1/2.5 Gigabit PHY
- SFP+ 4x 10GBit slot
- RTL8239 POE++ PSE controller with frontend MCU
The switch is powered directly via AC.
The external RS232 serial connector (RJ45, Cisco pinout) can be used to
access the terminal. Serial connection is via 115200 baud, 8N1.
A reset button is accessible through a hole in the front panel.
Installation
------------
* The device can be flashed by using sysupgrade command. Either from the
original vendor firmware or using an initramfs (see "Debug")
* Connect serial on front panel. Connection parameters: 115200 8N1
* The image must be copied using scp to /tmp of the device
scp openwrt-realtek-rtl931x-plasmacloud_psx28-squashfs-sysupgrade.bin root@[IP address of the device]:/tmp/
* start sysupgrade without saving the original vendor configuration
* Connect serial on front panel. Connection parameters: 115200 8N1.
* A tftp server is required, tftpd-hpa works well.
* Power the device, at U-Boot start rapidly hit Esc key to stop autoboot
* Enter passwords: "1234" or "plasmapsx"
* Enable network:
Sven Eckelmann [Mon, 14 Apr 2025 13:16:47 +0000 (13:16 +0000)]
realtek: rtl931x: Enable parsing of u-boot nvmem layouts
To be able to read out the ethaddr from the u-boot environment for MAC
address configuration, it is required to also enable the NVMEM layout
parsing code for the U-Boot env layout.
Tianling Shen [Fri, 3 Oct 2025 08:02:10 +0000 (16:02 +0800)]
rockchip: make use of OpenWrt compiled dtbs
OpenWrt buildroot will compile all dtbs defined in target to
$(KDIR)/image-$(DEVICE_DTS).dtb, so make use of it to allow us
debug and use external dtbs easier without patching kernel Makefile.
This also fixes commit 5c724939c396 which forgot to update DTS_DIR
in KERNEL variable.
Hauke Mehrtens [Sat, 4 Oct 2025 10:22:52 +0000 (12:22 +0200)]
firmware-utils: update to Git HEAD (2025-10-01)
4b7638925d3e iptime-crc32: add support for ipTIME AX3000M 12c0b42231be nosimg-enc: add new tool for XikeStor SKS8300 series 2051fe5bc2a1 mktplinkfw2: Add 16MLmtk layout 5d1446bf57d6 tplink-safeloader: Add more special_id's for MR70X 075cdc0c4dd4 iptime-crc32: add support for ipTIME AX3000Q 48ababab6b08 iptime-crc32: add support for ipTIME AX3000SM f29de74ecd7d iptime-crc32: Add device support for ipTIME AX6000M 3346d7711c9a build: add mkqdimg 950f83405a93 iptime-crc32: add support for ipTIME AX7800M-6E 0725c3d4aa1b build: require CMake >= 3.5 due to dropped legacy support 996dc482a7e8 ptgen: fix misprint and simplify calculation a bit febfef7a09b1 ptgen: use long long instead of long for sizes 6ea8b6dd44d0 ptgen: fix protective MBR partition size f1f98b0b8456 ptgen: do not create stub partition to fill a gap if gap caused by alignment 3f2d14829150 ptgen: allow non-default placement of gpt entry table 78d8084c7376 ptgen: allow image generation for a specified disk size 9fa340db640e ptgen: create separate images for gpt data structure d3f8b6ed940a zynsig: add new tool for creating images for the ZyXEL GS1920 series 7e6f69b444c3 npk_pack_kernel: add tool for creating MikroTik NPK kernel packages 0782d243d23e Revert "ptgen: do not create stub partition to fill a gap if gap caused by alignment"
Andy Chiang [Thu, 2 Oct 2025 21:12:12 +0000 (04:12 +0700)]
iptables: fix breaking packing
after change include/package-pack.mk in 16416782f194d1850a9d9accf02f04832a7fcea4, must use ALTERNATIVES to create soft link, otherwise the packing will be messed up.
Fixes: openwrt#20270 Fixes: openwrt#20291 Fixes: 16416782f194d1850a9d9accf02f04832a7fcea4 (include: make APK packing mtime reproducible) Signed-off-by: Andy Chiang <AndyChiang_git@outlook.com> Link: https://github.com/openwrt/openwrt/pull/20283 Signed-off-by: Robert Marko <robimarko@gmail.com>
Andreas Gnau [Fri, 3 Oct 2025 08:59:42 +0000 (10:59 +0200)]
tools/ccache: same behaviour for local and CI builds
If the environment variable `CI` is set, ccache will enable the CMake
option CCACHE_DEV_MODE by default. This leads to differing behaviour
between local and CI builds which takes quite some time to debug. 🤯
Achieve consistent behaviour between local builds and CI builds by
setting CCACHE_DEV_MODE. Set it to OFF, because CCACHE_DEV_MODE amongst
other settings like linker choice, enables -Werror, which will lead to
potential compilation failures when the host compiler is updated. Using
-Werror for host utils is not desirable, because the compiler version
used is not controlled by the OpenWrt build system and host utils should
compile successfully on an as wide range of host OSes as possible.
Reported-by: Roman Azarenko <roman.azarenko@iopsys.eu> Signed-off-by: Andreas Gnau <andreas.gnau@iopsys.eu> Link: https://github.com/openwrt/openwrt/pull/20290 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
d3be5474f6e6 udebug-cli: ignore zero-length messages in logstream c79f02d899df ucode: fix skipping lines where the timestamp cannot be parsed 5327524e7153 cmake: bump minimum required version to 3.13
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
If transmissions are done outside of the DSA switch (directly from the CPU
port), the STP state must not block the transmission. Otherwise, STP frames
are not correctly submitted and the STP frames cannot correctly detect
loops before switching a port in the forwarding state.
The same applies for the LLDP frames. These must be submitted independent
of the STP state to identify neighbors or configure POE limits.
It is not necessary to filter specific destination mac addresses because
the transmission was done outside the bridge/switch in the first place. The
transmission is therefore forced.
Signed-off-by: Issam Hamdi <ih@simonwunderlich.de> Co-developed-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/20184 Signed-off-by: Robert Marko <robimarko@gmail.com>
realtek: rtl93xx: dsa: Add support for port based mirroring
The RTL930X and RTL931X SoCs support port-based, flow-based, and
RSPAN-based mirroring. Like for other SoCs from the realtek target, only
the port based port mirroring can be exposed using Linux's tc subsystem.
The port_mirror_add() implementation was updated with the following
considerations for RTL93xx SoCs:
* mirrored packets must pass through the TX pipeline of the mirroring
port, so they are subject to configuration such as VLAN tagging,
remarking, and EVC
* when a packet hits both source ports (SPM) and destination port (DPM) of
a mirror group, the egress port traffic will be mirrored
The port_mirror_del() function doesn't require any modifications.
Signed-off-by: Sharadanand Karanjkar <sk@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/20264 Signed-off-by: Robert Marko <robimarko@gmail.com>
Sven Eckelmann [Tue, 15 Jul 2025 17:48:05 +0000 (19:48 +0200)]
realtek: dsa: Keep HW specific mirror code in SoC helper
Instead of using a lot of if-else blocks in the port mirror code, provide
SoC specific function which calculates the SoC specific portions. The
generic part of the port mirroring code can then simply operate on the
calculated register addresses and values.
Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20264 Signed-off-by: Robert Marko <robimarko@gmail.com>
Paul Spooren [Wed, 1 Oct 2025 13:22:38 +0000 (15:22 +0200)]
package: generate sha256sums by default
Right now the sha256sums are only created for the targets/ folder (i.e.
firmware images) and only the buildbot generates those sha256sums. Instead, let
the build system create the sha256sums directly.
Til Kaiser [Thu, 2 Oct 2025 13:01:35 +0000 (15:01 +0200)]
kernel: modules: fix mlxreg dependency to avoid deferred probe
The mlxreg-hotplug platform driver was failing to probe due to a missing
I²C multiplexer dependency. Previously, only kmod-i2c-mux-mlxcpld was
declared, but mlxreg also requires kmod-i2c-mux-reg to initialize its
I²C mux functionality.
Without this dependency, the driver probe was deferred:
The FIT loadaddr on RK3308/RK3566/RK3568/RK358x is 0x02000000
instead of 0x02080000, while on RK3576 it's 0x42000000, which is
quite different from the former SoCs and incompatible with current
kernel loadaddr value.
Jonas Jelonek [Fri, 12 Sep 2025 19:33:18 +0000 (19:33 +0000)]
realtek: rtl93xx: replace pending I2C patches with upstreamed patches
Replace the pending I2C backport patches for RTL93XX added in 44655c97bb with the upstreamed variants. The patches have been accepted
upstream in the meantime and are included in v6.17 or v6.18.
projects / thirdparty / openwrt.git / log
