While checking setup routines for stability and completeness,
random RTL838x SoC I/O areas were intentionally overwritten.
As soon as L2_CTRL_1->FAST_AGE_OUT is set to 1, the system
stalls during bootup. Analysis shows that it loops endlessly
in rtl838x_hw_stop()
/* Flush L2 address cache */
if (priv->family_id == RTL8380_FAMILY_ID) {
for (int i = 0; i <= priv->cpu_port; i++) {
sw_w32(1 << 26 | 1 << 23 | i << 5, priv->r->l2_tbl_flush_ctrl);
do { } while (sw_r32(priv->r->l2_tbl_flush_ctrl) & (1 << 26));
}
This is exactly the same logic as in the vendor GPL. There
are no hints about possible timeouts or issues. The reason is
still unclear. Nevertheless harden the function for further fuzzy
tests. Do this by resetting the configuration value to its SoC
default.
Additionally convert some shifts to BIT() for better readability.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19679
Signed-off-by: Robert Marko <robimarko@gmail.com>
The bootloader on these devices uses 0x81000000 as load address for the
compressed image. Since the kernel uses a load address 0x80100000, this
only leaves a space of 15 MiB for the uncompressed image. For larger
images, the compressed data starts to get overwritten, and at some point
the boot will fail:
## Booting image from partition ... 0
## Booting kernel from Legacy Image at 81000000 ...
Version: 9.9.9.9
Created: 2025-08-07 14:56:09 UTC
Data Size: 6756645 Bytes = 6.4 MB
Checksum ... OK
Uncompressing ... LZMA: uncompress or overwrite error 1 - must RESET board to recover
Currently, initramfs images with default config are already over the
limit. And while they still happen to work regardless, adding additional
packages easily pushes the size so much that the boot fails.
Fix this by switching to rt-loader (which relocates the data to the
upper end of the RAM before decompression). The switch includes regular
kernel images to avoid this becoming an issue again in the future.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19734
Signed-off-by: Robert Marko <robimarko@gmail.com>
Once tested this will go upstream.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19468
Signed-off-by: Robert Marko <robimarko@gmail.com>
Previous implementation was directly copied from rtl930x and was not
working. Table field offsets are different between rlt931x and rtl930x
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19580
Signed-off-by: Robert Marko <robimarko@gmail.com>
The .rma_bpdu_fld_pmask is not used anywhere in the code for RTL930x nor
RTL931x. But the RTL930x was still initializing this member. To avoid
problems in the future, simply initialize it also on RTL931x.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19569
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Neither the RTL930x not the RT931x use the BPDU flooding mechanism which
was used for other SoCs. At the same time, the RTL931x must use the same
debugfs initialization function as RTL930x.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19569
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The RTL930x mdio functions are scattered around the code. Relocate
them to the bus (still inside the ethernet driver). With this change
the phy identification looks into the proper registers. The SerDes
phy identifier (register 2/3) must be changed.
Additionally provide a consistent SerDes register access through the
mdio bus. Until now when a SerDes directly drives a SFP module there
is no clear rule of how to handle its register set that consists of
two parts:
- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after
The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.
Adapt the bus to the new consistent phy interface that mixes the
SerDes register set like classic Realtek phys do it.
- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
registers 16-23 according to the page select register (31).
That gives a register mapping as follows:
+-----------------------+-----------------------+---------------+-------------+
| reg 0x00-0x0f | reg 0x10-0x17 | reg 0x18-0x1e | reg 0x1f |
+-----------------------+-----------------------+---------------+-------------+
| SerDes fiber page (3) | real SerDes registers | zero | SerDes page |
| registers 0 - 15 | in packages of 8 | | select reg |
+-----------------------+-----------------------+---------------+-------------+
Example to make it as clear as possible.
SerDes registers on a RTL930x show
Page / Reg | 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B ...
-------------+----------------------------------------------------------------
0 - SDS | 0C03 0F00 7060 7106 074D 0EBF 0F0F 0359 5248 0000 0F80 0000 ...
1 - SDS_EXT | 0000 0000 85FA 8C6D 5CCC 0000 20D8 0003 79AA 8C64 00C3 1482 ...
2 - FIB | 1140 6189 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...
3 - FIB_EXT | 1140 6109 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...
This translates to this phy layout
| SerDes fiber registers normal SerDes registers zero p.sel
Page / Reg | 0x00 0x01 0x02 0x03 ... 0x10 0x11 0x12 0x13 ... 0x18 ... 0x1f
-------------+---------------------------------------------------------------
0 | 1140 6189 001C CA40 ... 0C03 0F00 7060 7106 ... 0000 ... 0000
1 | 1140 6189 001C CA40 ... 5248 0000 0F80 0000 ... 0000 ... 0001
...
4 | 1140 6189 001C CA40 ... 0000 0000 85FA 8C6D ... 0000 ... 0004
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19692
Signed-off-by: Robert Marko <robimarko@gmail.com>
Some known RTL93xx devices like the Linksys LGS328C or LGS352C are
NAND based. These require additional drivers and packages (e.g. UBI).
The current subtargets are already taylored down for devices with
only 16MB flash. Adding features that are not used will only make
the storage situation more complicated.
Add two new subtargets for RTL93xx that include the basic NAND, UBI
and MTD features. To achieve this do the following:
- Create new subtarget folders
- Copy the existing config and makefiles over
- Add the basic additional features
- Mark them as SOURCE-ONLY
- Add empty image makefiles
- Remove unneded NAND/MTD features from existing configs
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19700
Signed-off-by: Robert Marko <robimarko@gmail.com>
These devices need a tiny (<8MB) initramfs. There are first
occurrences where this fails with newer kernels and diagnostic
packages.
Switch the recipe over to use lzma compression and rt-loader.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19687
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The current variables tagged_ports and untagged_ports suggest that
these are distinct and describe only the ports in each of these
configuration types.
That is wrong. The hardware is configured via member ports and
untagged ports. The first one being a superset of the second.
Rename the variables to reflect that.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19684
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Both RTL930x and RTL931x were missing the code to support enabling and
disabling MAC address learning and unknown unicast flooding on a per-port
basis.
* rtl93*x_enable_learning() allows toggling of dynamic MAC learning on
individual ports by modifying the L2 learning constraint control
register.
* rtl93*x_enable_flood() provides the ability to control unknown unicast
flooding behavior, disabling forwarding when set. If it is enabled, it
will just forward it. If it is disabled, packets will simply be dropped.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19581
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
mach-rtl83xx.h contained the required register definitions for older SoC
families but was missing it for RTL930x and RTL931x.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19574
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Each MBR ctrl block has 64 bits to store the 56 possible ports. The offsets
between the groups is therefore also 64 bit.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19574
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The comment incorrectly stated that RTL931X doesn't have smi_poll_ctrl. But
there is actually a register for using it.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19574
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Some of the parameters added to RTL9300_FAMILY_ID are missing for
RTL9310_FAMILY_ID. Simply add the missing ones to keep sharing code between
the two SoCs.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19574
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* In RTL931x, bit 31 of the (4th column) of 802_1Q_VLAN_QINQ table
indicates the validity of l2 tunnel. Before bit 63 (3rd column)
was being checked for validity of l2 tunnel.
* The untagged_ports requires 64 bits to represent 56 ports. Do not
store u64 in u32 variable
* First 24 ports are represented in the 2nd register not just first 20
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19576
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The workqueue items don't need to be processed directly when they are
scheduled. It can happen that they are simply processed at a much later
time. It is therefore necessary to ensure that all workqueue items of a
driver are no longer being processed before the driver (or structures of
this driver) are destroyed.
When skipping this step, the driver driver can cause a kernel Oops on
reboot.
Unfortunately, it is not recommended [1] to flush items out of the system
workqueue - simply because this can cause deadlocks. The driver itself must
have a private workqueue which is then flushed.
[1] https://lkml.kernel.org/r/49925af7-78a8-a3dd-bce6-cfc02e1a9236@I-love.SAKURA.ne.jp
Signed-off-by: Issam Hamdi <ih@simonwunderlich.de>
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19570
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Just like rtl930x, rtl931x also requires two reads to fetch current link
status.
While at it, rename the function to a proper naming scheme.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Co-developed-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19578
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Link status needs to be read twice, and a single register value is
enough for determining link status for all the ports
It is not necessary to go through each potential port separately and later
actually identify for which ports the interrupt actually was. The helper
for_each_set_bit() directly iterate through all set bits.
While at it, rename the function to a proper naming scheme.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19578
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently the SerDes driven SFP ports give strange ethtool readings
on RTL93xx devices. Especially duplex and speed are shown even if
no link is up and running. That leads to confusion because the MAC
reports arbitrary values.
Enhance the readout by refactoring the pcs_get_state() function.
Calculate speed/duplex/pause only if link is detected.
Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19575
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The media_sts register only shows type of link, fiber/copper,
and has nothing to do with the link status
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19575
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
We are slowly getting to the point where the mdio driver will be
carved out from the ethernet driver. Since the beginning it had
the feature to hand out SFP serdes as phys. So one can access
them from the phy driver. This will be kept during the final
migration and it even will provide a consistent interface for the
phy/serdes registers.
With this being done we need to identify how to handle the affected
ports in a generic way for all targets. Doing first things first,
this starts with a consistent DTS. Currently we have:
for RTL838x + Zyxel XGS1210:
phy-mode = "1000base-x"
managed = "in-band-status"
phy-handle = ...
for all other RTL93x devices:
phy-mode = "10gbase-r"
managed = "in-band-status"
pseudo-phy-handle = ...
Looking at the phylink kernel code one can see a nifty detail.
There is dynamic phy bringup depending on the mode.
int phylink_fwnode_phy_connect(struct phylink *pl,
const struct fwnode_handle *fwnode,
u32 flags)
{
struct fwnode_handle *phy_fwnode;
struct phy_device *phy_dev;
int ret;
/* Fixed links and 802.3z are handled without needing a PHY */
if (pl->cfg_link_an_mode == MLO_AN_FIXED ||
(pl->cfg_link_an_mode == MLO_AN_INBAND &&
phy_interface_mode_is_8023z(pl->link_interface)))
return 0;
...
}
Where 802.3z means 1000base-x or 2500base-x. Aligning this with
IEEE specs it means essentially:
- 10gbase-r defined ports with phy-handle must statically bring up
a phylink from the beginning that immediately depends on a
phy read_status() implementation.
- 1000base-x/2500base-x defined ports will dynamically bringup a
phylink during link detection regardless of a phy-handle. So
it usually runs at the moment when a SFP has been plugged in.
We currently still rely on a phy-handle but do not want to bring
up the phy immediately. Commit 4457c1eee4 ("realtek: rtl93xx:
support SFPs with phys") tried to fix exactly that error for
10gbase-r definied ports. Kernel shows "sfp sfp-p8: sfp_add_phy
failed: -EBUSY" in that case.
But it did it in the wrong way. It implemented a workaround by
introducing a DTS property "pseudo-phy-handle". Instead it
should have simply converted the DTS nodes to 1000base-x.
Revert the commit and fix the DTS with wrong definitions. From
now on we have a consistent SFP definition throughout all DTS
and targets.
Aside from the positive effect this setting has it is more or
less an arbitrary speed definition. When plugging in the SFP the
real speed will be choosen dynamically.
Fixes: 4457c1eee4 ("realtek: rtl93xx: support SFPs with phys")
Tested-By: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19648
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The current build recipe creates a lzma based initramfs and
a gzip based sysupgrade (installation) image. No need to
use different compression methods. Use lzma for both.
Tested-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19669
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add SoC revision, CPU part number, and a flag for engineering samples to
the rtl83xx_soc_info structure.
Also extend the system type string to include this information.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19653
Signed-off-by: Robert Marko <robimarko@gmail.com>
Move the definitions to mach-rtl83xx.h, so they can be used during init
to read more detailed SoC information. Also rename the RTL931X register,
as it has the same address on all RTL93xx.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19653
Signed-off-by: Robert Marko <robimarko@gmail.com>
Read model name from the register instead of using hard-coded values.
Also remove detection of the unsupported Realtek ESW/SSW SoCs. The Fast
Ethernet variants of the Maple and Cypress series stay for now, but are
moved to the RTL8380/RTL8390 families.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19653
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the lzma recipe for the device for both initramfs and sysupgrade to
save some flash space due to smaller image. U-Boot build on this device
has native lzma support.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19657
Signed-off-by: Robert Marko <robimarko@gmail.com>
The migration of the RTL930x mdio/serdes access functions over to the
mdio bus is a little more complicated than for RTL83xx. There are several
places where the serdes is accessed directly. So do it in two steps. With
this first step:
- use the rtmdio prefix for the serdes reader/writer functions
- move the functions over to the bus (inside the ethernet driver)
- Adapt all callers.
This is not only a copy/paste but the serdes access will be hardened too.
For this:
- put a mutex around the read/write functions because we have only
indirect register access through a mdio style bus.
- Verify input values to avoid data mess.
Tested-by: Bjørn Mork <bjorn@mork.no>
Tested-by: Jan Hoffmann <jan@3e8.eu>
Tested-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19662
Signed-off-by: Robert Marko <robimarko@gmail.com>
Like RTL839x the RTL930x SoCs have multithreading built in.
Activate it in the kernel configuration.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19624
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL839x mdio functions are scattered around the code. Relocate
them to the bus (still inside the ethernet driver).
Additionally provide a consistent SerDes register access through the
mdio bus. Until now when a SerDes directly drives a SFP module there
is no clear rule of how to handle its register set that consists of
two parts:
- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after
The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.
Adapt the bus to the new consistent phy interface that mixes the
SerDes register set like classic Realtek phys do it.
- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
registers 16-23 according to the page select register (31).
That gives a register mapping as follows:
+-----------------------+-----------------------+---------------+-------------+
| reg 0x00-0x0f | reg 0x10-0x17 | reg 0x18-0x1e | reg 0x1f |
+-----------------------+-----------------------+---------------+-------------+
| SerDes fiber page (3) | real SerDes registers | zero | SerDes page |
| registers 0 - 15 | in packages of 8 | | select reg |
+-----------------------+-----------------------+---------------+-------------+
Example to make it as clear as possible.
SerDes registers on a RTL839x show
Page / Reg | 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B ...
-------------+----------------------------------------------------------------
0 - SDS | 0C03 0F00 7060 7106 074D 0EBF 0F0F 0359 5248 0000 0F80 0000 ...
1 - SDS_EXT | 0000 0000 85FA 8C6D 5CCC 0000 20D8 0003 79AA 8C64 00C3 1482 ...
2 - FIB | 1140 6189 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...
3 - FIB_EXT | 1140 6109 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...
This translates to this phy layout
| SerDes fiber registers normal SerDes registers zero p.sel
Page / Reg | 0x00 0x01 0x02 0x03 ... 0x10 0x11 0x12 0x13 ... 0x18 ... 0x1f
-------------+---------------------------------------------------------------
0 | 1140 6189 001C CA40 ... 0C03 0F00 7060 7106 ... 0000 ... 0000
1 | 1140 6189 001C CA40 ... 5248 0000 0F80 0000 ... 0000 ... 0001
...
4 | 1140 6189 001C CA40 ... 0000 0000 85FA 8C6D ... 0000 ... 0004
...
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19634
Signed-off-by: Robert Marko <robimarko@gmail.com>
* Use SDS for phy 48/49
* Use correct link/phy settings for SFP ports
* Remove read-only flag from u-boot env so fw_setenv actually works
Signed-off-by: Joe Holden <jwh@zorins.us>
Link: https://github.com/openwrt/openwrt/pull/19596
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When a SerDes directly drives a SFP module there is no clear rule of
how to handle its register set that consists of two parts:
- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after
The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.
Provide a consistent phy interface that mixes the SerDes register
set like classic Realtek phys do it.
- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
registers 16-23 according to the page select register (31).
That gives a register mapping as follows:
+-----------------------+-----------------------+---------------+-------------+
| reg 0x00-0x0f | reg 0x10-0x17 | reg 0x18-0x1e | reg 0x1f |
+-----------------------+-----------------------+---------------+-------------+
| SerDes fiber page (3) | real SerDes registers | zero | SerDes page |
| registers 0 - 15 | in packages of 8 | | select reg |
+-----------------------+-----------------------+---------------+-------------+
Example to make it as clear as possible.
SerDes registers on a RTL838x show
Page / Reg | 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B ...
-------------+----------------------------------------------------------------
0 - SDS | 0C03 0F00 7060 7106 074D 0EBF 0F0F 0359 5248 0000 0F80 0000 ...
1 - SDS_EXT | 0000 0000 85FA 8C6D 5CCC 0000 20D8 0003 79AA 8C64 00C3 1482 ...
2 - FIB | 1140 6189 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...
3 - FIB_EXT | 1140 6109 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...
This translates to this phy layout
| SerDes fiber registers normal SerDes registers zero p.sel
Page / Reg | 0x00 0x01 0x02 0x03 ... 0x10 0x11 0x12 0x13 ... 0x18 ... 0x1f
-------------+---------------------------------------------------------------
0 | 1140 6189 001C CA40 ... 0C03 0F00 7060 7106 ... 0000 ... 0000
1 | 1140 6189 001C CA40 ... 5248 0000 0F80 0000 ... 0000 ... 0001
...
4 | 1140 6189 001C CA40 ... 0000 0000 85FA 8C6D ... 0000 ... 0004
For now just do it for RTL838x devices.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19604
Signed-off-by: Robert Marko <robimarko@gmail.com>
The DSA has a link to the MDIO bus and already uses the read/write functions
that are provided. In parallel the dsa_switch_ops structure provides an
interface for phy_read and phy_write. These are still open-coded and sadly
circumvent the bus. Simplify the implementation and avoid inconsistencies by
reusing the existing bus infrastructure.
Additionally, remove two unused MMD header definitions as a quick win.
Reported-by: Jan Hoffmann <jan@3e8.eu>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19548
Signed-off-by: Robert Marko <robimarko@gmail.com>
The function rtl93xx_setup() is called by both RTL930x and RTL931x. But
only the RTL930x specific function to print port matrix was called.
Unfortuntaly, RTL931x needs a different function to access the correct
registers to retrieve the port matrix information.
It is therefore necessary differentiate in rtl93xx_setup between the
SoC families before calling the appropriate function.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19572
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL931x has 56 (0-55) non-CPU ports. To receive updates about the port
state, it is therefore necessary to enable the interrupts for all these
ports.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19572
Signed-off-by: Robert Marko <robimarko@gmail.com>
* traffic isolation tables are different between rtl930x and rtl931x
* traffic_enable/disable/get/set functions span multiple columns in the
rtl931x as a result, previous implementation would only enable traffic
in some ports.
traffic_enable/disable and traffic_set/get should now work on all ports and
not just the initial 32
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19572
Signed-off-by: Robert Marko <robimarko@gmail.com>
Include the NAND specs into the DTS. It is unclear which devices
really need it. Keep it disabled for now. As the SoC register area
is defined too small until now, increase the size to an appropriate
value.
If enabled one can see the following log messages (e.g. Linksys
LGS328C or LGS352C).
[ 1.206600] spi-nand spi1.0: Macronix SPI NAND was found.
[ 1.212795] spi-nand spi1.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[ 1.222217] 3 fixed-partitions partitions found on MTD device spi1.0
[ 1.229466] OF: Bad cell count for /soc/spi@1a400/flash@0/partitions
[ 1.236617] OF: Bad cell count for /soc/spi@1a400/flash@0/partitions
[ 1.244164] Creating 3 MTD partitions on "spi1.0":
[ 1.249620] 0x000000000000-0x000004000000 : "ubifs"
[ 1.423593] 0x000004000000-0x000005e00000 : "firmware"
[ 1.738268] mtdsplit_uimage: no uImage found in "firmware"
[ 1.744577] 0x000005e00000-0x000007c00000 : "runtime2"
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19583
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL93xx devices have a NAND controller built in. Upstream already
has a driver in place. Include it downstream. Activate it in the
RTL93xx builds and disable it for the RTL83xx builds.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19583
Signed-off-by: Robert Marko <robimarko@gmail.com>
During PHY matching, the SMI polling must be disabled to avoid conflicts
during the complex detection routine. Only after this finished, SMI polling
is allowed again.
This was implemented for all realtek families besides RTL931x.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19603
Signed-off-by: Robert Marko <robimarko@gmail.com>
A RTL930x function to read the value from an SDS register must not used on
an RTL931x SoC. Doing it with rtl930x_read_sds_phy() would corrupt the
written results when only parts of the bits are written.
Fixes: 7026084066 ("realtek: Add SDS configuration routines for the RTL93XX platforms")
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19603
Signed-off-by: Robert Marko <robimarko@gmail.com>
Vimin VM-S100-0800MS is an 8 port Multi-Gig switch, based on RTL9303.
Ported from XikeStor SKS8300-8X with changes to support different u-boot
build.
Specification:
- SoC : Realtek RTL9303
- RAM : DDR3 512 MiB
- Flash : SPI-NOR 16 MiB (Winbond W25Q128JVSQ)
- Ethernet : 8x 1/2.5/10 Gbps (SFP+)
- LEDs/Keys (GPIO): 0x/1x
- UART : "Console" port on the front panel
- type : RS-232C
- connector : RJ-45
- settings : 115200n8
- Power : AC100-240V 50/60Hz
Flash instruction using initramfs image:
1. Prepare TFTP server with an IP address "192.168.1.111"
2. Connect your PC to Port1 on VM-S100-0800MS
3. Power on VM-S100-0800MS and interrupt boot by pressing Esc
4. Enable Port1 with the following commands
rtk 10g 0 fiber1g (or fiber10g if 10GBase-*R, dac300cm for DAC cable)
rtk ext-devInit 0
rtk ext-pinSet 2 0
Note: the last command sets tx-disable to low
7. Download initramfs image from TFTP server
tftpboot 0x82000000 <image name>
8. Boot with the downloaded image
bootm
9. On the initramfs image, backup the stock firmware if needed
10. Upload (or download) sysupgrade image to the device
11. Erase "firmware" partition to cleanup JFFS2 of stock FW
mtd erase firmware
12. Perform sysupgrade with the sysupgrade image
13. Wait ~120 sec to complete flashing
Reverting to stock firmware:
1. Prepare by downloading the stock firmware. Vimin doesn't have
the firmware on their website, tested using firmware for shared
hardware Nicgiga S100-0800S-M.
Filename: vmlinux-nicgiga-S100-0800S-M-241126EN.bix
2. Prepare TFTP server with an IP address "192.168.1.111"
3. Connect your PC to Port1 on VM-S100-0800MS
4. Power on VM-S100-0800MS and interrupt boot by pressing Esc
5. Enable Port1 with the following commands
rtk 10g 0 fiber1g (or fiber10g if 10GBase-*R, dac300cm for DAC cable)
rtk ext-devInit 0
rtk ext-pinSet 2 0
Note: the last command sets tx-disable to low
6. Download initramfs image from TFTP server
tftpboot 0x82000000 <image name>
7. Boot with the downloaded image
bootm
8. Under Management -> Firmware -> Upgrade/Backup, upload bix file.
9. Reboot device
Signed-off-by: Colton Pawielski <cepawiel@mtu.edu>
Link: https://github.com/openwrt/openwrt/pull/19477
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This commit adds support for Hasivo S1100W-8XGT-SE switch.
Device specification
--------------------
SoC Type: RTL9303
RAM: Samsung K4B461646E-BYKO (512MB)
Flash: Fudan FM25Q128A (16 MB)
Ethernet: 8x 10G via 2x RTL8264 PHY
LEDs: 2 LEDs, 1 power green, 1 system green
Button: Reset
USB ports: None
Bootloader: Realtek U-Boot - U-Boot 2011.12.(3.6.6.55087) (Nov 13 2022 - 14:37:31)
Fan: 2 fans controlled by STC8G1K08 TSOP-20 microcontroller
Note: The fan appears to operate the same irrespective of the running
firmware. The STC9G1K08 is likely operating independently.
To explore the stock vendor firmware, there are 2 avenues to gain root
access. This is not necessary to install OpenWrt, but is here for
reference.
Root access via serial
----------------------
1. ctrl+t
2. password: switchrtk
3. press 's' for shell
Root access via SSH
-------------------
1. ctrl+t
2. password: switchrtk
3. sys command sh
4. log in with your username+password
5. ctrl+t
6. password: switchrtk
7. press 's' for shell
Credit to https://forum.openwrt.org/t/hasivo-switches/151758/174 for rooting instructions.
Installing OpenWrt
------------------
1. Connect to UART. UART requires soldering an RJ45 connector to the
console footprint on the board. The header is on the top right of
this image: 4d2ab97fad.jpeg
2. Set computer IP to 192.168.0.111.
3. Enter bootloader by pressing esc key during boot.
4. Enter password 'Hs2021cfgmg'.
5. Type 'XXXX'.
6. setenv bootcmd 'rtk network on; bootm 0xb4300000'
7. saveenv
8. rtk network on
9. tftpboot 0x84f00000 <openwrt-initramfs>
10. bootm 0x84f00000
Now you can copy over the sysupgrade image and install.
Credit to
https://forum.openwrt.org/t/hasivo-switches/151758/22?u=andrewjlamarche
for u-boot console access instructions.
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17137
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Maintain 64 bit counters by polling the hardware counters and adding up
the differences. Polling needs to happen just often enough to catch
every single overflow.
As we now have non-overflowing counters now, we can safely calculate
composite counters without getting weird results on overflow. Use this
to follow RFC 3635 more accurately by mapping the hardware counters to
the proper counters, while taking into account hardware quirks as best
as possible.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/18415
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
By default, the network interface stats are based on software counters,
which only consider traffic from and to the CPU. Implementing the
get_stats64 method allows to report the full hardware counters instead.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/18415
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The kernel offers several alternatives to get_ethtool_stats which allow
to report some stats in a more structured way. Use them where possible.
Ideally, we should follow RFC 3635 to translate the hardware counters to
the supported frame and octet counters. However, this is not feasible,
as some of the counters are 32-bit only (so it would produce incorrect
results as soon as one of them overflows).
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/18415
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The MIB registers contain different stats depending on the SoC, and for
RTL930x some stats are in an additional register.
Create separate MIB descs for each SoC to implement this. Also make
reading 64-bit counters more robust, by protecting against an overflow
of the lower 32 bits during the read.
RTL931x remains unsupported, because it uses a table and thus requires
a separate implementation.
While we are at it, rename structs/functions to use the rtldsa prefix.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/18415
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
After observation that timer interrupt 7 always fires on secondary VPEs
the counter was disabled in the startup code. This is a bad idea when
building the kernel with jitterentropy. To generate entropy it makes use
of function random_get_entropy(). On MIPS architecture this simply reads
the counter register on the current core. With a disabled counter it
always returns the same value and the entropy initialization stalls the
core if it runs on a secondary VPE. See backtrace
[ 21.736246] rcu: INFO: rcu_sched self-detected stall on CPU
[ 21.736246] rcu: INFO: rcu_sched self-detected stall on CPU
[ 21.748594] rcu: 1-....: (2100 ticks this GP) idle=064c/1/0x40000002 softirq=7/7 fqs=1050
[ 21.748594] rcu: 1-....: (2100 ticks this GP) idle=064c/1/0x40000002 softirq=7/7 fqs=1050
[ 21.766871] rcu: (t=2102 jiffies g=-1187 q=25 ncpus=2)
[ 21.766871] rcu: (t=2102 jiffies g=-1187 q=25 ncpus=2)
[ 21.778429] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.39 #482
[ 21.778429] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.39 #482
[ 21.778461] Hardware name: Zyxel GS1900-48
[ 21.778461] Hardware name: Zyxel GS1900-48
...
[ 21.779757] [<8029b968>] jent_measure_jitter+0xc8/0x10c
[ 21.779757] [<8029b968>] jent_measure_jitter+0xc8/0x10c
[ 21.779779] [<8029b9e8>] jent_gen_entropy+0x3c/0xb0
[ 21.779779] [<8029b9e8>] jent_gen_entropy+0x3c/0xb0
[ 21.779800] [<8029bcc0>] jent_entropy_collector_alloc+0x104/0x118
[ 21.779800] [<8029bcc0>] jent_entropy_collector_alloc+0x104/0x118
[ 21.779822] [<8029bd6c>] jent_entropy_init+0x4c/0x2ec
[ 21.779822] [<8029bd6c>] jent_entropy_init+0x4c/0x2ec
[ 21.779844] [<8086f184>] jent_mod_init+0x58/0xac
[ 21.779844] [<8086f184>] jent_mod_init+0x58/0xac
[ 21.779865] [<80100200>] do_one_initcall+0x70/0x250
[ 21.779865] [<80100200>] do_one_initcall+0x70/0x250
[ 21.779883] [<8085c018>] kernel_init_freeable+0x1f0/0x280
[ 21.779883] [<8085c018>] kernel_init_freeable+0x1f0/0x280
[ 21.779905] [<8067cba4>] kernel_init+0x20/0xb0
[ 21.779905] [<8067cba4>] kernel_init+0x20/0xb0
[ 21.779926] [<80101158>] ret_from_kernel_thread+0x14/0x1c
[ 21.779926] [<80101158>] ret_from_kernel_thread+0x14/0x1c
This bit of entropy is helpful on these low end devices. Reenable the
counter and simply disable the interrupt.
Fixes: b7aab19585 ("realtek: SMP handling of R4K timer interrupts")
Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19499
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The mdio bus functions are still split between ethernet and dsa driver.
Before moving everthing out to a separate mdio driver we decided to
collect everything in the ethernet driver with the rtmdio prefix.
Take over the remaining RTL838x functions.
Remark: This is more or less a copy/paste with function renaming. As
there are still some consumers in the DSA driver the definitions and
inclusions must be flipped.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19484
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently the SerDes driven SFP ports give strange ethtool readings
on RTL83xx devices. Especially duplex and speed are shown even if
no link is up and running. That leads to confusion because the MAC
reports arbitrary values.
Enhance the readout by refactoring the pcs_get_state() function.
Calculate speed/duplex/pause only if link is detected. Additionally
add reporting of 10G for SFP+ on RTL839x.
ethtool for empty SFP cage before/after
root@OpenWrt:~# ethtool lan9
Settings for lan9:
Supported ports: [ MII ]
Supported link modes: 1000baseT/Full
1000baseKX/Full
1000baseX/Full
1000baseT1/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
1000baseKX/Full
1000baseX/Full
1000baseT1/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: no
root@OpenWrt:~# ethtool lan9
Settings for lan9:
Supported ports: [ MII ]
Supported link modes: 1000baseT/Full
1000baseKX/Full
1000baseX/Full
1000baseT1/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
1000baseKX/Full
1000baseX/Full
1000baseT1/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: no
ethtool with inserted but NOT connected 1G module before/after
root@OpenWrt:~# ethtool lan9
Settings for lan9:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: no
root@OpenWrt:~# ethtool lan9
Settings for lan9:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Port: FIBRE
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: no
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19524
Signed-off-by: Robert Marko <robimarko@gmail.com>
The SerDes setup function needs to be called to make 2500Base-X work.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19517
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
On some devices (like ZyXEL GS1920) the phys are not initialized and patched
by the bootloader. This is done through the vendor SDK when the software
starts. To make these devices usable too, provide the most basic setup
sequence for the RTL8218B.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19491
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The driver currently uses two checks to verify the capabilities. These
are ..._phylink_get_caps() and ..._pcs_validate(). For RTL930x these
must allow 2.5G modes. Enhance that as follows:
Add 2500BASEX to phylink_get_caps(). Sort the interfaces alphabetically
and rename the function to the new prefix. IMPORTANT REMARK! Until now
this function allowed the XGMII mode (10G only parallel interface) that
was somehow mixed with the Realtek proprietary mode XSGMII (10G SGMII).
Remove it to avoid further confusion.
Looking upstream pcs_validate() is used less and less. There are only
2 consumers left in 6.16 and the calling location reads:
/* Validate the link parameters with the PCS */
if (pcs->ops->pcs_validate) {
ret = pcs->ops->pcs_validate(pcs, supported, state);
if (ret < 0 || phylink_is_empty_linkmode(supported))
return -EINVAL;
/* Ensure the advertising mask is a subset of the
* supported mask.
*/
linkmode_and(state->advertising, state->advertising,
supported);
}
There is no need for this additional check. Drop the functions.
Tested-by: Jan Hoffmann <jan@3e8.eu>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19429
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
RTL83xx devices have two types of receive interrupts for each of its
8 rings. One for packet received and another for ring overflow. When
the switch is flooded with incoming packets the receive handler will
disable the packet receive notification but still keeps the overflow
notification enabled. While the receive path "slowly" processes the
received packets each new packet triggers the overflow IRQ again. The
device becomes unresponsive and eventually produces messages like:
[18441.709764] rcu: Stack dump where RCU GP kthread last ran:
[18441.727892] Sending NMI from CPU 1 to CPUs 0:
[18441.742300] NMI backtrace for cpu 0 skipped: idling at 0x8080e994
[18415.251700] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[18415.271350] rcu: 0-...!: (0 ticks this GP) idle=d740/0/0x0 ...
[18415.303046] rcu: (detected by 1, t=6004 jiffies, g=230925, ...
[18415.326095] Sending NMI from CPU 1 to CPUs 0:
[18415.340540] NMI backtrace for cpu 0
Fix this issue by always disabling receive and overflow interrupts at
the same time.
Test with hping3 --udp -p 5021 -d 1400 --flood 192.168.2.72
Before (3sec run):
[183260.324846] rtl838x-eth 1b00a300.ethernet eth0: RX buffer overrun: status 0x101, mask: 0x7ffeff
[183260.340524] rtl838x-eth 1b00a300.ethernet eth0: RX buffer overrun: status 0x1, mask: 0x7ffeff
[183260.345799] net_ratelimit: 489997 callbacks suppressed
After (3 sec run):
[ 373.981479] rtl838x-eth 1b00a300.ethernet eth0: rx ring overrun: status 0x101, mask: 0x7fffff
[ 374.031118] rtl838x-eth 1b00a300.ethernet eth0: rx ring overrun: status 0x101, mask: 0x7fffff
[ 377.919996] net_ratelimit: 34 callbacks suppressed
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19365
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The current implementation has several issues:
- it uses the hacky phy_port* macros
- it uses SoC dependent raw pages
- it disables/enables SoC dependent polling
Get rid of these dependencies and access the mdio bus the normal way.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19372
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In rtl931x_led_init, the number of leds per port is not properly set. It
currently uses a hardcoded value of 1 which seems to be taken initially
from a specific device. This hardcoded value assumes any port always has
exactly two leds.
The RTL930x variant - rtl930x_led_init - does a better job at this. So
take it and use it for RTL931x too with the corresponding register.
While at it, rename the function to a proper naming scheme.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19241
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The operating mode of a SerDes must be aligned with the attached PHY or
SFP module. That does not only require to change the protocol (e.g. SGMII,
10Gbase-R, ...) but also the speed (e.g. 1.25G). For this the SerDes must
be re-initialized properly.
- It must be taken into power down
- The PLL speed must be set
- Maybe the CMU (clock management unit) must be resetted
- The new mode must be set
- The state machine must be resetted
- The power must be reactivated
Until now this sequence is bugged. First the driver relies on a clean
setup from U-Boot (rtk network on) and second trying to to change mode
and PLL speeds does not work at all. And not to forget: Currently two
adjacent SerDes cannot drive SGMII/HSGMII at the same time. Fix this by
taking care about the right SerDes/PLL/CMU command init order.
P.S. This code is inspired by the work of Jan Hofmann, who tried to
enable parallel SGMII/HSGMII mode. The only missing bit was a proper CMU
reset sequence.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19220
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL931x devices have an other register that describes the
current RAM configuration. Enhance the identification routine.
Tested on LGS352C (RTL9311).
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19284
Signed-off-by: Robert Marko <robimarko@gmail.com>
Until now the rt-loader only works on U-Boot driven devices where the
environment (e.g. coprocessor) is usually setup properly. Devices like
the ZyXEL GS1920 series use BootBase as start environment and skip
some of the basic initialization steps. rt-loader will fail in these
cases. Take care about the CP0 registers.
Additionally enhance the documentation of the printf implementation.
It was optimized during the different revisions of the initial PR.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19253
Signed-off-by: Robert Marko <robimarko@gmail.com>
There are too many supported Realtek devices so avoid activating the
rt loader recipe in the default builds. Just start with the LGS310C.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18397
Signed-off-by: Robert Marko <robimarko@gmail.com>
To make use of the new rt-loader provide the needed recipes.
This has been tested with the following devices:
- rtl838x Linksys LGS310: initramfs & flash
- rtl930x Zyxel XGS1210: initramfs
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18397
Signed-off-by: Robert Marko <robimarko@gmail.com>
The bootloader of many Realtek switches only supports gzipped kernel images.
With limited flash space that might get critical in future versions. For better
compression allow support for compressed images. For this a new loader was
developed. Several ideas have been taken over from the existing lzma loader
but this has been enhanced to make integration simpler. What is new:
- Loader is position independent. No need to define load addresses
- Loader identifies device memory on its own
- Loader uses "official" upstream kernel lzma uncompress
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/decompress_unlzma.c
- Loader uses "official" UNMODIFIED nanoprintg that is used by several
bare metal projects. https://github.com/charlesnicholson/nanoprintf
Compiled the loader ist just under 12KiB and during boot it will show:
rt-loader
Found RTL8380M (chip id 6275C) with 256MB
Relocate 2924240 bytes from 0x80100000 to 0x8fce0000
Extract kernel with 2900144 bytes from 0x8fce521c to 0x80100000...
Extracted kernel size is 9814907 bytes
Booting kernel from 0x80100000 ...
[ 0.000000] Linux version 6.12.33 ...
[ 0.000000] RTL838X model is 83806800
...
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18397
Signed-off-by: Robert Marko <robimarko@gmail.com>
During setup the mdio driver decides the polling mode of the 4 smi
busses depending on the DTS phy settings. This works as follows:
- set polling to c45 if at least one phy is ethernet-phy-ieee802.3-c45
- set polling to c22 if all phys are ethernet-phy-ieee802.3-c22
On RTL930x it is not possible to switch to c22 if uboot has set c45
before. Fix this by overwriting the bitfield properly. While we are
here:
- Sort variables according to kernel style (inverse christmas tree)
- Initialize fields properly with = { 0 }
- Use GENMASK() for better readability
- Make use of RTMDIO_MAX_SMI_BUS
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19161
Signed-off-by: Robert Marko <robimarko@gmail.com>
Until now the timer management on the RTL931x devices depends
on the MIPS default timer. Looking at the clock progress on
these devices one can see that it is totally off. It is running
at half the required speed (e.g. if 1 minute passes the date
command shows that according to the timers only 30 seconds have
elapsed). This is a mix from wrong DTS and bad startup code.
This is not only a cosmetic issue but has effects on every
delay operation inside the kernel. Switch RTL931x to the proven
Otto timer.
Tested on LGS352C based on RTL9311.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19205
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Otto timer is very helpful on the RTL931x devices.
Include it into the builds.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19205
Signed-off-by: Robert Marko <robimarko@gmail.com>
Upstream has gained support for forced affinity settings in the MIPS
GIC interrupt controller. This is needed to enable the Otto timer on
the RTL931x platform. See
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/
commit/?id=2250db8628a0d8293ad2e0671138b848a185fba1
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19205
Signed-off-by: Robert Marko <robimarko@gmail.com>
Remove all files etc. for 6.6 because 6.12 is default now.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19139
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use Linux 6.12 as default for all subtargets.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19139
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. For
this device it is only a substitution of the existing DTS configuration.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. For
this device it is only a substitution of the existing DTS configuration.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. For
this device it is only a substitution of the existing DTS configuration.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. For
this device it is only a substitution of the existing DTS configuration.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
REMARK! The original commit c829bc1f2c ("realtek: Add support for
Netgear S350 series switches GS308T and GS310TP") says that the SFP
ports are untested. Looking at device internal pictures from
https://techinfodepot.shoutwiki.com/wiki/Netgear_GS310TP there are no
external phys for the SFP ports. So fix port description.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. With
this change the driver now knows that ports 24/26 are driven by serdes
4/5.
For the RTL838x devices this is currently only an additional information
for the mdio bus. It is not evaluated further because everything is
hardcoded.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Until now only the RTL930x devices make use of the following notation.
phy8: ethernet-phy@8 {
compatible = "ethernet-phy-ieee802.3-c22";
phy-is-integrated;
reg = <8>;
sds = <3>;
};
This indicates that the link is driven by a serdes directly without
external phy. As the devices have multiple serdes it must be clarified
what serdes is responsible for that port.
Nevertheless all other devices have the same requirements. E.g. RTL838x
usually drives port 24 from serdes 4 and port 26 from serdes 5. All this
currently works because the driver has a lot of hardcoded port/serdes
mapping.
Make the situation better by adding dts helpers that can describe the
topology as needed.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Run this script:
./scripts/kconfig-reorder.sh
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Link: https://github.com/openwrt/openwrt/pull/19200
Signed-off-by: Robert Marko <robimarko@gmail.com>
This allows the SFPs to work without manually switching port type.
Signed-off-by: Joe Holden <jwh@zorins.us>
Link: https://github.com/openwrt/openwrt/pull/18914
Signed-off-by: Robert Marko <robimarko@gmail.com>
The 4 sfp ports on the RTL8214FC are actually wired to the gpio expander instead of internal.
Relatively minor changes to the dts are required, simply overriding some of the properties
inherited from rtl8393_hpe_1920.dtsi.
The speed is reported as 100/full and the media type is incorrect, but the ports pass traffic
just fine.
Signed-off-by: Joe Holden <jwh@zorins.us>
Link: https://github.com/openwrt/openwrt/pull/18914
Signed-off-by: Robert Marko <robimarko@gmail.com>
The SMP environment is prepared well for the RTL93X. Now describe the
power cluster controller in the DTS. Tested on RTL9311 based Linksys
LGS352C.
Without patch:
root@OpenWrt:~# dmesg | grep CPU
[ 0.140425] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))
[ 0.191952] Synchronize counters for CPU 1: done.
[ 1.232191] CPU2: failed to start
[ 1.237863] No online CPU in core 1 to start CPU3
[ 2.273784] CPU3: failed to start
[ 2.277589] smp: Brought up 1 node, 2 CPUs
root@OpenWrt:~# cat /proc/cpuinfo | grep -E "model|proc"
processor : 0
cpu model : MIPS interAptiv (multi) V2.0
processor : 1
cpu model : MIPS interAptiv (multi) V2.0
With patch:
root@OpenWrt:~# dmesg | grep CPU
[ 0.000000] CPU0 revision is: 0001a120 (MIPS interAptiv (multi))
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Failed to get CPU clock: -2
[ 0.000000] CPU frequency from device tree: 1000MHz
[ 0.133360] smp: Bringing up secondary CPUs ...
[ 0.140418] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))
[ 0.191950] Synchronize counters for CPU 1: done.
[ 0.230103] CPU2 revision is: 0001a120 (MIPS interAptiv (multi))
[ 0.289220] Synchronize counters for CPU 2: done.
[ 0.326189] CPU3 revision is: 0001a120 (MIPS interAptiv (multi))
[ 0.378861] Synchronize counters for CPU 3: done.
[ 0.413829] smp: Brought up 1 node, 4 CPUs
processor : 0
cpu model : MIPS interAptiv (multi) V2.0
processor : 1
cpu model : MIPS interAptiv (multi) V2.0
processor : 2
cpu model : MIPS interAptiv (multi) V2.0
processor : 3
cpu model : MIPS interAptiv (multi) V2.0
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19110
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The switchcore node is the central location that describes the Realtek switch
register addresses starting at 0x1b000000. It will be used by current and
future regmap enabled device drivers. The upstream MDIO driver already makes
use of it by calling syscon_node_to_regmap(dev->parent->of_node);
In the current DTS base we have 3 issues that should be fixed:
- rtl838x.dtsi has a length of 0x20000 instead of 0x10000
- rtl839x.dtsi has a length of 0x20000 instead of 0x10000
- rtl931x.dtsi has no switchcore node at all
Align these mismatches with the "good" RTL930x template.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18642
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The drivers for I2C bus and mux for RTL931x have an incorrectly defined
SDA0 pin number, causing an error with correct pin numbers specified in
the device tree.
Using the `show tech-support board` on the vendor firmware of a Netgear
MS510TXM shows the correct pin numbers but they don't work with the
drivers. So fix this.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19171
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Backport accepted BCM5325 patches from net-next.
These patches will be merged in the v6.17 kernel window.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
From now on both SFP ports can be used without manual intervention.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18737
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently only RTL83xx devices are known with shared SCL pins.
So activate the driver only for those targets.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18737
Signed-off-by: Robert Marko <robimarko@gmail.com>
Some Realtek switches have been designed with I2C busses that share a
single SCL line. The clock line is used for 2 or more busses. This cannot
be used with the standard i2c-gpio driver that relies on distinct SDA
and SCL pairs.
Provide a derived i2c-gpio-shared driver that can be used instead. This
driver can handle up to 4 busses with only a single clock line.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18737
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Zyxel XGS1210-12 Switch is a 10 + 2 port multi-GBit switch with
8 x 1000BaseT, 2 x 10/100/1000/2500BaseT Ethernet ports and
2 SFP+ module slot.
Hardware:
- RTL9302B SoC
- Macronix MX25L12833F (16MB flash)
- Nanja NT5CC64M16GP-1 (128MB DDR3 SDRAM)
- RTL8231 GPIO extender to control the port LEDs
- RTL8218D 8x Gigabit PHY
- RTL8226 2x 10m/100m/1/2.5 Gigabit PHY
- SFP+ 2x 10GBit slot
Power is supplied via a 12V 1.5A standard barrel connector. At the
right side behind the grid is UART serial connector. A Serial
header can be connected to from the outside of the switch trough
the airvents with a standard 2.54mm header.
Pins are from top to bottom Vcc(3.3V), TX, RX and GND. Serial
connection is via 115200 baud, 8N1.
A reset button is accessble through a hole in the front panel
At the time of this commit, all ethernet ports work under OpenWrt,
including the various NBaseT modes, SFP+ slots are supported with i2c bus.
Installation
--------------
* Connect serial as per the layout above. Connection parameters: 115200 8N1.
* Navigate to 'Management' in the OEM web interface and click on 'Firmware upgrade'
to the left.
* Upload the OpenWrt initramfs image, and wait till the switch reboots.
* Connect to the device through serial and change the U-boot boot command.
> fw_setenv bootcmd 'rtk network on; boota'
* Reboot, scp the sysupgrade image to /tmp, verify the checksum and flash it:
> sysupgrade openwrt-realtek-rtl930x-Zyxel_xgs1210-12-squashfs-sysupgrade.bin
* Upon reboot, you have a functional OpenWrt installation. Leave the bootcmd
value as is - without 'rtk network on' the switch will fail to initialise
the network.
Debug
------------
* Connect serial as per the layout above. Connection parameters: 115200 8N1.
* A tftp server is requiered, 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 (default is 192.168.1.1):
> setenv ipaddr 192.168.1.6
* Download initramfs:
> tftpboot 0x84f00000 192.168.1.111:openwrt-realtek-rtl930x-Zyxel_xgs1210-12-initramfs-kernel.bin
* Boot loaded file:
> bootm 0x84f00000
This prodecudre also apply to the sock firmware with the file XGS1210-12_V2.00(ABTY.1)C0.bix.
More information can be found on the page of XGS1250-12 as they share the same base.
Signed-off-by: Nicolas BERTRAND <nicolasbertrand89@gmail.com>
[fixed white space error]
Signed-off-by: Paul Spooren <mail@aparcar.org>
The TP-Link TL-ST1008F is an 8-port multi-gig switch with 8x SFP+ ports
which support 1G/2.5G/10G speeds. Out of the box it is an unmanaged
switch but with RTL9303 and sufficient RAM + Flash it easily can run as
a managed Linux switch.
Hardware:
- Realtek RTL9303 Switch SoC
- Winbond 25Q256JVFQ (32MB flash)
- Samsung K4B4G1646E-BYMA (512MB DDR3 SDRAM)
- TCA9534 GPIO extender to control the port LEDs
- 8x SFP+ 1/2.5/10G slot
- Serial: 3V3 logic, 115200 8N1
- 5-pin JTAG
- physical tri-state switch (used by stock firmware for port speed
config)
- 24-LED port speed matrix
- robust full-metal case
Power is supplied via a 12V 2A standard barrel connector.
There are THT holes on the PCB for serial console next to the flash chip
and JTAG pads. Serial uses 3V3 logic and standard 115200-8N1 config.
Pinout is labeled on the PCB.
All ports/connectors and LEDs are on the back, only Power LED is on the
front.
Hints before flashing
----------------------
* It is recommended to backup the stock flash contents before proceeding.
Backup can be done from U-Boot (with memory display), from OpenWrt
initramfs or probably with SPI flash programmer.
There is no stock recovery functionality.
* Use a small image for RAM boot or first flash. Since you need to use
ymodem, this is really slow and takes time.
* This does not keep the dual-partition layout for firmware to have more
space available for a single OpenWrt installation.
Initial flashing
----------------------
The stock U-boot has broken networking thus no TFTP available. Serial
transfer only.
1. Open device and connect serial as per layout and settings
(recommended to use picocom, ymodem not working with minicom)
2. Connect power to device and press Esc when prompted to enter
the U-Boot console.
3. Boot initramfs
* in the U-Boot console:
loady 0x82000000 (load OpenWrt image via ymodem)
CTRL-A CTRL-S <initramfs.bin> (specify initramfs image for
picocom to upload)
bootm 0x82000000 (boot initramfs from RAM)
(Just to be on the safe side, backup your flash now while RAM-booted)
4. Connect network to your device
5. Upload the sysupgrade image (e.g. with scp)
6. Do sysupgrade
There's no need to adjust the bootcmd in U-Boot. Networking is running
fine once the realtek driver initialized everything in OpenWrt. No
functional difference with running 'rtk network on' within U-Boot
before. Running this even fails and returns with an error.
Return to stock
------------------
This only works if you did a backup of the flash before flashing
OpenWrt. Stock dump then can be flashed from within U-Boot or OpenWrt.
There is no vendor firmware image because this is an unmanaged switch!
CAUTION: Make sure to not overwrite the U-Boot partition(s). If you do
not have a flash programmer, you may not be able to debrick
your device then.
Co-authored-by: Balázs Triszka <balika011@gmail.com>
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Only 2 devices use leading zeroes to pad interface names,
align the remaining ones so that it is consistent.
Signed-off-by: Joe Holden <jwh@zorins.us>
Link: https://github.com/openwrt/openwrt/pull/18913
Signed-off-by: Robert Marko <robimarko@gmail.com>
Three different code paths for the same phy model. Now the bus
is prepared to handle c45 (mmd) read/writes correctly. Remove
the custom implementations and let generic kernel functions do
their best. To achieve this
- disable the PHY-mode EEE in rtl821x_config_init() as upstream does
- provide mmd read/write functions that avoid EEE via c45 over c22
While chaning the phy_driver functions sort them alphabetically.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
rtl8214fc_media_is_fibre() will need to be run when bus lock is held.
Split the function into two versions.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
As the mdio bus has been hardened and can now handle c45 requests
the DSA driver must honor that as well. For this
- add proper upstreamed bus read_c45 and write_c45 functions
- take over the disabled port mask from upstream bus
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
With the follow up EEE patches the mdio bus will run c22 and c45
accesses during initial scan. Especially when accessing addresses
beyond the CPU port phy requests might fail in a way that cannot
be handled gratefully. Do two things
- do not allow access to addresses starting from cpu port
- set the scan disable bitmask to ports starting from cpu port
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Some bits where missed during the last enhancement of the mdio
patch. In the forthcoming patches the phy_mask will be populated
to avoid unwanted ports (>= cpu port) from being scanned. Add
additional locations where 32 bit values need to be converted
to 64 bits.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
If mmd and normal phy ops are issued the bus is lost because
of wrong park page settings. Force it to 0x1f as in GPL.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Allow to build the new kernel.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
The new kernel has relocated the definition of struct platform_device.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
The DSA driver uses set_mac_eee() for the outside API while
the interal helper is called port_eee_set(). Align that.
Additionally do not call the internal helpers directly by
the function names but use the register assignments.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Upstream will get rid of the get_mac_eee() function in the DSA
driver and replace it by a boolean alternative. While we fill a
lot of data here (because of EEE bugs in the Realtek phy layer)
other DSA drivers only return if EEE is available or not for a
port. To make the next kernel upgrade easier follow that design.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
To avoid unneeded interrupts the R4K timer is deactivated during
secondary cpu initialization. This is currently done during
phase init_secondary(). With the upgrade to 6.12 the kernel runs
a primary/secondary cpu timer/counter synchronization to verify the
proper setup in synchronise_count_slave(). That runs at a later
point in time and expects the secondary counter to be fully
functional. Finding a deactivated counter results in the following
messages:
WARNING: CPU: 1 PID: 0 at arch/mips/kernel/sync-r4k.c:99 check_counter_warp+0x220/0x254
Warning: zero counter calibration delta: 0 [max: 6500000]
Counter synchronization [CPU#0 -> CPU#1]:
Measured 278760029 cycles counter warp between CPUs
Relocate the deactivation to smp_finsh() at the end of the cpu
startup sequence. Additionally polish the startup code and remove
all unneeded parts.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Per IEEE 802.3 definition we have:
- parallel XGMII for single 10GBit ONLY links
- serial USGMII for 8 port 1GBit links (not known by kernel)
- serial USXGMII: for single/multiple links with a total bandwidth of 10GBit
The phy-mode of the first eight ports of the XGS1250-12 have always been
defined as XGMII (without S). This came from a confusion with the similar
named Realtek proprietary XSGMII (with S) mode that is basically 10GB SGMII.
From the above definition this is wrong but worked until kernel 6.6. With
the upgrade to 6.12 there is an enforced capabilities check within
phy_caps_from_interface() and link validation fails with
lan1: validation of xgmii with support 62ef and advertisement 62c0 failed: -EINVAL
lan1: failed to connect to PHY: -EINVAL
lan1: error -22 setting up PHY for tree 0, switch 0, port 0
Switch the ports to USXGMII as the most flexible option. This might be no
final solution but at least it better describes the phy/mac link.
Fixes 5b8b382df9 ("realtek: Add support for ZxXEL XGS1250-12 Switch")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Fix minor compilation errors due to kernel changes.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Upstream has integrated the Realtek target into the generic MIPS
initialization and so MACH_REALTEK_RTL has gained some new features.
Especially:
- CONFIG_MACH_GENERIC_CORE generates central modules
- board-realtek module adds device specific extensions
The current downstream initialization works well and upgrading to
kernel 6.12 is not the right time to harmonize this. Modify the
MACH definitions to the current needs.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
The validate function no longer exists in phylink_mac_ops. Remove
it for the internal ethernet interface. Instead provide some
meaningful mac capabilities.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Not only the link but also the mac capabilities are needed here.
Additionally do some alphabetical sorting.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
The old upstream notation has been changed to something not so racist.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
EEE functions are now called with ethtool_keee instead of
ethtool_eee. Replace all occurrences. This will fix function
signature checks but still produces compilation errors due
to structure changes.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Patches where fuzz had to be cleaned up.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
All these patches needed no manual intervention and applied cleanly
with new source code positions.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Thanks to Chris Packham this driver got upstreamed. Drop the
downstream files and patches.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Automatically generated commit.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Automatically generated commit.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Automatically generated commit.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Automatically generated commit.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Automatically generated commit.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
Automatically generated commit.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
* Extends SoC thermal sensor on rtl839x
* Tested on HP JG928A
Signed-off-by: Stephen Howell <howels@allthatwemight.be>
Link: https://github.com/openwrt/openwrt/pull/18825
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add support for V3 of the Engenius EWS2910P PoE switch. Like its v1
brother, This is an RTL8380 based switch with two SFP slots, and PoE
802.3af one every RJ-45 port.
Unlike its older brother, the max budget is 55W instead of 61.6 W.
Investigation into the communication protocol with the PoE controller
is ongoing, though it appears the vendor firmware configures the PSE
with a per-port budget of 30.0W.
Specifications:
---------------
* SoC: Realtek RTL8380M
* Flash: 32 MiB SPI flash Macronix MX25L25635E
* RAM: 256 MiB (As reported by bootloader)
* Ethernet: 8x 10/100/1000 Mbps with PoE
2x SFP slots
* Buttons: 1 "Reset" button on front panel
1 "LED mode: button on front panel
1 "On/Off" Toggle switch on the back
* Power: 48V-54V DC barrel jack
* UART: 1 serial header (JP1) with populated 2.54mm pitch header
Labeled GRTV for ground, rx, tx, and 3.3V respectively
* PoE: 1 STM ST32... microcontroller (U15)
1 RTL8238B PSE controller
Works:
------
- (8) RJ-45 ethernet ports
- Switch functions
- LEDs and buttons
Not yet enabled:
----------------
- Power-over-Ethernet (requires realtek-poe support for RTL8232B)
Install via web interface:
-------------------------
The factory firmware will accept and flash the initramfs image. It is
recommended to flash to "Partition 0". Flashing to "Partition 1" is
not supported at this point.
The factory web GUI will show the following warning:
" Warning: The firmware version is v0.00.00-c0.0.00
The firmware image you are uploading is older than the current
firmware of the switch. The device will reset back to default
settings. Are you sure you want to proceed?"
This is expected when flashing OpenWrt. After the initramfs image
boots, flash the -sysupgrade using either the commandline or LuCI.
Install via serial console/tftp:
--------------------------------
See commit 2cfaab4549 ("realtek: add support for EnGenius EWS2910P").
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15217
Signed-off-by: Robert Marko <robimarko@gmail.com>
When the Engenius EWS-2910P was added, only v1 was known. Move the
common parts to a dtsi, and split up the support to acccount for the
hardware version.
On v3, for example, the root partition uses a different uImage magic.
Add a "engenius,ews2910p-v1" compatible, while leaving the legacy
"engenius,ews2910p" to also mean v1.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15217
Signed-off-by: Robert Marko <robimarko@gmail.com>
DSA silently drops internal phy access to ports >= 32 in dsa_user_phy_read()
and dsa_user_phy_write(). The code shows:
static int dsa_user_phy_read(struct mii_bus *bus, int addr, int reg)
{
struct dsa_switch *ds = bus->priv;
if (ds->phys_mii_mask & (1 << addr))
return ds->ops->phy_read(ds, addr, reg);
return 0xffff;
}
With ds->phys_mii_mask being a 32 bit variable the reason is clear. So do
not only increase the max values but also adapt the needed bitmasks in
the dsa and phy code. This fixes the dsa_user_ports() and dsa_cpu_ports()
too.
While we are here combine the old separated patches because dsa, mdio and
phy are tigthly coupled.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18846
Signed-off-by: Robert Marko <robimarko@gmail.com>
In 2023 upstream has tightened compiler checks with this patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
/scripts/Makefile.extrawarn?h=v6.15&id=0fcb70851fbfea1776ae62f67c503fef8f0292b9
A consistent function definition is now needed. I.e.
- functions must be either declared with "static" or
- functions need an additional declaration (in the header file)
Before upgrading the Realtek target to 6.12 clean the code so that the main
6.12 PR can focus on real issues from the version bump.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18925
Signed-off-by: Robert Marko <robimarko@gmail.com>
In 2023 upstream has tightened compiler checks with this patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
/scripts/Makefile.extrawarn?h=v6.15&id=0fcb70851fbfea1776ae62f67c503fef8f0292b9
A consistent function definition is now needed. I.e.
- functions must be either declared with "static" or
- functions need an additional declaration (in the header file)
Before upgrading the Realtek target to 6.12 clean the code so that the main
6.12 PR can focus on real issues from the version bump.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18925
Signed-off-by: Robert Marko <robimarko@gmail.com>
In 2023 upstream has tightened compiler checks with this patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
/scripts/Makefile.extrawarn?h=v6.15&id=0fcb70851fbfea1776ae62f67c503fef8f0292b9
A consistent function definition is now needed. I.e.
- functions must be either declared with "static" or
- functions need an additional declaration (in the header file)
Before upgrading the Realtek target to 6.12 clean the code so that the main
6.12 PR can focus on real issues from the version bump.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18925
Signed-off-by: Robert Marko <robimarko@gmail.com>
In 2023 upstream has tightened compiler checks with this patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
/scripts/Makefile.extrawarn?h=v6.15&id=0fcb70851fbfea1776ae62f67c503fef8f0292b9
A consistent function definition is now needed. I.e.
- functions must be either declared with "static" or
- functions need an additional declaration (in the header file)
Before upgrading the Realtek target to 6.12 clean the code so that the main
6.12 PR can focus on real issues from the version bump.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18925
Signed-off-by: Robert Marko <robimarko@gmail.com>
In 2023 upstream has tightened compiler checks with this patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
/scripts/Makefile.extrawarn?h=v6.15&id=0fcb70851fbfea1776ae62f67c503fef8f0292b9
A consistent function definition is now needed. I.e.
- functions must be either declared with "static" or
- functions need an additional declaration (in the header file)
Before upgrading the Realtek target to 6.12 clean the code so that the main
6.12 PR can focus on real issues from the version bump.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18925
Signed-off-by: Robert Marko <robimarko@gmail.com>
There are still a lot of mdio functions scattered around the code.
Move the RTL838x serdes helpers closer to the bus, add the proper
prefix and simplify the functions.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18847
Signed-off-by: Robert Marko <robimarko@gmail.com>
There is a patch/bug cascade in the realtek target phy code that must be resolved.
1. The phy_driver structure is patched to add features ONLY needed for RTL8214FC
2. The kernel is patched to allow switching fiber/copper port of phys through ethtool
by calling these new features.
3. With those patches applied the bootup always switches RTL8214FC ports to copper.
Even if a SFP module was found before and the phy driver switched to fibre before.
3. So another patch is needed that reprobes the SFP module to activate fiber again.
4. Because of the reprobing we need a fourth patch that avoid duplicate devices.
Simplify this by removing all patches and reusing the existing ethtool phy tunable
interface. The command line usage might be counterintuitive but it avoids tons of
problems in the code. In addition, this scenario is not used frequently.
Before:ethtool -s lan25 port fibre/tp
After: ethtool --set-phy-tunable lan25 downshift on/off
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18816
Signed-off-by: Robert Marko <robimarko@gmail.com>
The MIPS CPC (Cluster Power Controller) is setup during boot and can take
its configuration from the devicetree. This is currently not possible
because the cpc probing happens before dt initialization. Call order
during startup is:
setup_arch()
prom_init() <- our function
mips_cpc_probe()
smp_stuff()
arch_mem_init()
device_tree_init() <- our function
unflatten_and_copy_device_tree()
To avoid ugly hacking and support a clean devicetree relocate the cps/smp
stuff to device_tree_init(). This is basically the same location as in
generic mips initialization.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Link: https://github.com/openwrt/openwrt/pull/18888
Signed-off-by: Robert Marko <robimarko@gmail.com>
Make it easier to upgrade the kernel in the future. For this remove
the 320-harden-fw_init_cmdline.patch and add the logic into the
startup sequence at the right place.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18853
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL931x devices are dual core with two threads each. That is a total
of 4 VPEs (CPUs) in the kernel. Adapt the kernel config for that.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Link: https://github.com/openwrt/openwrt/pull/18889
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since the early beginning of the Realtek DSA driver there is an uncovered
locking issue between the standard (parent) mdio bus and the DSA (child)
mdio bus. This comes from the fact that the DSA bus simply links to the
parent read and write functions and calls them directly. This leads to
the following lock issue.
- Child bus calls phy_read/write functions and uses its internal lock
- Parent bus calls phy_read/write functions and uses its internal lock
It becomes clear that critical section can be accessed twice without
knowing that a operation from the other bus is currently active. This
can lead to critical malfunctions because the mdio driver needs a lot of
internal magic to get page selection done right. Effects are:
- The original page is lost after a phy_write/read_paged() call
- dmesg like "Realtek RTL8218B (external) rtl838x slave mii-0:00:
Expected external RTL8218B, found PHY-ID 6b23"
Other DSA drivers simply use the read/write functions from the parent bus
and thus avoid locking issues. Do it the same way.
Fixes: 2b88563ee5 ("realtek: update the tree to the latest refactored version")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18824
Signed-off-by: Robert Marko <robimarko@gmail.com>
There are currently two power functions for the RTL8214FC in the driver
- rtl8380_rtl8214fc_on_off(): powers on/off both ports
- rtl8214fc_power_set(): powers on/off fibre or copper individually
While it seems obvious to merge these, one of them uses extended register
29 and the other register 30 to achieve the update. From looking at the
GPL source drops both methods exist with exactly the same operations. So
where to go from here? The descision was made based on:
- register 30 is only used during patching, 29 during normal operation
- Avoid raw page if possible to use function for RTL839x
So the attached patch was created. The result in the power down bits
was compared for the two old and the new implementation. Result is
always the same.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18707
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL9311 switches (like the Linksys LGS352C) will boot but have not set
the right family id in the soc_info structure. Fix that so drivers do
their work right when checking for that.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18871
Signed-off-by: Robert Marko <robimarko@gmail.com>
Cleanup the code of the RTL83xx packet receive interrupt handler. Not
only for better readability but to avoid inconsistencies and stalls on
the RTL839x targets.
The current implementation seems to come from the GPL source code.
Calling the existing cleanup() function inside the interrupt context
without any locks conflicts with SMP & NAPI polling and makes things
worse instead of giving any benefit. Simply ignore RX buffer overruns
and let the device handle packet dropping itself.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18855
Signed-off-by: Robert Marko <robimarko@gmail.com>
RFC4541, section 2.1.2 says:
Packets with a destination IP (DIP) address in the 224.0.0.X range
which are not IGMP must be forwarded on all ports.
And section 3 says:
In IPv6, the data forwarding rules are more straight forward because
MLD is mandated for addresses with scope 2 (link-scope) or greater.
The only exception is the address FF02::1 which is the all hosts
link-scope address for which MLD messages are never sent. Packets
with the all hosts link-scope address should be forwarded on all
ports.
However, currently when a listener on FF12::1 or FF12:🔢0:1 for
example joins then not only packets to these addresses but also for
FF02::1 won't be flooded to all ports anymore, too. Which violates
RFC4541.
This happens because A): They all map to the same ethernet multicast
address, that is 33:33:00:00:00:01. And B) the VLAN profile L2
unknown MC flood setting will only apply flooding of 33:33:00:00:00:01
if there is no specific listener registered for it.
So to fix this, avoid registering an MDB entry in the switch for
33:33:00:00:00:01 at all.
The downside of this is that FF12::1, FF12:🔢0:1 etc.
will always be flooded, too. However fixing the handling of 224.0.0.X
and FF02::1 and adhering to RFC4541 must have priority to avoid
undesired packetloss, to avoid breaking IPv4/IPv6.
Tested-on: ZyXEL GS1900-24HP v1
Fixes: cde31976e3 ("realtek: Add support for Layer 2 Multicast")
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Link: https://github.com/openwrt/openwrt/pull/18769
Signed-off-by: Robert Marko <robimarko@gmail.com>
Kernel does
if (phydev->drv->set_loopback)
ret = phydev->drv->set_loopback(phydev, enable, speed);
else
ret = genphy_loopback(phydev, enable, speed);
So no need to explicitly set genphy_loopback() in phy_driver. Drop
references to let kernel do its work.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18782
Signed-off-by: Robert Marko <robimarko@gmail.com>
We are lucky to have a working realtek environment. But some things where mixed
heavily. To say it clear a bus is a bus and an ethernet is an ethernet. With
the new naming conventions and defines this becomes even more obvious.
Decouple it by moving the bus specific parts out of the ethernet device. To
make the code more readable rename bus_priv variables to priv and sort variable
definitions in inverse tree order (length descending) where it makes sense.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18402
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
At least since 2022 there is a major bug in the MDIO driver that
produces out-of-bound reads and erratic behaviour during initialization.
- mdiobus_scan_bus_c22() scans the bus for 64 devices (PHY_MAX_ADDR)
- private bus structure only supports 57 entry arrays (MAX_PORTS)
All the bus/reader writer functions accept calls with addr>=57 and will
silently read beyond their limits. This can lead to ghost SERDES like
https://github.com/openwrt/openwrt/issues/18665#issuecomment-2846053813
Add proper boundary checks and end the functions with -ENODEV that is
the only accepted error code from the bus scan function.
Fixes: 0536c582e6 ("realtek: Fix RTL931X Ethernet driver") etc ...
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18402
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
These two arrays have been fixed to some sane size (= 64 ports). Now
that everything is in place reuse the global RTMDIO_MAX_PORT define.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18402
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Relocate the bus structure definition into the MDIO source code area
of the ethernet driver. So if the real bus driver is forked from the
rest of the code only one area needs to be removed. Rename it to make
clear it belongs to the bus.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18402
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Although a dfine is used to set the maxiumum number of SMI
busses (=4) it is not used at all appropriate places in the code.
Replace hard coded constants with that define.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18402
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Inside the ethernet driver lives the mdio bus. It is not always clear
what belongs where. Prefix some leftovers from the kernel 6.6 refactor
to clearly state what belongs to the bus. Group all defines together
in one place. This commit has no functional changes.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18402
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
There are no supported devices on this sub-target. It can be
considered that it is still under development. Therefore,
there is no need to make the buildbot build it every day.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/18757
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL8214FC currently uses generic PHY functions. That makes it look like a copper
device. Switching to/from fibre works fortunately but the autonegotiation handling
still works on MII_LPA (PHY register 5) as if a copper link is used. Fix that by
- advertising a superset of TP/FIBRE features
- using clause 37 functions when on fibre
Additionally enhance the code of the driver to assist further development.
- log the speed of the inserted module to detect wrongly inserted 10gbase-r modules
- order phy driver functions alphabetically (keep match/name on top)
- remove genphy_loopback as the kernel uses it if not provided
Remark! The driver internally uses PORT_MII for the TP port. Align with that and
report MII to ethtool instead of TP. Other drivers do the same and it can be
changed in the future if needed.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18724
Signed-off-by: Robert Marko <robimarko@gmail.com>
When many multicast entries are installed broadcast flooding might
potentially stop working for several ports. This is because the layer
2 broadcast flood port mask index has the wrong offset. It should be
9 bits, matching the 2^9 = 512 indexes on rtl838x, not 12.
The wrong offset leads to L2_BC_FLD_PMSK being set to 504, not 511
((511 << 12) >> 9) & 511 = 504). So, as by default an unset PMSK
is set to all ports, the issue would only become noticeable once
many multicast entries are installed, causing the 504th entry to be set
to something other than all ports.
Fixing this by setting the offset to 9 bits, to correctly point to our
511th reserved entry for all ports.
Tested-on: ZyXEL GS1900-24HP v1
Fixes: 28e972b2ea ("realtek: Configure initial L2 learning setup")
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Link: https://github.com/openwrt/openwrt/pull/18733
Signed-off-by: Robert Marko <robimarko@gmail.com>
Some DTS files have a qsgmii link mode for the CPU port. This does
not harm but it is wrong. The CPU port of the realtek switch is always
directly connected to the switch by some unknown wiring and should
therefore be described as internal. Align the wrongly defined DTS
files to the standard.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18691
Signed-off-by: Robert Marko <robimarko@gmail.com>
Commit d7e82c78d7 added a generic kernel patch that exposes a new
symbol REALTEK_PHY_HWMON when REALTEK_PHY and HWMON are enabled. The new
symbol was added to kmod-phy-realtek, but the kmod is not used in the
realtek target.
Fixes: d7e82c78d7 ("generic: backport Realtek PHY patches from upstream")
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Probing of the RTL8214FC on RTL839x is currently very strange.
- On RTL8393 nothing is detected and only generic PHY is reported
- On RTL8392 the port 1 is not detected while port 2-4 seem to work
Someone left a special RTL8393 detection rules that seems to indicate
that the we probe the internal SerDes instead. That is not true. Since
upgrade to kernel 6.6 the RTL8218/RTL8214FC detection is 100% accurate
and probing functions are only called when really needed.
Fix the issue by removing the condition. For now do PHY patching only
on the RTL838x where it already worked before.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18671
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
The ATS SFP GT-T quirk patch was backported to stable kernel 6.6 but
was not notice while bumping the kernel version as they listed the quirk
at the bottom of the SFP quirk table while our hack patch put it at the
top.
With migrating to the upstream version, the duplication was made more
apparent.
Drop the double entry for the SFP module as it's already there and not
needed and refresh patches.
Link: https://github.com/openwrt/openwrt/pull/18484
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Move all patch that got merged upstream from pending to backport and add
related tag. This is to make it easier to update to kernel 6.12.
Patch 680 required some special care as the upstream version had to be
split in a series of 6 patch.
Referesh all affected patch.
Link: https://github.com/openwrt/openwrt/pull/18464
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This patch adds support for D-Link DGS-1210-26 rev. F1
Hardware specification
----------------------
* RTL8382M SoC, 1 MIPS 4KEc core @ 500MHz
* 128MB DRAM
* 32MB NOR Flash (MX25L25635E)
* 24 x 10/100/1000BASE-T ports
* 2 x SFP ports
* Power LED
* Reset button on front panel
Installation using OEM webinterface
-----------------------------------
1. Make sure you are running OEM firmware from secondary slot. If not, switch to image2 using the menus
System > Firmware Information > Boot from image2
Tools > reboot
2. Upload image squashfs-factory_image1.bin via Tools > Backup / Upgrade Firmware > image1
3. Toggle startup image via System > Firmware Information > Boot from image1
4. Tools > reboot
Known working firmware version for this procedure: 6.20.007
Installation using TFTP and serial console
------------------------------------------
1. Prepare a TFTP server with the OpenWrt *initramfs-kernel.bin and assign it an IP from 10.90.90.0/24 (except 10.90.90.90)
2. Connect the TFTP server to one of switch's ports
3. Connect to the serial console (115200 baud) and power on the switch
4. Press the ESC key once you see "Hit Esc key to stop autoboot" in the console output
5. Press CTRL+C keys to get into the real U-Boot prompt
6. Init the network with the command "rtk network on"
7. Load the OpenWrt image with the command "tftpboot 0x8f000000 <TFTP_SERVER_IP>:<IMAGE_FILE>"
(<TFTP_SERVER_IP> is the TFTP server's IP, e.g. 10.90.90.100; <IMAGE_FILE> is the name of the image provided by the TFTP server)
8. Boot the OpenWrt image with the command "bootm"
9. Browse to https://192.168.1.1/cgi-bin/luci/admin/system/flash
10. Upload the the OpenWrt *squashfs-sysupgrade.bin to the switch
11. Wait for it to reboot
Signed-off-by: Christian Steiner <christian.steiner@outlook.de>
Link: https://github.com/openwrt/openwrt/pull/18378
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Currently, network ports using PHYs get a link, but there is no traffic.
Make it work again by moving the MAC config to phylink_mac_link_up.
A similiar change has been previously applied for RTL83xx in commit
cd958d945b ("realtek: 6.6: refactor mac config and link up for
RTL83xx").
Fixes: https://github.com/openwrt/openwrt/issues/17010
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Tested-by: Christoph Krapp <achterin@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18268
Signed-off-by: Sander Vanheule <sander@svanheule.net>
RTL8261N is used on some Airoha and Realtek devices. Move the driver
from Mediatek to generic so it can be used everywhere.
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18163
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The CONFIG_NET_SWITCHDEV option is needed by CONFIG_DSA and some other
options. It is boolean, we have to compile it into the kernel it self.
Activate it for all targets in the generic configuration, it is already
activated for most of them. This allows to install DSA drivers as a
module.
On the ramips/mt7620 target the kernel would grown by 4.5kB.
For some small targets which do not support a DSA switch by default the
option is deactivated.
Link: https://github.com/openwrt/openwrt/pull/17668
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes the handling of some FS copper SFP modules using the RollBall
protocol and needing some extra treatment.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Some devices have both the color/function and label property defined.
The label can be constructed from the former properties, making it
redundant.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
This makes sgmii work for 1000Base-T SFPs by stupidly adding the sgmii mode
wherever 1000base-x is accepted. No intelligence has been used in the
process. But it "works for me".
There is an obvious need for refactoring this code to make it more obvious
how and why we configure the mac/phy link like we do for different modes.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17950
Signed-off-by: Sander Vanheule <sander@svanheule.net>
These features have been added to the mdio-i2c driver and are now used by
the sfp driver. The support is required for some newer SFPs.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17950
Signed-off-by: Sander Vanheule <sander@svanheule.net>
This driver use "phy-handle" as a placeholder for mac configuration
data. Such handles are therefore required for all ports - even those
connected directly to SFP slots and having a managed property set to
"in-band-status".
The DSA core will register these nodes as if they are real phys. This
prevents later attachment of pluggable phys with errors like
sfp sfp-p8: sfp_add_phy failed: -EBUSY
Replace the virtual SFP slot handles with "pseudo-phy-handle" to keep
the driver logic as-is but hide the node from the DSA core.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17950
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The SMBus patch broke the logic and caused the driver to always
register an mdio bus, regardless of the sfp. Restore original
logic.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17950
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Re-probing on interface up will register a new duplicate hwmon device. Skip
the hwmon probe if we already have a sensor device.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17950
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Fix a typo which resulted in wrong .read hooks and unset .write
hooks. This made I2C_SMBUS_BLOCK_DATA transfers dereference the
NULL .write hook and Oops.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17950
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The log noise emmitted by this driver is overwhelming, even for developers
looking at specific issues. Demoting to debug allows individual messages
to be dynamically enabled instead.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17950
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Adding a static IPv4 route made the driver repeatedly print
rtl83xx_l3_nexthop_update: Setting up fwding: ip 192.168.1.42, GW mac 0000001b21a7xxxx
Route with id 3 to 192.168.99.0 / 24
rtl83xx_l3_nexthop_update: total packets: 0
Warning: TEMPLATE_FIELD_RANGE_CHK: not configured
These messages are only useful to developers while debugging offloading.
Demote to debug level, which in general is more useful for developers
by allowing precise dynamic control.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17950
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Both hardware and firmware of these devices appears identical except for the
manufacturers logo and device name. The documented XikeStor SKS8300-8X
installation method is verified to work on the ONTi ONT-S508CL-8S using
Openwrt images made for the XikeStor SKS8300-8X. This includes the OEM boot
loader magic password phrases.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/18071
Signed-off-by: Sander Vanheule <sander@svanheule.net>
By switching to the new RTL8231 driver in commit b7af54d5c1 ("realtek:
Simple conversions to RTL8231 MFD driver"), the bootloader state of the
RTL8231's pins is now maintained. As the bootloader de-asserts the PoE
enable signal, this means PoE output is no longer available.
Add a gpio-hog with high output, restoring the line value from when the
pin was configured (by default) as an input with a pull-up resistor.
This will hard-enable the PoE output, but the individual ports can still
be administratively disabled by realtek-poe or a similar tool.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The JG928A has an RTL8231 on the aux mdio bus. Add it to dts to expose
the GPIO pins used to control and monitor the fan speed. To enable speed
control, add the appropriate kernel driver module to DEVICE_PACKAGES.
Of note, this does not control all fans for the unit. The power supply
fans are not controlled.
Signed-off-by: Evan Jobling <evan@jobling.au>
Link: https://github.com/openwrt/openwrt/pull/17699
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The old RTL8231 driver integrated the MDIO bus access with the GPIO
control ops, making this driver not very portable to newer platforms.
It depended on the SoC ID instead of the compatible to determine the
MDIO access register, further complicating portability.
A new MFD driver is now available, which offers proper pin config as
well as optional LED support, which can work on any (bitbanged) MDIO
bus. Now that all devices have been migrated, we can drop the old code.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
By switching to the new RTL8231 driver in commit b7af54d5c1 ("realtek:
Simple conversions to RTL8231 MFD driver"), the bootloader state of the
RTL8231's pins is now maintained. As the bootloader de-asserts the PoE
enable signal, this means PoE output is no longer available.
Add a gpio-hog with high output, restoring the line value from when the
pin was configured (by default) as an input with a pull-up resistor.
This will hard-enable the PoE output, but the individual ports can still
be administratively disabled by realtek-poe or a similar tool.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Switch the implementation for the RTL8231 GPIO expander to the new
driver.
This allows specifying the GPIO driving the RTL8231's reset as a proper
MDIO reset line, so the gpio-hog can be dropped. Since it was pinned at
a high level, the reset line is actually active-low (i.e. high when not
in reset).
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Update the common external GPIO DTSI file for the DGS-1210 devices to
use an MDIO device on the auxilairy MDIO bus, as the original driver was
doing behind the screen.
Switching to the new driver will allow for full pin-control and will no
longer reset pin config set by the bootloader.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The DTS file for the DGS-1210-10P is slightly different from the other
DGS-1210 devices, in that it didn't specify a gpio-restart node when it
was added. The gpio-restart has been found to work on the DGS-1210-10P
as well, so switch it over to the common definitions.
This converts the last device from the product family to the common
definition for the (external) GPIOs.
Tested-by: Michel Thill <jmthill@gmail.com>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The 'indirect-access-id' property on gpio0 is a remnant from the
original GPIO driver. This property has not been relevant on the SoC's
embedded GPIO controller for a long time, so just drop it.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Change devices with RTL8231 GPIO expander definition that can easily be
translated to the new RTL8231 binding and carry over any gpio-hogs. This
will let them use the new RTL8231 MFD driver, without any functional
changes.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Zyxel GS1900-8 v2 devices have been produced more recently than v1
devices. As there are v1 boards with RTL8380M rev. C SoCs, it can likely
safely be assumed that all v2 devices will also have a recent SoC
revision, supporting the hardware auxiliary MDIO controller.
Make the GS1900-8 v1 use an emulated auxiliary MDIO bus, for backward
compatibility with devices containing an RTL8380M rev. A.
Since the devicetrees are otherwise identical, GS1900-8 v1 devices with
an RTL8380M rev. B or C will also be able to use the (more efficient) v2
image. This includes any currently functioning device with OpenWrt, so
include the old compatible as a supported device for the GS1900-8 v2.
Link: https://github.com/openwrt/openwrt/issues/9534
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The mdio-gpio driver is required to support early revision of RTL8380M
slicon (rev A) where the auxilairy MDIO controller does not function
correctly. Add this driver to the rtl838x kernel so devices with old
SoCs are also able to function correctly.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
In order to be able to define the external GPIO controller on an
emulated MDIO bus, move the controller definition outside of the main
GS1900 include for RTL838x-based devices.
Additionally, a new DTSI is provided defining the RTL8231 on the
emulated MDIO bus.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Some RTL8380M-based devices have been around for a long time and use an
early A revision of the RTL8380M SoC. This revision has an issue with
the auxiliary MDIO controller, causing it to malfunction. This may lead
to device reboots when the controller is used.
Provide a bit-banged MDIO bus, which muxes the auxiliary MDIO pins to
their GPIO function. Although this will result in lower performance,
there should otherwise be no functional differences.
Link: https://github.com/openwrt/openwrt/issues/9534
Signed-off-by: Sander Vanheule <sander@svanheule.net>
