EDMA maps RX fill buffers with DMA_TO_DEVICE but unmaps them with DMA_FROM_DEVICE. Use DMA_FROM_DEVICE consistently, release mappings left on RX rings during teardown, and flush ring-disable writes before descriptor cleanup.
Signed-off-by: krava <igor.kravchenko05@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24218
Signed-off-by: Robert Marko <robimarko@gmail.com>
Kernel modules from the packages feed differ between builds on 6.18,
e.g. kmod-v4l2loopback, kmod-jool-netfilter, kmod-pf-ring and
kmod-usb-serial-dmx_usb_module:
-/builder/shared-workdir/build/build_dir/.../linux-6.18.52/include/linux/ucopysize.h
+/tmp/rebuilderd-openwrt.Xebb8P/src/build_dir/.../linux-6.18.52/include/linux/ucopysize.h
These packages call make -C $(LINUX_DIR) M=... without
KERNEL_MAKE_FLAGS, so they get none of the OpenWrt prefix maps. With
6.12 that did not matter, since srctree stayed "." and the kernel
headers were included by a relative path. Since 6.13 srctree holds the
absolute path of the kernel tree for external modules, while kbuild
only maps srcroot, the module directory.
Add a pending patch that maps the kernel tree for external modules too.
It is added before the map of srcroot and before KCFLAGS, and GCC uses
the last matching map, so modules built through KERNEL_MAKE_FLAGS keep
their current output.
Link: https://github.com/openwrt/openwrt/pull/25356
Signed-off-by: Paul Spooren <mail@aparcar.org>
Add upstream patch marking the 'gpll0_main' clock as critical on
IPQ5018 (gcc-ipq5018 driver), backported from upstream commit
33f9cb56cc28 ("clk: qcom: gcc-ipq5018: mark 'gpll0_main' clock as
critical").
During boot the APCS core clock feeding the CPUs can use GPLL0 as
its parent. On some boards (e.g. TP-Link Archer AX55 v1 using the
in-tree DTS since v6.18), the ipq-cmn-pll driver's pm_runtime_put()
call in its probe function asynchronously disables
'gcc_cmn_blk_ahb_clk', which in turn disables 'gpll0_main' as well,
hanging the system until the hardware watchdog restarts the board.
Marking gpll0_main as CLK_IS_CRITICAL fixes the underlying issue
directly in the GCC driver, making the previous workaround in
0191-clk-qcom-ipq-cmn-pll-keep-the-CMN-block-bus-clocks-enabled.patch
unnecessary. Drop that patch, as it addressed the same symptom by
keeping the CMN PLL block's bus clocks permanently enabled via a
devres-managed runtime PM reference instead of fixing the actual
critical clock.
Refresh the context in
0721-clk-gcc-ipq5018-remove-the-unsupported-clk-combinati.patch and
0723-clk-qcom-gcc-ipq5018-fix-uniphy-soft-reset-issue.patch, whose
hunks shifted by 9 lines due to the newly inserted patch.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/25386
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add thermal zone for the Wi-Fi chip using the same trip levels and cooling maps as the CPU. The
kernel thermal governor will act on whichever temperature is the highest. There is only a single
heatsink and fan to cover both the SoC and Wi-Fi chip, so tracking both CPU and Wi-Fi temperatures
ensures that neither chip will overheat from low fan speed.
The trip levels are spaced 1.25C apart with double that (2.5C) for the hysteresis, with 5C
hysteresis for the lowest trip level (65C) because it is preferable for the fan to run for longer at
low speed than to stop and start repeatedly.
In the absence of continuous proportional feedback control, tightly grouping the trip levels and
cooling maps minimises the frequency and amplitude of temperature and fan speed oscillations.
The cooling states are set to increments of 5 (out of 255) from 12% to 61% and then increments of 10
from 61% to 100% with kick start speed at 15%. In comparison, the default in mt7981b.dtsi starts at
50% fan speed and leads to constant on/off cycles within a short period of time (every ~2 minutes).
Signed-off-by: Ryan Leung <untilscour@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/22936
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Add a common dtsi with macros for thermal trip levels and cooling maps that can be included in other
device trees.
The trip levels are spaced 1.25C apart with double that (2.5C) for the hysteresis, with 5C
hysteresis for the lowest trip level (65C) because it is preferable for the fan to run for longer at
low speed than to stop and start repeatedly.
In the absence of continuous proportional feedback control, tightly grouping the trip levels and
cooling maps minimises the frequency and amplitude of temperature and fan speed oscillations.
There are 36 trip levels and the cooling maps start from cooling state 1 (0-index) so cooling-levels
must have at least 37 elements. If greater increments between trip levels/cooling-levels are desired
or needed the cooling-levels can be padded with repeated values.
The THERMAL_TRIPS_COMMON and THERMAL_COOLING_MAPS_COMMON macros take one argument as the prefix to
the trip levels node labels. The prefix must be the same within a thermal zone.
Signed-off-by: Ryan Leung <untilscour@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/22936
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The post_config hooks finalize a powered-up SerDes and may calibrate
its receiver. Configure autonegotiation and the BMCR speed first so
finalization runs with the requested PCS state.
This is required for 100BASE-X on RTL930x. Calibrating with the default
1000 Mbps BMCR setting produced symbol errors until BMCR was switched
to 100 Mbps.
Preserve the changed result from set_autoneg across the post_config
callback so pcs_config keeps its existing return semantics.
Tested runtime mode transitions and cold boot on RTL838x, RTL930x and
RTL931x. Links came up and passed traffic in all tested modes with no
regressions observed.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Phylink can only request interface modes advertised by the DSA port.
Expose 100BASE-X when the SoC MAC capabilities include MAC_100 so that
ports backed by a capable PCS can select the newly supported mode.
Keep this independent of MAC_1000FD because the 100 Mbps and 1 Gbps MAC
capabilities are reported separately.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The generic, RTL930x, and RTL931x setup paths now handle 100BASE-X.
Add the RTL93xx hardware mode value and mapping, select the 1G analog
CMU page, and advertise the mode from RTL93xx SerDes instances.
This makes the prepared support available to PCS consumers.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL931x handles 100BASE-X through its 1G fiber digital path, but the
FIB1G link detector must remain disabled at 100 Mbps.
Add 100BASE-X to the fiber setup and symbol-error handling paths. Share
the 1000BASE-X setup while selecting the appropriate FIB1G link-enable
value for each mode. Keep the mode unavailable until the shared
RTL93xx support is enabled.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL930x uses the IP-driven mode setup for Base-X links and the 1G
analog configuration for SGMII and 1000BASE-X.
Route 100BASE-X through the same IP-driven and 1G analog setup paths.
Keep the mode unavailable until all RTL93xx support is in place.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
100BASE-X uses a direct SerDes attachment and the same 1G-class PLL
configuration as 1000BASE-X on the supported hardware.
Teach the common attachment and PLL selectors about the mode. This is
preparation only; no additional SerDes advertises support yet.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
100BASE-X does not use in-band autonegotiation and requires BMCR to
select 100 Mbps. Extend the generic autonegotiation helper to always
disable AN for this mode and then program BMCR_SPEED100.
This ordering is required on RTL93xx, which ignores speed-selection
updates while BMCR_ANENABLE is set.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL93xx ignores BMCR speed-selection updates while BMCR_ANENABLE is
set. The RTL931x mode setup therefore cannot reliably select 1000 Mbps
for forced 1000BASE-X before generic autonegotiation handling runs.
Move forced 1000BASE-X speed selection into the generic helper and
perform it after disabling autonegotiation. This also removes the
ineffective RTL931x-specific write.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Some of these GPIOs are shared between interfaces. Use a regulator to be
able to share them. Enable Kconfig options so that they work.
Backport one patch upstream so the patch applies. Rename another to
clarify it's in 7.2.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25296
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Use the realtek-pse-mcu kernel driver instead of realtek-poe. The MCU
is a Nuvoton M05xx using the gen1 protocol over UART at 19200 baud.
realtek-poe turns off the MCU's port mapping at startup, which reversed
the PoE port numbering and the front-panel PoE LEDs. The kernel driver
leaves the mapping alone, so both now match the front panel. The MCU
keeps this state across a warm reboot, so a unit sysupgraded from a
realtek-poe image stays reversed until its first power cycle.
Tested on a GS110TPP v1: the driver probes the MCU and its BCM59121,
and a PoE device on lan1 is powered.
Signed-off-by: Kel Modderman <kelvmod@gmail.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/25298
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The atm feature has no entry in target_config_features(), so it selects
no symbol, and nothing else reads the feature list beyond the broken and
source-only filters. It has never gated anything. The kmod-ltq-atm-*
packages are unrelated name matches, pulled in through DEFAULT_PACKAGES.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This appears to reduce the CPU temp by at least a few degrees C on
Linksys EA4500, which is notorious for its thermal challenges.
Tested only on EA4500 by running without issues for a few weeks under a
light workload.
Signed-off-by: Will Mortensen <willmo@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25276
Signed-off-by: Robert Marko <robimarko@gmail.com>
Armada 38x uses Cortex-A9 r4p1, but the current kernel config selects
erratum 720789, which was fixed in r2p0, and omits some errata that
still affect r4p1. Fix the config.
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25297
Signed-off-by: Robert Marko <robimarko@gmail.com>
The WR3000S has a GPIO LED behind its front-panel "Internet" lamp
(white:wan-online, &pio 11), but no board.d entry, so no trigger is ever
set and the lamp stays dark. Give it the same netdev trigger the WR3000H
and WR3000P already use for their white:wan-online LED: follow the link
state of the wan port. As on those boards, "link" means the wan port has
carrier, not that connectivity works.
The panel's WAN and LAN1-4 lamps are not GPIO LEDs and are not registered
as Linux LEDs at all; they light on link in hardware, so board.d cannot
address them and they are untouched here. The -ubootmod variant includes
the same mt7981b-cudy-wr3000s-v1.dtsi, and so the identical LED, and is
listed alongside.
Tested on a WR3000S v1 (OEM layout), on an image built from main at
6727587d24 plus this commit: after a config-wipe sysupgrade the board.d
entry is applied automatically (board.json -> system.led_internet), the
lamp lights while the WAN port has link, and it goes dark when it loses
link. Only the OEM-layout variant was flashed.
Signed-off-by: Ivan Rainbolt <ivan@github.ivanthegeek.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/25335
Signed-off-by: Robert Marko <robimarko@gmail.com>
The driver doesn't really care about the address in dts, but might as
well fix it anyway.
0 is just wrong.
1f is the address for the builtin FE switch, not the external gigabit
switch.
10 is the driver default.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25370
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill") the
fork path snapshots kill_seq in cgroup_css_set_fork() before the
CLONE_INTO_CGROUP target has been resolved, so it always records the
forking task's own cgroup while cgroup_post_fork() reads the target's
and compares the two. Once cgroup.kill has been written to a cgroup,
every child later cloned out of it into another cgroup is SIGKILLed
before it runs a single instruction, for as long as that cgroup exists.
This breaks re-creating an OCI container under procd, whose service
supervisor kills the instance cgroup on exit and leaves it in place: the
container init ujail clones with CLONE_INTO_CGROUP is killed at birth and
the create fails with no diagnostic. The fix is in mainline from v7.3-rc2
and carries Cc: stable, so it is expected to reach 6.18.y with a future
stable release, at which point this patch can be dropped.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The Charter Spectrum SBE1V1K fails to boot with the default kernel
load address. The device gets stuck early in the boot process due to
the stock bootloader encountering memory overlap or alignment issues
with the default `0x41000000` address.
Changing `KERNEL_LOADADDR` to `0x42200000` resolves the boot failure
and ensures stable operation.
Why `0x42200000` instead of `0x42000000`?
While testing showed that `0x42000000` also boots successfully,
`0x42200000` was explicitly chosen for two primary safety reasons:
1. Avoid U-Boot `loadaddr` Overlap: On many QCA/IPQ platforms,
`0x42000000` is commonly used as the default `loadaddr` to fetch
the FIT image into memory. Setting the extraction destination
(`KERNEL_LOADADDR`) to the exact same base address risks in-place
decompression overlaps.
2. Reserved Memory Buffer: The memory range below `0x42000000`
is heavily utilized by TZ, SMEM, and vendor-specific reserved
memory in newer Askey firmwares. Adding a 2MB aligned offset
(`0x200000`) provides a safer buffer against shifting vendor
memory boundaries in future OEM bootloader updates, while still
strictly satisfying the ARM64 2MB alignment requirement.
This fix and the `0x42200000` address have been successfully tested
on actual SBE1V1K hardware by community member motolav.
Link: https://forum.openwrt.org/t/spectrum-sbe1v1k-ipq9574-openwrt-support/245244/262
Tested-by: motolav <https://forum.openwrt.org/u/motolav>
Signed-off-by: Jackie Han <jackie.han@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25344
Signed-off-by: Robert Marko <robimarko@gmail.com>
The driver carried the constants for all three sensors but registered
one zone and read only the bandgap one. Register a zone per sensor and
add two zones to the device tree.
The bandgap sensor stays zone 0 with its trips and cooling map.
#thermal-sensor-cells goes from 0 to 1.
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25147
Signed-off-by: Robert Marko <robimarko@gmail.com>
Two thermal zones reading the shared ADC at once interleave and convert
another sensor's diodes with the wrong constants. On AN7583 the zone
carrying the critical trip crossed 120 C on a chip at 55 C, shutting the
board down.
Serialise the sequence, read the mux selection back instead of caching
it, check it again after sampling and refuse to divide by a zero gain.
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25147
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Quectel EG120K-EA (LTE Cat.12) reports USB ID 2c7c:030b and exposes
its QMI/RMNET function on a vendor-specific ff/ff/ff interface. The same
product ID is already known to the option driver as EM060K, which claims
the serial interfaces, but without a qmi_wwan entry the data interface is
left unbound and no cdc-wdm node appears.
Add the device using QMI_MATCH_FF_FF_FF so the DTR quirk is applied.
Tested on a GL.iNet GL-X2000, where the modem enumerates at SuperSpeed and
now brings up cdc-wdm0 and wwan0. A data session over MEO (268-06) was
verified end to end.
Accepted upstream via netdev/net, so this is carried as a backport and can
be dropped once the kernel is bumped to 7.3 or later. Inserting it ahead of
the MeigLink hack shifts that patch's offsets, so
780-usb-net-MeigLink_modem_support.patch is refreshed as well.
Link: https://patch.msgid.link/20260921093426.2870266-1-gilbertorconde@gmail.com
Signed-off-by: Gilberto Conde <gilbertorconde@gmail.com>
Both 10G ports have a yellow and a green LED driven by the RTL8261CE
rather than by GPIO. Index 2 is yellow, index 3 green. The
index-to-colour mapping was determined empirically by inverting the
polarity bits in VEND2 0xd044 one at a time.
Configure the triggers to match the 1G ports on this board, where green
means gigabit: yellow for 10/100, green from 1000 up, and both together
for 10000. Without this the LEDs come up with no trigger and stay dark,
losing the firmware defaults they had before.
The indices were only verified on an RTL8261CE. Board revisions carrying an
RTL8261N are unaffected for now since that driver has no LED callbacks, but
the mapping should be rechecked there before relying on it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Hardware revisions of this board ship either an RTL8261N, handled by the
out-of-tree RTL826x driver, or an RTL8261CE, handled by the mainline
driver. The two need different firmware and the revision is not known at
image build time, so ship both.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The RTL8261C/D drive their LEDs through the same register block as the
RTL8221B, with four LEDs instead of three and two more speed bits. Wire
the callbacks to the RTL8261C_CG and RTL8261CE_CG entries so the 10G
ports of the Gemtek W1700K can be driven from the netdev trigger instead
of coming up dark.
Submitted upstream in the same series as the SerDes lane polarity patch.
Apply it ahead of the out-of-tree
742-net-phy-realtek-add-5G-and-10G-PHY-support.patch as well, so it too
can be carried exactly as submitted. 742's realtek_drvs[] hunk is rebased
on top of it, which only moves its leading context.
Refresh out-of-tree patches in realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The Gemtek W1700K routes the USXGMII lanes between the AN7581 and its
RTL8261CE inverted and describes that in the device tree, but nothing in
the RTL8261C/D driver reads tx-polarity/rx-polarity and the Airoha PCS
has no polarity handling of its own. The copper side negotiates normally
while the SerDes never trains and the netdev stays NO-CARRIER.
Add a read and a read-modify-write helper for the VEND1 SerDes command
window and program the lane polarity from rtl8261x_config_init().
Submitted upstream as part of a series documenting the RTL8261C/D device
tree bindings and adding SerDes lane polarity and LED support.
Apply it ahead of the out-of-tree
742-net-phy-realtek-add-5G-and-10G-PHY-support.patch so it can be carried
exactly as submitted. 742 drops its own select PHY_COMMON_PROPS and its
phy-common-props.h include, as both come from here now. Once accepted
upstream this patch only moves to backports, so they stay dropped.
Refresh out-of-tree patches in realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Backport support for the Realtek RTL8261CE_CG (PHY ID 0x001cc899),
merged for v7.4. It shares the sub-PHY-ID and the firmware with the
RTL8261C_CG.
ca44c21fc117 ("net: phy: realtek: add support for RTL8261CE_CG")
Parts reporting this PHY ID fall through to the generic Clause 45
driver. Both 10G ports of the Gemtek W1700K carry one and never come up.
The patch applies before the out-of-tree
742-net-phy-realtek-add-5G-and-10G-PHY-support.patch, which is where the
RTL_8261N/RTL_8264/RTL_8264B context around the new define comes from, so
742 gains the RTL_8261CE_CG define as context.
Refresh various out-of-tree patches in generic and realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Backport the upstream series adding support for the Realtek RTL8261C_CG
(PHY ID 0x001cc898) and RTL8261D 10Gbps PHYs, merged for v7.3 as
"add-support-for-rtl8261c-d".
Both parts share the PHY ID and are told apart by a sub-PHY-ID read from
the vendor extension page (0x00 for the RTL8261C, 0x81 for the RTL8261D).
The RTL8261C loads rtl_nic/rtl8261c.bin, the RTL8261D needs no firmware.
Two Clause 45 helpers the driver depends on are backported along with it.
3b63c19e64f8 ("net: phy: c45: add genphy_c45_pma_soft_reset()")
d7722c03089e ("net: phy: c45: add setup and read master/slave helpers")
b772b5ae4537 ("net: phy: realtek: add support for RTL8261C_CG")
a04171a1cf32 ("net: phy: realtek: load firmware for RTL8261C_CG")
f0667918d5fc ("net: phy: realtek: add support for RTL8261D")
Refresh various out-of-tree patches in generic and realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Add support for RTL9302B-based Ubiquiti UniFi USW Pro Max 24 PoE switch
with 16x GbE and 8x 2.5G RJ45 ports, 2x SFP+, and a front display.
Hardware
========
- RTL9302B switch SoC
- 512 MiB RAM
- 32 MiB SPI-NOR flash
- 16x 100M/1G RJ45 ports via 2x RTL8218E
- 8x 100M/1G/2.5G RJ45 ports via 2x RTL8224
- PoE:
- 400W total budget
- 8x 802.3at, 32W per port (ports 1-8)
- 16x 802.3bt, 60W per port (ports 9-24)
- 2x SFP+ ports
- Buttons: 1x Reset
- LEDs: RGBW LED per port (Etherlighting)
- Front touch display via USB ACM (see below)
- Console: TTL 3.3V, 115200 8N1 (internal pin header close to SoC;
layout front to back: VCC RX TX GND)
- Etherlighting feature (lighting patterns and color control)
- Vendor firmware: U-Boot + LEDE-based Ubiquiti OS
MAC address
===========
Single MAC address in EEPROM partition, applied to all ports.
Front touch display
===================
The unit has a touch-capable front display, driven by a dedicated
STM32-based MCU. Unlike other Ubiquiti switches where the MCU is
connected to the SoC via UART directly, here it is exposed as a USB
CDC-ACM serial device through an on-board Genesys Logic GL850G USB hub.
The MCU runs Ubiquiti's LCM firmware and exposes a high-level JSON
protocol (page selection, button-press events, etc.); arbitrary
pixel-level control is not possible without replacing the MCU firmware.
Display support therefore depends on both USB host support and a driver
for the LCM protocol, neither of which is currently available.
Known issues
============
- Etherlighting not controllable, driver WIP. Port LEDs for link work
though. By default, the controller keeps the LEDs in a breathing
state, gated by the link state delivered by the Realtek SoC.
Disclaimer
==========
Stock firmware uses a dual-bank layout (kernel0/kernel1, ~15 MiB each).
OpenWrt replaces both banks with a single contiguous firmware partition.
Flashing OpenWrt writes or invalidates both stock kernel slots; U-Boot
remains intact and can be used for recovery.
Installation
============
1. Enable SSH on the stock UniFi OS and log in with user account.
2. Copy the OpenWrt sysupgrade image to /tmp on the switch (e.g. via
scp).
3. Adjust IMG below to point at the copied file, then run the block as a
whole. It verifies the expected stock partition layout and image size,
writes kernel0, splits into kernel1 if the image is larger than that
slot (otherwise invalidates kernel1 so U-Boot cannot pick a stale
bank), and reboots:
set -e
IMG=/tmp/openwrt-realtek-rtl930x-ubnt_usw-pro-max-24-poe-squashfs-sysupgrade.bin
K0_SIZE=$((0xf10000))
K0_BLOCKS=$((K0_SIZE / 0x10000))
grep -q '^mtd2: 00f10000 00010000 "kernel0"$' /proc/mtd
grep -q '^mtd3: 00f20000 00010000 "kernel1"$' /proc/mtd
IMG_SIZE=$(wc -c < "$IMG")
[ "$IMG_SIZE" -gt 0 ]
[ "$IMG_SIZE" -le $((0x1e30000)) ]
dd if="$IMG" of=/dev/mtdblock2 bs=64k count=$K0_BLOCKS conv=fsync
if [ "$IMG_SIZE" -gt "$K0_SIZE" ]; then
dd if="$IMG" of=/dev/mtdblock3 bs=64k skip=$K0_BLOCKS conv=fsync
else
dd if=/dev/zero of=/dev/mtdblock3 bs=64k count=1 conv=fsync
fi
sync
reboot
The switch comes up in OpenWrt after reboot.
4. It is recommended to modify the bootcmd to speed up the boot and
prevent any issues due to the dual-boot selection. Since U-Boot by
default uses bootubnt which does a lot of (unneeded) RTK
initialization, quite some time passes until Linux is started.
Additionally, the U-Boot logic fiddles with some bits on flash which
causes JFFS2 errors in OpenWrt. While this doesn't seem to cause
issues yet, be defensive and set the bootcmd from OpenWrt with:
fw_setenv bootcmd 'bootm 0xb40b0000'
fw_printenv bootcmd
This directly boots the uImage from flash, without doing all the
initialization. OpenWrt is able to bootstrap the networking
completely on its own.
It does not matter which bank stock booted from when the dd block
runs: both banks are touched in the same pass (kernel0 written, kernel1
either written or invalidated). With kernel1 invalidated, U-Boot's
internal fallback kicks in and permanently switches to kernel0 on the
next boot, so the device stays on OpenWrt as long as kernel0 is
bootable.
Recovery
========
Since the installation procedure invalidates or partially overwrites
the second bank, recovery requires serial console access (see Hardware
above for pinout).
1. Interrupt U-Boot autoboot by spamming a key during early boot to
drop into the U-Boot prompt.
2. Bring up networking:
rtk network on
3. Transfer an OpenWrt initramfs image via TFTP and boot it:
tftpboot 0x82000000 <server>:<initramfs.bin>
bootm 0x82000000
4. From the running initramfs OpenWrt, do a sysupgrade to reflash
OpenWrt or whatever you want to recover. There is no need for the
complicated procedure from installation since OpenWrt sees the
firmware partition already as a whole.
Return to stock firmware
========================
There is no fully-supported revert path. The stock firmware blob is a
Ubiquiti UBNT archive (header + parts, see firmware-utils' fw.h) that
embeds a u-boot and a kernel0 uImage payload; only the latter is
relevant when writing back to the kernel partitions.
The snippet below extracts the kernel0 uImage from such a blob by
locating the uImage magic and using the size carried in the uImage
header itself, without parsing any UBNT framing. It is provided as a
best-effort starting point; verify the result before flashing,
otherwise you're on your own:
BLOB=<firmware.bin>
OFF=$(grep -aboF $'\x27\x05\x19\x56' "$BLOB" | head -1 | cut -d: -f1)
SIZE=$(( $(dd if="$BLOB" bs=1 skip=$((OFF + 12)) count=4 2>/dev/null \
| hexdump -e '1/4 "%u"') + 64 ))
dd if="$BLOB" of=kernel0.uImage bs=1 skip="$OFF" count="$SIZE"
Once you have a clean uImage, boot an OpenWrt initramfs as described in
Recovery, copy kernel0.uImage to /tmp, and run:
set -e
[ "$(wc -c < /tmp/kernel0.uImage)" -le $((0xf10000)) ] || exit 1
mtd write /tmp/kernel0.uImage firmware
fw_setenv bootcmd bootubnt
fw_printenv bootcmd
reboot
After rebooting, Ubiquiti's firmware should boot.
Or, if you made backups of the flash before installation, just write
the backup back to flash.
Link: https://github.com/openwrt/openwrt/pull/25280
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The RTL8218E exposes XSGMII as one logical SerDes, but its eight
MAC-side channels are represented by two groups of four. The initial
setup disables autonegotiation only for the first group on page 0x400,
leaving the second group on page 0x500 in autonegotiation mode.
Consequently, the first four package ports pass traffic while the
remaining four establish copper link but do not pass packets. Disable
XSGMII autonegotiation for the second group as well by forcing
register 0x500.12[9:8] to 01.
This changes 0x500.12 from 0x70d0 to 0x71d0 and brings
0x507.15[7:4] from 0 to 0xf on hardware, after which all eight ports
pass traffic.
Fixes: 2db820be865f ("realtek: phy: fix RTL8218E XSGMII initialization")
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25364
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Now that 6.18 is the only supported kernel version for bcm53xx,
remove the 6.12 kernel configs (config-6.12 and per-subtarget
config-6.12 files) and the entire patches-6.12 patch stack, as they
are no longer used.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25307
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The positive and negative VTH values occupy disjoint fields in the same
register. Combine them into one masked read-modify-write instead of
updating each field separately.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Program impedance, pre-amplitude, and post-amplitude in that order so
dependent enable state is not exposed before its coefficient.
Then update the main amplitude and both enable bits together. This
replaces three REG07 read-modify-write transactions with one.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
XSG fan-out is only required for the low digital pages on SerDes 2 and
3. Apply the analog configuration tables through the normal write path
and remove the now-unused XSG table helper.
Limit the XSG operation to its supported targets, reuse the normal
RTL930x write for the first SerDes, and derive the companion from the
existing physical mapping.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Document the common SerDes soft-reset register and field. Replace magic
register values in the RTL838x and RTL839x reset sequences with named,
SDK-style masked field updates. Merge the two sequences by dropping the
RTL839x-specific delay - which is unneeded according to the SDK - and
provide a combined helper.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Document RTL931x SerDes registers and fields, then replace magic offsets
and bit ranges at their call sites. Use FIELD_PREP() where values need
positioning and named masks for field updates.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Document RTL930x SerDes registers and fields, then replace magic offsets
and bit ranges at their call sites. Use FIELD_PREP() where values need
positioning and named masks for field updates.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Document SerDes registers and fields shared by RTL930x and RTL931x.
Replace magic offsets and bit ranges at their call sites with the named
registers and field masks.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Backports an accepted upstream patch targeted for 7.4 to extend the
Realtek SPI driver with support for the second CS. Though no devices
made use of this so far, further devices may do so.
Link: https://github.com/openwrt/openwrt/pull/25334
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
This reverts commit 487ff3cfa0.
Three problems:
CONFIG_AR8216_PHY is enabled and to stop it from interfering and
crashing on boot, internal MDIO needs to be used.
Once internal MDIO gets used, ports end up dying even in the absence of
traffic. This is currently believed to be an issue with qca,qca8327
specifically. There are no reports of qca,qca8337 behaving badly.
Routing speed with DSA becomes much slower. Gigabit routing is no longer
doable, even with flow offload. This needs further research.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25308
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The generic config builds CONFIG_INTEL_XWAY_PHY for all devices while
only a single one uses it. Avoid bloating the kernel by using the module
for the only device that uses this PHY.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25294
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
krava
Robert Marko
Paul Spooren
Mieczyslaw Nalewaj
Ryan Leung
Jonas Jelonek
Rosen Penev
Kel ModdermanandClaude Opus 5.5
Daniel Golle
Will Mortensen
Qingfang Deng
Ivan RainboltandClaude Opus 5
Shiji Yang
Jackie Han
Vitaliy Sochnev
Gilberto Conde
Simon Polack
Daniel Pawlik
Ross Barnes-Brown