Commit graph

51 commits

Author SHA1 Message Date
Harshal Gohel
843e8a47e2 realtek: rtl930x: Disable L3 offloading
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
L3 Offloading caused DHCP packets to be dropped at hardware level
And potentially buggy route implementation can cause a crash

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Sven Eckelmann <se@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20208
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-10-21 21:59:28 +02:00
Markus Stockhausen
b49f9d9804 realtek: backport ECC driver
Upstream will get support for the Realtek ECC engine with 6.18.
To make use of this in Openwrt

- backport upstream patches
- change config so that ECC will be built for nand subtargets
- define ECC engine in RTL93xx DTS.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19746
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-09-30 11:15:26 +02:00
Markus Stockhausen
fe27cce1ec realtek: add SerDes PCS driver
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Build all core packages / Build all core packages for selected target (push) Waiting to run
Until now the the SerDes configuration is realized with helper functions
scattered around the DSA and PHY driver. Give them a new home as a PCS
driver.

The target design is as follows:

- dsa driver manages switch
- pcs driver manages SerDes on high level (this commit)
- mdio driver manages SerDes on low level

This driver adds the high level SerDes access via PCS. It makes use of
the low level mdio SerDes driver to access the registers.

Remark: This initial version provides exactly all phylink_pcs_ops that
are currently part of the DSA driver. So this can be swapped in one of
the next commits as a drop in replacement. To make use of it something
like this is needed:

...
ports = of_get_child_by_name(node, "ethernet-ports");
if (!ports)
	return -EINVAL;

for_each_available_child_of_node(ports, port) {
	pcs_node = of_parse_phandle(port, "pcs-handle", 0);
	of_property_read_u32(port, "reg", &port_nr)) {

	priv->pcs[port_nr] = rtpcs_create(dev, pcs_node, port_nr);
}
...

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20075
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-09-20 12:51:23 +02:00
Markus Stockhausen
7a7ee72c4d realtek: mdio: add SerDes driver
Until now the SerDes access is realized with some helper functions
in the mdio bus. These were moved around a lot and had no real home.
End that temporary solution to move them where they belong.

The target design for the different Realtek drivers is as follows:

- dsa driver manages switch
- pcs driver manages SerDes on high level (to be developed)
- mdio driver manages SerDes on low level (this commit)

This driver adds the low level SerDes access via mdio. For debugging
purposes the user can interact with the SerDes in different ways.

First, there is a debug interface in
/sys/kernel/debug/realtek_otto_serdes/serdes.X/registers.
With that a dump of all registers can be shown.

> cat /sys/kernel/debug/realtek_otto_serdes/serdes.4/registers
Back SDS  4:   00   01   02   03   04   05   06   07   08
SDS        : 0C03 0F00 7060 7106 074D 0EBF 0F0F 0359 5248
SDS_EXT    : 0000 0000 85FA 8C6D 5CCC 0000 20D8 0003 79AA
...

Second, one can read/write registers via the mmd functions of the
mdio command line tool. Important to know: The registers are accessed
on the vendor specific MDIO_MMD_VEND1 device address (=30). Additionally
the SerDes page and register are concatenated into the the mmd register.
Top 8 bits are SerDes page and bottom 8 bits are SerDEs register.
E.g.

- mmd 0x0206 : SerDes page 0x02, SerDes register 0x06
- mmd 0x041f : SerDes page 0x04, SerDes register 0x1f

Read register 0x02 on page 0x03 of SerDes 0
> mdio realtek-serdes-mdio mmd 0:30 raw 0x0302

Write register 0x12 on page 0x02 of SerDes 1
> mdio realtek-serdes-mdio mmd 1:30 raw 0x0212 0x2222

For now this driver is only defined in the devicetree and activated
in the kernel build. There is no current consumer but at least
the debugging interface is available. Cleanup of the currently used
SerDes functions will come later.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20062
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-09-17 19:23:15 +02:00
Markus Stockhausen
fcd3ce6954 realtek: carve out mdio bus from ethernet driver
So much code was distributed between phy/ethernet/dsa drivers. A lot
was already cleand up before. With this step the mdio bus gets its
own space and is no longer hidden inside the ethernet driver.

This commit is mostly a copy/paste that includes only minor changes.

- define prefixes are renamed to RTMDIO
- The driver is totally self contained (does not rely on SoC include)
- The DTS structure (mdio node below ethernet node) was kept
- The driver is added to the kernel config of all subtargets.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19942
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-09-07 11:37:59 +02:00
Markus Stockhausen
41b0340ff0 realtek: backport NAND driver for RTL93xx
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>
2025-07-30 23:22:24 +02:00
Markus Stockhausen
b1597c9ad4 realtek: convert RTL838x toolchain to 24kc
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
The Realtek RTL838x devices have a MIPS 4Kec core. This has a very simple pipeline.
OpenWrt uses CPU_TYPE:=4kec to honour this and adds a dedicated toolchain with
some GB of extra space. There would be no problem if that toolchain would do what
it is expected to do. Looking at the build process one can see:

during kernel builds:
  ps -ef | grep mtune
  ... -march=mips32r2 -mtune=34kc ...

during package builds
  ps -ef | grep mtune
  ... -mips32r2 -mtune=4kec ...

So the kernel is optimized for the wrong cpu type while the applications fit fine.
Explanation for this is the generic/308-mips32r2_tune.patch. This forces kernel
builds to -mtune=34kc. Nevertheless everything runs fine since years on the RTL838x
targets.

It does not make sense to provide a dedicated 4kec toolchain for this mess. So
change the setup as follows:

- switch CPU type to mips24kc for RTL838x -> This drops one toolchain and saves space
- Add a RTl838x specific mtune=4kec patch -> Builds kernel with the proper setting

Downside is packages will be built with -mtune=24kc. So a look at a simple benchmark
should give insight if this has really a big impact. See numbers attached. To sum it
up in two sentences

- All non RSA benchmarks are within expectation
- RSA benchmarks show large deviations (before and after)

The normal usecase for these switches is definetly not a CPU intensive workload
so this is ok for now.

Before: kernel 6.12 (mtune=34kc) + apps (mtune=4kec)

root@OpenWrt:/usr/bin# ./wolfssl-benchmark
------------------------------------------------------------------------------
 wolfSSL version 5.7.6
------------------------------------------------------------------------------
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
RNG                          5 MiB took 1.426 seconds,    3.507 MiB/s
AES-128-CBC-enc              5 MiB took 1.178 seconds,    4.243 MiB/s
AES-128-CBC-dec              5 MiB took 1.171 seconds,    4.270 MiB/s
AES-192-CBC-enc              5 MiB took 1.307 seconds,    3.824 MiB/s
AES-192-CBC-dec              5 MiB took 1.311 seconds,    3.815 MiB/s
AES-256-CBC-enc              5 MiB took 1.447 seconds,    3.455 MiB/s
AES-256-CBC-dec              5 MiB took 1.421 seconds,    3.519 MiB/s
AES-128-GCM-enc              5 MiB took 3.772 seconds,    1.325 MiB/s
AES-128-GCM-dec              5 MiB took 3.756 seconds,    1.331 MiB/s
AES-192-GCM-enc              5 MiB took 3.939 seconds,    1.269 MiB/s
AES-192-GCM-dec              5 MiB took 3.932 seconds,    1.272 MiB/s
AES-256-GCM-enc              5 MiB took 4.043 seconds,    1.237 MiB/s
AES-256-GCM-dec              5 MiB took 4.033 seconds,    1.240 MiB/s
GMAC Default                 2 MiB took 1.056 seconds,    1.895 MiB/s
AES-128-CTR                  5 MiB took 1.195 seconds,    4.185 MiB/s
AES-192-CTR                  5 MiB took 1.319 seconds,    3.791 MiB/s
AES-256-CTR                  5 MiB took 1.460 seconds,    3.425 MiB/s
AES-CCM-enc                  5 MiB took 2.279 seconds,    2.194 MiB/s
AES-CCM-dec                  5 MiB took 2.273 seconds,    2.200 MiB/s
ARC4                        20 MiB took 1.226 seconds,   16.315 MiB/s
CHACHA                      15 MiB took 1.001 seconds,   14.982 MiB/s
CHA-POLY                    15 MiB took 1.440 seconds,   10.416 MiB/s
3DES                         5 MiB took 4.364 seconds,    1.146 MiB/s
MD5                         25 MiB took 1.034 seconds,   24.173 MiB/s
POLY1305                    35 MiB took 1.015 seconds,   34.467 MiB/s
SHA                         25 MiB took 1.127 seconds,   22.183 MiB/s
SHA-256                     10 MiB took 1.104 seconds,    9.056 MiB/s
SHA-384                      5 MiB took 1.324 seconds,    3.775 MiB/s
SHA-512                      5 MiB took 1.325 seconds,    3.774 MiB/s
SHA-512/224                  5 MiB took 1.319 seconds,    3.791 MiB/s
SHA-512/256                  5 MiB took 1.333 seconds,    3.751 MiB/s
AES-128-CMAC                 5 MiB took 1.145 seconds,    4.366 MiB/s
AES-256-CMAC                 5 MiB took 1.413 seconds,    3.539 MiB/s
HMAC-MD5                    25 MiB took 1.034 seconds,   24.186 MiB/s
HMAC-SHA                    25 MiB took 1.122 seconds,   22.272 MiB/s
HMAC-SHA256                 10 MiB took 1.104 seconds,    9.059 MiB/s
HMAC-SHA384                  5 MiB took 1.329 seconds,    3.762 MiB/s
HMAC-SHA512                  5 MiB took 1.323 seconds,    3.778 MiB/s
PBKDF2                       1 KiB took 1.018 seconds,    1.136 KiB/s
RSA     2048  key gen         1 ops took 15.547 sec, avg 15547.322 ms, 0.064 ops/sec
RSA     3072  key gen         1 ops took 66.131 sec, avg 66131.134 ms, 0.015 ops/sec
RSA     4096  key gen         1 ops took 563.611 sec, avg 563611.230 ms, 0.002 ops/sec
RSA     2048   public       200 ops took 1.403 sec, avg 7.015 ms, 142.542 ops/sec
RSA     2048  private       100 ops took 39.099 sec, avg 390.991 ms, 2.558 ops/sec
DH      2048  key gen        14 ops took 1.009 sec, avg 72.094 ms, 13.871 ops/sec
DH      2048    agree       100 ops took 15.714 sec, avg 157.139 ms, 6.364 ops/sec
ECC   [      SECP256R1]   256  key gen       100 ops took 5.590 sec, avg 55.901 ms, 17.889 ops/sec
ECDHE [      SECP256R1]   256    agree       100 ops took 5.555 sec, avg 55.554 ms, 18.001 ops/sec
ECDSA [      SECP256R1]   256     sign       100 ops took 5.705 sec, avg 57.048 ms, 17.529 ops/sec
ECDSA [      SECP256R1]   256   verify       100 ops took 4.396 sec, avg 43.963 ms, 22.746 ops/sec
CURVE  25519  key gen       320 ops took 1.000 sec, avg 3.127 ms, 319.841 ops/sec
CURVE  25519    agree       400 ops took 1.214 sec, avg 3.034 ms, 329.546 ops/sec
Benchmark complete

After: kernel 6.12 (mtune=4kec) + apps (mtune=24kc)

root@OpenWrt:~# wolfssl-benchmark
------------------------------------------------------------------------------
 wolfSSL version 5.7.6
------------------------------------------------------------------------------
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
RNG                          5 MiB took 1.428 seconds,    3.501 MiB/s
AES-128-CBC-enc              5 MiB took 1.174 seconds,    4.258 MiB/s
AES-128-CBC-dec              5 MiB took 1.162 seconds,    4.301 MiB/s
AES-192-CBC-enc              5 MiB took 1.307 seconds,    3.826 MiB/s
AES-192-CBC-dec              5 MiB took 1.313 seconds,    3.809 MiB/s
AES-256-CBC-enc              5 MiB took 1.432 seconds,    3.491 MiB/s
AES-256-CBC-dec              5 MiB took 1.426 seconds,    3.506 MiB/s
AES-128-GCM-enc              5 MiB took 3.761 seconds,    1.329 MiB/s
AES-128-GCM-dec              5 MiB took 3.748 seconds,    1.334 MiB/s
AES-192-GCM-enc              5 MiB took 3.918 seconds,    1.276 MiB/s
AES-192-GCM-dec              5 MiB took 3.922 seconds,    1.275 MiB/s
AES-256-GCM-enc              5 MiB took 4.019 seconds,    1.244 MiB/s
AES-256-GCM-dec              5 MiB took 4.014 seconds,    1.246 MiB/s
GMAC Default                 2 MiB took 1.052 seconds,    1.900 MiB/s
AES-128-CTR                  5 MiB took 1.189 seconds,    4.205 MiB/s
AES-192-CTR                  5 MiB took 1.315 seconds,    3.804 MiB/s
AES-256-CTR                  5 MiB took 1.455 seconds,    3.436 MiB/s
AES-CCM-enc                  5 MiB took 2.257 seconds,    2.215 MiB/s
AES-CCM-dec                  5 MiB took 2.269 seconds,    2.204 MiB/s
ARC4                        15 MiB took 1.062 seconds,   14.124 MiB/s
CHACHA                      15 MiB took 1.008 seconds,   14.880 MiB/s
CHA-POLY                    15 MiB took 1.461 seconds,   10.266 MiB/s
3DES                         5 MiB took 4.347 seconds,    1.150 MiB/s
MD5                         25 MiB took 1.029 seconds,   24.291 MiB/s
POLY1305                    35 MiB took 1.024 seconds,   34.181 MiB/s
SHA                         25 MiB took 1.115 seconds,   22.418 MiB/s
SHA-256                     10 MiB took 1.154 seconds,    8.664 MiB/s
SHA-384                      5 MiB took 1.345 seconds,    3.718 MiB/s
SHA-512                      5 MiB took 1.343 seconds,    3.723 MiB/s
SHA-512/224                  5 MiB took 1.350 seconds,    3.703 MiB/s
SHA-512/256                  5 MiB took 1.345 seconds,    3.718 MiB/s
AES-128-CMAC                 5 MiB took 1.143 seconds,    4.376 MiB/s
AES-256-CMAC                 5 MiB took 1.405 seconds,    3.559 MiB/s
HMAC-MD5                    25 MiB took 1.027 seconds,   24.334 MiB/s
HMAC-SHA                    25 MiB took 1.112 seconds,   22.490 MiB/s
HMAC-SHA256                 10 MiB took 1.096 seconds,    9.125 MiB/s
HMAC-SHA384                  5 MiB took 1.344 seconds,    3.721 MiB/s
HMAC-SHA512                  5 MiB took 1.347 seconds,    3.712 MiB/s
PBKDF2                       1 KiB took 1.012 seconds,    1.142 KiB/s
RSA     2048  key gen         1 ops took 27.136 sec, avg 27136.046 ms, 0.037 ops/sec
RSA     3072  key gen         1 ops took 39.922 sec, avg 39922.464 ms, 0.025 ops/sec
RSA     4096  key gen         1 ops took 519.483 sec, avg 519482.959 ms, 0.002 ops/sec
RSA     2048   public       200 ops took 1.398 sec, avg 6.989 ms, 143.073 ops/sec
RSA     2048  private       100 ops took 40.412 sec, avg 404.121 ms, 2.475 ops/sec
DH      2048  key gen        14 ops took 1.033 sec, avg 73.764 ms, 13.557 ops/sec
DH      2048    agree       100 ops took 16.401 sec, avg 164.009 ms, 6.097 ops/sec
ECC   [      SECP256R1]   256  key gen       100 ops took 5.583 sec, avg 55.830 ms, 17.912 ops/sec
ECDHE [      SECP256R1]   256    agree       100 ops took 5.555 sec, avg 55.549 ms, 18.002 ops/sec
ECDSA [      SECP256R1]   256     sign       100 ops took 5.703 sec, avg 57.032 ms, 17.534 ops/sec
ECDSA [      SECP256R1]   256   verify       100 ops took 4.203 sec, avg 42.030 ms, 23.792 ops/sec
CURVE  25519  key gen       315 ops took 1.001 sec, avg 3.176 ms, 314.822 ops/sec
CURVE  25519    agree       400 ops took 1.244 sec, avg 3.110 ms, 321.579 ops/sec
Benchmark complete

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19117
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-30 10:34:25 +02:00
Jonas Jelonek
12f13b227c realtek: remove patches, files and config for 6.6
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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>
2025-06-22 16:38:11 +02:00
Hauke Mehrtens
c695cf6109 kernel: Refresh kernel configs
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>
2025-06-22 11:28:09 +02:00
Markus Stockhausen
5b8155d434 realtek: activate i2c-gpio-shared driver
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>
2025-06-17 10:52:42 +02:00
Markus Stockhausen
c056cc8bb5 realtek: 6.12: restore config-6.6
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>
2025-06-11 22:27:21 +02:00
Markus Stockhausen
296a16bc28 realtek: 6.12: create config-6.12 from config-6.6
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>
2025-06-11 22:27:21 +02:00
Shiji Yang
0f8091334c kernel: reorder kernel symbol configs
Sort kernel configuration files alphabetically. Also resolve the
"CONFIG_ARM_PAN" conflict introduced in commit
057a0a075e ("generic: Fix up the v6.12 config for ARM"). Based on
the original PR comment[1], this symbol should be disabled by default.

[1] https://github.com/openwrt/openwrt/pull/18900#discussion_r2106253528
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/18947
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-05-29 23:05:02 +02:00
Stijn Tintel
ab87087672 realtek: add missing symbol
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>
2025-05-03 23:23:10 +03:00
Hauke Mehrtens
abd0418684 kernel: Activate CONFIG_NET_SWITCHDEV in generic config
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>
2025-03-15 13:54:59 +01:00
Bjørn Mork
864d6743ee realtek: thermal driver for rtl838x and rtl930x SoCs
Add simple driver reading the internal temperature sensor.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17967
Signed-off-by: Sander Vanheule <sander@svanheule.net>
2025-02-27 19:24:44 +01:00
Sander Vanheule
b410f2216c realtek: drop old RTL8231 driver
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>
2025-02-05 20:55:19 +01:00
Sander Vanheule
efffcfa436 realtek: rtl838x: Enable MDIO_GPIO driver
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>
2025-01-25 15:06:03 +01:00
Sander Vanheule
5141e2d861 realtek: rtl838x: Switch GS1900 rtl8231 driver
Update the devicetree files to switch the GS1900 devices over to the new
pinctrl and GPIO driver. Enable the drivers to ensure the nodes can be
used.

This may fix issues caused by bad RMW behaviour on the GPIO data lines,
or glitches due to setting the pin direction before the pin level.

Although the driver supports retaining GPIO state after a warm boot,
some bootloaders appear to apply a default configuration on boot, which
may cause an interrupt in PoE-PSE support.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
2025-01-07 14:36:34 +01:00
Sander Vanheule
6ef6014887 realtek: Add pinctrl support for RTL8231
Add pending patches to add RTL8231 support as a MDIO-bus attached
multi-functional device. This includes subdrivers for the pincontrol and
GPIO features, as well as the LED matrix support.

Leave the drivers disabled until required by a device.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
2025-01-07 14:36:34 +01:00
Sander Vanheule
92ae8cb16c realtek: rtl838x: Instantiate auxiliary MDIO bus
Add a disabled node for the auxiliary MDIO bus, used to manage the
RTL8231 expanders. A simple-mfd parent node is added, at the same
(implied) address as the switch@1b000000 node, as the switch drivers
should anyway transistion to MFD subdivices at some point.

Additionally, two pinctrl-single node are added to allow the MDX pins to
be muxed correctly, in case the bootloader leaves these unconfigured.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
2025-01-07 14:36:34 +01:00
Sander Vanheule
ae833c01b3 realtek: Add driver for auxiliary MDIO busses
Add a driver that exposes the auxiliary busses, used for the RTL8231
expanders, as a proper MDIO controller. The device must be instantiated
under an MFD device, so the driver should also be compatible with SoC
managed by an external CPU via SPI.

Leave the driver disabled in builds until required.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
2025-01-07 14:36:34 +01:00
Sander Vanheule
a6edcb4cb0 realtek: rtl838x: Refresh kernel config
Run 'make kernel_oldconfig' to get an up-to-date config.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
2025-01-07 14:36:34 +01:00
Markus Stockhausen
65964c42f8 realtek: align kernel config with upstream
Since the start of the Realtek target OpenWrt works with RTL83XX as the
target architecture. Upstream is using MACH_REALTEK_RTL instead. To
simplify further development align that.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/16963
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-11-16 18:02:18 +01:00
Mieczyslaw Nalewaj
3dd3c61c30 realtek: drop 5.15 support
Drop config and files for Linux 5.15.

Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/16417
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-09-20 11:16:02 +02:00
Markus Stockhausen
325d79f0f9 realtek: 6.6: copy files and config from 5.15
Copy files and config from 5.15 kernel version. Because of the big version jump
leave out the patches for now so we can treat them individually later on.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2024-09-14 19:58:54 +02:00
Nick Hainke
1d3e71bd97
treewide: remove files for building 5.10 kernel
All targets are bumped to 5.15. Remove the old 5.10 patches, configs
and files using:

  find target/linux -iname '*-5.10' -exec rm -r {} \;

Further, remove the 5.10 include.

Signed-off-by: Nick Hainke <vincent@systemli.org>
2023-05-12 13:02:43 +02:00
Hauke Mehrtens
0fc3a4aa10 kernel: Deactivate CONFIG_LEGACY_PTYS
The legacy (BSD) PTY support could open security problems in a system,
We do not need them in OpenWrt, deactivate this option in all targets.

Debian also deactivates this option.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2023-04-29 21:56:53 +02:00
Sander Vanheule
a336b6c7cf realtek: remove KERNEL_PATCHVER overrides
On the realtek target, the subtarget makefiles include a KERNEL_PATCHVER
setting, shadowing KERNEL_PATCHVER from target/linux/realtek/Makefile.
This makes the realtek target an exception in this regard, and makes
switching kernel version a bit bothersome. Remove the overrides so all
subtargets use the same kernel version.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
2023-01-29 16:29:42 +01:00
Olliver Schinagl
1bf39d91d5 realtek: Refresh kernel config with no_except_fill
Update the config files with the previous commit.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
2023-01-24 21:00:19 +01:00
Olliver Schinagl
c9a7c00f80 realtek: Disable boston clock
We are not on the 'boston' platform so no point in having that clock
driver enabled.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
2023-01-01 22:31:20 +01:00
Olliver Schinagl
94d8b4852b realtek: Cleanup Makefiles
Our current Makefiles a little bit messy and can be improved somewhat,
both in whitespace and in style.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
2022-12-27 16:33:15 +01:00
INAGAKI Hiroshi
f3a9975549 realtek: refresh config-5.15 in all subtargets
Refresh config-5.15 in all subtargets by kernel_menuconfig.

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
2022-12-15 20:52:40 +01:00
INAGAKI Hiroshi
8fb15ea52a realtek: copy dts/files/patches/configs for 5.15
Copy dts/files/patches/configs from 5.10 to 5.15.

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
[refresh with updated DGS-1210 dts files]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
2022-12-15 20:52:09 +01:00
Markus Stockhausen
ec675fb744 realtek: timer driver: activate for RTL838X devices
Use the new timer driver for the RTL838X devices. Remove the no
longer needed modules.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[correct timer compatible order, update selected symbols]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
2022-10-23 22:33:08 +02:00
Markus Stockhausen
7c18aab6e0 realtek: activate clock driver for RTL838X/RTL839X targets
Make use the new clock driver for RTL838X and RTL839x target devices. Of course
we will enable their primary consumer (cpufreq-dt) too. To be careful just set
the default governor to userspace. As we rely on SRAM activate that module too.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2022-08-28 11:48:30 +02:00
Alexandru Gagniuc
6d5873a162 realtek: add support for TP-Link SG2008P
Add support for the TP-Link SG2008P switch. This is an RTL8380 based
switch with 802.3af one the first four ports.

Specifications:
---------------
 * SoC:       Realtek RTL8380M
 * Flash:     32 MiB SPI flash (Vendor varies)
 * RAM:       256 MiB (Vendor varies)
 * Ethernet:  8x 10/100/1000 Mbps with PoE on 4 ports
 * Buttons:   1x "Reset" button on front panel
 * Power:     53.5V DC barrel jack
 * UART:      1x serial header, unpopulated
 * PoE:       1x TI TPS23861 I2C PoE controller

Works:
------
  - (8) RJ-45 ethernet ports
  - Switch functions
  - System LED

Not yet enabled:
----------------
  - Power-over-Ethernet (driver works, but doesn't enable "auto" mode)
  - PoE, Link/Act, PoE max and System LEDs

Install via web interface:
-------------------------

Not supported at this time.

Install via serial console/tftp:
--------------------------------

The footprints R27 (0201) and R28 (0402) are not populated. To enable
serial console, 50 ohm resistors should be soldered -- any value from
0 ohm to 50 ohm will work. R27 can be replaced by a solder bridge.

The u-boot firmware drops to a TP-Link specific "BOOTUTIL" shell at
38400 baud. There is no known way to exit out of this shell, and no
way to do anything useful.

Ideally, one would trick the bootloader into flashing the sysupgrade
image first. However, if the image exceeds 6MiB in size, it will not
work. The sysupgrade image can also be flashed. To install OpenWRT:

Prepare a tftp server with:
 1. server address: 192.168.0.146
 2. the image as: "uImage.img"

Power on device, and stop boot by pressing any key.
Once the shell is active:
 1. Ground out the CLK (pin 16) of the ROM (U7)
 2. Select option "3. Start"
 3. Bootloader notes that "The kernel has been damaged!"
 4. Release CLK as sson as bootloader thinks image is corrupted.
 5. Bootloader enters automatic recovery -- details printed on console
 6. Watch as the bootloader flashes and boots OpenWRT.

Blind install via tftp:
-----------------------

This method works when it's not feasible to install a serial header.

Prepare a tftp server with:
 1. server address: 192.168.0.146
 2. the image as: "uImage.img"
 3. Watch network traffic (tcpdump or wireshark works)
 4. Power on the device.
 5. Wait 1-2 seconds then ground out the CLK (pin 16) of the ROM (U7)
 6. When 192.168.0.30 makes tftp requests, release pin 16
 7. Wait 2-3 minutes for device to auto-flash and boot OpenWRT

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2022-08-13 19:59:47 +02:00
Hauke Mehrtens
ff06edd1f0 kernel: Activate CONFIG_GPIOLIB in generic configuration
All targets expect the malta target already activate the CONFIG_GPIOLIB
option. Move it to generic kernel configuration and also activate it for
malta.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2022-08-10 21:36:17 +02:00
Daniel Golle
a49212d762 Revert "realtek: remove support for HPE 1920 series"
This reverts commit a63aeaecf1.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-07-28 16:45:19 +02:00
Sander Vanheule
a63aeaecf1 realtek: remove support for HPE 1920 series
Support for HPE 1920 images depends on two non-existent tools (mkh3cimg
and mkh3cvfs) from the in the firmware-utils package. Revert commit
f2f09bc002 ("realtek: add support for HPE 1920 series") until support
for these tools is merged and made available in OpenWrt.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
2022-07-28 15:17:04 +02:00
Jan Hoffmann
f2f09bc002 realtek: add support for HPE 1920 series
Hardware information:
---------------------

- HPE 1920-8G:
  - RTL8380 SoC
  - 8 Gigabit RJ45 ports (built-in RTL8218B)
  - 2 SFP ports (built-in SerDes)

- HPE 1920-16G / HPE 1920-24G (same board):
  - RTL8382 SoC
  - 16/24 Gigabit RJ45 ports (built-in RTL8218B, 1/2 external RTL8218D)
  - 4 SFP ports (external RTL8214FC)

- Common:
  - RJ45 RS232 port on front panel
  - 32 MiB NOR Flash
  - 128 MiB DDR3 DRAM
  - PT7A7514 watchdog

Booting initramfs image:
------------------------

- Prepare a FTP or TFTP server serving the OpenWrt initramfs image and
  connect the server to a switch port.

- Connect to the console port of the device and enter the extended
  boot menu by typing Ctrl+B when prompted.

- Choose the menu option "<3> Enter Ethernet SubMenu".

- Set network parameters via the option "<5> Modify Ethernet Parameter".
  Enter the FTP/TFTP filename as "Load File Name" ("Target File Name"
  can be left blank, it is not required for booting from RAM). Note that
  the configuration is saved on flash, so it only needs to be done once.

- Select "<1> Download Application Program To SDRAM And Run".

Initial installation:
---------------------

- Boot an initramfs image as described above, then use sysupgrade to
  install OpenWrt permanently. After initial installation, the
  bootloader needs to be configured to load the correct image file

- Enter the extended boot menu again and choose "<4> File Control",
  then select "<2> Set Application File type".

- Enter the number of the file "openwrt-kernel.bin" (should be 1), and
  use the option "<1> +Main" to select it as boot image.

- Choose "<0> Exit To Main Menu" and then "<1> Boot System".

NOTE: The bootloader on these devices can only boot from the VFS
filesystem which normally spans most of the flash. With OpenWrt, only
the first part of the firmware partition contains a valid filesystem,
the rest is used for rootfs. As the bootloader does not know about this,
you must not do any file operations in the bootloader, as this may
corrupt the OpenWrt installation (selecting the boot image is an
exception, as it only stores a flag in the bootloader data, but doesn't
write to the filesystem).

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
2022-07-28 14:08:56 +02:00
Tomasz Maciej Nowak
539e60539a generic: enable CRYPTO_LIB_BLAKE2S[_X86|_ARM]
This is now built-in, enable so it won't propagate on target configs.

Link: https://lkml.org/lkml/2022/1/3/168
Fixes: 79e7a2552e ("kernel: bump 5.15 to 5.15.44")
Fixes: 0ca9367069 ("kernel: bump 5.10 to 5.10.119")
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(Link to Kernel's commit taht made it built-in,
CRYPTO_LIB_BLAKE2S[_ARM|_X86] as it's selectable, 5.10 backport)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2022-06-24 17:10:24 +02:00
Tony Ambardar
76fae1d169 config: limit CONFIG_DEBUG_INFO to top-level generic configs
Remove redundant target-level entries, noting that these settings will be
configured from "Kernel build options" of Kconfig.

Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[remove from new configs introduced after patch submission]
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
2022-05-18 13:32:06 +03:00
INAGAKI Hiroshi
da1347d6d6 realtek: enable pca953x driver for rtl838x subtarget
The system status LED on Panasonic Switch-M8eG PN28080K is connected to
a PCA9539PW. To use the LED as a status LED of OpenWrt while booting,
enable the pca953x driver and built-in to the kernel.
Also enable CONFIG_GPIO_PCA953X_IRQ to use interrupt via RTL83xx GPIO.

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Acked-by: Sander Vanheule <sander@svanheule.net>
2022-03-13 19:54:57 +01:00
Birger Koblitz
5cb2828092 realtek: Use new CEVT timer
Selects the new CEVT timer for Realtek instead of the previous
timer driver. While we are at it, we explicitily state we do
not use the I2C driver of the RTL9300.

Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
2022-02-17 15:21:47 +00:00
Birger Koblitz
b3287a2165 realtek: Increase zone size for Ethernet driver DMA
Set CONFIG_FORCE_MAX_ZONEORDER setting to 13 to allow larger
contiguous memory allocation for the DMA of the Ethernet
driver. Increase the number of entries in the RX ring
to 300 making use of the larger DMA region now possible for
receiveing packets.

Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
2022-02-17 15:21:47 +00:00
Birger Koblitz
4021dd527b realtek: Optimize kernel configuration for RTL838X
The RTL838X SoCs do not use Aquantia PHYs, remove this.
Also the RTL838X uses a high resolution R4K timer.

Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
2022-02-17 15:21:47 +00:00
Birger Koblitz
fce11f6849 realtek: Create 4 different Realtek Platforms
Creates RTL83XX as a basic kernel config parameter for the
RTL838X, RTL839x, RTL930X and RTL931X platforms with respective
configurations for the SoCs, which are introduced in addition.

Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
2022-02-17 15:21:47 +00:00
Birger Koblitz
47be1943ed realtek: Add initial kernel config for RTL838x sub-target
Move the generic kernel configs to the rtl838x sub-target.

Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
2022-02-17 15:21:46 +00:00
Birger Koblitz
cf8e145955 realtek: Set RTL838X sub-target specific properties
This defines the sub-target specific properties for the RTL838X
sub-target.

Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
2022-02-17 15:21:46 +00:00