aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/realtek
Commit message (Collapse)AuthorAgeFilesLines
* kernel: bump 5.10 to 5.10.146John Audia2022-10-041-1/+1
| | | | | | | All patches automatically rebased. Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit eed0a31b90e4feeb65f3b54853bd4db1f5bcd524)
* kernel: bump 5.10 to 5.10.144John Audia2022-10-041-1/+1
| | | | | | | All patches automatically rebased. Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit eff4f8b2f0a2900c945c21c8183d1faa0ac35ec1)
* kernel: bump 5.10 to 5.10.139John Audia2022-09-171-1/+1
| | | | | | | All patches automatically rebased. Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit e0753c5d5cef5b03c60601364188afb262ccd02e)
* realtek: fix RTL839x receive tag decodingBjørn Mork2022-09-091-2/+2
| | | | | | | | | | The previous fixup was incomplete, and the offsets for the queue and crc_error cpu_tag bitfields were still wrong on RTL839x. Fixes: 545c6113c93b ("realtek: fix RTL838x receive tag decoding") Suggested-by: Jan Hoffmann <jan@3e8.eu> Signed-off-by: Bjørn Mork <bjorn@mork.no>
* realtek: fix RTL838x receive tag decodingBjørn Mork2022-09-081-3/+6
| | | | | | | | | | | | | | | | | | | | Commit dc9cc0d3e2a1 ("realtek: add QoS and rate control") replaced a 16 bit reserved field in the RTL83xx packet header with the initial cpu_tag word, shifting the real cpu_tag fields by one. Adjusting for this new shift was partially forgotten in the new RX tag decoders. This caused the switch to block IGMP, effectively blocking IPv4 multicast. The bug was partially fixed by commit 9d847244d9fd ("realtek: fix RTL839X receive tag decoding") Fix on RTL838x too, including correct NIC_RX_REASON_SPECIAL_TRAP value. Suggested-by: Jan Hoffmann <jan@3e8.eu> Fixes: dc9cc0d3e2a1 ("realtek: add QoS and rate control") Signed-off-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit 545c6113c93bbf7de1b0e515141a4565f7e6cece)
* realtek: Fix typo in Kconfig promptOlliver Schinagl2022-08-061-1/+1
| | | | | | | | | | As the symbol RTL930x shows, the bool enables the RTL930x platform, not the RTL839x one. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> (slightly changed commit subject) Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (cherry picked from commit 943905b0b6ee59fb7eaf3611960c0ec87ed61bbc)
* realtek: correct egress frame port verificationSander Vanheule2022-07-212-39/+36
| | | | | | | | | | | | | | | | | | | | | Destination switch ports for outgoing frame can range from 0 to CPU_PORT-1. Refactor the code to only generate egress frame CPU headers when a valid destination port number is available, and make the code a bit more consistent between different switch generations. Change the dest_port argument's type to 'unsigned int', since only positive values are valid. This fixes the issue where egress frames on switch port 0 did not receive a VLAN tag, because they are sent out without a CPU header. Also fixes a potential issue with invalid (negative) egress port numbers on RTL93xx switches. Reported-by: Arınç ÜNAL <arinc.unal@xeront.com> Suggested-by: Birger Koblitz <mail@birger-koblitz.de> Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit 1773264a0c6da099af7f36046f95f0126d6de1eb)
* realtek: correct egress frame priority assignmentSander Vanheule2022-07-211-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Priority values passed to the egress (TX) frame header initialiser are invalid when smaller than 0, and should not be assigned to the frame. Queue assignment is then left to the switch core logic. Current code for RTL83xx forces the passed priority value to be positive, by always masking it to the lower bits, resulting in the priority always being set and enabled. RTL93xx code doesn't even check the value and unconditionally assigns the (32 bit) value to the (5 bit) QID field without masking. Fix priority assignment by only setting the AS_QID/AS_PRI flag when a valid value is passed, and properly mask the value to not overflow the QID/PRI field. For RTL839x, also assign the priority to the right part of the frame header. Counting from the leftmost bit, AS_PRI and PRI are in bits 36 and 37-39. The means they should be assigned to the third 16 bit value, containing bits 32-47. Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit 0b35a08a057848d909156604c4391a5d9f1d97e5)
* realtek: fix egress L2 learning on rtl839xSander Vanheule2022-07-211-1/+1
| | | | | | | | | | | | | The flag to enable L2 address learning on egress frames is in CPU header bit 40, with bit 0 being the leftmost bit of the header. This corresponds to BIT(7) in the third 16-bit value of the header. Correctly set L2LEARNING by fixing the off-by-one error. Fixes: 9eab76c84e31 ("realtek: Improve TX CPU-Tag usage") Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit d6165ea75baea4f9039f3a378d55219c74b932a7)
* realtek: fix egress port mask on rtl839xSander Vanheule2022-07-211-1/+1
| | | | | | | | | | | | | The flag to enable the outgoing port mask is in CPU header bit 43, with bit 0 being the leftmost bit of the header. This corresponds to BIT(4) in the third 16-bit value of the header. Correctly set AS_DPM by fixing the off-by-one error. Fixes: 9eab76c84e31 ("realtek: Improve TX CPU-Tag usage") Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit d9516cacb087fed7716b34b1e02ce956bb6c27f1)
* realtek: build sane factory images for DGS-1210 modelsMarkus Stockhausen2022-07-082-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | During upload of firmware images the WebUI and CLI patch process extracts a version information from the uploaded file and stores it onto the jffs2 partition. To be precise it is written into the flash.txt or flash2.txt files depending on the selected target image. This data is not used anywhere else. The current OpenWrt factory image misses this label. Therefore version information shows only garbage. Fix this. Before: DGS-1210-20> show firmware information IMAGE ONE: Version : xfo/QE~WQD"A\Scxq... Size : 5505185 Bytes After: DGS-1210-20> show firmware information IMAGE ONE: Version : OpenWrt Size : 5505200 Bytes Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> (cherry picked from commit fae3ac3560459320a88be86b31c572c4bca42645)
* realtek: build factory images for all DGS-1210 modelsMarkus Stockhausen2022-07-081-7/+7
| | | | | | | | | | Currently we build factory images only for DGS-1210-28 model. Relax that constraint and take care about all models. Tested on DGS-1210-20 and should work on other models too because of common flash layout. Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> (cherry picked from commit 2b49ec3a28ad09446f48f1f830a42bdfe3bce9be)
* realtek: rename u-boot-env2 to board-nameLuiz Angelo Daros de Luca2022-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | | Some realtek boards have two u-boot-env partitions. However, in the DGS-1210 series, the mtdblock2 partition is not a valid u-boot env and simply contains the board/device name, followed by nulls. 00000000 44 47 53 2d 31 32 31 30 2d 32 38 2d 46 31 00 00 |DGS-1210-28-F1..| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00040000 00000000 44 47 53 2d 31 32 31 30 2d 35 32 2d 46 31 00 00 |DGS-1210-52-F1..| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00040000 The misleading u-boot-env2 name also confuses uboot-envtools. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> (cherry picked from commit 8b798dbb39856463878efb07ddef87ce2e522ceb)
* realtek: build DGS-1210 images with CAMEO tagMarkus Stockhausen2022-07-082-0/+5
| | | | | | | | | From now on we will insert CAMEO tags into sysupgrade images for DGS-1210 devices. This will make the "OS:...FAILED" and "FS:...FAILED" messages go away. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> (cherry picked from commit e763c4c89fc5569d7264ff60837eb4aff69a0bfb)
* realtek: add DGS-1210-28 factory imageLuiz Angelo Daros de Luca2022-07-082-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DGS-1210 switches support dual image, with each image composed of a kernel and a rootfs partition. For image1, kernel and rootfs are in sequence. The current OpenWrt image (written using a serial console), uses those partitions together as the firmware partition, ignoring the partition division. The current OEM u-boot fails to validate image1 but it will only trigger firmware recovery if both image1 and image2 fail, and it does not switch the boot image in case one of them fails the check. The OEM factory image is composed of concatenated blocks of data, each one prefixed with a 0x40-byte cameo header. A normal OEM firmware will have two of these blocks (kernel, rootfs). The OEM firmware only checks the header before writing unconditionally the data (except the header) to the correspoding partition. The OpenWrt factory image mimics the OEM image by cutting the kernel+rootfs firmware at the exact size of the OEM kernel partition and packing it as "the kernel partition" and the rest of the kernel and the rootfs as "the rootfs partition". It will only work if written to image1 because image2 has a sysinfo partition between kernel2 and rootfs2, cutting the kernel code in the middle. Steps to install: 1) switch to image2 (containing an OEM image), using web or these CLI commands: - config firmware image_id 2 boot_up - reboot 2) flash the factory_image1.bin to image1. OEM web (v6.30.016) is crashing for any upload (ssh keys, firmware), even applying OEM firmwares. These CLI commands can upload a new firmware to the other image location (not used to boot): - download firmware_fromTFTP <tftpserver> factory_image1.bin - config firmware image_id 1 boot_up - reboot To debrick the device, you'll need serial access. If you want to recover to an OpenWrt, you can replay the serial installation instructions. For returning to the original firmware, press ESC during the boot to trigger the emergency firmware recovery procedure. After that, use D-Link Network Assistant v2.0.2.4 to flash a new firmware. The device documentation does describe that holding RESET for 12s trigger the firmware recovery. However, the latest shipped U-Boot "2011.12.(2.1.5.67086)-Candidate1" from "Aug 24 2021 - 17:33:09" cannot trigger that from a cold boot. In fact, any U-Boot procedure that relies on the RESET button, like reset settings, will only work if started from a running original firmware. That, in practice, cancels the benefit of having two images and a firmware recovery procedure (if you are not consider dual-booting OpenWrt). Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> (cherry picked from commit 1005dc0a64587e954364ff3a64bbb38b2ca371cd)
* kernel: Refresh patches for all targetsHauke Mehrtens2022-07-031-1/+1
| | | | | | | | | | | | | | | | This refreshes the patches on top of kernel 5.4.127. Deleted (upstreamed): bcm27xx/patches-5.10/950-0005-Revert-mailbox-avoid-timer-start-from-callback.patch [0] bcm27xx/patches-5.10/950-0678-bcm2711_thermal-Don-t-clamp-temperature-at-zero.patch [1] Needed manual modifications: bcm27xx/patches-5.10/950-0410-drm-atomic-Pass-the-full-state-to-CRTC-atomic-begin-.patch [0]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.127&id=bb2220e0672b7433a9a42618599cd261b2629240 [1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.127&id=83603802954068ccd1b8a3f2ccbbaf5e0862acb0 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* generic: enable CRYPTO_LIB_BLAKE2S[_X86|_ARM]Tomasz Maciej Nowak2022-06-274-0/+8
| | | | | | | | | | | | | 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> (cherry picked from commit 539e60539a2fde6531bd179c94bb9c7f8f490f2b)
* realtek: make "u-boot-env" partition writable for Netgear 3xx seriesAndreas Böhler2022-06-241-1/+0
| | | | | | | | | | The Netgear GS3xx devices do not properly initialise the port LEDs during startup unless the boot command in U-Boot is changed. Making the U-Boot env partition writable allows this modification to be done from within OpenWrt by calling "fw_setenv bootcmd rtk network on\; boota". Signed-off-by: Andreas Böhler <dev@aboehler.at> (cherry picked from commit d9e12c21fa98c90d0cc355e344d90469c5fd42c1)
* realtek: make Netgear GS1xx u-boot env partition writableStijn Segers2022-06-241-1/+0
| | | | | | | | | | | | Make the u-boot environment partition for the NETGEAR GS108T v3 and GS110TPP writable (they share a DTS), so the values can be manipulated from userspace. See https://forum.openwrt.org/t/57875/1567 for a real world example. Signed-off-by: Stijn Segers <foss@volatilesystems.org> (cherry picked from commit 9c381d3386ab375a4c79812641192faef368d191)
* realtek: add support for power LED on Netgear GS108Tv3Pascal Ernster2022-06-191-0/+27
| | | | | | | | | | | | | | | | | | | | | | The Netgear GS108Tv3 is already supported by OpenWrt, but is missing LED support. After OpenWrt installation, all LEDs are off which makes the installation quite confusing. This enables support for the green/amber power LED to give feedback about the current status. This is basically just a verbatim copy of commit c4927747d25a ("realtek: add support for power LED on Netgear GS308Tv1"). Please note that both LEDs are wired up in an anti-parallel fashion, which means that only one of both LEDs/colors can be switched on at the same time. If both LEDs/colors are switched on simultanously, the LED goes dark. Tested-by: Pascal Ernster <git@hardfalcon.net> Signed-off-by: Pascal Ernster <git@hardfalcon.net> [add title to commit reference] Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit adbdfc9366fed2d28dbd36883ddbdb566a313f71)
* realtek: add support for power LED on Netgear GS308Tv1Andreas Böhler2022-06-191-0/+27
| | | | | | | | | | | The Netgear GS308Tv1 is already supported by OpenWrt, but is missing LED support. After OpenWrt installation, all LEDs are off which makes the installation quite confusing. This enables support for the green/amber power LED to give feedback about the current status. Signed-off-by: Andreas Böhler <dev@aboehler.at> (cherry picked from commit c4927747d25af59db8233a66a59fdf9e8c0e395d)
* kernel: bump 5.10 to 5.10.120John Audia2022-06-071-1/+1
| | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800, x86/64 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit f800f8d6fc4f21ed87454aa657ebbf376dc3b6cf)
* kernel: bump 5.10 to 5.10.119John Audia2022-06-071-1/+1
| | | | | | | | | | | Delete the crypto-lib-blake2s kmod package, as BLAKE2s is now built-in. Patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800, x86/64 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit cd634afe6cb6565eb6865931c8d73d97cab3600a)
* realtek: add gpio-restart for D-Link DGS-1210-28Luiz Angelo Daros de Luca2022-06-071-0/+6
| | | | | | | | | A GPIO assert is required to reset the system. Otherwise, the system will hang on reboot. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Robert Marko <robimarko@gmail.com> (cherry picked from commit a2817ce96f17db3a5af77837ae5733b47182ae0d)
* realtek: add reset button for D-Link DGS-1210-28Luiz Angelo Daros de Luca2022-06-071-0/+18
| | | | | | | | Tested in a DGS-1210-28 F3, both triggering failsafe and reboot. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Robert Marko <robimarko@gmail.com> (cherry picked from commit b85f59b726442621efb95153ff60b8767723feca)
* realtek: add support for ZyXEL GS1900-24ERaylynn Knight2022-06-062-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ZyXEL GS1900-24E is a 24 port gigabit switch similar to other GS1900 switches. Specifications -------------- * Device: ZyXEL GS1900-24E * SoC: Realtek RTL8382M 500 MHz MIPS 4KEc * Flash: 16 MiB Macronix MX25L12835F * RAM: 128 MiB DDR2 SDRAM Nanya NT5TU128M8GE * Ethernet: 24x 10/100/1000 Mbps * LEDs: 1 PWR LED (green, not configurable) 1 SYS LED (green, configurable) 24 ethernet port link/activity LEDs (green, SoC controlled) * Buttons: 1 "RESET" button on front panel * Switch: 1 Power switch on rear of device * Power 120-240V AC C13 * UART: 1 serial header (JP2) with populated standard pin connector on the left side of the PCB. Pinout (front to back): + Pin 1 - VCC marked with white dot + Pin 2 - RX + Pin 3 - TX + PIn 4 - GND Serial connection parameters: 115200 8N1. Installation ------------ OEM upgrade method: * Log in to OEM management web interface * Navigate to Maintenance > Firmware * Select the HTTP radio button * Select the Active radio button * Use the browse button to locate the realtek-rtl838x-zyxel_gs1900-24e-initramfs-kernel.bin file and select open so File Path is updated with filename. * Select the Apply button. Screen will display "Prepare for firmware upgrade ...". *Wait until screen shows "Do you really want to reboot?" then select the OK button * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade -n /tmp/realtek-rtl838x-zyxel_gs1900-24e-squashfs-sysupgrade.bin it may be necessary to restart the network (/etc/init.d/network restart) on the running initramfs image. U-Boot TFTP method: * Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10). * Set up a TFTP server on your client and make it serve the initramfs image. * Connect serial, power up the switch, interrupt U-boot by hitting the space bar, and enable the network: > rtk network on * Since the GS1900-24E is a dual-partition device, you want to keep the OEM firmware on the backup partition for the time being. OpenWrt can only boot from the first partition anyway (hardcoded in the DTS). To make sure we are manipulating the first partition, issue the following commands: > setsys bootpartition 0 > savesys * Download the image onto the device and boot from it: > tftpboot 0x84f00000 192.168.1.10:openwrt-realtek-rtl838x-zyxel_gs1900-24e-initramfs-kernel.bin > bootm * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade -n /tmp/openwrt-realtek-rtl838x-zyxel_gs1900-24e-squashfs-sysupgrade.bin it may be necessary to restart the network (/etc/init.d/network restart) on the running initramfs image. Signed-off-by: Raylynn Knight <rayknight@me.com> (cherry picked from commit b515ad10a6e1bd5c5da0ea95366fb19c92a75dea)
* realtek: add support for ZyXEL GS1900-16Raylynn Knight2022-05-172-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ZyXEL GS1900-16 is a 16 port gigabit switch similar to other GS1900 switches. Specifications -------------- * Device: ZyXEL GS1900-16 * SoC: Realtek RTL8382M 500 MHz MIPS 4KEc * Flash: 16 MiB Macronix MX25L12835F * RAM: 128 MiB DDR2 SDRAM Nanya NT5TU128M8HE * Ethernet: 16x 10/100/1000 Mbps * LEDs: 1 PWR LED (green, not configurable) 1 SYS LED (green, configurable) 16 ethernet port link/activity LEDs (green, SoC controlled) * Buttons: 1 "RESET" button on front panel * Power 120-240V AC C13 * UART: 1 serial header (J12) with populated standard pin connector on the right back of the PCB. Pinout (front to back): + Pin 1 - VCC marked with white dot + Pin 2 - RX + Pin 3 - TX + PIn 4 - GND Serial connection parameters: 115200 8N1. Installation ------------ OEM upgrade method: * Log in to OEM management web interface * Navigate to Maintenance > Firmware * Select the HTTP radio button * Select the Active radio button * Use the browse button to locate the realtek-generic-zyxel_gs1900-16-initramfs-kernel.bin file amd select open so File Path is update with filename. * Select the Apply button. Screen will display "Prepare for firmware upgrade ...". *Wait until screen shows "Do you really want to reboot?" then select the OK button * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade -n /tmp/realtek-generic-zyxel_gs1900-16-squashfs-sysupgrade.bin it may be necessary to restart the network (/etc/init.d/network restart) on the running initramfs image. U-Boot TFTP method: * Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10). * Set up a TFTP server on your client and make it serve the initramfs image. * Connect serial, power up the switch, interrupt U-boot by hitting the space bar, and enable the network: > rtk network on * Since the GS1900-16 is a dual-partition device, you want to keep the OEM firmware on the backup partition for the time being. OpenWrt can only boot from the first partition anyway (hardcoded in the DTS). To make sure we are manipulating the first partition, issue the following commands: > setsys bootpartition 0 > savesys * Download the image onto the device and boot from it: > tftpboot 0x84f00000 192.168.1.10:openwrt-realtek-generic-zyxel_gs1900-16-initramfs-kernel.bin > bootm * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade -n /tmp/openwrt-realtek-generic-zyxel_gs1900-16-squashfs-sysupgrade.bin it may be necessary to restart the network (/etc/init.d/network restart) on the running initramfs image. Signed-off-by: Raylynn Knight <rayknight@me.com> [removed duplicate patch title, align RAM specification] Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit 580723e86ae53f14273ff8c3a0ebf5d15b4ce1f1)
* kernel: bump 5.10 to 5.10.114John Audia2022-05-172-2/+2
| | | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: bcm2711/RPi4B Run-tested: bcm2711/RPi4B Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit 8592df67f40b3afdee68e36dc3820187ec0f98fc)
* realtek: do not reset SerDes on link changeBirger Koblitz2022-05-142-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do not reset the RTL930x SerDes on link changes, instead set up the SDS with internal PHYs for the SFP+ ports only. This fixes the 8 1GBit ports on the Zyxel XGS1250 which do not work without this patch. A complete SerDes reset was performed on all SerDes links. For copper 1Gbit ports, this is commonly a single XGMII link to an RTL8218D. There is however no support for setting up the XGMII link on RTL9300/RTL9310, thereby wiping the (RX/TX) setup done by u-boot and breaking the 1GBit ports. No SerDes reset should be done for these links. The handling of SGMII/HiSGMII, 1000BX or 10GR links is actually entirely different. All these modes need to be suitably RX calibrated and the pre- main and post- amplifiers set up properly for TX. The 10GBit SFP+ fiber links are recalibrated instead of reset, which e.g. is necessary when someone pulls a module out and puts another in. This makes swapping out 10GBit fiber modules possible. 1GBit modules are not yet supported, nor any modules with an internal phy. Tested-by: Stijn Segers <foss@volatilesystems.org> Signed-off-by: Birger Koblitz <git@birger-koblitz.de> [rewrite commit message based on discussion] Link: http://lists.infradead.org/pipermail/openwrt-devel/2022-May/038623.html Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit d1b824650f1ee694ec2dbdd2f4f9ec64e650cf86)
* realtek: Trap all frames with switch as destination to CPU-portBirger Koblitz2022-05-141-0/+9
| | | | | | | | | | | | | This fixes a bug where frames sent to the switch itself were flooded to all ports unless the MAC address of the CPU-port was learned otherwise. Tested-by: Wenli Looi <wlooi@ucalgary.ca> Tested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Birger Koblitz <git@birger-koblitz.de> [fix code formatting] Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit 98bb26f9f762408e42bd8a906f0eb01c41ada10a)
* realtek: add ZyXEL GS1900-24HP v1 supportMartin Kennedy2022-04-193-0/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ZyXEL GS1900-24HP v1 is a 24 port PoE switch with two SFP ports, similar to the other GS1900 switches. Specifications -------------- * Device: ZyXEL GS1900-24HP v1 * SoC: Realtek RTL8382M 500 MHz MIPS 4KEc * Flash: 16 MiB * RAM: Winbond W9751G8KB-25 64 MiB DDR2 SDRAM * Ethernet: 24x 10/100/1000 Mbps, 2x SFP 100/1000 Mbps * LEDs: * 1 PWR LED (green, not configurable) * 1 SYS LED (green, configurable) * 24 ethernet port link/activity LEDs (green, SoC controlled) * 24 ethernet port PoE status LEDs * 2 SFP status/activity LEDs (green, SoC controlled) * Buttons: * 1 "RESET" button on front panel (soft reset) * 1 button ('SW1') behind right hex grate (hardwired power-off) * PoE: * Management MCU: ST Micro ST32F100 Microcontroller * 6 BCM59111 PSE chips * 170W power budget * Power: 120-240V AC C13 * UART: Internal populated 10-pin header ('J5') providing RS232; connected to SoC UART through a TI or SIPEX 3232C for voltage level shifting. * 'J5' RS232 Pinout (dot as pin 1): 2) SoC RXD 3) GND 10) SoC TXD Serial connection parameters: 115200 8N1. Installation ------------ OEM upgrade method: * Log in to OEM management web interface * Navigate to Maintenance > Firmware > Management * If "Active Image" has the first option selected, OpenWrt will need to be flashed to the "Active" partition. If the second option is selected, OpenWrt will need to be flashed to the "Backup" partition. * Navigate to Maintenance > Firmware > Upload * Upload the openwrt-realtek-rtl838x-zyxel_gs1900-24hp-v1-initramfs-kernel.bin file by your preferred method to the previously determined partition. When prompted, select to boot from the newly flashed image, and reboot the switch. * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade /tmp/openwrt-realtek-rtl838x-zyxel_gs1900-24hp-v1-squashfs-sysupgrade.bin U-Boot TFTP method: * Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10). * Set up a TFTP server on your client and make it serve the initramfs image. * Connect serial, power up the switch, interrupt U-boot by hitting the space bar, and enable the network: > rtk network on * Since the GS1900-24HP v1 is a dual-partition device, you want to keep the OEM firmware on the backup partition for the time being. OpenWrt can only be installed in the first partition anyway (hardcoded in the DTS). To ensure we are set to boot from the first partition, issue the following commands: > setsys bootpartition 0 > savesys * Download the image onto the device and boot from it: > tftpboot 0x81f00000 192.168.1.10:openwrt-realtek-rtl838x-zyxel_gs1900-24hp-v1-initramfs-kernel.bin > bootm * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade /tmp/openwrt-realtek-rtl838x-zyxel_gs1900-24hp-v1-squashfs-sysupgrade.bin Signed-off-by: Martin Kennedy <hurricos@gmail.com> [Add info on PoE hardware to commit message] Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit a5ac8ad0ba9df50bdd0dda1dc26cf36f83006893)
* realtek: Fix tc default packageHauke Mehrtens2022-03-291-1/+1
| | | | | | | | | | | The tc package does not exits any more, it was split into tc-tiny, tc-full and tc-bpf. Include tc-bpf by default into realtek images. This increases the compressed image size by about 232KBytes. Tested-by: Stijn Segers <foss@volatilesystems.org> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 34fb36e165d5b6e6e37d33b4b0da789a8f1430bb)
* realtek: Use firewall4Hauke Mehrtens2022-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | The realtek target is not a router, but basic device, see DEVICE_TYPE. The basic device type does not come with firewall by default, see include/target.mk for details. The realtek target extended DEFAULT_PACKAGES manually with firewall. This changes the defaults to take firewall4 and nftables instead of firewall and iptables. This also adds the additional package kmod-nft-offload. The only difference to the router type is the missing ppp, ppp-mod-pppoe, dnsmasq and odhcpd-ipv6only package. This increases the compressed image size by about 422KBytes. Tested-by: Stijn Segers <foss@volatilesystems.org> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 469030659c5cb140bdbff1b3d8fc9691f98f984b)
* realtek: Remove dnsmasq and odhcpd-ipv6only from defaultHauke Mehrtens2022-03-291-1/+1
| | | | | | | | | | | | Do not include the dnsmasq and odhcpd-ipv6only package by default any more. These services are not needed on a switch. If someone needs this it is still possible to use opkg or image builder to add them. This decreases the compressed image size by about 165KBytes. Tested-by: Stijn Segers <foss@volatilesystems.org> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 2acebbdcaafbdfd3f677052c28bc0af04c6b5ab8)
* kernel: bump 5.10 to 5.10.106John Audia2022-03-191-2/+2
| | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: bcm2711/RPi4B, mt7622/RT3200 Run-tested: bcm2711/RPi4B, mt7622/RT3200 Signed-off-by: John Audia <graysky@archlinux.us>
* realtek: add support for Panasonic Switch-M8eG PN28080KINAGAKI Hiroshi2022-03-133-0/+338
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Panasonic Switch-M8eG PN28080K is a 8 + 1 port gigabit switch, based on RTL8380M. Specification: - SoC : Realtek RTL8380M - RAM : DDR3 128 MiB (Winbond W631GG8KB-15) - Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G) - Ethernet : 10/100/1000 Mbps x8 + 1 - port 1-8 : TP, RTL8218B (SoC) - port 9 : SFP, RTL8380M (SoC) - LEDs/Keys : 7x / 1x - UART : RS-232 port on the front panel (connector: RJ-45) - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45) - 9600n8 - Power : 100-240 VAC, 50/60 Hz, 0.5 A - Plug : IEC 60320-C13 - Stock OS : VxWorks based Flash instruction using initramfs image: 1. Prepare the TFTP server with the IP address 192.168.1.111 2. Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to the TFTP directory 3. Download the official upgrading firmware (ex: pn28080k_v30000.rom) and place it to the TFTP directory 4. Boot M8eG and interrupt the U-Boot with Ctrl + C keys 5. Execute the following commands and boot with the OpenWrt initramfs image rtk network on tftpboot 0x81000000 bootm 6. Backup mtdblock files to the computer by scp or anything and reboot 7. Interrupt the U-Boot and execute the following commands to re-create filesystem in the flash ffsmount c:/ ffsfmt c:/ this step takes a long time, about ~ 4 mins 8. Execute the following commands to put the official images to the filesystem updatert <official image> example: updatert pn28080k_v30000.rom this step takes about ~ 40 secs 9. Set the environment variables of the U-Boot by the following commands setenv loadaddr 0xb4e00000 setenv bootcmd bootm saveenv 10: Download the OpenWrt initramfs image and boot with it tftpboot 0x81000000 0101A8C0.img bootm 11: On the initramfs image, download the sysupgrade image and perform sysupgrade with it sysupgrade <imagename> 12: Wait ~ 120 seconds to complete flashing Note: - "Switch-M8eG" is a model name, and "PN28080K" is a model number. Switch-M8eG has an another (old) model number ("PN28080"), it's not a Realtek based hardware. - Switch-M8eG has a "POWER" LED (Green), but it's not connected to any GPIO pin. - The U-Boot checks the runtime images in the flash when booting and fails to execute anything in "bootcmd" variable if the images are not exsisting. - A filesystem is formed in the flash (0x100000-0x1DFFFFF) on the stock firmware and it includes the stock images, configuration files and checksum files. It's unknown format, can't be managed on the OpenWrt. To get the enough space for OpenWrt, move the filesystem to the head of "fs_reserved" partition by execution of "ffsfmt" and "updatert". - On the other devices in the same series of Switch-M8eG PN28080K, the INT pin on the PCA9555 is not connected to anywhere. Back to the stock firmware: 1. Delete "loadaddr" variable and set "bootcmd" to the original value on U-Boot: setenv loadaddr setenv bootcmd 'bootm 0x81000000' on OpenWrt: fw_setenv loadaddr fw_setenv bootcmd 'bootm 0x81000000' 2. Perform reset or reboot on U-Boot: reset on OpenWrt: reboot Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com> Reviewed-by: Sander Vanheule <sander@svanheule.net>
* realtek: enable pca953x driver for rtl838x subtargetINAGAKI Hiroshi2022-03-131-0/+3
| | | | | | | | | | 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: add ZyXEL GS1900-24 v1 supportMartin Kennedy2022-03-132-0/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ZyXEL GS1900-24 v1 is a 24 port switch with two SFP ports, similar to the other GS1900 switches. Specifications -------------- * Device: ZyXEL GS1900-24 v1 * SoC: Realtek RTL8382M 500 MHz MIPS 4KEc * Flash: 16 MiB * RAM: Winbond W9751G8KB-25 64 MiB DDR2 SDRAM * Ethernet: 24x 10/100/1000 Mbps, 2x SFP 100/1000 Mbps * LEDs: * 1 PWR LED (green, not configurable) * 1 SYS LED (green, configurable) * 24 ethernet port link/activity LEDs (green, SoC controlled) * 2 SFP status/activity LEDs (green, SoC controlled) * Buttons: * 1 "RESET" button on front panel (soft reset) * 1 button ('SW1') behind right hex grate (hardwired power-off) * Power: 120-240V AC C13 * UART: Internal populated 10-pin header ('J5') providing RS232; connected to SoC UART through a SIPEX 3232EC for voltage level shifting. * 'J5' RS232 Pinout (dot as pin 1): 2) SoC RXD 3) GND 10) SoC TXD Serial connection parameters: 115200 8N1. Installation ------------ OEM upgrade method: * Log in to OEM management web interface * Navigate to Maintenance > Firmware > Management * If "Active Image" has the first option selected, OpenWrt will need to be flashed to the "Active" partition. If the second option is selected, OpenWrt will need to be flashed to the "Backup" partition. * Navigate to Maintenance > Firmware > Upload * Upload the openwrt-realtek-rtl838x-zyxel_gs1900-24-v1-initramfs-kernel.bin file by your preferred method to the previously determined partition. When prompted, select to boot from the newly flashed image, and reboot the switch. * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade /tmp/openwrt-realtek-rtl838x-zyxel_gs1900-24-v1-squashfs-sysupgrade.bin U-Boot TFTP method: * Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10). * Set up a TFTP server on your client and make it serve the initramfs image. * Connect serial, power up the switch, interrupt U-boot by hitting the space bar, and enable the network: > rtk network on > Since the GS1900-24 v1 is a dual-partition device, you want to keep the OEM firmware on the backup partition for the time being. OpenWrt can only be installed in the first partition anyway (hardcoded in the DTS). To ensure we are set to boot from the first partition, issue the following commands: > setsys bootpartition 0 > savesys * Download the image onto the device and boot from it: > tftpboot 0x81f00000 192.168.1.10:openwrt-realtek-rtl838x-zyxel_gs1900-24-v1-initramfs-kernel.bin > bootm * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade /tmp/openwrt-realtek-rtl838x-zyxel_gs1900-24-v1-squashfs-sysupgrade.bin Signed-off-by: Martin Kennedy <hurricos@gmail.com>
* realtek: add support for I-O DATA BSH-G24MBINAGAKI Hiroshi2022-03-072-0/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I-O DATA BSH-G24MB is a 24 port gigabit switch, based on RTL8382M. Specification: - SoC : Realtek RTL8382M - RAM : DDR2 128 MiB (Nanya NT5TU128M8HE-AC) - Flash : SPI-NOR 16 MiB (Macronix MX25L12835FM2I-10G) - Ethernet : 10/100/1000 Mbps x24 - port 1-8 : RTL8218B - port 9-16 : RTL8218B (SoC) - port 17-24 : RTL8218B - LEDs/Keys : 2x, 1x - UART : pin header on PCB - JP2: 3.3V, TX, RX, GND from rear side - 115200n8 - Power : 100 VAC, 50/60 Hz - Plug : IEC 60320-C13 Flash instruction using sysupgrade image: 1. Boot BSH-G24MB normally 2. Connect BSH-G24MB to the DHCP enabled network 3. Find the device's IP address and open the WebUI and login Note: by default, the device obtains IP address from DHCP server of the network 4. Open firmware update page ("ファームウェア アップデート") 5. Rename the OpenWrt sysupgrade image to "bsh-g24mb_v100.image" and select it 6. Press apply ("適用") button to perform update 7. Wait ~150 seconds to complete flashing Note: - BSH-G24MB has a power-related LED ("電源"), but it's not connected to the GPIO of the SoC or RTL8231 and cannot be controlled. Instead of it, use system status LED on other than running-state. - "sys_loop" LED indicates system status and loop-detection status in stock firmware. - BSH-G24MB has 2x os-image partitions named as "RUNTIME"/"RUNTIME2" in 16 MiB SPI-NOR flash and the size of image per partition is only 6848 KiB. The secondary image is never used on stock firmware, so also use it on OpenWrt to get more space. Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* realtek: net: dsa: configure better brport flags when ports leave the bridgeBjørn Mork2022-03-061-0/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensures that the DSA driver sets exactly the same default flags as the bridge when a port joins or leaves. Without this we end up with a confusing flag mismatch, where DSA and bridge ports use different sets of flags. This is critical as the "learning" mismatch will be harmful to the network, causing all traffic to be flooded on all ports. The original commit was buggy, trying to set the flags one-by-one in a loop. This was not supported by the API and the end result was that all but the last flag were cleared. This bug was implicitly fixed upstream by commit e18f4c18ab5b ("net: switchdev: pass flags and mask to both {PRE_,}BRIDGE_FLAGS attributes"). This is a minimum temporary stop measure fix for the critical lack of "learning" only. The major API change associated with a full v5.12+ backport is neither required nor wanted. A simpler fix, moving the call to dsa_port_bridge_flags() out of the loop, has therefore been merged into this modified backport. Fixes: afa3ab54c03d ("realtek: Backport bridge configuration for DSA") Signed-off-by: Bjørn Mork <bjorn@mork.no> Acked-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Stijn Tintel <stijn@linux-ipv6.be> [fix typos in commit message] Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
* kernel: bump 5.10 to 5.10.102John Audia2022-03-012-2/+2
| | | | | | | | | | | | | | | Removed upstreamed: bcm4908/patches-5.10/180-i2c-brcmstb-fix-support-for-DSL-and-CM-variants.patch[1] All other patches automatically rebased. 1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.102&id=f333c1916fd6b55900029bf8f918cc00009e2111 Build system: x86_64 Build-tested: bcm2711/RPi4B, mt7622/RT3200 Run-tested: bcm2711/RPi4B, mt7622/RT3200 Signed-off-by: John Audia <graysky@archlinux.us>
* realtek: remove debugging code from timerSander Vanheule2022-02-201-15/+3
| | | | | | | Remove some (dead) debugging code from the Realtek timer to clean up the sources of this driver. Signed-off-by: Sander Vanheule <sander@svanheule.net>
* realtek: use DT provided address for timersSander Vanheule2022-02-202-24/+24
| | | | | | | | | | | | | | | The I/O base address for the timers was hardcoded into the driver, or derived from the HW IRQ number as an even more horrible hack. All supported SoC families have these timers, but with hardcoded addresses the code cannot be reused right now. Request the timer's base address from the DT specification, and store it in a private struct for future reference. Matching the second interrupt specifier, the address range for the second timer is added to the DT specification. Signed-off-by: Sander Vanheule <sander@svanheule.net>
* realtek: clean up RTL930x timer DT nodeSander Vanheule2022-02-201-3/+1
| | | | | | | | | | | | | | The Realtek timer node for RTL930x doesn't have any child nodes, making the use of '#address-cells' quite pointless. It is also not an interrupt controller, meaning it makes no sense to define '#interrupt-cells'. The I/O address for this node is also wrong, but this is hidden by the fact that the driver associated with this node bypasses the usual DT machinery and does it's own thing. Correct the address to have a sane value, even though it isn't actually used. Fixes: a75b9e3ecb61 ("realtek: Adding RTL930X sub-target") Signed-off-by: Sander Vanheule <sander@svanheule.net>
* realtek: ZyXEL GS1900-48: fix system LED polaritySander Vanheule2022-02-201-1/+1
| | | | | | | | | When driven by a GPIO pin, the system LED needs to be configured as active high. Otherwise the LED switches off after booting and initialisation. Fixes: 47f5a0a3eed5 ("realtek: Add support for ZyXEL GS1900-48 Switch") Signed-off-by: Sander Vanheule <sander@svanheule.net>
* realtek: ZyXEL GS1900-48: drop status from gpio1Sander Vanheule2022-02-201-2/+0
| | | | | | | | The default value for a DT node's status property is already "okay", so there's no need to specify it again. Drop the status property to clean up the DTS. Signed-off-by: Sander Vanheule <sander@svanheule.net>
* realtek: use higher priority for timer interruptsSander Vanheule2022-02-201-1/+1
| | | | | | | | | | | | | | The assigned output index for the event timers was quite low, lower even than the ethernet interrupt. This means that high network load could preempt timer interrupts, possibly leading to all sorts of strange behaviour. Increase the interrupt output index of the event timers to 5, which is the highest priority output and corresponds to the (otherwise unused) MIPS CPU timer interrupt. Fixes: a75b9e3ecb61 ("realtek: Adding RTL930X sub-target") Signed-off-by: Sander Vanheule <sander@svanheule.net>
* realtek: move RTL8231 definitions to board filesSander Vanheule2022-02-204-21/+23
| | | | | | | | | | | | | | The RTL8231 is an external chip, and not part of the SoC. That means it is more appropriate to define it in the board specific (base) files, instead of the DT include for the SoC itself. Moving the RTL8231 definition also ensures that boards with no GPIO expander, or an alternative one, don't have a useless gpio1 node label defined. Tested on a Netgear GS110TPPv1. Signed-off-by: Sander Vanheule <sander@svanheule.net>
* realtek: fix node addresses for RTL839xSander Vanheule2022-02-201-3/+3
| | | | | | | | | | The address in some node names doesn't match the actual offset specified in the DT node. Update the names to fix this. While fixing the node names, also drop the unused node labels. Fixes: 0a7565e53653 ("realtek: Update rtl839x.dtsi for realtek,rtl-intc, new gpio controller remove RTL8231 node") Signed-off-by: Sander Vanheule <sander@svanheule.net>
* realtek: consolidate bootargs againSander Vanheule2022-02-205-11/+3
| | | | | | | | | | | | | | | | | Bootargs for devices in the realtek target were previously consolidated in commit af2cfbda2bf5 ("realtek: Consolidate bootargs"), since all devices currently use the same arguments. Commit a75b9e3ecb61 ("realtek: Adding RTL930X sub-target") reverted this without any argumentation, so let's undo that. Commit 0b8dfe085180 ("realtek: Add RTL931X sub-target") introduced the old bootargs also for RTL931x, without providing any actual device support. Until that is done, let's assume vendors will have done what they did before, and use a baud rate of 115200. Fixes: a75b9e3ecb61 ("realtek: Adding RTL930X sub-target") Signed-off-by: Sander Vanheule <sander@svanheule.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-19 09:22:16 +0000