aboutsummaryrefslogtreecommitdiff
path: root/target/linux/realtek/rtl838x
Commit message (Collapse)AuthorAge
* realtek: backport NAND driver for RTL93xxMarkus Stockhausen2025-07-30
| | | | | | | | | | 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>
* realtek: convert RTL838x toolchain to 24kcMarkus Stockhausen2025-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* realtek: remove patches, files and config for 6.6Jonas Jelonek2025-06-22
| | | | | | | | 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>
* kernel: Refresh kernel configsHauke Mehrtens2025-06-22
| | | | | | | | | 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>
* realtek: activate i2c-gpio-shared driverMarkus Stockhausen2025-06-17
| | | | | | | | | 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>
* realtek: 6.12: restore config-6.6Markus Stockhausen2025-06-11
| | | | | | | | 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>
* realtek: 6.12: create config-6.12 from config-6.6Markus Stockhausen2025-06-11
| | | | | | | | 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>
* kernel: reorder kernel symbol configsShiji Yang2025-05-29
| | | | | | | | | | | | Sort kernel configuration files alphabetically. Also resolve the "CONFIG_ARM_PAN" conflict introduced in commit 057a0a075edc ("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>
* realtek: add missing symbolStijn Tintel2025-05-03
| | | | | | | | | | Commit d7e82c78d7a2 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: d7e82c78d7a2 ("generic: backport Realtek PHY patches from upstream") Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
* kernel: Activate CONFIG_NET_SWITCHDEV in generic configHauke Mehrtens2025-03-15
| | | | | | | | | | | | | | | | 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>
* realtek: thermal driver for rtl838x and rtl930x SoCsBjørn Mork2025-02-27
| | | | | | | | 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>
* realtek: drop old RTL8231 driverSander Vanheule2025-02-05
| | | | | | | | | | | | | 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>
* realtek: rtl838x: Enable MDIO_GPIO driverSander Vanheule2025-01-25
| | | | | | | | | 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>
* realtek: rtl838x: Switch GS1900 rtl8231 driverSander Vanheule2025-01-07
| | | | | | | | | | | | | | | 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>
* realtek: Add pinctrl support for RTL8231Sander Vanheule2025-01-07
| | | | | | | | | | 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>
* realtek: rtl838x: Instantiate auxiliary MDIO busSander Vanheule2025-01-07
| | | | | | | | | | | | 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>
* realtek: Add driver for auxiliary MDIO bussesSander Vanheule2025-01-07
| | | | | | | | | | | 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>
* realtek: rtl838x: Refresh kernel configSander Vanheule2025-01-07
| | | | | | Run 'make kernel_oldconfig' to get an up-to-date config. Signed-off-by: Sander Vanheule <sander@svanheule.net>
* realtek: align kernel config with upstreamMarkus Stockhausen2024-11-16
| | | | | | | | | | 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>
* realtek: drop 5.15 supportMieczyslaw Nalewaj2024-09-20
| | | | | | | | 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>
* realtek: 6.6: copy files and config from 5.15Markus Stockhausen2024-09-14
| | | | | | | 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>
* treewide: remove files for building 5.10 kernelNick Hainke2023-05-12
| | | | | | | | | | | 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>
* kernel: Deactivate CONFIG_LEGACY_PTYSHauke Mehrtens2023-04-29
| | | | | | | | | 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>
* realtek: remove KERNEL_PATCHVER overridesSander Vanheule2023-01-29
| | | | | | | | | | 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>
* realtek: Refresh kernel config with no_except_fillOlliver Schinagl2023-01-24
| | | | | | Update the config files with the previous commit. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
* realtek: Disable boston clockOlliver Schinagl2023-01-01
| | | | | | | We are not on the 'boston' platform so no point in having that clock driver enabled. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
* realtek: Cleanup MakefilesOlliver Schinagl2022-12-27
| | | | | | | 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>
* realtek: refresh config-5.15 in all subtargetsINAGAKI Hiroshi2022-12-15
| | | | | | Refresh config-5.15 in all subtargets by kernel_menuconfig. Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* realtek: copy dts/files/patches/configs for 5.15INAGAKI Hiroshi2022-12-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>
* realtek: timer driver: activate for RTL838X devicesMarkus Stockhausen2022-10-23
| | | | | | | | | 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>
* realtek: activate clock driver for RTL838X/RTL839X targetsMarkus Stockhausen2022-08-28
| | | | | | | | 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>
* realtek: add support for TP-Link SG2008PAlexandru Gagniuc2022-08-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* kernel: Activate CONFIG_GPIOLIB in generic configurationHauke Mehrtens2022-08-10
| | | | | | | | 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>
* Revert "realtek: remove support for HPE 1920 series"Daniel Golle2022-07-28
| | | | | | This reverts commit a63aeaecf1f3387df020854c9b22a365207399ce. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* realtek: remove support for HPE 1920 seriesSander Vanheule2022-07-28
| | | | | | | | | Support for HPE 1920 images depends on two non-existent tools (mkh3cimg and mkh3cvfs) from the in the firmware-utils package. Revert commit f2f09bc00280 ("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>
* realtek: add support for HPE 1920 seriesJan Hoffmann2022-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* generic: enable CRYPTO_LIB_BLAKE2S[_X86|_ARM]Tomasz Maciej Nowak2022-06-24
| | | | | | | | | | | | This is now built-in, enable so it won't propagate on target configs. Link: https://lkml.org/lkml/2022/1/3/168 Fixes: 79e7a2552e89 ("kernel: bump 5.15 to 5.15.44") Fixes: 0ca93670693b ("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>
* config: limit CONFIG_DEBUG_INFO to top-level generic configsTony Ambardar2022-05-18
| | | | | | | | | | 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>
* realtek: enable pca953x driver for rtl838x subtargetINAGAKI Hiroshi2022-03-13
| | | | | | | | | | 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>
* realtek: Use new CEVT timerBirger Koblitz2022-02-17
| | | | | | | | 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>
* realtek: Increase zone size for Ethernet driver DMABirger Koblitz2022-02-17
| | | | | | | | | | 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>
* realtek: Optimize kernel configuration for RTL838XBirger Koblitz2022-02-17
| | | | | | | 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>
* realtek: Create 4 different Realtek PlatformsBirger Koblitz2022-02-17
| | | | | | | | 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>
* realtek: Add initial kernel config for RTL838x sub-targetBirger Koblitz2022-02-17
| | | | | | Move the generic kernel configs to the rtl838x sub-target. Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: Set RTL838X sub-target specific propertiesBirger Koblitz2022-02-17
| | | | | | | This defines the sub-target specific properties for the RTL838X sub-target. Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
* realtek: Create rtl838x subtargetBirger Koblitz2022-02-17
mv generic/target.mk to rtl838x/target.mk in order to create an initial makefile for the rtl838x sub-architecture Signed-off-by: Birger Koblitz <git@birger-koblitz.de>
Powered by cgit, Themed by Ted Yin.