Christoph Krapp [Thu, 25 Sep 2025 07:30:27 +0000 (09:30 +0200)]
ath79: add calibtation variant for TP-Link Archer C59 v1
Now that we have a board file, add calibration variant for TP-Link
Archer C59 v1 and add ipq-wifi package for it.
Tested-by: Mateusz Jończyk <matjon@users.noreply.github.com> Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20401 Signed-off-by: Robert Marko <robimarko@gmail.com>
apk-tools: fix compilation warning from downstream full print patch
Fix trivial compilation warning caused by downstream full print patch.
../src/app_list.c: In function 'print_full':
../src/app_list.c:85:35: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'uint64_t' {aka 'long long unsigned int'} [-Wformat=]
85 | printf("Installed-Size: %zu\n", pkg->installed_size);
| ~~^ ~~~~~~~~~~~~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| unsigned int
| %llu
../src/app_list.c:86:25: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'uint64_t' {aka 'long long unsigned int'} [-Wformat=]
86 | printf("Size: %zu\n", pkg->size);
| ~~^ ~~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| unsigned int
| %llu
../src/app_list.c:58:31: warning: unused variable 'd' [-Wunused-variable]
58 | struct apk_dependency d;
Remove unused variable and use PRIu64 to handle uint64_t type.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
tools/meson: add pending patch to improve binary reproducibility
Add 3 pending patch that improve binary reproducibility. The first
address a problem with RPATH string not getting cleared on removal of
RPATH entry from ELF section. The other 2 skip including external shared
library in RPATH in meson build phase.
This follows the logic that on cross-compiling we can't run the binary
anyway as it does target a different arch hence it doesn't make sense to
include those extra path in RPATH causing reproducibility problems (as
path for those external library will depend on the build system path)
George Moussalem [Tue, 14 Oct 2025 09:36:17 +0000 (13:36 +0400)]
qualcommax: ipq50xx: fix XO board clock rate for Yuncore AX850
Commit 468975a985ab changed the XO board clock definition from a fixed
clock to a fixed rate clock in the dtsi.
As such, boards must use clock dividers and multipliers to calculate
the clock rate based on the referenced parent clock.
Fixes: 5d2994a73e20 ("qualcommax: ipq50xx: Add support for Yuncore AX850") Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://github.com/openwrt/openwrt/pull/20405 Signed-off-by: Robert Marko <robimarko@gmail.com>
Add pending patch to address PCI sysfs creation entry race observed on
ipq806x. This is to handle a kernel warning on creating the same sysfs
entry multiple times.
Shiji Yang [Wed, 18 Jun 2025 11:50:39 +0000 (19:50 +0800)]
ipq806x: migrate wifi configuration device paths for 6.12 kernel
The device tree PCIe host node names have been changed in the new
6.12 kernel[1]. Hence we have to update the wifi device path to
make sure it can work properly.
This script is based on:
target/linux/qualcommax/ipq807x/base-files/etc/hotplug.d/ieee80211/05-wifi-migrate
These devices' reg cell[0] is equal to 0x10000, hence the correct
node unitname should be "0,0". This patch fixes the following dtc
warnings on 6.12 kernel:
qcom-ipq8065-tr4400-v2.dts:482.11-487.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-tr4400-v2.dts:499.11-504.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-rt4230w-rev6.dts:584.11-589.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-rt4230w-rev6.dts:601.11-606.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-g10.dts:291.11-295.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-g10.dts:303.11-307.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wxr-2533dhp.dts:525.11-530.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wxr-2533dhp.dts:539.11-544.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ecw5410.dts:235.11-239.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ecw5410.dts:251.11-255.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ap3935.dts:261.11-264.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ap3935.dts:275.11-278.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-fap-421e.dts:347.11-352.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-fap-421e.dts:362.11-367.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-cryptid-common.dtsi:78.18-81.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-cryptid-common.dtsi:89.18-92.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-cryptid-common.dtsi:100.18-103.4: Warning (pci_device_reg): /soc/pcie@1b900000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wg2600hp.dts:464.11-469.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wg2600hp.dts:478.11-483.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8062-wg2600hp3.dts:404.11-410.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8062-wg2600hp3.dts:419.11-426.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-d7800.dts:210.11-215.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-d7800.dts:227.11-232.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-r7500v2.dts:213.11-218.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-r7500v2.dts:230.11-235.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-nighthawk.dtsi:546.18-549.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-nighthawk.dtsi:559.18-562.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-ac400i.dts:202.11-206.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-ac400i.dts:218.11-222.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-ad7200-c2600.dtsi:319.11-324.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-ad7200-c2600.dtsi:333.11-338.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-vr2600v.dts:347.11-352.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-vr2600v.dts:361.11-366.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
Shiji Yang [Sun, 1 Jun 2025 04:56:09 +0000 (12:56 +0800)]
ipq806x: dts: rework PCIe nodes for Chromium OnHub
- Reuse the bridges node defined on "qcom-ipq8064.dtsi".
- Rename PCIe device nodes to unified "wifi@0,0".
- Add the missing "qcom,ath10k" compatibles.
- Remove unseless property "interrupt-controller". There are no
consumers use these PCIe devices as interrupt controllers.
- Change bus number from 0 to 1, just like other ipq806x devices.
The valid PCIe bus range on this platform is 1 - 255.
Shiji Yang [Sat, 31 May 2025 16:41:31 +0000 (00:41 +0800)]
ipq806x: fix build errors on 6.12 kernel
- Replace "strlcpy()" with "strscpy()".
- Convert platform driver .remove() to .remove_new().
This patch fixes the following compile errors:
drivers/of/fdt.c:1064:17: error: implicit declaration of function 'strlcpy'; did you mean 'strncpy'? [-Wimplicit-function-declaration]
1064 | strlcpy(cmdline, p, min((int)l, COMMAND_LINE_SIZE));
| ^~~~~~~
| strncpy
drivers/devfreq/krait-cache-devfreq.c:171:27: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Wincompatible-pointer-types]
171 | .remove = krait_cache_remove,
| ^~~~~~~~~~~~~~~~~~
drivers/devfreq/ipq806x-fab-devfreq.c:145:27: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Wincompatible-pointer-types]
145 | .remove = ipq806x_fab_remove,
| ^~~~~~~~~~~~~~~~~~
Shiji Yang [Sat, 31 May 2025 15:09:58 +0000 (23:09 +0800)]
ipq806x: refresh kernel symbol configs
This is a preparation for introducing the 6.12 kernel support.
All configs are automatically refreshed. In theory, they will
generate the same .config files in the kernel build directory
as before.
sdk: set package as the root directory for base feed
To produce consistent source entry for package compiled from non-SDK and
SDK build, set the "--root=package" flag for the base feed.
This will set the root directory for the base feed to the OpenWrt
core repository "package" directory.
This fix the reproducible problem of package build from SDK that have
the source entry set to "feeds/base/package/..." for every package
coming from the base feed.
scripts/feeds: implement support for --root option
Some feeds might need to set the source for their packages in a
different directory than the cloned one.
For example a feed "test" might be an entire repository and the relevant
packages that wants to be included are in the directory "foo".
In such scenario the source info in the package will result in something
like "feeds/test/foo/network/dnsmasq" instead of an expected entry like
"feeds/test/network/dnsmasq".
To give a more real-world example, this problem is currently present
with OpenWrt SDK where the SDK clone the entire OpenWrt core repository
as "base" feeds but the package are present in the "package" directory.
This cause every package to have the source entry set to
"feeds/base/package/..." conflicting with what a non-SDK build do with
setting the source entry to "feeds/base/..."
To solve this, actually enable support for "flags" in the feeds script
and implement a new option "--root" to set the root directory for the
defined feed to an inner directory.
The "flags" in the feed script are no more than argument option that can
be defined right after the "src-" type in the feed.conf file.
This feature was partially implemented but never actually used for
anything keeping it dormant with all the core piece there (the pattern
regex always accounted for these extra option but they were never passed
to the relevant functions)
An example of the "--root" flag is the following:
src-git --root=package base https://git.openwrt.org/openwrt/openwrt.git;main
With "--root" defined, the script will append "_root" to the feed name
clone directory and will create a symbolic link named with the feed name
and pointing to the feed name clone directory + the value in root.
From the previous example:
feed name: base -> clone directory: base_root
symbolic link: base -> base_root/package
The script internally reference the "_root" directory for every update
operation and OpenWrt build system transparently use the feed name
directory to reference feed packages producing consistent source info
entry.
Zhi-Jun You [Wed, 8 Oct 2025 06:55:06 +0000 (14:55 +0800)]
wifi-scripts: ucode: fix airtime_mode with hostapd-mini
Currently wifi-scripts ucode appends airtime_mode to hostapd config file
unconditionally.
However this breaks bringing up interface with hostapd-mini
because the mini variant doesn't support airtime policy.
Fix this by changing the script to append airtime_mode only when
airtime_mode is set to greater than zero value in /etc/config/wireless.
Fixes: #20136 Fixes: #20314 Signed-off-by: Zhi-Jun You <hujy652@protonmail.com>
Lorenz Brun [Fri, 10 Oct 2025 21:11:38 +0000 (23:11 +0200)]
realtek: fix SFP ports on RTL83xx
Right now the phylink capability function enables 2.5G and 10G modes on
Maple and Cypress, which they mostly (other than two SERDES on Cypress)
don't support. This causes these modes to be selected and break the link
as they are not supported by hardware.
I looked into doing this properly, but it cannot just be done based on
SoC, but needs to take the whole topology into account as a given MAC
might have very different capabilities depending on what SERDES are
assigned to it. So for now just use 1G and QSGMII for RTL83xx and 10G
for RTL93xx. This mostly works, except it will downgrade some 10G links
on RTL839x, but since there are also 1G SFPs on these this cannot be
solved without fully accounting for the global MAC and SERDES
configuration.
So this makes all of the 1G SFP slots work again, while keeping most of
the 10G SFP+ slots working at 10G with minimal changes.
Sven Eckelmann [Mon, 29 Sep 2025 16:30:12 +0000 (18:30 +0200)]
realtek: Skip auto-MAC assignment for devices with MACs in DT
If the devicetree contains the appropriate nodes to configure the MAC
addresses for each physical DSA port, then these MAC addresses must be used
in OpenWrt and not some automatically generated ones. Otherwise the device
often ends up with addresses which are locally administered and not
matching any expected port-to-MAC scheme.
Devices which only get the MAC address for eth0 must still auto-generate
these MAC addresses until the devicetree was updated to also include the
correct ones.
Sven Eckelmann [Sun, 5 Oct 2025 07:00:08 +0000 (09:00 +0200)]
realtek: Avoid empty lan mac in initial network setup
If the lan_mac cannot be found, it is still used (as empty string) in
various operations. This is not valid and other 02_network scripts checking
for a non-empty string before using it. This should also be adopted for the
realtek 02_network.
Sven Eckelmann [Sun, 5 Oct 2025 06:55:49 +0000 (08:55 +0200)]
realtek: Split initial network setup in functions
Having everything in a big script without any structure makes it
unnecessary hard to get an overview or modify it without triggering
unexpected side effects.
Sven Eckelmann [Fri, 10 Oct 2025 09:49:56 +0000 (11:49 +0200)]
realtek: dsa: Adjust prefix for bridge member functions
The preferred prefix for the Realtek DSA driver code is "rtldsa" and no
longer "rtl83xx". This makes sure that the different drivers have
non-conflicting prefixes and because of this non-conflicting function
names.
Suggested-by: Felix Baumann <felix.bau@gmx.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20360 Signed-off-by: Robert Marko <robimarko@gmail.com>
Sven Eckelmann [Fri, 10 Oct 2025 09:49:56 +0000 (11:49 +0200)]
realtek: dsa: Fix name of RTL93xx switch_ops
The RTL930x and the RTL931x SoC families share the same struct
dsa_switch_ops. This should be represented in the name of the object.
Suggested-by: Felix Baumann <felix.bau@gmx.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20360 Signed-off-by: Robert Marko <robimarko@gmail.com>
Sven Eckelmann [Thu, 9 Oct 2025 12:59:16 +0000 (14:59 +0200)]
realtek: dsa: Add support for port isolation
If two ports are in isolation mode then these ports are not supposed to be
able to communicate between each other. This can be achieved in the realtek
switch by removing the other isolated port(s) from the port list of an
isolated port.
Sven Eckelmann [Thu, 9 Oct 2025 13:01:06 +0000 (15:01 +0200)]
realtek: dsa: Drop unused traffic_get helpers
The realtek driver is now in full control of the port matrix. It doesn't
need to rely on the current state of the HW to adjust it. The new port
matrix is calculated automatically using rtldsa_update_port_member() and
then written to the registers/tables.
Sven Eckelmann [Thu, 9 Oct 2025 14:28:47 +0000 (16:28 +0200)]
realtek: dsa: Simplify port member handling
It is not necessary to read the back the current port members for a
specific port for enabling/disabling a port. All these members which are
expected to be in the HW port matrix of an active port are already stored
in the port specific member "pm".
And when a port is disabled, the port must no longer forwarding traffic to
any other port. Just writing 0 to the members is therefore good enough and
no read-back of the old HW state is necessary.
Sven Eckelmann [Thu, 9 Oct 2025 12:56:39 +0000 (14:56 +0200)]
realtek: dsa: Share port member configuration code
The leave and join callbacks for DSA were using their own implementation of
the port member handling code. This makes the implementation of additional
functionality based on the port member matrix complicated because it needs
to be implemented in both places and also in the new code path for the
introduced feature.
By sharing this code, it is much easier to guarantee that all code paths
behave the same. This approach is already implemented by other DSA drivers
like qca8k, mt7530 or ksz.
Sven Eckelmann [Thu, 9 Oct 2025 11:56:19 +0000 (13:56 +0200)]
realtek: Switch booleans in rtl838x_port to single bits
In upstream kernel, it is not well received to use a lot of simple booleans
in structs. It is preferred to use 1-bit bitfields [1] and consolidate the
booleans together.
Robert Marko [Sun, 12 Oct 2025 09:59:34 +0000 (11:59 +0200)]
ipq-wifi: add Yuncore AX850
It seems that adding Yuncore AX850 was missed during the board support,
and this breaks buildbots for ipq50xx with:
ERROR: unable to select packages:
ipq-wifi-yuncore_ax850 (no such package):
required by: world[ipq-wifi-yuncore_ax850]
make[4]: *** [/builder/shared-workdir/build/include/image.mk:396: target-dir-90b51871] Error 1
make[4]: *** Waiting for unfinished jobs....
So, add the required meta package.
Fixes: 5d2994a73e20 ("qualcommax: ipq50xx: Add support for Yuncore AX850") Signed-off-by: Robert Marko <robimarko@gmail.com>
Daniel Golle [Wed, 8 Oct 2025 17:57:16 +0000 (18:57 +0100)]
uboot-mediatek: update to U-Boot v2025.10
The most relevant change is the removal of the empty board_init()
functions by u-boot/u-boot@70a4d1fa1dd, which makes many patches not
apply anymore and also requires most board defconfigs to be updated
by adding "# CONFIG_BOARD_INIT is not set" to them.
Also some config symbols have been renamed and downstream boards
had to be adapted accordingly:
u-boot/u-boot@0fd9a3480a0 ("env: Rename OVERWRITE_ETHADDR_ONCE to
ENV_OVERWRITE_ETHADDR_ONCE")
u-boot/u-boot@5fb88fa725d ("env: Rename SYS_REDUNDAND_ENVIRONMENT to
ENV_REDUNDANT")
u-boot/u-boot@123682c7651 ("env: Rename SYS_RELOC_GD_ENV_ADDR to
ENV_RELOC_GD_ENV_ADDR")
u-boot/u-boot@0f44d5549ed ("env: Rename SYS_MMC_ENV_DEV to
ENV_MMC_DEVICE_INDEX")
u-boot/u-boot@31617b880ab ("env: Rename SYS_MMC_ENV_PART to
ENV_MMC_EMMC_HW_PARTITION")
u-boot/u-boot@ffc4914703a ("env: Rename ENV_MMC_PARTITION to
ENV_MMC_SW_PARTITION")
u-boot/u-boot@fb5235239aa ("env: Rename DEFAULT_ENV_FILE to
ENV_DEFAULT_ENV_TEXT_FILE")
(also renamed USE_DEFAULT_ENV_FILE to USE_ENV_DEFAULT_ENV_TEXT_FILE)
Jonas Jelonek [Wed, 8 Oct 2025 08:19:25 +0000 (08:19 +0000)]
realtek: pcs: add more SerDes access helpers
Add more SerDes access helpers for the upcoming code import from PHY
driver. There, similar helpers are used to read and write full SerDes
registers or only parts of them (aka bitfields).
The helpers are expected to replace the following used in PHY SerDes
code:
- rtl9300_sds_field_r
- rtl9300_sds_field_w
- rtsds_931x_read
- rtsds_931x_read_field
- rtsds_931x_write
- rtsds_931x_write_field
Mark the helpers as unused for now to make the compiler happy. This will
be removed as soon as they are used.
There are two spi drivers for en7523/an7581/an7583:
* en7581-snand (spi-airoha-snfi.c)
* en7523-spi (spi-en7523.c)
The first one supports DMA, but until recently it has several nasty
issues. The second do things properly but does not support DMA.
Recently the first driver was greatly improved, so there is no sence
keep both drivers anymore.
This patch removes en7523-spi driver and use DMA capable driver instead.
Unfortunately there is a nasty en7523 specific issue.
We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of it's BOOT pins. This will lead
to booting in RESERVED boot mode. It was found that some flashes operates
incorrectly in RESERVED mode if DMA used.
This patch also adds a hack that turns off DMA and prints big fat warning
if booting in reserved mode was detected. This slow down flash operations
but does not kill your data.
boot: airoha: snfi: remove dirty hack required for both u-boot & linux
This patch removes dirty hack used to:
* operate with flash
* pass flash page settings to linux driver via SNFI registers
It has been proven that spinand flash page size is actually unnecessary.
We can get all required data from dirmap requests. Thus this patch
series drops the hack and do things properly.
After this fix (and corresponding linux fix) the hack is not needed
anymore.
This patch series removes dirty hack that reads flash page settings from
SNFI registers during driver startup.
Before these patches the airoha spi snfi driver needs to know spinand
flash page size. The driver can't get it from spinand subsystem, so the
following approach was implemented:
* bootloader know the flash page size (and some other parameters)
* to operate properly the bootloader writes flash page size (and some
other parameters) to SNFI registers
* bootloader starts linux
* after linux start SNFI registers keeps the values stored by bootloader
* linux snfi driver reads flash parameters from SNFI registers.
This works, but we can do better. It has been proven that flash page size
is actually unnecessary. We can get all required data from dirmap requests.
This patch series drops the hack and do things properly.
This patch series greatly improve airoha snfi driver and fix a
number of serious bugs.
Fixed bugs:
* Fix reading/writing of flashes with more than one plane per lun
* Fill the buffer with 0xff before writing
* Fix reading of flashes supporting continuous reading mode
* Fix error paths
Improvements:
* Add support of dual/quad wires spi modes in exec_op(). This also
fix flash reading/writing if dirmap can't be created.
* Support of dualio/quadio flash reading commands
Continuous reading mode is broken for some spi controllers. There are two
possible bug scenarios:
1) "continuous mode" flash and spi controller without dirmap support,
but with restriction on transfer length in adjust_op_size()
2) "continuous mode" flash and spi controller with dirmap support for a
single flash page
In the first case, any read that exceeds the limit specified in adjust_op_size()
will result in an EIO error. The limit may even be less than a size of a single
flash page. In this case, any read will result in an error.
In the second case, any read larger than flash page size will result in an EIO
error or spinand driver spoofing (because the spi controller driver returns
more bytes than were actually read).
This patch series tries to fix continuous reading (spinand driver side).
Unfortunately these fixes can't resolve "spinand driver spoofing" case.
Spi controller drivers might need fixes as well.
Petr Štetiar [Mon, 6 Oct 2025 19:41:03 +0000 (19:41 +0000)]
tools: xxhash: fix PKG_MIRROR_HASH
Current PKG_MIRROR_HASH is wrong, but it went unnoticed, because the
tarball is being fetched from @OPENWRT project mirrors. After 042996b46bd revert the correct hash can be reproduced with:
make tools/xxhash/{download,check} FIXUP=1 DL_DIR=/tmp PKG_MIRROR_HASH=''
qualcommax: ipq50xx: Add support for Yuncore AX850
Specifications:
SOC: Qualcomm IPQ5018 (64-bit dual-core ARM Cortex-A53 @ 1.0Ghz)
Flash: SPI NOR 8MB (Winbond W25Q64DW) + NAND 128MB (Winbond W25N01GWZEIG)
Memory: 512MB DDR3L
Standard: 802.11ax/ac/b/g/n
2.4G Frequency: 2.4GHz - 2.484GHz
2.4G Wi-Fi standard: 802.11b/g/n/ax
5G Frequency: 5.150GHz~5.850GHz
5G Wi-Fi Standard: 802.11 a/n/ac/ax
Buttons: 1 * Reset button, press 10 seconds to revert to default setting
2.4G Antenna: 2*2.4GHz/5.8GHz dual band antenna: 4dBi
5G Antenna: 2*5.8G antenna: 4dBi
Data Rate: 2.4GHz: 574Mbps, 5GHz:4800Mbps
Power: PoE 802.3at，DC2.0 12V/2A
Max Power Consumption: < 22W
LED Light: WAN, LAN, tricolor LED(sys-red, 2.4G-green, 5.8G-blue)
BACKUP YOUR STOCK FIRMWARE:
- Put openwrt-*-initramfs-uImage.itb to your
TFTP server and rename it to initramfs.bin
- Enable serial console and enter to u-boot cli
and exec these commands:
```
tftpboot <your_tftp_server_ip>:initramfs.bin
bootm
```
- Once boot completed and you get the openwrt shell
execute below commands:
```
device=ax850
mkdir -p /tmp/fw_backup; cd /tmp/fw_backup
rootfs=$(cat /proc/mtd | grep \"rootfs\" | cut -d: -f1)
rootfs_1=$(cat /proc/mtd | grep \"rootfs_1\" | cut -d: -f1)
dd if=/dev/${rootfs} of=rootfs_${rootfs} bs=1M
dd if=/dev/${rootfs_1} of=rootfs_1_${rootfs_1} bs=1M
cp /sys/firmware/fdt fdt.dtb
md5sum * > md5sum
tar -cvzf /tmp/${device}.tar.gz .
sum=$(md5sum /tmp/${device}.tar.gz | cut -d' ' -f1)
mv /tmp/${device}.tar.gz /tmp/${device}_${sum}.tar.gz
echo "stock fw backup saved to: /tmp/${device}_${sum}.tar.gz"
```
- Upload/save your backup to a safe place.
STOCK FIRMWARE RECOVERY:
- Boot initramfs image
- Upload your backed-up stock fw tarball to the device
using scp or download it from the device using wget.
- Enter device ssh cli or tty and exec:
```
cd /tmp && wget <your_web_server_ip>/${stock_fw_backup}.tar.gz`
tar -xpzf ${stock_fw_backup}.tar.gz
rootfs=$(cat /proc/mtd | grep \"rootfs\" | cut -d: -f1)
rootfs_1=$(cat /proc/mtd | grep \"rootfs_1\" | cut -d: -f1)
ubiformat /dev/${rootfs} -y -f /tmp/rootfs_${rootfs}
ubiformat /dev/${rootfs_1} -y -f /tmp/rootfs_1_${rootfs_1}
reboot
```
INSTALLATION:
1. initramfs method
- Put openwrt-*-initramfs-uImage.itb to your
TFTP server and rename it to initramfs.bin
- Enable serial console and enter to u-boot cli
and exec these commands:
```
tftpboot <your_tftp_server_ip>:initramfs.bin
bootm
```
- Once boot completed and you get the openwrt shell
execute below commands:
```
cd /tmp && wget <your_web_server_ip>/factory.ubi`
export rootfs=$(cat /proc/mtd | grep rootfs | cut -d: -f1)
export rootfs_1=$(cat /proc/mtd | grep rootfs_1 | cut -d: -f1)
ubiformat /dev/${rootfs} -y -f factory.ubi
ubiformat /dev/${rootfs_1} -y -f factory.ubi
reboot
```
2. u-boot factory.ubi image method
- Put factory.ubi to your TFTP server and
enter u-boot cli and exec these commands:
```
tftpboot <your_tftp_server_ip>:factory.ubi
#After downloading is finished:
flash rootfs
flash rootfs_1
reset
```
Paul Spooren [Wed, 8 Oct 2025 09:42:51 +0000 (11:42 +0200)]
package: do not sign individual APK packages
APK, unlike OPKG, can sign individual packages and not just indexes.
Since OpenWrt uses a distributed build infrastructure and only the build
master owns the private keys, signing of individual buildworkers doesn't
work. Right now, each buildworker creates a temporary build key to sign
packages, then transmits the package index to the buildmaster for a
signature.
As a result, all individual packages contain a nonsensical signature,
making them harder to reproduce. This commit removes the individual
package signing.
Since APK requires signatures per default, explicitly allow installation
of unsigned packages during the build process.
The config option here is for historical reasons misleading,
SIGNED_PACKAGES refers to the package index, not the individual
packages.
Paul Spooren [Sat, 4 Oct 2025 18:53:51 +0000 (20:53 +0200)]
packages: bump APK to improve reproducibility
The package bump to version rc6 incorporates two recent changes, first, the
stored `mtime` honors SOURCE_DATE_EPOCH, making a prior "touch" obsolete.
Secondly the order of files added to created packages is now sorted, improving
reproducibility, too.
Rosen Penev [Tue, 7 Oct 2025 00:39:54 +0000 (17:39 -0700)]
ipq806x: fix wifi node
In the conversion to nvmem of eax500 and unifi-ac-hd, the address was
set to 0 as is the case with most platforms, but not this one.
The wifi node also needs to be wrapped in a bridge node.
Matches every other device in ipq806x.
Fixes: 148f82ad4525 ("ipq806x: use nvmem for wifi mac") Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20325 Signed-off-by: Robert Marko <robimarko@gmail.com>
Changelog: a52bda0 (HEAD, tag: v6.17) bump version to 6.17 c5bfa2a iw: add support to print link level information in station dump efaf786 iw: Add support to set per-radio RTS threshold in multi-radio wiphy 009ad3b update nl80211.h aef3798 iw: don't set stupid socket buffer size 8d52fb4 iw: scan: Add partial Multi-Link element printing cfc0695 iw: print HE mcs correctly when mcs_len 8e4808f iw: Add command to enable/disable EPCS 85b79b3 update nl80211.h 612f9f5 iw: Prevent segfault in ftm get stats 1558e60 iw: print NO-EHT flags for reg get command 59660a3 iw: fix EHT capabilities on Big Endian platforms 8ea80d3 iw: scan: Add printing of EHT Operation Element 7c0511b util: rename hz to Hz vol 2 c2a12a5 util: rename hz to Hz 0cc98ae iw: scan: Decode additional WPA3 group ciphers f04e5c5 iw: scan: Decode additional WPA3 AKM suite types 41a07a8 iw: fix HE operation on Big Endian platforms c41971e iw: fix HE capabilities on Big Endian platforms a6ad3f1 iw: scan: add eht capability parsing 4c85991 iw: util: update and clean up eht capa printing a0a7dde iw: scan: replace passed ie buffer with ie context 7bc2a84 iw: print tx power per link for MLD 478ddd4 iw: add output for wiphy interface combinations 93e2309 update nl80211.h 966c590 iw: scan: add enum for element IDs 422419e scan: Add printing of HE Operation Element d088c8a update nl80211.h 73231dd iw: fix formats under MIPS64/PPC 8609336 iw: remove sizer section and related code c8b9e77 util: clarify comment about 'parsed' pointer b29da20 iw: add puncturing support cce9897 iw: refactor frequency help
Switch: 1 WAN, 4 LAN (Gigabit)
Gigabit RJ45 PoE Ports on 2~5
Max Power on a Single PoE Ports 30W
PoE Ports : The PoE ports comply with IEEE 802.3at/af standards.
Ports: 1 USB-A 3.0 Ports
LED:
System
PoE Max Status
Link/ACT/PoE Status of Each PoE Port
Physical Buttons:
Reset Button
Power Input:
DC Jack
Power Methods:
DC: 54V 1.11A
802.3at/af PoE
Passive PoE: 24/48V
Max Power Consumption (W):
Total: 60W
PoE: 55W
PoE (when USB Device is plugged in): 50W
No PoE: 5W
Installation:
To install OpenWRT, you need the intermediate firmware from Cudy. (U-boot is locked). After installing the intermediate firmware, you can install OpenWRT via sysupgrade.
Recovery:
TFTP available.
1. Place the recovery.bin in the serving directory of your TFTP server.
2. Set your IP to 192.168.1.88/24.
3. Press the “Reset” button of Cudy router and hold it. Before the Cudy router is powered on and before TFTP start to download the firmware, don't release the “Reset” button.
4. Power on the Cudy router.
5. You can release the reset button only when TFTP starts downloading firmware.
6. When the SYSTEM LED turns solid green, the upgrade is complete.
Serial:
1. Serial connection parameters: 115200 / 8N1
2. Serial connection voltage: 3.3V
PoE is not supported at the time of PR. The IP804R chip is not yet supported by OpenWRT.
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.
projects / thirdparty / openwrt.git / log
