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
============
- PoE not available, depends on WIP Realtek PSE MCU driver
- 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 overwrites 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 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:
IMG=/tmp/openwrt-realtek-rtl930x-ubnt_usw-pro-max-24-poe-squashfs-sysupgrade.bin
K0_BLOCKS=$((0xec0000 / 0x10000))
dd if="$IMG" of=/dev/mtdblock2 bs=64k count=$K0_BLOCKS conv=fsync
if [ "$(wc -c < "$IMG")" -gt $((0xec0000)) ]; 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 to:
bootm 0xb4150000
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, write it to the kernel partition from
within OpenWrt. If you adjusted the bootcmd during installation, make
sure to restore it to the default "bootcmd=bootubnt". After a reboot,
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/24110
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add support for RTL9313-based Ubiquiti UniFi USW Pro XG 8 PoE switch
with 8x 10G RJ45 and 2x SFP+ ports.
Hardware
========
- RTL9313 switch SoC
- 512 MiB RAM
- 32 MiB SPI-NOR flash
- 8x 100M/1G/2.5G/5G/10G RJ45 ports via 2x RTL8264B
- PoE: 8x 802.3bt, 60W per port, 155W total budget
- 2x 1G/2.5G/10G SFP+ ports
- Buttons: 1x Reset
- LEDs:
- System LED white/blue
- RGBW LED per port
- Console: TTL 3.3V, 115200 8N1, populated 4-pin header
(device must be opened to access header)
- 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.
Known issues
============
- PoE not available, depends on WIP Realtek PSE MCU driver
- 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 overwrites 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.
(at this stage you may make backups of the flash, just to be sure)
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 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:
IMG=/tmp/openwrt-realtek-rtl931x-ubnt_usw-pro-xg-8-poe-squashfs-sysupgrade.bin
K0_BLOCKS=$((0xec0000 / 0x10000))
dd if="$IMG" of=/dev/mtdblock2 bs=64k count=$K0_BLOCKS conv=fsync
if [ "$(wc -c < "$IMG")" -gt $((0xec0000)) ]; 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
Then reboot the switch, it comes up in OpenWrt after reboot.
You may also install the image in any other way, just make sure to
write it to the kernel0 partition and if the image is larger than
16MiB, write the rest to the kernel1 partition, otherwise invalidate
it so U-Boot cannot boot from the second bank.
4. It is recommended to modify the bootcmd to speedup 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 to:
bootm 0xb4150000
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=US3.rtl93xx_7.4.1+X.Y.Z.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, it can be written to the kernel partition
from within OpenWrt. If you adjusted the bootcmd during installation,
make sure to restore it to the default "bootcmd=bootubnt". After a reboot,
Ubiquiti's firmware should boot.
Or, if you did backups of the flash before, just write the backup to the
flash.
Link: https://github.com/openwrt/openwrt/pull/24010
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Some more cleanup for the calibration cleanup, removing some stray
whitespaces and collapsing subsequent writes in the same registers. The
former aren't helping anymore after the page -> named field conversion.
The latter can be collapsed because there is no reason to keep them
separate and thus, calls can be reduced.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
All calibration and SerDes config code runs in process context, so
busy-waiting with mdelay is unnecessary. Use usleep_range for delays
up to 10ms and msleep for longer ones to yield the CPU instead.
Add explicit linux/delay.h include to document the dependency.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace SDK-style step numbering (1.1.1, 1.1.2, ...) with descriptive
section headers and inline register name comments. This makes it easier
to follow the calibration sequence without cross-referencing the SDK.
Also correct the LEQ acronym expansion and tidy up variable comments.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace the raw register writes in rxcal_init with the previously
cleaned-up VTH and TAP helpers. Beyond readability, this also fixes two
latent bugs in the original tap4 initialisation: tap4_even was written
twice (both to PAGE_ANA_10G_EXT 0x01[5:0]) and tap4_odd was never
written at all (PAGE_ANA_10G 0x06[11:6]). Using tap_set_value(sds, 4,
0, 0) writes both fields correctly.
Also apply stage-then-latch ordering to the VTH init: write the value
registers before asserting the manual bit, consistent with the rest of
the calibration lock path.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Split tap_manual() into tap_set_adapt() and tap_set_value(), separating
mode control from value writes. Replace manual sign-magnitude bit
manipulation with rtpcs_sign_mag_encode/decode helpers. Update tap_get()
to use individual signed output pointers instead of an array and add
error propagation. Apply stage-then-latch ordering consistently: value
is written before the manual bit is set.
Remove the usleep from tap_set_adapt(enable=true). Callers already
carry explicit delays: vth_tap0_adapt_lock has msleep(200) and
dfe_taps_adapt has msleep(30) after enabling auto-adapt. The 10ms per
call was redundant and added 40ms to dfe_taps_adapt needlessly.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Split vth_manual() into vth_set_adapt() and vth_set_value(), separating
mode control from value writes, consistent with DCVS and LEQ helpers.
Rename vth_get() to match and switch from an array parameter to
individual pointers. Invert the manual boolean to 'enable' (true means
auto-adapt is running). Add error propagation throughout and demote the
read-out print from pr_info to pr_debug.
Remove the usleep from vth_set_adapt(enable=true). The only caller is
vth_tap0_adapt_lock which already has an explicit msleep(200) to wait
for adaptation to complete, making the embedded 10ms redundant. Delay
belongs at the call site, not baked into the setter.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Split leq_manual() into leq_set_adapt() and leq_set_coef(), separating
mode control from coefficient writes, consistent with the DCVS helpers.
Rename leq_get() to leq_get_coef() and leq_get_bin() to
leq_get_coef_bin() to match. Add error propagation throughout.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace the nine raw register writes that enable auto-adapt for all six
DCVS channels with a loop over dcvs_set_adapt(), consistent with how
TAP and VTH init was already converted.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Split the DCVS setter into two functions, separating mode control from
coefficient setting. The old pattern, combining everything in one
function, was still kept from the SDK but is rather confusing and makes
the function rather complex. Splitting this simplifies it a lot.
Cleanup the DCVS getter, making it consistent with the setters. Though
not used right now, kept for documentation purpose. So at least keep it
in a good style.
Remove the usleep from dcvs_set_adapt(enable=true). There is no lock
flow for DCVS that polls a result after enabling auto-adapt, so no
caller needs the delay. rxcal_init also enables VTH and TAP auto-adapt
via the load_in_init bulk write with no delay, confirming it is not
needed here either.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The (currently unused) DCVS setter (_dcvs_manual) is still based on the
XGS1210 SDK. Comparing this with other SDKs we have available (DMS1250,
TEG7124WS), a discrepancy between the setters can be seen. The variant
from XGS1210 SDK uses different fields for DCVS0 and DCVS4. They do not
match the other SDK variants, and also not the settings in
do_rx_calibration_1 where DCVS is initialized.
Adjust that to what the majority of SDK variants uses and to what makes
it consistent overall.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The three SerDes writes setting a debug output is heavily used by the
calibration code. But right now, it is duplicated in every user site. To
reduce duplication, carve out into a dedicated helper.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
One calibration function was renamed from the numbered naming before,
mostly because its full purpose wasn't known yet. This has changed now,
so rename that function to "rxcal_init" to reflect what it's doing.
Link: https://github.com/openwrt/openwrt/pull/24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Reduce repetition in dcvs_manual, dcvs_get, vth_manual and tap_manual
by hoisting the per-channel enable bit write out of per-case branches
and encoding per-channel register/bit mappings as lookup tables where
the pattern is uniform across channels.
This also fixes two bugs in dcvs_get that were hidden in the switch:
- DCVS1 read never populated dcvs_sign_out; it wrote the sign bit read
(0x14[4:4]) into dcvs_coef_bin and then immediately overwrote it with
the coefficient read, leaving the sign always zero for that channel.
- DCVS3 assigned the manual bit read directly to a bool without the !!
normalisation applied to all other cases.
Link: https://github.com/openwrt/openwrt/pull/23983
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace the mode-based approximation in the LEQ adapt+lock step with
proper media-based logic using the newly stored sds->media field. Those
adjustments are based on SDK code and digging through some basics of
signal conditioning.
PCB connections route through an external PHY (PHY-attached); that PHY
handles its own equalization so the SerDes LEQ is left in free-running
auto-adapt with no correction offset. DAC and fiber SFP connect directly
to the SerDes without an intermediate PHY and require a calibrated lock.
Replace the SDK's dacLongCableOffset/eqHoldEnable variable pair with a
single direct_serdes bool and encode the full per-media LEQ correction
into one switch: fiber +3 (direct SerDes, no cable), DAC short +4
(base 3 + 1), DAC long +6 (base 3 + 3).
Fix the MAXHOLD_EN bit (0x17[7]) and the 0x0c[8] write to be gated on
direct_serdes; both were previously conditioned on PCB which is the
PHY-attached case and thus wrong. Fix the LEQ lock to apply to all
direct SerDes connections (DAC + fiber), not just PCB. Also drop the
spurious dead-code branch that was an artifact of the original
transplanting.
No behavioral change because this particular function of calibration is
not used right now but will be in the future.
Link: https://github.com/openwrt/openwrt/pull/23983
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Track the resolved media type in struct rtpcs_serdes alongside hw_mode,
storing it as soon as rtpcs_sds_select_media() resolves it so all
subsequent ops (set_hw_mode, activate, post_config) can access it.
This is unused for now and will be used only in dead code in next
patches. Though, this dead code is going to be used with subsequent
patches.
Link: https://github.com/openwrt/openwrt/pull/23983
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Adapted from the SDK, the calibration functions are just named after
their sequential logic and with a numbering scheme. This doesn't help
understanding what the code is doing. Instead, give some of them
meaningful names where possible, revealing kind of a logical structure.
Link: https://github.com/openwrt/openwrt/pull/23983
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The calibration code is deeply nested with multiple function using
numeric nesting. Though it tries to follow the SDK pattern, this makes
it just unnecessarily complex and confusing. Dissolve some of this
unneeded nesting, together with some minor cleanup here and there.
Link: https://github.com/openwrt/openwrt/pull/23983
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The LED_GLB_CTRL register has a field to select the clock used for LED
output, either for serial LED output or for the external auxiliary MDIO
to connect a RTL8231. While the default value for the period time of
400ns is the correct one for most applications, some special devices
require a dedicated setting, e.g. UniFi switches with Etherlighting.
Support the generic DT property "clock-frequency" within the LED node,
and read + apply during LED configuration. In case the property isn't
specified, no change is applied to keep previous behavior. In case an
unsupported value is supplied, the default is used as a fallback
Link: https://github.com/openwrt/openwrt/pull/23944
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Remove kernel configs and patches for 6.12, now that layerscape target
was switched to 6.18. This was missed during the 6.12 -> 6.18 PR.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace all hardcoded page values in various calls and definitions with
the previously added defines. This should help readability, giving those
various values a name and making it easier to compare and track within
the context of what is being set.
Link: https://github.com/openwrt/openwrt/pull/23915
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
To reduce having magic values all over the place in the whole driver,
add definitions for the SerDes register pages. They are equal among all
variants and can be clearly named, as already done in the debugfs output
of the realtek-otto-serdes-mdio driver. This should ease comparison,
code understanding and very likely is a step forward towards
upstream-readyness.
Also define two macros to cover the special cases for RTL931x's digital
SerDes via 0x40/0x80 page offset.
Link: https://github.com/openwrt/openwrt/pull/23915
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
For RTL930x and RTL931x, there were some functions to get and set the
CMU band. However, they were used nearly nowhere and even the SDK
doesn't use them for active SerDes configuration. Drop them to reduce
dead code.
Dropping the cmu_band_set call from RTL931x configuration has no
negative effect. We do not know where this call originally came from.
It was introduced 51c8f76612 ("realtek: improve MAC config handling for
all SoCs") but without any explanation why and where it came from. The
SDK doesn't have it and it may be overwritten again in the later CMU
setup when parts of the SerDes are reset.
Link: https://github.com/openwrt/openwrt/pull/23904
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The xsg_write operation for RTL931x already offers the correct procedure
writing to both page + 0x40 and page + 0x80. Though, this wasn't used
so far because this pattern was still open-coded where needed. Replace
that with the xsg_write helper call.
In clear_symerr, this deliberately changes the exact sequence of
operations a bit. However, this shouldn't have any practical effect and
testing shows no issues.
Link: https://github.com/openwrt/openwrt/pull/23904
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Rename the 'determine_hw_mode' to 'select_hw_mode' to better express
what the function does. Based on the requested interface, the number of
links on a SerDes and the capabilities, it selects a suitable hardware
mode. 'determine' is clunkier and less expressive in this case.
Link: https://github.com/openwrt/openwrt/pull/23904
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Instead of hardcoding the USXGMII AN opcode values and potentially
losing track of what they actually mean, add a define for them. Actually
only one is used, however the other one gets a macro too for
documentation purpose.
Link: https://github.com/openwrt/openwrt/pull/23904
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Changelog included in source tar.
Removed patches:
- 000-getopt-prototype.patch
- 001-getopt-declaration.patch
Both patch changes are included upstream in this version.
Link: https://github.com/openwrt/openwrt/pull/23911
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
A patch was added without proper header and not obvious that it's a
backport. Replace that patch with a backport of the upstream commit.
Patch 001-build-simplify-the-instantiation-of-nftversion-h.patch
rebased, all others refreshed.
Fixes: 255f4c8e60 ("packages: nftables: fix build on host with busybox ash")
Link: https://github.com/openwrt/openwrt/pull/23910
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Bump the PKG_RELEASE as it was missed when adding a patch.
Fixes: 255f4c8e60 ("packages: nftables: fix build on host with busybox ash")
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Introducing the setup_serdes hook in the PCS driver was always intended
to be only a temporary solution. It was needed to be able to collect all
scattered code in the PCS driver first. Later, refactoring can be done
to bring everything into a proper shape.
Now we've reached the point where the setup of all variants has been
refactored in such a way that all share the same high-level sequence.
This is fully orchestrated in pcs_config now. Thus, the setup_serdes hook
is no longer needed. Move the last piece out of it into another SerDes
op hook, then drop setup_serdes.
Link: https://github.com/openwrt/openwrt/pull/23861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
One deviating piece left is the extra call in 931x's setup_serdes to
config_cmu. It is called right after the hw mode configuration, in
contrast to 930x. Until we find a better home, move it to the end of
config_hw_mode to retain behavior but to pave the way for the final
unification steps.
Link: https://github.com/openwrt/openwrt/pull/23861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
As next step, move the media configuration to pcs_config by adding
another optional SerDes ops hook which is called from pcs_config. Drop
the redundant call sites in setup_serdes then.
Link: https://github.com/openwrt/openwrt/pull/23861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Rename the RTL931x function _sds_set_media to _sds_config_media to (1)
match the RTL930x name and (2) better express what it's doing. It's not
just setting the media type, it's configuring media-specific parameters.
Link: https://github.com/openwrt/openwrt/pull/23861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Move the two pieces for media configuration from RTL930x's setup_serdes
into a separate function, having the same encapsulation as RTL931x. This
will further allow to unify the setup sequence, and play a central role
in refactoring of the whole calibration code later.
Link: https://github.com/openwrt/openwrt/pull/23861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
So far, RTL931x implemented its media selection logic within
setup_serdes, unavailable to potential other users. One of those is
RTL930x which needs this too. To easy further refactoring, carve out the
logic to a generic helper providing the equal selection for all variants
anyway.
Link: https://github.com/openwrt/openwrt/pull/23861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Right now, setting the hardware mode of a SerDes is always the last step
in setup_serdes for each variant and more or less does exactly the same.
Drop that redundancy, replacing it with a ops hook and unified call from
pcs_config.
This changes behavior for RTL839x. Before, setup for 5G SerDes was
skipped entirely. Now, the mode is set properly. Tested on a device,
this has no negative effect.
Link: https://github.com/openwrt/openwrt/pull/23861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
RTL838x and RTL839x call a reset at the end of their setup procedure
while RTL93xx do not do that. Since this is another hurdle for unifying
the setup procedure, move them to the activation hooks for now.
This retains behavior for both variants. Though something is called now
for RTL839x, the reset still skips 5G SerDes.
Link: https://github.com/openwrt/openwrt/pull/23861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The SFP SMBus patches to access SFP modules with more than just byte
access have finally been accepted upstream. Replace them with the
upstreamed version, reorder them before our still downstream SMBus MDIO
patches and refresh all.
Link: https://github.com/openwrt/openwrt/pull/23825
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Make use of scoped_guard macro to ease lock and error handling in
pcs_config by having a dedicated scope and no need for gotos.
While being here, replace -ENOTSUPP with preferred -EOPNOTSUPP and drop
{ } brackets for single statement block.
Link: https://github.com/openwrt/openwrt/pull/23759
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add the mandatory activate/deactivate bring-up hooks to rtpcs_sds_ops
and let rtpcs_pcs_config() drive the full sequence around the variant
configuration:
deactivate -> setup_serdes -> activate -> post_config
The per-variant calls that were open-coded at the start and end of the
setup_serdes() functions are removed in favour of these indirections.
RTL839X never powered the SerDes down/up, so it gets no-op stubs to
satisfy the contract for now. Execution order is preserved for all
variants.
Link: https://github.com/openwrt/openwrt/pull/23759
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Some variants need finalization that must run only after the SerDes is
powered up: RTL838X performs a one-shot switch queue reset on first
start, RTL930X runs RX calibration and the TX config. So far this lived
at the tail of the variant setup_serdes() functions.
Add an optional post_config hook to rtpcs_sds_ops and call it from
rtpcs_pcs_config() right after setup_serdes(), then relocate the
RTL838X and RTL930X tail work into it. As activate() still runs at the
end of setup_serdes() here, the execution order is unchanged.
Link: https://github.com/openwrt/openwrt/pull/23759
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
In RTL930x setup, tx config was called at then end of the procedure
after configuration and calibration ran. This is still a leftover from
the old code located in DSA/PHY. However, applying TX configuration like
amplification factors, etc. doesn't make sense after calibration, it
should run before. Moreover the call was commented with "leave loopback
mode" which is just wrong and doesn't describe what the function does.
Fix this misery.
Testing on device with different interface modes shows no difference so
far, especially no negative effects.
Link: https://github.com/openwrt/openwrt/pull/23759
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Sometimes redundancy is so obvious that one likely misses it. Trying to
bring all SerDes setup into a unified shape, one thinks twice if
something is really needed or not.
For the RTL838x case, the single writes for take/release reset were still
an outlier. Looking closer at them one can see that the same bits are all
covered already in deactivate/activate. So before, they have been put
into the desired state but those outlier writes mess with them again.
[0, 3, 0x7146/0x7106] just deals with the SOFT_RST bit that is already
covered by rtpcs_838x_sds_reset.
[0, 0, 0xc00] touches multiple bits, amongst the EN_RX/EN_TX bits
already covered in deactivate/active. Moreover, it potentially forces
other bits into a state causing broken functionality, e.g.
INV_HSI/INV_HSO which deal with the polarity. This has no effect right
no right now but might be a latent issue in the future.
Also move the reset call down to the end of the function, doing a
soft/RX reset after every configuration is done. This is likely what the
SDK also intended, and mirrors the 839x behavior.
Link: https://github.com/openwrt/openwrt/pull/23746
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Reduce the per-SerDes patching to a per-mode patching since they share a
lot of similarities, especially for QSGMII.
For fiber patching, the differences are bigger. This takes an approach
to merge the sequences completely despite applying some settings which
weren't applied before on one of the SerDes. Testing and SerDes dumps
showed no or minimal differences, and no practical effect on
functionality. A look at the SerDes register documentation we have shows
reordering the writes isn't problematic because most of the bits aren't
any trigger bits.
With all its users gone, we can now drop also the workaround SDS macro.
Link: https://github.com/openwrt/openwrt/pull/23741
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
For an attempt to simplify and reduce patching, carve out two special
writes for SerDes 0/1. While their exact purpose isn't fully known, they
need to match to make QSGMII on those two SerDes work. In order to be
able to merge the per-SerDes QSGMII patching sequences, carve them out
to the patching function one level above.
Link: https://github.com/openwrt/openwrt/pull/23741
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
In order to have a unified SerDes setup sequence, align RTL838x to all
other variants. Set the mode after patching has been applied. Testing on
devices showed the order is rather irrelevant.
Link: https://github.com/openwrt/openwrt/pull/23741
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Expand the 838x deactivate/activate helpers to also cover the analog lane
enables (REG0 EN_RX/EN_TX) and the fiber path power-down (FIB_REG0
CFG_FIB_PDOWN), which are operational-state concerns rather than reset
concerns:
- _deactivate: clear EN_RX/EN_TX and set CFG_FIB_PDOWN in addition to
block-level power off.
- _activate: clear CFG_FIB_PDOWN and set EN_RX/EN_TX before block-level
power on. The pulse-start EN=0 is omitted since _deactivate already
established EN=0 and nothing in between touches REG0[1:0].
Shrink rtpcs_838x_sds_reset() accordingly: it now owns only the SOFT_RST
toggle, making it a pure digital reset primitive. The stale "SerDes %d
reset" dev_info was dropped along with the analog/fiber writes.
Behavioural note: the EN and FIB_PDOWN writes now happen *after* the
SOFT_RST release inside rtpcs_838x_sds_reset(), rather than before it as
in the old combined sds_reset. This creates a brief window where the
SerDes is out of digital reset with lanes still disabled, before
activate re-enables them. Consistent with the new
power_off/deactivate -> configure -> reset -> activate/power_on phase
structure, but diverges from the SDK ordering (EN pulse before SOFT_RST
release). Testing on real hardware shows no difference.
Link: https://github.com/openwrt/openwrt/pull/23741
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The setup path has been adjusted before to at least not break a working
XSGMII setup. On the currently single affected device, the U-boot
pre-init runs unconditionally anyway. Thus, we can drop the top-level
gate and let our driver "setup" this mode. This enables further
structural changes.
Link: https://github.com/openwrt/openwrt/pull/23674
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
While this doesn't claim to be a standalone setup for XSGMII, at least
it doesn't break the working XSGMII setup from U-boot on Linksys
LGS352C, the currently only supported device using this mode. Later
during further refactoring, this should be improved to make sure
everything is properly set.
Link: https://github.com/openwrt/openwrt/pull/23674
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
rtpcs_931x_sds_deactivate() forces the SerDes IP mode register to OFF
(force-bit set, mode OFF) via apply_ip_mode(OFF). For IP-driven modes a
subsequent bring-up re-asserts the force-bit with the target mode, so the
lock is released. XSGMII, however, is MAC-driven: rtpcs_931x_sds_set_mode
only wrote the MAC mode and never released the IP force-lock, leaving the
IP block pinned OFF. XSGMII therefore only worked when the bootloader had
already configured the SerDes before deactivate ran.
Route the XSGMII branch through rtpcs_93xx_sds_set_mac_driven_mode(),
which unforces the IP mode (page 0x1f reg 0x09 bit 6) before writing the
MAC mode -- the same fix applied to RTL930x in 383c4469e4.
Link: https://github.com/openwrt/openwrt/pull/23674
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The MAC-driven set_mode path on RTL930x performs three steps: release the
IP mode force-lock so the MAC side takes over (deactivate forces IP=OFF),
write the MAC mode, then apply the USXGMII submode for modes that need
one. Pull these into a shared rtpcs_93xx_sds_set_mac_driven_mode() helper.
No functional change: rtpcs_930x_sds_set_mode now calls the helper instead
of open-coding the sequence. This prepares the helper for reuse by the
RTL931x XSGMII path, which currently lacks the IP force-unlock and so is
left pinned OFF by a preceding deactivate.
Link: https://github.com/openwrt/openwrt/pull/23674
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add a per-SerDes supported_modes bitmap, filled at probe by each
variant from the SerDes id or type, and reject unsupported modes in
determine_hw_mode() via test_bit().
This replaces the rtl838x is_hw_mode_supported() switch and adds the
same gating to rtl839x/rtl93xx, which previously relied only on the
per-variant mode-value table. Unlike that table, the bitmap is per
SerDes instance, so it also rejects modes the table can encode but that
a given SerDes cannot actually use. Rejection uses the uapi -EOPNOTSUPP
instead of the internal -ENOTSUPP.
Link: https://github.com/openwrt/openwrt/pull/23608
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
SerDes modes HISGMII and QHSGMII are practically dead but were added/kept
for documentation purposes. However, these modes will likely never be
used and we have other documentation than in the code. Drop them to
reduce the modes to what we actually use.
Link: https://github.com/openwrt/openwrt/pull/23608
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
A recent target-wide change missed the DTSI for a few devices causing a
build issue for RTL930x. Fix that.
Fixes: 43562f97e7 ("realtek: dts: add link index cell to pcs-handle phandles")
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
PCS driver registers each SerDes as an fwnode_pcs provider in probe;
the resolver returns the cached or freshly-allocated rtpcs_link for
the requested (sds, link_idx) cell. DSA glue stops calling
rtpcs_create directly, drops .mac_select_pcs, and instead populates
phylink_config.num_available_pcs / fill_available_pcs from each
port's pcs-handle in phylink_get_caps. The rtl838x_port.pcs pointer
becomes a has_pcs bool populated at port probe via fwnode_property_
present, since nothing assigns the actual phylink_pcs anymore but the
"does this port use a PCS?" checks elsewhere still need a presence
flag.
Without .mac_select_pcs, phylink_major_config only searches the
pcs_list when state->interface is set in phylink_config.pcs_interfaces
(drivers/net/phy/phylink.c:1378). Populate it per port whenever the
port has a pcs-handle, listing the SerDes-routable interface modes for
each SoC variant -- without this, pcs_config / pcs_link_up are never
called and the SerDes is left unconfigured.
pcs_get_state still needs the MAC port number to index per-port link
status registers. Recover it at probe via rtpcs_map_links: walk the
sibling switch's ethernet-ports subtree (same backwards topology
lookup the sibling MDIO driver does for phy-handle), and for every
port whose pcs-handle resolves to one of our SerDes, store the port's
reg in sds->link_port[]. The resolver consults link_port[] when
allocating rtpcs_link and fails with -ENODEV if a consumer requested
a link the map step didn't record. Avoids a driver-side port_base
table that would have to encode per-SoC SerDes-to-port wiring (and
would silently break on non-contiguous variants); the DT is the
single source of truth.
Kconfig selects FWNODE_PCS.
Assisted-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add an s16 link_port[] array to struct rtpcs_serdes, initialised to
-1 in probe. This is preparatory storage for the port number that
each link serves; it will be populated in the follow-up fwnode_pcs
migration commit by scanning consumer DT nodes for their reg, and
consumed by the resolver when allocating rtpcs_link.
Assisted-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Move the rtpcs_link pointer array from rtpcs_ctrl (keyed by global
DSA port) into rtpcs_serdes (keyed by the per-SerDes link index).
This matches how the hardware is structured -- a SerDes hosts up to
RTPCS_MAX_LINKS_PER_SDS PCS links -- and aligns the in-driver
addressing with the cell the DTSes just gained on pcs-handle, so the
upcoming fwnode_pcs resolver becomes a direct sds->link[cell] lookup.
rtpcs_create() takes a new link_idx parameter and stores into
sds->link[link_idx] instead of ctrl->link[port]; the DSA glue switches
its phandle lookup to of_parse_phandle_with_args() and forwards the
cell. The port number stays on rtpcs_link for legacy callers that
still need it. Bounds and double-bind checks (-EINVAL, -EBUSY) guard
against malformed DT references that would otherwise OOB or silently
overwrite an existing link.
Drops RTPCS_PORT_CNT, whose only user was the relocated array, and
fixes a pre-existing of_node_put leak on the pcs-handle phandle in
the DSA glue as a side effect of the parse-with-args conversion.
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
A SerDes can host multiple PCS links: QSGMII binds four ports to one
SerDes, USXGMII variants up to eight. Today pcs-handle references the
SerDes as a whole, with no way to express which link inside the SerDes
a port wants. The driver gets away with this because it carries its own
port->link bookkeeping and the link slot is implicit in DSA's port
iteration order -- functional, but the wiring information lives nowhere
in DT.
The upcoming fwnode_pcs migration moves PCS lookup to the generic
fwnode provider API, which disambiguates multiple instances per fwnode
via phandle cells. To make that landable as small, code-only commits,
the DT needs to carry the link index ahead of time.
Bump #pcs-cells from 0 to 1 on every SerDes node in the four SoC DTSIs
and append the link cell to every pcs-handle reference across boards
and the SWITCH_PORT_* macros. Cell values match the existing wiring:
0 for single-link SerDes (10GBase-R, SGMII, fiber, single-link
USXGMII), 0..3 per SerDes for QSGMII and USXGMII-QX, 0..7 for the
RTL9311 octal USXGMII layout.
No code reads the new cell yet -- of_parse_phandle_with_args() in the
PCS driver already cooperates with cells = 0 or 1, and the DSA glue
uses of_parse_phandle() which ignores cells entirely. The change is
runtime-neutral on its own; it exists so the follow-up code patches
can be a few lines each instead of dragging a bridge counter into the
driver to invent slot numbers DT could have provided directly.
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Switch rtpcs_serdes from struct device_node * to struct fwnode_handle *
in preparation for fwnode_pcs_add_provider, which keys providers by
fwnode. Storing the fwnode directly avoids of_fwnode_handle() wrappers
at every API boundary.
The conversion is mechanical: of_node_get/put become fwnode_handle_get/
put (same refcount on OF-backed fwnodes), polarity helpers drop their
of_fwnode_handle() wrapping, and the link counter compares fwnodes
directly via of_fwnode_handle(arg_np). No behavior change.
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Like other RTL931x devices, the Plasma Cloud ESX28 and PSX28 also have
inverted polarity on the SerDes which drive the SFP ports. Commonly,
those always seem to have inverted TX polarity. This was missing from
when the devices were added at which time SFP on RTL931x wasn't working
at all yet. Add the polarity to the DTS now.
Verified on Plasma Cloud PSX28.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Make deactivate fully restore the SerDes to an inert state at both the
MAC and IP layers. Previously deactivate only zeroed the MAC mode via
set_mode(OFF), which on the default branch only writes the MAC mode
register and leaves the IP mode register untouched. The IP mode register
then retained whatever the previous bring-up left behind (force=1 with
a stale mode value, or force=0 from boot defaults), making "deactivate"
not fully deactivate the SerDes.
Replace the set_mode(OFF) call with explicit set_mac_mode(OFF) plus
set_ip_mode(OFF). The latter writes force=1 with mode=OFF, pinning the
IP block to OFF until a subsequent bring-up takes a defined action.
This forced-OFF state would break MAC-driven modes (USXGMII / QSGMII /
XSGMII), which set only the MAC mode register and rely on the IP block
following along. To compensate, add an explicit unforce of the IP mode
force-bit (page 0x1f reg 0x09 bit 6) at the start of the MAC-mode branch
of rtpcs_930x_sds_set_mode. IP-mode bring-up via apply_ip_mode is
unaffected -- it re-asserts force=1 with the target mode value, which
overrides the deactivate force-OFF.
Net result: deactivate fully and explicitly deactivates the SerDes; each
set_mode path takes its own responsibility for the IP mode register
state. The previous asymmetric behaviour (set_mode default branch silently
not touching the IP register) is now explicit code rather than an
implicit accident-of-dispatch.
Verified on RTL930x hardware: SGMII, 2500BASE-X, 10GBASE-R, USXGMII-QX
and XSGMII all bring up correctly with link, traffic and iperf3 as
expected.
Link: https://github.com/openwrt/openwrt/pull/23513
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Move rtpcs_930x_sds_set_power() and rtpcs_930x_sds_rx_reset() out of
rtpcs_930x_sds_apply_ip_mode() and into rtpcs_930x_sds_{de,}activate().
After this, apply_ip_mode is pure IP-mode/CMU/state-machine programming
and the SerDes-core analog power is owned by the outer phase pair, the
same place that already owns the 1G/10G PHY block and fiber RX power.
Behavioural change: USXGMII / QSGMII / XSGMII modes did not previously
go through apply_ip_mode and therefore never had the SerDes-core power
gated on mode transitions. After this commit, every mode transition
power-cycles the SerDes core via the outer deactivate/activate.
For the SGMII / 1000BASE-X / 2500BASE-X / 10GBASE-R path the set of
register writes is unchanged; only the relative ordering vs. the
fiber/PHY power writes shifts: set_power(false) now precedes those
writes (was after), set_power(true) now follows them (was before).
Verified on RTL930x hardware: SGMII, 2500BASE-X, 10GBASE-R, USXGMII-QX
and XSGMII all come up with link, ping and iperf3 throughput as
expected.
Link: https://github.com/openwrt/openwrt/pull/23513
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Move rtpcs_931x_sds_set_mode(sds, hw_mode) ahead of
rtpcs_931x_sds_activate() in rtpcs_931x_setup_serdes(). The IP-block
mode registers latch with the SerDes powered down, so the mode can be
committed during the configure phase rather than after power-on.
This matches the phase order already used by 838x and 930x
(deactivate -> configure -> set_mode -> activate) and is a step toward
a unified bring-up sequence across variants.
Verified on RTL931x hardware: USXGMII, SGMII and 10GBASE-R modes all
come up, link is established, L2 forwarding works, and iperf3 reports
expected throughput.
Link: https://github.com/openwrt/openwrt/pull/23513
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Move the 1G and 10G PHY block power-up writes (clear BMCR_PDOWN on pages
0x02 and 0x04) out of rtpcs_930x_phy_enable_10g_1g() and into
rtpcs_930x_sds_activate(), and add the mirror writes (set BMCR_PDOWN) to
rtpcs_930x_sds_deactivate(). Same for the fiber RX bit.
With 1G PHY / 10G PHY / fiber RX all now handled symmetrically, drop the
rtpcs_930x_phy_enable_10g_1g() helper. The remaining write it contained
(set medium = fiber on page 0x1f reg 11 bit 1) is unrelated to power
management, unconditionally applied, and to-be-inspected for non-fiber
modes. Move it inline into setup_serdes with a TODO comment; proper
mode-aware handling is out of scope for this commit.
Behavioural note: the 1G/10G PHY blocks and fiber RX are now
power-cycled on every mode transition. Previously they were only
powered up (never explicitly down) and the state persisted across
reconfigure. The new behaviour makes each setup_serdes a standalone
bring-up that does not rely on the prior state of these bits.
Link: https://github.com/openwrt/openwrt/pull/23513
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Mirror of the previous sds_deactivate commit: add rtpcs_{838x,931x}_sds_activate()
helpers that each wrap the variant-specific "bring the SerDes back to operational"
block-power call at the end of setup_serdes, and replace the inline call.
- 838x: wraps rtpcs_838x_sds_power(sds, true)
- 931x: wraps rtpcs_931x_sds_power(sds, true)
RTL839x and RTL930x are intentionally not given an activate helper in this
commit:
- RTL839x calls rtpcs_839x_sds_reset() at the end of setup_serdes. That is
a reset pulse whose internals (per-type 10G/5G analog sequences, internal
REG3 0x7146 -> 0x7106 dance) are not yet fully characterized. Aliasing
it as _activate would misrepresent the function.
- RTL930x has no separate activation step: rtpcs_930x_sds_set_mode(sds,
hw_mode) is what commits the new mode and is intended to be surfaced
as its own "set mode" phase in a later commit rather than hidden inside
a variant-specific _activate wrapper.
Both variants will be revisited when their respective phases are clarified.
This commit is a pure refactor, no behavioural change.
Link: https://github.com/openwrt/openwrt/pull/23513
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add rtpcs_{838x,930x,931x}_sds_deactivate() helpers that each encapsulate
the variant-specific "make SerDes inert before reconfigure" sequence, and
replace the inline calls at the start of each setup_serdes with a single
call to the new helper:
- 838x: wraps rtpcs_838x_sds_power(sds, false)
- 930x: wraps rtpcs_930x_sds_set_mode(sds, RTPCS_SDS_MODE_OFF)
- 931x: rtpcs_931x_sds_power(sds, false) + rtpcs_931x_sds_set_mode(sds,
RTPCS_SDS_MODE_OFF)
RTL839x has no deactivate step to factor out and is left unchanged.
This is a pure refactor: same register writes, same order, same return-
value handling at the call site. The helpers give each variant a named
hook for the deactivate phase and prepare for a subsequent commit that
promotes it to an rtpcs_sds_ops entry and hoists the call site into
rtpcs_pcs_config.
Link: https://github.com/openwrt/openwrt/pull/23513
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
A recently added patch needs to be refreshed. Do that with make
target/linux/refresh.
Fixes: 89ef8aaf3e ("kernel: backport lm63 enhancements")
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The target was recently switched to 6.18. However, it was missed to drop
the kernel config 6.12 and a rebase unintendedly reverted previous
changes. Since the config isn't needed anymore, drop it.
Fixes: d3a7e89569 ("qoriq: switch to 6.18 kernel")
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add support for the RTL9303-based Ubiquiti UniFi USW Aggregation, an
8-port 10G SFP+ aggregation switch.
Hardware
========
- RTL9303 SoC
- 256 MiB DDR
- 16 MiB SPI-NOR flash
- 8x 1G/10G SFP+ cages
- Per-port LEDs: 1x white LED per SFP+ cage
- Buttons: 1x Reset
- Console: TTL 3.3V, 115200 8N1, internal unpopulated 4-hole THT
footprint (the device must be opened to solder a header)
- pinout (with the front panel facing you, left to right):
VCC/unused, RX, TX, GND
- Front touch display (see below)
- Software chain:
- U-Boot (Ubiquiti-flavoured)
- UniFi OS (OpenWrt-based)
MAC address
===========
Single MAC address derived from the eeprom partition. Applied to all
switch ports.
Front touch display
===================
The unit has a touch-capable front display, driven by a dedicated
STM32-based MCU connected to the host via UART. 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. The display is therefore
not supported beyond what the stock LCM firmware offers.
Disclaimer
==========
Stock uses a dual-bank layout (kernel0/kernel1, 7 MiB each). OpenWrt
replaces both banks with a single contiguous firmware partition.
Flashing OpenWrt overwrites both stock kernel slots; U-Boot remains
intact and can be used for recovery.
The stock firmware blob is RSA-signed and cannot be flashed via the
UniFi web UI. Installation has to be done from a root shell on the
running UniFi OS.
Installation
============
1. Enable SSH on the stock UniFi OS and log in as root.
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 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:
IMG=/tmp/openwrt-realtek-rtl930x-ubnt_usw-aggregation-squashfs-sysupgrade.bin
K0_BLOCKS=$((0x710000 / 0x10000))
dd if="$IMG" of=/dev/mtdblock2 bs=64k count=$K0_BLOCKS conv=fsync
if [ "$(wc -c < "$IMG")" -gt $((0x710000)) ]; 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.
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, re-run the installation
procedure above (the dd block, with $IMG pointing at the image on
/tmp).
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=US.rtl930x_X.Y.Z.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, write it to both kernel banks (since
the bootselect mechanism is not yet decoded, this guarantees U-Boot
picks the stock image regardless of bank):
dd if=kernel0.uImage of=/dev/mtdblock2 bs=64k conv=fsync
dd if=kernel0.uImage of=/dev/mtdblock3 bs=64k conv=fsync
Link: https://github.com/openwrt/openwrt/pull/23506
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Previously, sds->num_of_links was incremented from rtpcs_create() as
each DSA port bound its phylink_pcs. The count therefore relied on a
temporal contract (DSA must finish enumerating before pcs_config runs)
and on rtpcs_create() being the single chokepoint for all consumers.
Replace this with a probe-time scan of pcs-handle references in the
live OF tree: for every available consumer node carrying a pcs-handle
property pointing at one of our SerDes subnodes, bump that SerDes'
num_of_links. After the scan, the count is final regardless of when
or whether DSA later calls in.
To allow of_parse_phandle_with_args() to walk the property correctly,
add #pcs-cells = <0> to every serdes@N node in the 838x/839x/930x/931x
.dtsi files. A future cell-bearing form remains possible without
touching the scan.
Over-references (DT pointing more consumers at one SerDes than the
hardware can carry) are clamped at RTPCS_MAX_LINKS_PER_SDS and warned
about, but do not fail probe — the correctly-wired ports on that
SerDes still come up, and only the surplus reference is dropped.
The bounds check and the bare ++ in rtpcs_create() become redundant
under the scan-driven count and are removed.
This decouples num_of_links from DSA call ordering and is a prereq
for migrating to fwnode_pcs providers, where rtpcs_create() goes away
as the centralised counter.
Link: https://github.com/openwrt/openwrt/pull/23484
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The led_set node was previously duplicated in the per-device DTS for
-10/-12HP and -12F, even though all three share the same Base-T LED
encoding. Move the shared led_set with the Base-T mapping into the
common DTSI as set 0, and have XS1930-12F append its SFP-port mapping
as led_set1 via a property override. Swap the led-set index on the
-12F ports accordingly so SFP ports use set 1 and the two Base-T
ports use set 0.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23428
Signed-off-by: Robert Marko <robimarko@gmail.com>
The -12HP variant has a dedicated red LED on GPIO 3 that lights up
when the PoE budget is exhausted. Add it as led_poe_max with
function = "poe-usage" so userspace can drive it from the PoE stack.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23428
Signed-off-by: Robert Marko <robimarko@gmail.com>
The cloud and locator LEDs were declared with no function (cloud) or
with the generic LED_FUNCTION_INDICATOR (locator), which doesn't
match what the hardware actually exposes. Use the descriptive
function strings "cloud" and "locator" instead so the LEDs end up
with sensible names in sysfs.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23428
Signed-off-by: Robert Marko <robimarko@gmail.com>
The XS1930-12HP model from Zyxel doesn't actually use the same GPIOs for
the SYS LED. This was assumed first but proved wrong now. Instead, the
green part of the SYS LED is on another GPIO and the red part of the SYS
LED is on GPIO 0 instead of the green part. Adjust that accordingly in
the device tree.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23428
Signed-off-by: Robert Marko <robimarko@gmail.com>
The support addition for those switches defined the restore button as a
button to trigger a restart. However, those switches also have a reset
button which is wired to the SoC's reset line, causing a reset upon
pressing. Thus, using the restore button for basically the same purpose
doesn't make sense. Change the 'linux,code' property to 'BTN_0' to
assign no real function to that button, allowing it to be used for
different purposes.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23428
Signed-off-by: Robert Marko <robimarko@gmail.com>
The switches from Zyxels XS1930 have one or two fans in the case. They
might be controlled in a limited fashion. There's a single GPIO which -
depending on the state - drives the fan in slow or fast mode. Wire that
up as a device tree node to be able to control that in userspace.
XS1930-10 and XS1930-12HP use the same GPIO while XS1930-12F moves that
to one of its GPIO expanders. Also add 'kmod-hwmon-gpiofan' for all
three devices to be selected by default.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23428
Signed-off-by: Robert Marko <robimarko@gmail.com>
XS1930-10 and XS1930-12HP share most of their layout: the same
8-port AQR813 Base-T block, the same SFP+ GPIO mux, identical I2C
master config and serdes polarity. Carve those shared pieces out
into a new intermediate rtl9313_zyxel_xs1930-aqr813.dtsi and have both
device DTS files include it, leaving only their device-specific
differences (LED-set masks, extra PoE bits on -12HP, extra AQR113C
PHYs on -12HP) in the per-device files. XS1930-12F continues to
include the common DTSI directly since its layout differs too much
to share usefully.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23428
Signed-off-by: Robert Marko <robimarko@gmail.com>
The power, cloud and locator LEDs exist on all three XS1930 variants
with the same colors and roles, only the GPIOs differ. Declare them
once in the common DTSI with the -10/-12HP pinout and let -12F
override the gpios properties via phandle references. This removes
three near-identical led-node blocks from the device DTS files.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23428
Signed-off-by: Robert Marko <robimarko@gmail.com>
The AddDepends/pse-pd helper appended kmod-pse-pd to DEPENDS without the
'+' prefix, making it a hard dependency rather than an auto-selecting one.
This breaks pulling any PSE controller driver (kmod-pse-pd692x0,
kmod-pse-si3474, kmod-pse-tps23881, kmod-pse-regulator, ...) in via a
device's DEVICE_PACKAGES: the kmod itself is auto-selected, but the
unsatisfied hard dep on kmod-pse-pd silently drops it from .config.
Prefix the kmod-pse-pd entry with '+' so it auto-selects, matching how
the other deps in the same file (kmod-i2c-core, etc.) are expressed. The
helper is the right place to fix this; every PSE controller driver routes
through it.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23449
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add support for the RTL9301-based Zyxel XGS1930-28HP, a 28-port Gigabit
PoE+ switch. The XGS1930 is an EOL Zyxel series of RTL9301-based
switches available with 28 or 52 ports, with and without PoE.
Hardware
========
- RTL9301 SoC
- 512 MiB DDR3 RAM
- 32 MiB SPI-NOR flash
- 24x 10/100/1000M RJ45 ports
- 4x 1G/10G SFP+ cages
- PoE:
- 802.3af/at on all 24 RJ45 ports
- 375 W total power budget
- RTL8231 for port LEDs
- Front LEDs: PWR, SYS, CLOUD, LOCATOR, PoE usage bar (5 steps)
- Buttons: 1x "Restore"
- Console: TTL 3.3V, 115200 8N1, 4-pin header
- pinout (front to back): GND RX TX -
- Software chain:
- Bootbase/stripped-down U-Boot
- RAS/ZyNOS
MAC address
===========
Single MAC address derived from the board partition. Applied to all
switch ports.
Disclaimer
==========
PoE is not yet supported.
Flashing OpenWrt overwrites ZyNOS. The Bootbase/U-Boot remains intact
and can be used for recovery.
Installation
============
Simple web upgrade:
1. Take the OpenWrt factory.bin image generated by the build.
2. In the ZyNOS web UI, login and go to Maintenance -> Firmware Upgrade.
3. If the device runs ZyNOS 5.00, untick "Enhanced firmware integrity
check sha256sum". Otherwise the upload check will reject the image.
4. Select and upload the factory.bin image and click upgrade.
5. After flashing has finished, reboot the switch. It will now boot
into OpenWrt.
Initramfs boot
==============
Luckily the switch uses a standard design, thus networking works with
a default hardware profile of RTK U-boot.
1. Connect to the serial console and interrupt the boot process by
spamming '$' during the DRAM test to drop into Bootbase/U-Boot.
2. Bring up the network:
> rtk network on
Use a copper port; the SFP+ cages are likely not usable from the
bootloader.
3. Load the initramfs image via TFTP:
> tftpboot 0x82000000 <server>:<image>
4. Run the image (not bootm, the image has no uImage header):
> go 0x82000000
Return to stock firmware
========================
1. Download the stock firmware for the switch from the Zyxel website
and unzip it; there should be a .bin file with an alphanumeric name.
2. Upload that file to the running OpenWrt instance.
3. Flash it (use -F since the image has no OpenWrt metadata):
> sysupgrade -F <stock-firmware>.bin
4. Wait for sysupgrade to finish and the switch to reboot. ZyNOS should
come up again.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23389
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL930x calibration code is especially chatty. There are debug
prints for every start and end of a section corresponding to the
sections the SDK uses. In the end, this doesn't help a user much and
just wastes CPU cycles. Moreover it doesn't help in understand what is
done there. As a first step, drop "start" and "end" prints but preserve
their meaning as comments.
While at it, slightly adjust two other prints and drop one confusing
print.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23288
Signed-off-by: Robert Marko <robimarko@gmail.com>
There is no need to be extra chatty for simple writes which set a single
bit. As a nice side effect, without the prints there's no need to have
open-coded register access when there a helper that covers that.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23288
Signed-off-by: Robert Marko <robimarko@gmail.com>
The SerDes setup code for RTL931x still has a lot of debug prints as
pr_info from former times. A lot has changed and we don't need that
rather useless chattiness anymore. We reached a state where we have a
standalone setup of most hardware modes. The registers printed are still
"documented" in rtpcs_931x_sds_config_hw_mode and
rtpcs_93xx_sds_config_cmu. For every other issues we rely on comparison
of full SerDes dumps instead of cherry-picked registers.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23288
Signed-off-by: Robert Marko <robimarko@gmail.com>
Specifications
==============
- SoC: RTL9302C
- Flash: 32 MiB SPI NOR flash
- RAM: 256 MiB
- Ethernet: 8x 10/100/1000/2500 Mbps (RTL8224)
- PoE: 802.3 af/at/bt on 8x RJ45 ports
- 60W per port, 130W total budget
- SFP: 2x SFP+ cages
- UART: 1x 4 pins serial header, 115200 bauds, 8n1, 3.3v logic levels,
pinout: unused (top), TX, RX, GND (bottom)
- Buttons: 1x "Restore" button, 1x "LED mode" button
MAC address
===========
Single MAC address derived from board partition with vendor-specific
format. MAC address is 70:49:a2:xx:xx:xx and applied to all switch
ports.
PoE
===
PoE is supported by realtek-poe package. To make it work, additional
options in the realtek-poe configuration file /etc/config/poe must be
set:
config globals
option force_baudrate '115200'
option force_dialect 'realtek'
Disclaimer
==========
Flashing OpenWrt will overwrite BootExtension + ZyNOS. BootExtension
functionality is not available anymore then. The U-boot/Bootbase still
has some limited functionality which can be used in emergency cases.
Installation
============
Simple web upgrade:
1. Take the OpenWrt factory.bin image generated by the build.
2. In the ZyNOS web UI, login and go to Maintenance -> Firmware Upgrade.
3. Under "Boot Image", make sure the Config Boot Image is set to 1. In
other words, make sure the switch booted from firmware image 1 or it
will do so on next reboot.
This is crucial, otherwise OpenWrt cannot boot.
4. Below, select and upload the factory.bin image. After clicking
upgrade, the image will be flashed.
5. After flashing has finished, reboot the switch. It will now boot into
OpenWrt.
U-Boot
======
This device ships with U-boot masked as Bootbase. After the device is
powered, a DRAM test is performed. Spamming $ during that test will drop
you into a shell after test finished. You'll have a limited command set
at first.
Unlocking the shell with [1] or [2] will give you a normal U-boot
command set. From here, you can perform initramfs boot or recovery.
Initramfs boot:
> loady 0x82000000 + go 0x82000000
Recovery:
> upgradeY image2 0x82000000 115200
Return to stock firmware
========================
1. Download the firmware for the switch from Zyxel website.
2. Unzip the download, there should be a .bin file with a alphanumeric
name.
3. Upload this file to running OpenWrt.
4. Run (use -F since the image doesn't have image metadata):
> sysupgrade -F <stock-firmware>.bin
5. Wait for the sysupgrade to succeed and the switch reboot. At the next
boot, ZyNOS should come up again.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23218
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL930x SoCs have a second serial interface UART1 which is exposed on
dual-function pins shared with JTAG. The SoC defaults to the JTAG
functionality after reset. Similar to existing pinmux registers, there's
a separate register for that where a selector decides about JTAG vs
UART.
Add a now pinctrl node for that register and a pinmux node to enable
UART1 functionality. Reference the pinmux in the (by default disabled)
uart1 node. Without this, UART1 doesn't work when it is actually needed.
This is e.g. the case with some PoE-capable switch where the PSE MCU
communicates with the SoC via UART instead of I2C.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23218
Signed-off-by: Robert Marko <robimarko@gmail.com>
Jonas Jelonek