The Plasma Cloud ESX28 Switch is a 24 + 4 port multi-GBit switch with
24x 10/100/1000/2500BaseT Ethernet ports and 4x SFP+ module slot.
Hardware:
- RTL9312C SoC
- Macronix MX25L25645G (32MB flash)
- 512MB DDR3 SDRAM
- RTL8231 GPIO extender to control the port LEDs
- 6x RTL8224 4x 10m/100m/1/2.5 Gigabit PHY
- SFP+ 4x 10GBit slot
The switch is powered directly via AC.
The external RS232 serial connector (RJ45, Cisco pinout) can be used to
access the terminal. Serial connection is via 115200 baud, 8N1.
A reset button is accessible through a hole in the front panel.
Installation
------------
* The device can be flashed by using sysupgrade command. Either from the
original vendor firmware or using an initramfs (see "Debug")
* Connect serial on front panel. Connection parameters: 115200 8N1
* The image must be copied using scp to /tmp of the device
scp openwrt-realtek-rtl931x-plasmacloud_esx28-squashfs-sysupgrade.bin root@[IP address of the device]:/tmp/
* start sysupgrade without saving the original vendor configuration
sysupgrade -n /tmp/openwrt-realtek-rtl931x-plasmacloud_esx28-squashfs-sysupgrade.bin
Installation via u-boot
-----------------------
If you have an TFTP server connected to the switch, it is possible to
directly install the device using the factory image from u-boot
# setup networking and IP of TFP server
rtk network on
setenv ipaddr 10.100.100.99
setenv serverip 10.100.100.20
# get factory image
tftp 0x84000000 factory.bin
# erase firmware partitions
sf probe 0
sf erase 0x5e0000 0x1a20000
# write firmware to both partitions
sf write ${fileaddr} 0x5e0000 ${filesize}
sf write ${fileaddr} 0x12f0000 ${filesize}
# adjust the boot commands
setenv bootargs "mtdparts=spi0.0:768k(u-boot),64k(u-boot-env),64k(u-boot-env2),5120k(reserved),13376k(inactive),13376k(firmware2)"
setenv bootcmd "rtk init; bootm 0xb52f0000"
# restart
reset
Debug
-----
* Connect serial on front panel. Connection parameters: 115200 8N1.
* A tftp server is required, tftpd-hpa works well.
* Power the device, at U-Boot start rapidly hit Esc key to stop autoboot
* Enter passwords: "1234" or "plasmapsx"
* Enable network:
rtk network on
* Change ip address of device:
setenv ipaddr 192.168.1.6
* Download initramfs from TFTP server:
tftpboot 0x84000000 192.168.1.111:openwrt-realtek-rtl931x-plasmacloud_esx28-initramfs-kernel.bin
* Boot loaded file:
bootm 0x84000000
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Sven Eckelmann <se@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20172
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Plasma Cloud PSX28 Switch is a 24 + 4 port multi-GBit switch with
24x 10/100/1000/2500BaseT Ethernet ports and 4x SFP+ module slot.
Hardware:
- RTL9312C SoC
- Macronix MX25L25645G (32MB flash)
- 512MB DDR3 SDRAM
- RTL8231 GPIO extender to control the port LEDs
- 6x RTL8224 4x 10m/100m/1/2.5 Gigabit PHY
- SFP+ 4x 10GBit slot
- RTL8239 POE++ PSE controller with frontend MCU
The switch is powered directly via AC.
The external RS232 serial connector (RJ45, Cisco pinout) can be used to
access the terminal. Serial connection is via 115200 baud, 8N1.
A reset button is accessible through a hole in the front panel.
Installation
------------
* The device can be flashed by using sysupgrade command. Either from the
original vendor firmware or using an initramfs (see "Debug")
* Connect serial on front panel. Connection parameters: 115200 8N1
* The image must be copied using scp to /tmp of the device
scp openwrt-realtek-rtl931x-plasmacloud_psx28-squashfs-sysupgrade.bin root@[IP address of the device]:/tmp/
* start sysupgrade without saving the original vendor configuration
sysupgrade -n /tmp/openwrt-realtek-rtl931x-plasmacloud_psx28-squashfs-sysupgrade.bin
Installation via u-boot
-----------------------
If you have an TFTP server connected to the switch, it is possible to
directly install the device using the factory image from u-boot
# setup networking and IP of TFP server
rtk network on
setenv ipaddr 10.100.100.99
setenv serverip 10.100.100.20
# get factory image
tftp 0x84000000 factory.bin
# erase firmware partitions
sf probe 0
sf erase 0x5e0000 0x1a20000
# write firmware to both partitions
sf write ${fileaddr} 0x5e0000 ${filesize}
sf write ${fileaddr} 0x12f0000 ${filesize}
# adjust the boot commands
setenv bootargs "mtdparts=spi0.0:768k(u-boot),64k(u-boot-env),64k(u-boot-env2),5120k(reserved),13376k(inactive),13376k(firmware2)"
setenv bootcmd "rtk init; bootm 0xb52f0000"
# restart
reset
Debug
-----
* Connect serial on front panel. Connection parameters: 115200 8N1.
* A tftp server is required, tftpd-hpa works well.
* Power the device, at U-Boot start rapidly hit Esc key to stop autoboot
* Enter passwords: "1234" or "plasmapsx"
* Enable network:
rtk network on
* Change ip address of device:
setenv ipaddr 192.168.1.6
* Download initramfs from TFTP server:
tftpboot 0x84000000 192.168.1.111:openwrt-realtek-rtl931x-plasmacloud_psx28-initramfs-kernel.bin
* Boot loaded file:
bootm 0x84000000
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Sven Eckelmann <se@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20172
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
To be able to read out the ethaddr from the u-boot environment for MAC
address configuration, it is required to also enable the NVMEM layout
parsing code for the U-Boot env layout.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20172
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
If transmissions are done outside of the DSA switch (directly from the CPU
port), the STP state must not block the transmission. Otherwise, STP frames
are not correctly submitted and the STP frames cannot correctly detect
loops before switching a port in the forwarding state.
The same applies for the LLDP frames. These must be submitted independent
of the STP state to identify neighbors or configure POE limits.
It is not necessary to filter specific destination mac addresses because
the transmission was done outside the bridge/switch in the first place. The
transmission is therefore forced.
Signed-off-by: Issam Hamdi <ih@simonwunderlich.de>
Co-developed-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20184
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL930X and RTL931X SoCs support port-based, flow-based, and
RSPAN-based mirroring. Like for other SoCs from the realtek target, only
the port based port mirroring can be exposed using Linux's tc subsystem.
The port_mirror_add() implementation was updated with the following
considerations for RTL93xx SoCs:
* mirrored packets must pass through the TX pipeline of the mirroring
port, so they are subject to configuration such as VLAN tagging,
remarking, and EVC
* when a packet hits both source ports (SPM) and destination port (DPM) of
a mirror group, the egress port traffic will be mirrored
The port_mirror_del() function doesn't require any modifications.
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Co-developed-by: Sven Eckelmann <se@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20264
Signed-off-by: Robert Marko <robimarko@gmail.com>
Instead of using a lot of if-else blocks in the port mirror code, provide
SoC specific function which calculates the SoC specific portions. The
generic part of the port mirroring code can then simply operate on the
calculated register addresses and values.
Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20264
Signed-off-by: Robert Marko <robimarko@gmail.com>
Replace the pending I2C backport patches for RTL93XX added in
44655c97bb with the upstreamed variants. The patches have been accepted
upstream in the meantime and are included in v6.17 or v6.18.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20273
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL931x has next to its SPI flash controller a SPI master interface. It
is connected to
* SPI_CS#[1,0]: AH22 , AK22 (aka: GPIO 12, 11)
* SPI_CLK: AL23 (aka: GPIO 8)
* SPI_MISO: AM23 (aka: GPIO 9)
* SPI_MOSI: AL22 (aka: GPIO 10)
It is not the same as the SPI flash controller which uses pins:
* SPI_CS#[1,0]: B24, A24
* SPI_SCLK: A23
* SPI_SDI/SIO0: B21
* SPO_SDO_SIO1: B21
* SPI_SIO2: A22
* SPI_SIO3: B22
* SPI_RSTN: B23
As shown above, the SPI master controller shares its pin with GPIO 8, 9,
10, 11, 12. In some upcoming devices (like the Plasma Cloud PSX28/ESX28),
they will be used for SFP cage signaling. These pins must therefore be
switched manually to the GPIO mode.
The SPI_CTRL0 register provides all necessary configuration to enforce the
GPIO mode of the pins. And until more requirements (and a correct driver)
for the SPI master controller arise, it is therefore possible to use
pinctrl-single to configure it using the devicetree.
Previously the ethernet driver did configure the SPI master controller for
31.25 MHz. It is unknown for which kind of device this was originally made
and what was actually connected there. But this manual write to the
register conflicts potentially with the write of the pinctrl driver to the
same register. Luckily, we don't need this SPI speed configuration in the
ethernet driver. Still, to allow this device an easy migration, the
`spi0-31mhz` configuration was already prepared.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20263
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL8224 used by Plasma Cloud PSX8/PSX10 is not using USXGMII but
USXGMII 10G-QXGMII mode. The correct phy-mode string for this is
"10g-qxgmii".
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20239
Signed-off-by: Robert Marko <robimarko@gmail.com>
The current SerDes implementation for RTL931x handles 10G-QXGMII via the
"usxgmii" PHY mode. This is not 100% correct because it is not a single
port with 10G (max) but 4 ports with 2.5G each.
To allow setting of the "10g-qxgmii" phy mode, just change the code for now
to use the same codepaths as USXGMII. This has to be cleaned up further
during the SerDes driver rewrites.
Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20239
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Plasma Cloud PSX28 and ESX28 are using RTL8224 as ethernet PHY. This
phy works perfectly fine on PSX8/PSX10 (RTL930x) but failed to establish a link
on rtl931x because the upstream realtek phy driver was not enabled.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20239
Signed-off-by: Robert Marko <robimarko@gmail.com>
Upstream will get support for the Realtek ECC engine with 6.18.
To make use of this in Openwrt
- backport upstream patches
- change config so that ECC will be built for nand subtargets
- define ECC engine in RTL93xx DTS.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19746
Signed-off-by: Robert Marko <robimarko@gmail.com>
During testing, we discovered that when adding a new offload FDB rule
on certain VLANs and then delete it, does not work as expected.
Steps to Reproduce:
* Create VLAN 4094 on the port lan1:
bridge vlan add vid 4094 dev lan1 pvid
* Add a new FDB entry on port lan1 for VLAN 4094:
bridge fdb add 00:01:02:22:33:44 dev lan1 vlan 4094 master permanent
* Delete the new FDB entry on port lan1 for VLAN4094
bridge fdb del 00:01:02:22:33:44 dev lan1 vlan 4094 master permanent
Root Cause:
The failure occurs because the hash_msb flag is not set correctly
based on the VLAN ID when adding a new L2 entry.
Signed-off-by: Issam Hamdi <ih@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20183
Signed-off-by: Robert Marko <robimarko@gmail.com>
Align GS1900-10HP dts with other realtek devices to reduce the risk of device
specific regressions with the upcoming driver cleanup/rewrite.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/20228
Signed-off-by: Robert Marko <robimarko@gmail.com>
Parse the pcs-handle property regardless of phy-handle
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/20228
Signed-off-by: Robert Marko <robimarko@gmail.com>
There are SFP modules which only work if auto-negotiation is disabled,
like some "OEM SFP-2.5G-T" modules. This also seems to be necessary for
RTL8226/RTL8221B PHYs when using 2500Base-X.
However, currently, it is always enabled, so add support for configuring
it to make these SFP modules and PHYs work.
This also adds locking which should be useful for future extension of
the PCS driver.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19518
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that MDIO and DSA driver only look for pcs-handle drop all
usages of the sds property.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20148
Signed-off-by: Robert Marko <robimarko@gmail.com>
In the Realtek dts the pcs-handle property at the switch port is the
successor of the sds property at the phy. Rearrange the MDIO and DSA
driver so they always look at the new attribute.
Remark! This code can be dropped completely if the new PCS driver
is fully featured. But this will take some time.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20148
Signed-off-by: Robert Marko <robimarko@gmail.com>
Zyxel labels their switch revisions A1, B1, ... and not v1, v2, ...
Rename the supported device to A1 to make it clear this is the only
known compatible hardware revision.
Also add a compatible for seamless upgrade.
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Link: https://github.com/openwrt/openwrt/pull/20118
Signed-off-by: Robert Marko <robimarko@gmail.com>
Zyxel labels their switch revisions A1, B1, ... and not v1, v2, ...
Rename the devices as such in OpenWrt to match the labels. Of note:
the first (A1) revision is never labeled as such on the label, just
in the web UI. Provide compatibles for seamless sysupgrade.
For a recent overview of Zyxel GS1900 series revisions, see the
table linked in https://forum.openwrt.org/t//57875/3874.
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Link: https://github.com/openwrt/openwrt/pull/20118
Signed-off-by: Robert Marko <robimarko@gmail.com>
Zyxel labels their switch revisions A1, B1, ... and not v1, v2, ...
Rename the devices as such in OpenWrt to match the labels. Of note:
the first (A1) revision is never labeled as such on the label, just
in the web UI. Provide compatibles for seamless sysupgrade.
For a recent overview of Zyxel GS1900 series revisions, see the
table linked in https://forum.openwrt.org/t//57875/3874.
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Link: https://github.com/openwrt/openwrt/pull/20118
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that there is a dedicated PCS driver remove the old functions
from the DSA driver and make use of the new ones.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20129
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
For all switch ports where the assigned SerDes is known, add the new
pcs-handle to the dts. Leave the existing <sds> assignments to the
PHYs as is because the driver has not yet been updated.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20111
Signed-off-by: Robert Marko <robimarko@gmail.com>
Until now the the SerDes configuration is realized with helper functions
scattered around the DSA and PHY driver. Give them a new home as a PCS
driver.
The target design is as follows:
- dsa driver manages switch
- pcs driver manages SerDes on high level (this commit)
- mdio driver manages SerDes on low level
This driver adds the high level SerDes access via PCS. It makes use of
the low level mdio SerDes driver to access the registers.
Remark: This initial version provides exactly all phylink_pcs_ops that
are currently part of the DSA driver. So this can be swapped in one of
the next commits as a drop in replacement. To make use of it something
like this is needed:
...
ports = of_get_child_by_name(node, "ethernet-ports");
if (!ports)
return -EINVAL;
for_each_available_child_of_node(ports, port) {
pcs_node = of_parse_phandle(port, "pcs-handle", 0);
of_property_read_u32(port, "reg", &port_nr)) {
priv->pcs[port_nr] = rtpcs_create(dev, pcs_node, port_nr);
}
...
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20075
Signed-off-by: Robert Marko <robimarko@gmail.com>
In the future the PCS & DSA drivers will lookup the SerDes of a
switch port via pcs-handle (like upstream does). Provide a macro
that allows to expand the existing port definitions. To link a
SerDes to port simply do
Either in short form:
replace SWITCH_PORT(0, 1, qsgmii)
with SWITCH_PORT_SDS(0, 1, 3, qsgmii) (Link to SerDes 3)
Or in long form:
port@24 {
reg = <24>;
label = "lan25";
pcs-handle = <&serdes4>; (Link to SerDes 4)
phy-handle = <&phy24>;
phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <&sfp0>;
};
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20075
Signed-off-by: Robert Marko <robimarko@gmail.com>
The fixes for the dying timers were finally accepted upstream.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20097
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently following warnings are given
dts/rtl930x.dtsi:166.4-23: Warning (reg_format):
/switchcore@1b000000/i2c@36c:reg: property has invalid length
(8 bytes) (#address-cells == 2, #size-cells == 1)
Obviously default address-cells size is fixed to 64 bit. Align
with upstream and override address size to 32 bit.
Suggested-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20091
Signed-off-by: Robert Marko <robimarko@gmail.com>
The upcoming PCS driver will lookup the SerDes mdio bus via
of_mdio_find_bus() and the devicetree. This is only possible
with proper registration via devm_of_mdiobus_register().
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20078
Signed-off-by: Robert Marko <robimarko@gmail.com>
No need two write a dedicated 1:1 mapping function and link that
for all the targets except RTL931x. Combine everything into a generic
helper and reduce the configuration structure.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20078
Signed-off-by: Robert Marko <robimarko@gmail.com>
The new SerDes mdio driver produces the following compilation
error in non-debug builds.
drivers/net/mdio/mdio-realtek-otto-serdes.c:72:12:
error: 'rtsds_sds_to_mmd' defined but not used [-Werror=unused-function]
72 | static int rtsds_sds_to_mmd(int sds_page, int sds_regnum)
| ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Move the function into the debug section.
Fixes: 7a7ee72c4d ("realtek: mdio: add SerDes driver")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20078
Signed-off-by: Robert Marko <robimarko@gmail.com>
Until now the SerDes access is realized with some helper functions
in the mdio bus. These were moved around a lot and had no real home.
End that temporary solution to move them where they belong.
The target design for the different Realtek drivers is as follows:
- dsa driver manages switch
- pcs driver manages SerDes on high level (to be developed)
- mdio driver manages SerDes on low level (this commit)
This driver adds the low level SerDes access via mdio. For debugging
purposes the user can interact with the SerDes in different ways.
First, there is a debug interface in
/sys/kernel/debug/realtek_otto_serdes/serdes.X/registers.
With that a dump of all registers can be shown.
> cat /sys/kernel/debug/realtek_otto_serdes/serdes.4/registers
Back SDS 4: 00 01 02 03 04 05 06 07 08
SDS : 0C03 0F00 7060 7106 074D 0EBF 0F0F 0359 5248
SDS_EXT : 0000 0000 85FA 8C6D 5CCC 0000 20D8 0003 79AA
...
Second, one can read/write registers via the mmd functions of the
mdio command line tool. Important to know: The registers are accessed
on the vendor specific MDIO_MMD_VEND1 device address (=30). Additionally
the SerDes page and register are concatenated into the the mmd register.
Top 8 bits are SerDes page and bottom 8 bits are SerDEs register.
E.g.
- mmd 0x0206 : SerDes page 0x02, SerDes register 0x06
- mmd 0x041f : SerDes page 0x04, SerDes register 0x1f
Read register 0x02 on page 0x03 of SerDes 0
> mdio realtek-serdes-mdio mmd 0:30 raw 0x0302
Write register 0x12 on page 0x02 of SerDes 1
> mdio realtek-serdes-mdio mmd 1:30 raw 0x0212 0x2222
For now this driver is only defined in the devicetree and activated
in the kernel build. There is no current consumer but at least
the debugging interface is available. Cleanup of the currently used
SerDes functions will come later.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20062
Signed-off-by: Robert Marko <robimarko@gmail.com>
There is some open coding in the ethernet driver. Drop
that and use kernel helpers instead.
- Use napi_gro_receive() instead of local skb list
- Use skb_put_data() instead of skb_put() plus memcpy()
- Use netdev_alloc_skb_ip_align() instead of manual alignment
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20030
Signed-off-by: Robert Marko <robimarko@gmail.com>
Converts the KS8995 "phy" driver to a proper DSA switch.
Currently the upstream only supports the "none" tag
but this is a good improvement already.
Make the old module depend on kernel 6.6 and the new
one depend on !6.6.
The Realtek RTL8261n patch needs to be refreshed
because of textual dependencies.
Realtek RTL838x DSA and phy patches also have textual
dependencies and need to be refreshed.
The Mediatek in-flight DSA patch and related patches
also need to be rebased and refreshed.
Link: https://github.com/openwrt/openwrt/pull/19970
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
During SerDes rework the helper functions were temporarily
renamed to ..._new(). Fix the leftovers by
- giving the functions a new rtsds_ prefix nad
- dropping the _new appendix.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20034
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that HSGMII is not used any longer drop the patch
the invents this mode.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20002
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The only consumers of the Realtek HSGMII (2.5G SGMII) mode were
the RTL8226/RTL8221B PHYs. These have been converted to dynamic
SGMII/2500base-x mode switching. Drop the leftovers of the mode
implementation.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20002
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The mdio controller got its own dts node with a dedicated bus node.
Until now it still searches the phy nodes in the ethernet node.
Change the driver so it searches the nodes at the right location.
For this to work move the phy nodes in all dts/dtsi over to the new
bus node. Use the following replacement rule:
Replace old full declaration
ðernet0 {
mdio-bus {
...
};
};
and old abbreviated declaration
&mdio {
...
};
simply with the new declaration
&mdio_bus0 {
...
};
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19986
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The mdio controller has now its own target specific device nodes. This
is much closer to upstream notation. Adapt the driver to make use of it.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19986
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Until now the mdio bus is a subnode of the ethernet device. This
coupling is different from upstream and wrong. Ethernet and mdio
are different devices. Additionally differentiate between mdio
controller and mdio bus. To make it clear:
- There is one mdio controller
- With up to 4 busses (on RTL93xx)
Prepare new mdio controller and bus nodes with SoC specific compatibles.
These will be used later when refactoring the mdio driver probing.
Remark! For now only define the first bus for the RTL93xx targets.
So the driver still relies on "rtl9300,smi-address = <x y>;". It will
need much more refactoring to get totally aligned with upstream.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19986
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
While converting the RTL931x SerDes code to the new frontend
access methods, the target specific workarounds where left in
place. The old functions were kept and the phy/sds mapping
was unchanged too. It is time to clean this up
- drop the old functions
- reuse the existing read/write logic
- harden the new functions
For now keep the function naming rtmdio_...__new() as is. This
will be changed in a future commit.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19973
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
A lot of definitions in the global mach include have been taken over
to the individual drivers. Only a few of the definitions are really
used nowadays. Remove all the unneeded lines.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19995
Signed-off-by: Robert Marko <robimarko@gmail.com>
So much code was distributed between phy/ethernet/dsa drivers. A lot
was already cleand up before. With this step the mdio bus gets its
own space and is no longer hidden inside the ethernet driver.
This commit is mostly a copy/paste that includes only minor changes.
- define prefixes are renamed to RTMDIO
- The driver is totally self contained (does not rely on SoC include)
- The DTS structure (mdio node below ethernet node) was kept
- The driver is added to the kernel config of all subtargets.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19942
Signed-off-by: Robert Marko <robimarko@gmail.com>
The ethernet and mdio code will be splitted. The dsa driver depends
on proper loading of both, before switch setup can start. Sadly there
are severe cleanup issues in the probe() function if one of the
required devices is not available.
As a temporary workaround provide a dedicated check function that
verifies if the ethernet platform device driver is loaded and can
be used.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19942
Signed-off-by: Robert Marko <robimarko@gmail.com>
At the end of RX NAPI polling the counter and mask registers are
cleaned up. Although this might run in parallel there is no
synchronization and the register modifications are some wild mix.
RTL83xx enables only the interrupt of a single ring while RTL93xx
just reactivates all interrupts (even for other NAPI threads).
Make use of the driver lock and only modify the interrupt bits that
the current thread owns.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19960
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that the counter registers work fine there is no need to
free buffers in software. Hardware will automatically block
input processing when software processing is too slow.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19960
Signed-off-by: Robert Marko <robimarko@gmail.com>
The receive path of the RTL93xx SoCs is currently discarding packets
in software. Analysis gives the following explanation:
- RX ring size registers are setup with the full software ring size
- When packets are received the packet counter registers are increased
- After RX processing the counter registers are changed the wrong way
- From then SOC is allowed to receive more packets than software allows
- Overflow interrupts are fired
- As a reaction to that the software drops packets
Change the processing as follows:
- Setup ring size registers with a headroom of 2 buffers
- Decrease the counter registers with the real work done
With this change no more overflow interrupts occur because the SoC
disables the queues before they can overflow or hit a buffer that is
still owned by the CPU.
Benchmark from single stream iperf3 run, with server process running
on ZyXEL XGS1210 (RTL930x).
iperf3 run before
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.2.86, port 54412
[ 5] local 192.168.2.71 port 5201 connected to 192.168.2.86 port 54418
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 384 KBytes 3.14 Mbits/sec
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 3.00-4.01 sec 5.12 MBytes 42.8 Mbits/sec
[ 5] 4.01-5.00 sec 11.4 MBytes 95.8 Mbits/sec
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec
iperf3 run after
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.2.86, port 55228
[ 5] local 192.168.2.71 port 5201 connected to 192.168.2.86 port 55232
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 22.8 MBytes 191 Mbits/sec
[ 5] 1.00-2.01 sec 25.4 MBytes 211 Mbits/sec
[ 5] 2.01-3.00 sec 25.4 MBytes 215 Mbits/sec
[ 5] 3.00-4.01 sec 26.5 MBytes 220 Mbits/sec
[ 5] 4.01-5.00 sec 26.2 MBytes 222 Mbits/sec
[ 5] 5.00-6.00 sec 26.9 MBytes 225 Mbits/sec
[ 5] 6.00-7.00 sec 27.0 MBytes 226 Mbits/sec
[ 5] 7.00-8.01 sec 26.9 MBytes 224 Mbits/sec
[ 5] 8.01-9.00 sec 26.5 MBytes 223 Mbits/sec
[ 5] 9.00-10.00 sec 26.8 MBytes 225 Mbits/sec
[ 5] 10.00-10.02 sec 640 KBytes 224 Mbits/sec
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19960
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport quirks for two SFP+ modules. Both support the RollBall protocol.
The fix for the FLYPRO module is queued in net-next tree.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/19949
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
These patches hacked the set_eee() and get_eee() functions into
the phy_driver. Drop them with no consumer left.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Since we are using upstream PHY drivers there is no more need
for the downstream version. Side effect is that the SoC dependent
polling functions are no longer needed. This was always wrong
in this driver.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
A new version of the ZyXEL XGS1210-12 has been discovered in
the wild. It includes at least two known hardware changes
- lan9/lan10 use RTL8221B instead of RTL8226
- lan9/lan10 use different SMI busses
Pave the new device the way by splitting the existing DTS.
According to the vendor website the models are named
- A1 (first version): not explicetly labeled
- B1 (second version): Label Rev. B1 on device
Rename the current OpenWrt device definition to A1 as it was
made for the first version. To stay compatible with older
installations, add the old device name to the list of
supported devices.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19908
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The rt-loader currently only supports booting piggy backed lzma
compressed kernels. This requires a data layout where the kernel
directly follows the loader. That might not be sufficient for
more complex flash layouts.
Especially bootbase devices (like ZyXEL GS1920) will need some
kind of chain loading that needs to be explored yet.
Enhance the rt-loader as follows:
- Allow to build as standalone version
- In this case a flash start address is given
- During boot loader will search the ROM starting from that address
- If it finds a uImage this will be loaded into RAM
- Afterwards it will be decompressed to its load address
- While we are here add uncompressed uImage support
As always the implementation tries to be as simple as possible.
- uImage detection works without magics
- uImage will be loaded to highest possible memory address
- Documentation in Makefile has been adapted accordingly
Funny side fact: A standalone rt-loader can chain load a piggy
backed rt-loader from flash.
During bootup loader will show
rt-loader
Running on RTL8380M (chip id 6275C) with 256MB
Relocate 15760 bytes from 0x82000000 to 0x8ffa0000
Searching for uImage starting at 0xb45a0000 ...
uImage 'MIPS OpenWrt Linux-6.12.40' found at 0xb45a0000 with load address 0x80100000
Copy 2923034 bytes of image data to 0x8fcd61e6 ...
Extract image with 2923034 bytes from 0x8fcd61e6 to 0x80100000 ...
Final kernel size is 2923034 bytes
Booting kernel from 0x80100000 ...
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19832
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Provide a crc32 function (will be needed later). Do some
minor naming and coding cleanups
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19832
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Registers must not be accessed in parallel by multiple drivers.
Read-modify-write operations are not atomic, and the result of parallel
access is undefined.
The MAC_L2_GLOBAL_CTRL2 register is essentially a pin configuration
register and is represented by a pinmux node in the devicetree. Operations
on this register by the realtek,rtl838x-eth driver must therefore also be
reflected in the devicetree.
Since the MDIO sets used are board-specific, the pins must be enabled in
the board’s devicetree. This can be achieved using the pinctrl properties
for the realtek,rtl83xx-switch.
&switch0 {
pinctrl-names = "default";
pinctrl-0 = <&pinmux_enable_mdc_mdio_0>,
<&pinmux_enable_mdc_mdio_1>;
....
};
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/19815
Signed-off-by: Robert Marko <robimarko@gmail.com>
The pinmux-related registers on the RTL931X SoC family are spread across
various non-consecutive registers. It might be tempting to modify them
directly in a specific driver (SPI, LED, etc.), but this would cause issues
with parallel, non-locked read-modify-write operations, which are required
to update individual portions of these registers.
Instead, it is better to use the devicetree pinctrl properties to define
the correct configurations for the various operation modes.
One important setting here is the LED Sync bit. This allows the LED
controller to generate an additional positive edge on the `STCP`
("STore Clock Pin", also known as `RCLK`) of the LED shift register after
the actual content has already been shifted in using the normal shift
clock. The LED shift register is then expected to copy the content from the
shift register section into the storage registers, which act as the actual
LED output control. This functionality is available in, and commonly used
with, the SNx4HC595 family of shift registers.
To activate it, simply register it in the default state of the
"realtek,rtl83xx-switch" node:
&switch0 {
pinctrl-names = "default";
pinctrl-0 = <&pinmux_enable_led_sync>;
....
};
It would be nicer when this can be directly added to the led subnode. But
for this to work, `realtek,rtl9300-leds` must first be an actual driver
(known to the driver core).
[1] https://www.ti.com/lit/ds/symlink/sn74hc595.pdf
Suggested-by: Bevan Weiss <bevan.weiss@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/19815
Signed-off-by: Robert Marko <robimarko@gmail.com>
The MAC_L2_GLOBAL_CTRL2 register is primarily used for pin configuration.
It is necessary to select specific modes for pins or to free them for use
as GPIOs.
Fixes: 9dbc04785c ("realtek: add rtl8231-aux to rtl931x.dtsi")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/19815
Signed-off-by: Robert Marko <robimarko@gmail.com>
The pinmux-related registers on the RTL930X SoC family are spread across
various non-consecutive registers. It might be tempting to modify them
directly in a specific driver (SPI, LED, etc.), but this would cause issues
with parallel, non-locked read-modify-write operations, which are required
to update individual portions of these registers.
Instead, it is better to use the devicetree pinctrl properties to define
the correct configurations for the various operation modes.
One important setting here is the LED Sync bit. This allows the LED
controller to generate an additional positive edge on the `STCP`
("STore Clock Pin", also known as `RCLK`) of the LED shift register after
the actual content has already been shifted in using the normal shift
clock. The LED shift register is then expected to copy the content from the
shift register section into the storage registers, which act as the actual
LED output control. This functionality is available in, and commonly used
with, the SNx4HC595 family of shift registers.
To activate it, simply register it in the default state of the
"realtek,rtl83xx-switch" node:
&switch0 {
pinctrl-names = "default";
pinctrl-0 = <&pinmux_enable_led_sync>;
....
};
It would be nicer when this can be directly added to the led subnode. But
for this to work, `realtek,rtl9300-leds` must first be an actual driver
(known to the driver core).
[1] https://www.ti.com/lit/ds/symlink/sn74hc595.pdf
Suggested-by: Bevan Weiss <bevan.weiss@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/19815
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport support for Aeonsemi AS121xxx PHY. The PHY require dedicated
firmware to be loaded to correctly work and support a big family of
Aeonsemi PHY that provide from 1G to 10G speed.
Automatically refresh all affected patch and file (rtl PHY).
Link: https://github.com/openwrt/openwrt/pull/19816
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Fix the model name in DTS compatible, Makefiles and board scripts by
using dash instead of comma or underscore. This aligns it with other
examples in OpenWrt and makes in consistent in all places where the
board model is used.
'tplink,tl-st1008f,v2' --> 'tplink,tl-st1008f-v2'
'tplink,tl-st1008f_v2' --> 'tplink,tl-st1008f-v2'
Fixes: 39b9b491bb ("realtek: add support for TP-Link TL-ST1008F v2.0")
Fixes: #19930
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19934
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently the calculation for the CMU (even) SerDes works similar
to this pseudo code.
analog_backend_serdes = get_analog_serdes(frontend_serdes);
even_backend_serdes = analog_backend_serdes & ~1;
write_to(even_backend_serdes);
Because of the SerDes layout and frontend/backend mapping this can
be swapped to the following order with the same resulting Serdes.
even_frontend_serdes = frontend_serdes ~1;
analog_backend_serdes = get_analog_serdes(even_frontend_serdes);
write_to(analog_backed_serdes);
In the later example the frontend/backend mapping code is already
in our new functions. So swap the calculation logic and use the
new access functions. This allows to finally drop the old access
functions without mapping.
From now on all RTL931x SerDes functions will use a consistent
frontend view.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19873
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The RTL931x has 14 frontend and at least 26 backend serdes. Currently
the programming functions always need to determine the right backend
serdes from the given frontend serdes on their own. We plan to provide
a consistent serdes mapping to all callers.
As the third step make use of these new functions whenever we want to
access the "digital 2" pages. The pages are mapped starting at 0x200.
So the function conversion is as simple as this:
Old:
dsds = (sds - 1) * 2;
rtmdio_931x_read_sds_phy(dsds + 1, page, ...)
New:
rtmdio_931x_read_sds_phy_new(sds, page + 0x200, ...)
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19873
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The more we step down into the SerDes deeps the more confusing it
gets. Nevertheless it is not to late to fix a wrong assumption.
Until now it seemed as if the frontend/backend SerDes mapping is
totally without intersection. This is not true.
The backend SerDes mapping is also dependent on the mode. Especially
the proprietary Realtek XSGMII mode stands out from all other
mappings. So fix the descriptions and the calculation of the third
page package (digital 2 aka XSGMII 2).
As it was not yet used it had no impact.
Fixes: a4cbb44c1b ("realtek: convert access to RTL931x analog serdes pages")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19873
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The RTL931x has 14 frontend and at least 26 backend serdes. Currently
the programming functions always need to determine the right backend
serdes from the given frontend serdes on their own. We plan to provide
a consistent serdes mapping to all callers.
As the second step make use of these new functions whenever we
want to access the digital 1 pages. The pages are mapped starting
at 0x100. So the function conversion is as simple as this:
Old:
dsds = (sds - 1) * 2;
rtmdio_931x_read_sds_phy(dsds, page, ...)
New:
rtmdio_931x_read_sds_phy_new(sds, page + 0x100, ...)
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19873
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
For some reason 3 of the 4 mdio access functions contain an
artifical delay of 10ms. While it might have been part of
older Realtek SDKs it can no longer be found in current ones.
Remove the delays.
While we are here remove the pre-access bus ready checks.
It is sufficient to run them after the command start. If
anything fails the caller will get an error. This is the
same behaviour as for the other targets.
Finally cleanup the error handling. Something like this makes
no sense at all.
err = rtmdio_838x_smi_wait_op(100000);
if (err)
goto errout;
err = 0;
errout:
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19901
Signed-off-by: Robert Marko <robimarko@gmail.com>
Prepare the SerDes patch function to allow different patch sequences
depending on the phy mode. Patches are required to allow devices with a
lightweight bootloader (one that doesn't have a "rtk network init"
command) to use the serdes. Some modes required a different patch
sequence than the one currently used.
Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19834
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
We reached the point of no return. Upstream has gained the final
bits for the RTL8226 PHYs. That means.
- RTL8226 MAC side behaves like RTL8221(B)
- It's serdes no longer uses proprietary HSGMII (2.5G SGMII)
- Instead it dynamically switches between SGMII and 2500base-x
This (partly) solves one of the central henn/egg problems of the
Realtek target. To change the MAC/PHY interface mode both sides
need to have all bits in place to do so. But where to start if
so much needs to be done?
Now the PHY side has created facts and it mitigates a lot of
problems. All downstream HSGMII patches and coding can be dropped
in the future.
For now only adapt the only DTS that still maps PHYs to HSGMII.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19843
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The patching sequence of the RTL8214x/8218x is very similar.
Especially the preparation for readiness is always the same.
Provide a common helper to improve readability.
While we are here clean up the changed functions
- Sort variable definitions according to upstream
- simplify some messages
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19810
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Our phy driver can handle some multiport phys (e.g. RTL8218B
or RTL8214FC). To access arbitrary ports some package access
functions have been defined. These were implemented in the
mdio bus with poor knowledge about the phy/mdio dependencies.
So they add unneeded complexity to the bus and the phy driver
must access these external functions directly.
Provide a new helper get_package_phy() that can derive any
phy device in a package from a given phy of that package.
Make use of this local helper and cut the mdio dependency.
While we refactor several firmware patching functions rename
the loop variables to "port" to better indicate what we are
working on.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19810
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Now that we have a get_base_phy() function a lot code of the RTL8214FC
handling can be cleaned up. To name a few:
- use phy_read/phy_write instead of mdiobus functions or the even worse
phy_package_..._paged() helpers
- replace messages with phydev_info()
- remove if/else statements around copper/fibre handling
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19810
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently phy packages (like RTL8214x/RTL8218x) are patched and
initialized as soon as the first phy of the package is found.
In this situation the shared structure is not finalized because
devm_phy_package_join() has only been called for the first phy.
This is no issue as the patching directly hammers the bus addresses
for the follow-up phys.
In the future we want to simplify the package handling and allow
to access all phy_device structures from only one phy_device of
the package. With this we can use normal phy_read/phy_write.
Switch the probing logic to "late patching". With this we will
initialize the firmware of the package when the last phy of the
package has been found and thus the shared structure is complete.
Provide get_base_phy() as the first package helper that allows
to determine the first phy of the package from any other phy.
While we are here drop the shared structure that only repeats the
phy name and has no other use.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19810
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Plasma Cloud PSX10 Switch is a 8 + 2 port multi-GBit switch with
8x 10/100/1000/2500BaseT Ethernet ports and 2x SFP+ module slot.
Hardware:
- RTL9302C SoC
- Macronix MX25L25645G (32MB flash)
- Winbond W632GU6NB-12 (256MB DDR3 SDRAM - only 128 MB configured*)
- 2x RTL8224 4x 10m/100m/1/2.5 Gigabit PHY
- SFP+ 2x 10GBit slot
- IC+ IP8008 POE+ PSE controller
The switch is powered by 54 Volts 2.77A barrel connector. The internal TTL
serial connector can be used to access the terminal. Pins from 1: TX RX
(unused) GND. Serial connection is via 115200 baud, 8N1.
A reset button is accessible through a hole in the front panel.
*) Only 128 MB of RAM are currently configured because there were
infrequent random memory corruptions detected when using memtester with a
256 MB DT configuration. This could also be reproduced with RTLSDK.
Installation
------------
* The device can be flashed by using sysupgrade command. Either from the
original vendor firmware or using an initramfs (see "Debug")
* Connect serial as per the layout above. Connection parameters: 115200 8N1
* The image must be copied using scp to /tmp of the device
scp openwrt-realtek-rtl930x-plasmacloud_psx10-squashfs-sysupgrade.bin root@[IP address of the device]:/tmp/
* start sysupgrade without saving the original vendor configuration
sysupgrade -n /tmp/openwrt-realtek-rtl930x-plasmacloud_psx10-squashfs-sysupgrade.bin
Installation via u-boot
-----------------------
If you have an TFTP server connected to the switch, it is possible to
directly install the device using the factory image from u-boot
# setup networking and IP of TFP server
rtk network on
setenv ipaddr 10.100.100.99
setenv serverip 10.100.100.20
# get factory image
tftp 0x84000000 factory.bin
# erase firmware partitions
sf probe 0
sf erase 0x100000 0x01f00000
# write firmware to both partitions
sf write ${fileaddr} 0x100000 ${filesize}
sf write ${fileaddr} 0x1080000 ${filesize}
# adjust the boot commands
setenv bootargs "mtdparts=spi0.0:896k(u-boot),64k(u-boot-env),64k(u-boot-env2),15872k(inactive),15872k(firmware2)"
setenv bootcmd "rtk init; bootm 0xb5080000"
# restart
reset
Debug
-----
* Connect serial as per the layout above. Connection parameters: 115200 8N1.
* A tftp server is required, tftpd-hpa works well.
* Power the device, at U-Boot start rapidly hit Esc key to stop autoboot
* Enable network:
rtk network on
* Change ip address of device:
setenv ipaddr 192.168.1.6
* Download initramfs from TFTP server:
tftpboot 0x84000000 192.168.1.111:openwrt-realtek-rtl930x-plasmacloud_psx10-initramfs-kernel.bin
* Boot loaded file:
bootm 0x84000000
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19362
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Plasma Cloud PSX8 Switch is a 8 port multi-GBit switch with
8x 10/100/1000/2500BaseT Ethernet ports.
Hardware:
- RTL9302C SoC
- Macronix MX25L25645G (32MB flash)
- Winbond W632GU6NB-12 (256MB DDR3 SDRAM - only 128 MB configured*)
- 2x RTL8224 4x 10m/100m/1/2.5 Gigabit PHY
- IC+ IP8008 POE+ PSE controller
The switch is powered by 54 Volts 2.77A barrel connector. The internal TTL
serial connector can be used to access the terminal. Pins from 1: TX RX
(unused) GND. Serial connection is via 115200 baud, 8N1.
A reset button is accessible through a hole in the front panel.
*) Only 128 MB of RAM are currently configured because there were
infrequent random memory corruptions detected when using memtester with a
256 MB DT configuration. This could also be reproduced with RTLSDK.
Installation
------------
* The device can be flashed by using sysupgrade command. Either from the
original vendor firmware or using an initramfs (see "Debug")
* Connect serial as per the layout above. Connection parameters: 115200 8N1
* The image must be copied using scp to /tmp of the device
scp openwrt-realtek-rtl930x-plasmacloud_psx8-squashfs-sysupgrade.bin root@[IP address of the device]:/tmp/
* start sysupgrade without saving the original vendor configuration
sysupgrade -n /tmp/openwrt-realtek-rtl930x-plasmacloud_psx8-squashfs-sysupgrade.bin
Installation via u-boot
-----------------------
If you have an TFTP server connected to the switch, it is possible to
directly install the device using the factory image from u-boot
# setup networking and IP of TFP server
rtk network on
setenv ipaddr 10.100.100.99
setenv serverip 10.100.100.20
# get factory image
tftp 0x84000000 factory.bin
# erase firmware partitions
sf probe 0
sf erase 0x100000 0x01f00000
# write firmware to both partitions
sf write ${fileaddr} 0x100000 ${filesize}
sf write ${fileaddr} 0x1080000 ${filesize}
# adjust the boot commands
setenv bootargs "mtdparts=spi0.0:896k(u-boot),64k(u-boot-env),64k(u-boot-env2),15872k(inactive),15872k(firmware2)"
setenv bootcmd "rtk init; bootm 0xb5080000"
# restart
reset
Debug
-----
* Connect serial as per the layout above. Connection parameters: 115200 8N1.
* A tftp server is required, tftpd-hpa works well.
* Power the device, at U-Boot start rapidly hit Esc key to stop autoboot
* Enable network:
rtk network on
* Change ip address of device:
setenv ipaddr 192.168.1.6
* Download initramfs from TFTP server:
tftpboot 0x84000000 192.168.1.111:openwrt-realtek-rtl930x-plasmacloud_psx8-initramfs-kernel.bin
* Boot loaded file:
bootm 0x84000000
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19362
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Plasma Cloud devices use a dual-firmware regions/slots boot mechanism. On
APs, the u-boot is "intelligent" and checks the NOR/NAND partitions (kernel
+ rootfs) for corruption via "datachk". If validation fails, the bootloader
automatically switches to the fallback partition.
On Realtek-based switches, this "datachk" helper is not available.
However, the bootloader still supports two firmware regions/slots.
When flashing a new image, the "inactive" partition is written instead of
overwriting the active one. If no "inactive" partition exists but
"firmware1" is present, the bootloader always treats "firmware1" as
fallback. Only after a successful flash is the `u-boot-env` updated to
select the newly written partition.
On reboot, the bootloader loads the kernel from the new partition and
passes `mtdparts` information as the kernel cmdline. The Plasma Cloud
switch device tree does not override this with a `bootargs` property, so
the active partition layout is honored from cmdline.
Since offsets, sizes, and names of partitions match between the device tree
and cmdline (except the inactive slot), properties and nodes such as
`nvmem-cells` or `compatible` remain fully usable.
This mechanism also allows switching back to the old firmware slot. For
example, if `firmware1` is currently active (`/proc/mtd` shows it), it can
be switched to slot 2 using:
. /lib/upgrade/upgrade_dualboot.sh
set_boot_part 2
reboot
Firmware upgrades use standard `sysupgrade` tarballs, chosen for
compatibility with vendor images. In theory, one can switch between vendor
and OpenWrt with:
sysupgrade -n /tmp/*-squashfs-sysupgrade.bin
Note: configuration files must not be preserved, as they are not compatible
with vanilla OpenWrt.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19362
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
To be able to read out the ethaddr from the u-boot environment for MAC
address configuration, it is required to also enable the NVMEM layout
parsing code for the U-Boot env layout.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19362
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The function of_get_mac_address is not taking care of evaluation the nvmem
address before trying to read out the mac-address properties. The driver
must check whether the return code is -EPROBE_DEFER and stop the probing
process in that case. If the nvmem-cell related driver code finished, the
probe can be redone ad the correct mac-address will appear for the device.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19362
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
LLDP packets must be transmitted on a single port and trapped on a port of
a device which understands LLDP. It must not forward it to other ports to
avoid confusing neighbor information on connected devices.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19571
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Driver needs to configure management frame actions
To support LLDP, EAPOL or MSTP, which needs to be trapped to the CPU
instead of being forwarded.
The function to implement the various management frame actions was already
present but not yet registered correctly.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19571
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Driver needs to configure management frame actions
To support LLDP, EAPOL or MSTP, which needs to be trapped to the CPU
instead of being forwarded
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19571
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The functions to enable trapping of management frames are not RTL83xx
specific. It is more appropriate to use the more generic "rtldsa" prefix
for them.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19571
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The RTL931x has 14 frontend and at least 26 backend serdes. Currently
the programming functions always need to determine the right backend
serdes from the given frontend serdes on their own.
We plan to provide a consistent serdes mapping to all callers as follows
Frontend SerDes | 0 1 2 3 4 5 6 7 8 9 10 11 12 13
-----------------+------------------------------------------
Backend SerDes 1 | 0 1 2 3 6 7 10 11 14 15 18 19 22 23
Backend SerDes 2 | 0 1 2 4 6 8 10 12 14 16 18 20 22 24
Backend SerDes 3 | 0 1 2 5 6 9 10 13 14 17 18 21 22 25
frontend page "even" frontend SerDes "odd" frontend SerDes
page 0x000-0x03f (analog): page 0x000-0x03f back SDS page 0x000-0x03f back SDS
page 0x100-0x13f (XSGMII1): page 0x000-0x03f back SDS page 0x000-0x03f back SDS+1
page 0x200-0x23f (XSGMII2): page 0x000-0x03f back SDS page 0x000-0x03f back SDS+2
As a first micro step provide some helpers that simply operate on
frontend serdes and will determine the backend serdes on their own.
So rtmdio_931x_read_sds_phy() and rtmdio_931x_write_sds_phy() operate
on backend serdes. While rtmdio_931x_read_sds_phy_**new**() and
rtmdio_931x_write_sds_phy_**new**() operate on frontend serdes.
This is only an intermediate naming convention and will be cleanup
afterwards.
In a first step make use of these new functions whenever we
want to access the analog page. As the pages stay unchanged
in the new functions conversion is as simple as this:
Old:
asds = rtl931x_get_analog_sds(...)
rtmdio_931x_read_sds_phy(asds, ...)
New:
rtmdio_931x_read_sds_phy_new(sds, ...)
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19818
Signed-off-by: Robert Marko <robimarko@gmail.com>
When testing LLDP and STP, we observed that locally generated multicast
packets (e.g. LLDP, STP) were not restricted to the designated output
port(s). For example, when transmitting on `lan1`, the same packet was also
forwarded to other ports such as `lan2`.
Steps to reproduce:
1. Configure lldpd to use `lan1` in UCI and restart the service
2. Connect devices to `lan1` and `lan2`
3. Observe that the device on `lan2` still receives LLDP packets
The issue was caused by an incorrect `FWD_TYPE` setting in the TX CPU TAG,
which failed to enforce the selected egress port(s).
Fix this by updating the TX CPU TAG to set `FWD_TYPE` correctly, ensuring
that locally generated packets are transmitted only on the intended
port(s).
Signed-off-by: Issam Hamdi <ih@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19802
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
XikeStor (Seeker) SKS8310-8X is a 8 ports Multi-Gig switch, based on
RTL9303.
Specifications:
- SoC : Realtek RTL9303
- RAM : DDR3 512 MiB
- Flash : SPI-NOR 32 MiB (Macronix)
- Ethernet : 8x 1/2.5/10 Gbps (SFP+)
- LEDs/Keys (GPIO) : 1x/1x
- UART : "Console" port on the front panel
- type : RS-232C
- connector : RJ-45
- settings : 115200 8N1
- Power : 12 VDC, 2 A
Flash instruction using initramfs image:
1. Prepare TFTP server & connect to serial port.
2. Connect your computer to one of the ports on SKS8310-8X with a
suitable SFP module (some work, some don't).
3. Power on SKS8310-8X and interrupt autoboot with Shift + A.
4. Use Shift + Q to drop from vendor CLI to U-Boot CLI.
5. Enable networking within U-Boot.
> rtk network on
6. Set switch IP and TFTP server IP (optional, adjust to your setup).
> setenv ipaddr <ip>
> setenv serverip <ip>
7. Download initramfs image from TFTP server.
> tftpboot 0x82000000 <image name>
8. Boot with the downloaded image.
> bootm 0x82000000
9. With rambooted OpenWrt, backup the stock firmware if needed.
10. Copy sysupgrade image to the device.
11. Perform sysupgrade with the sysupgrade image.
12. After reboot, you should have functional OpenWrt.
Reverting to stock firmware:
1. Download latest firmware from XikeStor and upload to your device.
1. Write firmware with 'sysupgrade -F'.
2. After reboot, stock firmware should boot automatically.
Co-authored-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Alexandra Alth <alexandra@alth.de>
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19782
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Whilst testing Hasivo s1100wp-8gt-se LED configuration, several error
messages were presented which didn't indicate which led_set they were
referencing, nor what the value was that caused the invalid configuration.
Migrate to use dev_ print messages for this function.
And tidy up both when the error message is reported (don't show it when
an led_set isn't in the DTS) and what details the message presents.
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19791
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add defines for RTL930x and RTL931x led_set 'modes' (to avoid magic numbers
in dts files).
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19791
Signed-off-by: Robert Marko <robimarko@gmail.com>
This commit repeats the mdio function relocation from the other targets.
In short that means:
- phy read/write functions are moved away from the phy driver
- SerDes read/write functions are moved away from the dsa driver
- All gets consolidated into the mdio driver (inside the ethernet driver)
This is mostly a copy/paste to keep the changes small. The SerDes phy mapping
and the simplification of the central bus functions will come later.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19743
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that the driver has been enhanced for RTL931x devices and
the DTS is up to date, activate the needed kernel configuration
for the two RTL931x subtargets.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19776
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The RTL8231 auxiliary controller is not defined in the rtl931x.dtsi.
Additionally the pinmux is configured at the wrong address. Fix
this.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19776
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The auxiliary RTL8231 controller driver is missing RTL931x support.
Add it by defining the proper register and matching compatible.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19776
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Realtek DTS's use several macros for convenient phy/port definition.
These are repeated for the RTL83xx targets and most are missing for the
RTL93xx targets. In the near future we want to add high port count
switches with 1GBit Ethernet for them too. As a preparation provide a
central include so the definition is only needed once and is available
for all targets.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19772
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
We are using upstream otto timer. Delete some downstream leftovers.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19769
Signed-off-by: Robert Marko <robimarko@gmail.com>
Drop our downstream driver in favor of an upstream existing driver which
is available starting from v6.13.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19736
Signed-off-by: Robert Marko <robimarko@gmail.com>
Adapt the device tree definitions of rtl93xx devices and the base dtsi
for rtl930x and rtl931x to match with what's expected by the recently
backported RTL9300 I2C driver.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19736
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport/add all patches for the upstream RTL9300 I2C driver.
The upstream driver was added in 6.13 and was heavily based on our
downstream driver except for how the multiplexing behaviour is handled.
This driver was working fine with basic SFP operation on RTL930x devices
but there was no support for RTL931x though.
Major advantage over our downstream driver is: The multiplexing
behaviour is handled completely by the driver. Thus, there's no need for
a separate rtl9300-mux driver as we had it downstream. Moreover, this
simplifies the DTS of affected devices a lot since we can now move the
controller definition - which is in the DTS of each device so far - to
the base DTSI.
Currently pending patches are also included because the progress on
getting this upstream seems really slow right now, albeit upstream
maintainers may require several changes to the current state.
These include:
- patches fixing several issues in the driver
- patches doing a refactoring of the driver and adding support for RTL931x
See the commit messages included in each patch to have details on the
changes.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19736
Signed-off-by: Robert Marko <robimarko@gmail.com>
