aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* ramips: mt7621: Add support for ZyXEL NR7101Bjørn Mork2021-06-106-0/+203
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ZyXEL NR7101 is an 802.3at PoE powered 5G outdoor (IP68) CPE with integrated directional 5G/LTE antennas. Specifications: - SoC: MediaTek MT7621AT - RAM: 256 MB - Flash: 128 MB MB NAND (MX30LF1G18AC) - WiFi: MediaTek MT7603E - Switch: 1 LAN port (Gigabiti) - 5G/LTE: Quectel RG502Q-EA connected by USB3 to SoC - SIM: 2 micro-SIM slots under transparent cover - Buttons: Reset, WLAN under same cover - LEDs: Multicolour green/red/yellow under same cover (visible) - Power: 802.3at PoE via LAN port The device is built as an outdoor ethernet to 5G/LTE bridge or router. The Wifi interface is intended for installation and/or temporary management purposes only. UART Serial: 57600N1 Located on populated 5 pin header J5: [o] GND [ ] key - no pin [o] RX [o] TX [o] 3.3V Vcc Remove the SIM/button/LED cover, the WLAN button and 12 screws holding the back plate and antenna cover together. The GPS antenna is fixed to the cover, so be careful with the cable. Remove 4 screws fixing the antenna board to the main board, again being careful with the cables. A bluetooth TTL adapter is recommended for permanent console access, to keep the router water and dustproof. The 3.3V pin is able to power such an adapter. MAC addresses: OpenWrt OEM Address Found as lan eth2 08:26:97:*:*:BC Factory 0xe000 (hex), label wlan0 ra0 08:26:97:*:*:BD Factory 0x4 (hex) wwan0 usb0 random WARNING!! ISP managed firmware might at any time update itself to a version where all known workarounds have been disabled. Never boot an ISP managed firmware with a SIM in any of the slots if you intend to use the router with OpenWrt. The bootloader lock can only be disabled with root access to running firmware. The flash chip is physically inaccessible without soldering. Installation from OEM web GUI: - Log in as "supervisor" on https://172.17.1.1/ - Upload OpenWrt initramfs-recovery.bin image on the Maintenance -> Firmware page - Wait for OpenWrt to boot and ssh to root@192.168.1.1 - (optional) Copy OpenWrt to the recovery partition. See below - Sysupgrade to the OpenWrt sysupgrade image and reboot Installation from OEM ssh: - Log in as "root" on 172.17.1.1 port 22022 - scp OpenWrt initramfs-recovery.bin image to 172.17.1.1:/tmp - Prepare bootloader config by running: nvram setro uboot DebugFlag 0x1 nvram setro uboot CheckBypass 0 nvram commit - Run "mtd_write -w write initramfs-recovery.bin Kernel" and reboot - Wait for OpenWrt to boot and ssh to root@192.168.1.1 - (optional) Copy OpenWrt to the recovery partition. See below - Sysupgrade to the OpenWrt sysupgrade image and reboot Copying OpenWrt to the recovery partition: - Verify that you are running a working OpenWrt recovery image from flash - ssh to root@192.168.1.1 and run: fw_setenv CheckBypass 0 mtd -r erase Kernel2 - Wait while the bootloader mirrors Image1 to Image2 NOTE: This should only be done after successfully booting the OpenWrt recovery image from the primary partition during installation. Do not do this after having sysupgraded OpenWrt! Reinstalling the recovery image on normal upgrades is not required or recommended. Installation from Z-Loader: - Halt boot by pressing Escape on console - Set up a tftp server to serve the OpenWrt initramfs-recovery.bin image at 10.10.10.3 - Type "ATNR 1,initramfs-recovery.bin" at the "ZLB>" prompt - Wait for OpenWrt to boot and ssh to root@192.168.1.1 - Sysupgrade to the OpenWrt sysupgrade image NOTE: ATNR will write the recovery image to both primary and recovery partitions in one go. Booting from RAM: - Halt boot by pressing Escape on console - Type "ATGU" at the "ZLB>" prompt to enter the U-Boot menu - Press "4" to select "4: Entr boot command line interface." - Set up a tftp server to serve the OpenWrt initramfs-recovery.bin image at 10.10.10.3 - Load it using "tftpboot 0x88000000 initramfs-recovery.bin" - Boot with "bootm 0x8800017C" to skip the 380 (0x17C) bytes ZyXEL header This method can also be used to RAM boot OEM firmware. The warning regarding OEM applies! Never boot an unknown OEM firmware, or any OEM firmware with a SIM in any slot. NOTE: U-Boot configuration is incomplete (on some devices?). You may have to configure a working mac address before running tftp using "setenv eth0addr <mac>" Unlocking the bootloader: If you are unebale to halt boot, then the bootloader is locked. The OEM firmware locks the bootloader on every boot by setting DebugFlag to 0. Setting it to 1 is therefore only temporary when OEM firmware is installed. - Run "nvram setro uboot DebugFlag 0x1; nvram commit" in OEM firmware - Run "fw_setenv DebugFlag 0x1" in OpenWrt NOTE: OpenWrt does this automatically on first boot if necessary NOTE2: Setting the flag to 0x1 avoids the reset to 0 in known OEM versions, but this might change. WARNING: Writing anything to flash while the bootloader is locked is considered extremely risky. Errors might cause a permanent brick! Enabling management access from LAN: Temporary workaround to allow installing OpenWrt if OEM firmware has disabled LAN management: - Connect to console - Log in as "root" - Run "iptables -I INPUT -i br0 -j ACCEPT" Notes on the OEM/bootloader dual partition scheme The dual partition scheme on this device uses Image2 as a recovery image only. The device will always boot from Image1, but the bootloader might copy Image2 to Image1 under specific conditions. This scheme prevents repurposing of the space occupied by Image2 in any useful way. Validation of primary and recovery images is controlled by the variables CheckBypass, Image1Stable, and Image1Try. The bootloader sets CheckBypass to 0 and reboots if Image1 fails validation. If CheckBypass is 0 and Image1 is invalid then Image2 is copied to Image1. If CheckBypass is 0 and Image2 is invalid, then Image1 is copied to Image2. If CheckBypass is 1 then all tests are skipped and Image1 is booted unconditionally. CheckBypass is set to 1 after each successful validation of Image1. Image1Try is incremented if Image1Stable is 0, and Image2 is copied to Image1 if Image1Try is 3 or larger. But the bootloader only tests Image1Try if CheckBypass is 0, which is impossible unless the booted image sets it to 0 before failing. The system is therefore not resilient against runtime errors like failure to mount the rootfs, unless the kernel image sets CheckBypass to 0 before failing. This is not yet implemented in OpenWrt. Setting Image1Stable to 1 prevents the bootloader from updating Image1Try on every boot, saving unnecessary writes to the environment partition. Keeping an OpenWrt initramfs recovery as Image2 is recommended primarily to avoid unwanted OEM firmware boots on failure. Ref the warning above. It enables console-less recovery in case of some failures to boot from Image1. Signed-off-by: Bjørn Mork <bjorn@mork.no> Tested-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit 2449a632084b29632605e5a79ce5d73028eb15dd)
* treewide: make AddDepends/usb-serial selectiveAdrian Schmutzler2021-06-086-11/+11
| | | | | | | | Make packages depending on usb-serial selective, so we do not have to add kmod-usb-serial manually for every device. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit 9397b22df1473f315552578b58322db7f7750361)
* x86: kernel: enable Fusion-MPT SAS driverMark Carroll2021-06-081-0/+1
| | | | | | | | Compile in MPT SAS driver required to mount rootfs on some VMWare systems (e.g. required for 1&1 IONOS). Signed-off-by: Mark Carroll <git@markcarroll.net> (cherry picked from commit 8716dda0743454e3949b815613542a4d00fc2a09)
* ipq40xx: add uboot-envtools to default packagesTomasz Maciej Nowak2021-06-082-17/+14
| | | | | | | | | | | | | | | | | | | | When support for Luma WRTQ-329ACN was added, the instructions for flashing this device include using tools from uboot-envtools package. Unfortunately the OpenWrt buildroot system omits packages from DEVICE_PACKAGES when CONFIG_TARGET_MULTI_PROFILE, CONFIG_TARGET_PER_DEVICE_ROOTFS, CONFIG_TARGET_ALL_PROFILES are set. In result the official images are without tools mentioned in the instruction. The workoround for the fashing would be installing uboot-envtools when booted with initramfs image, but not always the access to internet is available. The other method would be to issue the necesary command in U-Boot environment but some serial terminals default configuration don't work well with pasting lines longer than 80 chars. Therefore add uboot-envtools to default packages, which adds really small flash footprint to rootfs, where increased size usually is not an issue. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> (cherry picked from commit 1984a6bbcaac95c439dd4a6eba2f78c54e9be215)
* ipq806x: fix LAN and WAN port assignments on TP-Link AD7200Alex Henrie2021-06-081-1/+4
| | | | | | | | | LAN port 4 was swapped with the WAN port and the remaining three LAN ports were numbered in reverse order from their labels on the case. Fixes: 1a775a4fd033 ("ipq806x: add support for TP-Link Talon AD7200") Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> (cherry picked from commit 6fb27e8e6d05ed426f200242fdc1710f6f849127)
* kernel: bump 5.4 to 5.4.124Hauke Mehrtens2021-06-0644-165/+166
| | | | | | | | | | | | | Manually rebased generic/hack-5.4/662-remove_pfifo_fast.patch ramips/patches-5.4/0048-asoc-add-mt7620-support.patch All others updated automatically. Compile-tested on: armvirt/64, x86/generic, ath79/generic, ramips/mt7621 Runtime-tested on: armvirt/64, x86/generic, ath79/generic Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* rampis: use lzma-loader for ZTE MF283+Lech Perczak2021-06-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Without that, after merging support to master, the device fails to boot due to LZMA decompression error: 3: System Boot system code via Flash. raspi_read: from:80000 len:40 . Image Name: MIPS OpenWrt Linux-5.4.99 Created: 2021-02-25 23:35:00 UTC Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size: 1786664 Bytes = 1.7 MB Load Address: 80000000 Entry Point: 80000000 raspi_read: from:80040 len:1b4328 ............................ Verifying Checksum ... OK Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover Use lzma-loader to fix it. Fixes: 59d065c9f81c ("ramips: add support for ZTE MF283+") Signed-off-by: Lech Perczak <lech.perczak@gmail.com> (cherry picked from commit 410fb05b445c89a147029d1471e184a5594602db) Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
* ramips: add support for ZTE MF283+Lech Perczak2021-06-024-0/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ZTE MF283+ is a dual-antenna LTE category 4 router, based on Ralink RT3352 SoC, and built-in ZTE P685M PCIe MiniCard LTE modem. Hardware highlighs: - CPU: MIPS24KEc at 400MHz, - RAM: 64MB DDR2, - Flash: 16MB SPI, - Ethernet: 4 10/100M port switch with VLAN support, - Wireless: Dual-stream 802.11n (RT2860), with two internal antennas, - WWAN: Built-in ZTE P685M modem, with two internal antennas and two switching SMA connectors for external antennas, - FXS: Single ATA, with two connectors marked PHONE1 and PHONE2, internally wired in parallel by 0-Ohm resistors, handled entirely by internal WWAN modem. - USB: internal miniPCIe slot for modem, unpopulated USB A connector on PCB. - SIM slot for the WWAN modem. - UART connector for the console (unpopulated) at 3.3V, pinout: 1: VCC, 2: TXD, 3: RXD, 4: GND, settings: 57600-8-N-1. - LEDs: Power (fixed), WLAN, WWAN (RGB), phone (bicolor, controlled by modem), Signal, 4 link/act LEDs for LAN1-4. - Buttons: WPS, reset. Installation: As the modem is, for most of the time, provided by carriers, there is no possibility to flash through web interface, only built-in FOTA update and TFTP recovery are supported. There are two installation methods: (1) Using serial console and initramfs-kernel - recommended, as it allows you to back up original firmware, or (2) Using TFTP recovery - does not require disassembly. (1) Using serial console: To install OpenWrt, one needs to disassemble the router and flash it via TFTP by using serial console: - Locate unpopulated 4-pin header on the top of the board, near buttons. - Connect UART adapter to the connector. Use 3.3V voltage level only, omit VCC connection. Pin 1 (VCC) is marked by square pad. - Put your initramfs-kernel image in TFTP server directory. - Power-up the device. - Press "1" to load initramfs image to RAM. - Enter IP address chosen for the device (defaults to 192.168.0.1). - Enter TFTP server IP address (defaults to 192.168.0.22). - Enter image filename as put inside TFTP server - something short, like firmware.bin is recommended. - Hit enter to load the image. U-boot will store above values in persistent environment for next installation. - If you ever might want to return to vendor firmware, BACK UP CONTENTS OF YOUR FLASH NOW. For this router, commonly used by mobile networks, plain vendor images are not officially available. To do so, copy contents of each /dev/mtd[0-3], "firmware" - mtd3 being the most important, and copy them over network to your PC. But in case anything goes wrong, PLEASE do back up ALL OF THEM. - From under OpenWrt just booted, load the sysupgrade image to tmpfs, and execute sysupgrade. (2) Using TFTP recovery - Set your host IP to 192.168.0.22 - for example using: sudo ip addr add 192.168.0.22/24 dev <interface> - Set up a TFTP server on your machine - Put the sysupgrade image in TFTP server root named as 'root_uImage' (no quotes), for example using tftpd: cp openwrt-ramips-rt305x-zte_mf283plus-squashfs-sysupgrade.bin /srv/tftp/root_uImage - Power on the router holding BOTH Reset and WPS buttons held for around 5 seconds, until after WWAN and Signal LEDs blink. - Wait for OpenWrt to start booting up, this should take around a minute. Return to original firmware: Here, again there are two possibilities are possible, just like for installation: (1) Using initramfs-kernel image and serial console (2) Using TFTP recovery (1) Using initramfs-kernel image and serial console - Boot OpenWrt initramfs-kernel image via TFTP the same as for installation. - Copy over the backed up "firmware.bin" image of "mtd3" to /tmp/ - Use "mtd write /tmp/firmware.bin /dev/mtd3", where firmware.bin is your backup taken before OpenWrt installation, and /dev/mtd3 is the "firmware" partition. (2) Using TFTP recovery - Follow the same steps as for installation, but replacing 'root_uImage' with firmware backup you took during installation, or by vendor firmware obtained elsewhere. A few quirks of the device, noted from my instance: - Wired and wireless MAC addresses written in flash are the same, despite being in separate locations. - Power LED is hardwired to 3.3V, so there is no status LED per se, and WLAN LED is controlled by WLAN driver, so I had to hijack 3G/4G LED for status - original firmware also does this in bootup. - FXS subsystem and its LED is controlled by the modem, so it work independently of OpenWrt. Tested to work even before OpenWrt booted. I managed to open up modem's shell via ADB, and found from its kernel logs, that FXS and its LED is indeed controlled by modem. - While finding LEDs, I had no GPL source drop from ZTE, so I had to probe for each and every one of them manually, so this might not be complete - it looks like bicolor LED is used for FXS, possibly to support dual-ported variant in other device sharing the PCB. - Flash performance is very low, despite enabling 50MHz clock and fast read command, due to using 4k sectors throughout the target. I decided to keep it at the moment, to avoid breaking existing devices - I identified one potentially affected, should this be limited to under 4MB of Flash. The difference between sysupgrade durations is whopping 3min vs 8min, so this is worth pursuing. In vendor firmware, WWAN LED behaviour is as follows, citing the manual: - red - no registration, - green - 3G, - blue - 4G. Blinking indicates activity, so netdev trigger mapped from wwan0 to blue:wwan looks reasonable at the moment, for full replacement, a script similar to "rssileds" would need to be developed. Behaviour of "Signal LED" in vendor firmware is as follows: - Off - no signal, - Blinking - poor coverage - Solid - good coverage. A few more details on the built-in LTE modem: Modem is not fully supported upstream in Linux - only two CDC ports (DIAG and one for QMI) probe. I sent patches upstream to add required device IDs for full support. The mapping of USB functions is as follows: - CDC (QCDM) - dedicated to comunicating with proprietary Qualcomm tools. - CDC (PCUI) - not supported by upstream 'option' driver yet. Patch submitted upstream. - CDC (Modem) - Exactly the same as above - QMI - A patch is sent upstream to add device ID, with that in place, uqmi did connect successfully, once I selected correct PDP context type for my SIM (IPv4-only, not default IPv4v6). - ADB - self-explanatory, one can access the ADB shell with a device ID added to 51-android.rules like so: SUBSYSTEM!="usb", GOTO="android_usb_rules_end" LABEL="android_usb_rules_begin" SUBSYSTEM=="usb", ATTR{idVendor}=="19d2", ATTR{idProduct}=="1275", ENV{adb_user}="yes" ENV{adb_user}=="yes", MODE="0660", GROUP="plugdev", TAG+="uaccess" LABEL="android_usb_rules_end" While not really needed in OpenWrt, it might come useful if one decides to move the modem to their PC to hack it further, insides seem to be pretty interesting. ADB also works well from within OpenWrt without that. O course it isn't needed for normal operation, so I left it out of DEVICE_PACKAGES. Signed-off-by: Lech Perczak <lech.perczak@gmail.com> [remove kmod-usb-ledtrig-usbport, take merged upstream patches] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit 59d065c9f81c4d1a89464d071134a50529449f34) [Manually remove no longer needed patches for modem] Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
* kernel: bump 5.4 to 5.4.123Kuan-Yi Li2021-05-3013-63/+32
| | | | | | | | | | | | Removed because in upstream generic/pending-5.4/770-02-net-ethernet-mtk_eth_soc-fix-rx-vlan-offload.patch All others updated automatically. Runtime-tested on bcm27xx/bcm2711. Fixes: FS#3085 Signed-off-by: Kuan-Yi Li <kyli@abysm.org>
* base-files: generate network config with "device" optionsRafał Miłecki2021-05-272-4/+4
| | | | | | | | Replace "ifname" with "device" as netifd has been recently patches to used the later one. It's more clear and accurate. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit 4b9a67362d70c544b85078b8d5c661f43f7472d9)
* ipq806x: improve system latencyAnsuel Smith2021-05-261-0/+17
| | | | | | | | | | | | | | | Various report and data show that the freq 384000 is too low and cause some extra latency to the entire system. OEM qsdk code also set the min frequency for this target to 800 mhz. Also some user notice some instability with this idle frequency, solved by setting the min frequency to 600mhz. Fix all these kind of problem by introducing a boot init.d script that set the min frequency to 600mhz and set the ondemand governor to be more aggressive. The script set these value only if the ondemand governor is detected. 384 mhz freq is still available and user can decide to restore the old behavior by disabling this script. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> (cherry picked from commit 861b82d36ae43efec8d16e61b82482e38996af92)
* archs38: set device vendor and model variablesMoritz Warning2021-05-261-0/+2
| | | | | | | This fixes the profiles.json output. Signed-off-by: Moritz Warning <moritzwarning@web.de> (cherry picked from commit cc54f65daa6101721c068cd00fdead1815db0bbf)
* arc770: set device vendor and model variablesMoritz Warning2021-05-261-0/+2
| | | | | | | This fixes the profiles.json output. Signed-off-by: Moritz Warning <moritzwarning@web.de> (cherry picked from commit d00bbd9de0719eededc7ee6a7cb2d8f4de6e4540)
* mvebu: 5.4 fix DVFS caused random boot crashesRobert Marko2021-05-231-0/+107
| | | | | | | | | | | | | | | | | | 5.10.37 and 5.4.119 introduced a lot of DVFS changes for Armada 37xx from 5.13 kernel. Unfortunately commit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/cpufreq/armada-37xx-cpufreq.c?h=v5.10.37&id=a13b110e7c9e0dc2edcc7a19d4255fc88abd83cc This patch actually corrects the things so that 1 or 1.2GHz models would actually get scaled to their native frequency. However, due to a AVS setting voltages too low this will cause random crashes on 1.2GHz models. So, until a new safe for everybody voltage is agreed on lets revert the patch. Fixes: 9d21ecc ("kernel: bump 5.4 to 5.4.119") Signed-off-by: Robert Marko <robert.marko@sartura.hr> (cherry picked from commit 080a0b74e39d159eecf69c468debec42f28bf4d8)
* generic: mt7530: fix EEE patchDENG Qingfang2021-05-231-1/+1
| | | | | | | | The higher 16-bit of EEE register was overwritten by mistake, fix that. Fixes: 5b9ba4a93e83 ("generic: mt7530: support adjusting EEE") Signed-off-by: DENG Qingfang <dqfext@gmail.com> (cherry picked from commit 8d1567ba6177f24969e76733d0cee30a830b5f7e)
* kernel: backport "mvmdio avoid error message for optional IRQ"Daniel González Cabanelas2021-05-231-0/+33
| | | | | | | | | | Rid of kernel error message: [ 0.780828] orion-mdio d0072004.mdio: IRQ index 0 not found on Marvell targets backporting the kernel commit fa2632f74e57 Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com> (cherry picked from commit d6831752367722e916bd15e5d1af79993c637a67)
* bcm63xx: Remove patch already applied upstreamHauke Mehrtens2021-05-231-34/+0
| | | | | | | | The patch 434-nand-brcmnand-fix-OOB-R-W-with-Hamming-ECC.patch is integrated in the kernel update 5.4.119 and not needed any more. Fixes: 9d21eccc6b76 ("kernel: bump 5.4 to 5.4.119") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ramips: fix SUPPORTED_DEVICES for ALFA Network devicesPiotr Dymacz2021-05-173-0/+5
| | | | | | | | | Vendor firmware expects model name without manufacturer name inside 'supported_devices' part of metadata. This allows direct upgrade to OpenWrt from vendor's GUI. Signed-off-by: Piotr Dymacz <pepe2k@gmail.com> (cherry picked from commit cf3f1f82eaa95c72b3b2620c6da15a81f8d57ba7)
* kernel: bump 5.4 to 5.4.119Hauke Mehrtens2021-05-1534-170/+45
| | | | | | | | | | | | | | | | | Removed because in upstream generic/backport-5.4/050-gro-fix-napi_gro_frags-Fast-GRO-breakage-due-to-IP-a.patch ath79/patches-5.4/0050-spi-ath79-remove-spi-master-setup-and-cleanup-assign.patch ramips/patches-5.4/999-fix-pci-init-mt7620.patch Manually rebased ath79/patches-5.4/0033-spi-ath79-drop-pdata-support.patch All others updated automatically. Compile-tested on: x86/64, ath79/generic Runtime-tested on: x86/64, ath79/generic Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* mvebu: Remove patch only needed for kernel 5.10Hauke Mehrtens2021-05-141-29/+0
| | | | | | | Kernel 5.10 is not supported by OpenWrt 21.02, remove this patch. Fixes: d530ff37bf33 ("mvebu: armada 370: dts: fix the crypto engine") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: Activate FORTIFY_SOURCE for MIPS kernel 5.4Hauke Mehrtens2021-05-1412-117/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_FORTIFY_SOURCE=y is already set in the generic kernel configuration, but it is not working for MIPS on kernel 5.4, support for MIPS was only added with kernel 5.5, other architectures like aarch64 support FORTIFY_SOURCE already since some time. This patch adds support for FORTIFY_SOURCE to MIPS with kernel 5.4, kernel 5.10 already supports this and needs no changes. This backports one patch from kernel 5.5 and one fix from 5.8 to make fortify source also work on our kernel 5.4. The changes are not compatible with the 306-mips_mem_functions_performance.patch patch which was also removed with kernel 5.10, probably because of the same problems. I think it is not needed anyway as the compiler should automatically optimize the calls to memset(), memcpy() and memmove() even when not explicitly telling the compiler to use the build in variant. This increases the size of an uncompressed kernel by less than 1 KB. Acked-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 9ffa2f8193a43b9044fcfd0e16b204e989b0d941)
* ramips: fix mac addresses of Youku YK1Shiji Yang2021-05-142-3/+4
| | | | | | | | | | | | | | | MAC addresses read from official firmware value location Wlan xx 71 de factory@0x04 Lan xx 71 dd factory@0x28 Wan xx 71 df factory@0x2e Label xx 71 dd factory@0x28 Signed-off-by: Shiji Yang <yangshiji66@qq.com> [fix sorting in 02_network, redact commit message] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit e57e460dc75836d3227e7370b9e64a0eabc9d91d)
* ipq40xx: fix hard_config partition size on MikroTik hAP-ac2Baptiste Jonglez2021-05-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The routerbootparts driver dynamically discovers the location of MikroTik partitions, but it cannot determine their size (except by extending them up to the start of the next discovered partition). The hard_config partition has a default size of 0x1000 in the driver, while it actually takes 0x2000 on the hAP-ac2. Set the correct size in the hAP-ac2 DTS. On most devices, this isn't a problem as the actual data fits in 0x1000 bytes. However, some devices have larger data that doesn't fit in 0x1000 bytes. In any case, all devices seen so far have enough space for a 0x2000 hard_config partition before the start of the dtb_config partition. With the current 0x1000 size: 0x00000000e000-0x00000000f000 : "hard_config" 0x000000010000-0x000000017bbc : "dtb_config" With this patch extending the size to 0x2000: 0x00000000e000-0x000000010000 : "hard_config" 0x000000010000-0x000000017bbc : "dtb_config" Other ipq40xx boards may need the same fix but it needs testing. References: https://forum.openwrt.org/t/support-for-mikrotik-hap-ac2/23333/324 Acked-by: Thibaut VARÈNE <hacks@slashdirt.org> Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org> (cherry picked from commit 979f4063668185182db7bd2ad4efe6010047765e)
* generic: platform/mikrotik: release mtd device after useThibaut VARÈNE2021-05-122-2/+10
| | | | | | | | | | | | | The code uses get_mtd_device_nm() which must be followed by a call to put_mtd_device() once the handle is no longer used. This fixes spurious shutdown console messages such as: [ 2256.334562] Removing MTD device #7 (soft_config) with use count 1 Reported-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org> (cherry picked from commit 4e385a27d6c4aab62ef7fc9856f09ebee9632985)
* kernel: fix parsing fixed subpartitionsRafał Miłecki2021-05-084-8/+84
| | | | | Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit ed4641e9f1ad940cb60187dea09cf17c865efcaf)
* kernel: bump 5.4 to 5.4.117Hauke Mehrtens2021-05-071-1/+1
| | | | | | | | | All updated automatically. Compile-tested on: x86/64, armvirt/32, ath79/generic Runtime-tested on: x86/64, armvirt/32, ath79/generic Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ipq40xx: add support for MikroTik SXTsq 5 acRoger Pueyo Centelles2021-05-037-3/+269
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds support for the MikroTik SXTsq 5 ac (RBSXTsqG-5acD), an outdoor 802.11ac wireless CPE with one 10/100/1000 Mbps Ethernet port. Specifications: - SoC: Qualcomm Atheros IPQ4018 - RAM: 256 MB - Storage: 16 MB NOR - Wireless: IPQ4018 (SoC) 802.11a/n/ac 2x2:2, 16 dBi antennae - Ethernet: IPQ4018 (SoC) 1x 10/100/1000 port, 10-28 Vdc PoE in - 1x Ethernet LED (green) - 7x user-controllable LEDs · 1x power (blue) · 1x user (green) · 5x rssi (green) Note: Serial UART is probably available on the board, but it has not been tested. Flashing: Boot via TFTP the initramfs image. Then, upload a sysupgrade image via SSH and flash it normally. More info at the "Common procedures for MikroTik products" page https://openwrt.org/toh/mikrotik/common. Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net> (cherry picked from commit d1f1e5269ed992e6fc30d575b43b0913c9e58ca2) [Compile and Run Tested] Signed-off-by: Nick Hainke <vincent@systemli.org>
* ipq40xx: add MikroTik hAP ac2 supportRobert Marko2021-05-036-1/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the MikroTik RouterBOARD RBD52G-5HacD2HnD-TC (hAP ac²), a indoor dual band, dual-radio 802.11ac wireless AP with integrated omnidirectional antennae, USB port and five 10/100/1000 Mbps Ethernet ports. See https://mikrotik.com/product/hap_ac2 for more info. Specifications: - SoC: Qualcomm Atheros IPQ4018 - RAM: 128 MB - Storage: 16 MB NOR - Wireless: · Built-in IPQ4018 (SoC) 802.11b/g/n 2x2:2, 2.5 dBi antennae · Built-in IPQ4018 (SoC) 802.11a/n/ac 2x2:2, 2.5 dBi antennae - Ethernet: Built-in IPQ4018 (SoC, QCA8075) , 5x 1000/100/10 port, passive PoE in - 1x USB Type A port Installation: Boot the initramfs image via TFTP and then flash the sysupgrade image using "sysupgrade -n" Signed-off-by: Robert Marko <robimarko@gmail.com> (cherry picked from commit faea7becafc634dc882f0ad8f9388862ccd5bd0d) [Compile Tested] Signed-off-by: Nick Hainke <vincent@systemli.org>
* ath79: force SGMII SerDes mode to MAC operationDavid Bauer2021-05-032-0/+14
| | | | | | | | | | | | | | | | | | The mode on the SGMII SerDes on the QCA9563 is 1000 Base-X by default. This only allows for 1000 Mbit/s links, however when used with an SGMII PHY in 100 Mbit/s link mode, the link remains dead. This strictly has nothing to do with the SerDes calibration, however it is done at the same point in the QCA reference U-Boot which is the blueprint for everything happening here. As the current state is more or less a hack, this should be fine. This fixes the issues outlined above on a TP-Link EAP-225 Outdoor. Reported-by: Tom Herbers <freifunk@tomherbers.de> Tested-by: Tom Herbers <freifunk@tomherbers.de> Signed-off-by: David Bauer <mail@david-bauer.net> (cherry picked from commit fbbad9a9a629b388626b477e6cd692c160f63fb3)
* ath79: fix USB power on TP-Link TL-WR810N v1Tom Stöveken2021-05-021-0/+1
| | | | | | | | | | | | Before: Kernel reported "usb_vbus: disabling" and the USB was not providing power After: USB power is switched on, peripheral is powered from the device Signed-off-by: Tom Stöveken <tom@naaa.de> [squash and tidy up] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit a6f7268dc7519b57251532fe4239412e8acf4ca7)
* kernel: bump 5.4 to 5.4.114Hauke Mehrtens2021-05-0218-109/+120
| | | | | | | | | | | | | | | | | | | | | | | Removed because in upstream* mvebu/patches-5.4/319-ARM-dts-turris-omnia-configure-LED-2--INTn-pin-as-interrupt-pin.patch Manually rebased* generic/backport-5.4/700-v5.5-net-core-allow-fast-GRO-for-skbs-with-Ethernet-heade.patch Added new backport* generic/backport-5.4/050-gro-fix-napi_gro_frags-Fast-GRO-breakage-due-to-IP-a.patch All others updated automatically. The new backport was included based on this[1] upstream commit that will be mainlined soon. This change is needed because Eric Dumazet's check for NET_IP_ALIGN (landed in 5.4.114) causes huge slowdowns on drivers which use napi_gro_frags(). Compile-tested on: x86/64, armvirt/64, ath79/generic Runtime-tested on: x86/64, armvirt/64, ath79/generic Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ath79: mikrotik: swap RB922UAGS-5HPaCD eth0/1 MACsRoger Pueyo Centelles2021-04-301-0/+5
| | | | | | | | | | | | Since support for SFP on the MikroTik RouterBOARD 922UAGS-5HPacD was added by 4387fe00cb, the MAC addresses for eth0 (Ethernet) and eth1 (SFP) were swapped. This patch fixes the 02_network script to assign MAC addresses correctly, so they match the label and the vendor's OS. Tested on a RouterBOARD 922UAGS-5HPacD board. Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net> (cherry picked from commit 14a95b36b1ecd038fffc279878c5a4c51043d709)
* ath79: mikrotik: enable SFP on RB922UAGS-5HPaCDRoger Pueyo Centelles2021-04-304-2/+51
| | | | | | | | | | | | | | | | | This patch enables the SFP cage on the MikroTik RouterBOARD 922UAGS-5HPacD. GPIO16 (tx-disable-gpios) should be governed by the SFP driver to enable or disable transmission, but no change is observed. Therefore, it is left as output high to ensure the SFP module is forced to transmit. Tested on a RouterBOARD 922UAGS-5HPacD board, with a CISCO GLC-LH-SMD 1310nm module and an unbranded GLC-T RJ45 Gigabit module. PC=>router iperf3 tests deliver 440/300 Mbps up/down, both via regular eth0 port or SFP port with RJ45 module. Bridge between eth0 and eth1 delivers 950 Mbps symmetric. Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net> (cherry picked from commit 4387fe00cb7536d9d341f6d27e465ff0f0b29b1b)
* kernel: drop the conntrack rtcache patchRui Salvaterra2021-04-224-566/+8
| | | | | | | | | | | It's in backports-5.4, but it wasn't ever merged. Upstream followed another approach, with flow offloading, which has much better performance. Drop this obsolete patch and refresh the kernel patches. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com> Acked-by: Stijn Tintel <stijn@linux-ipv6.be> Acked-by: Felix Fietkau <nbd@nbd.name> (cherry picked from commit 17576b1b2aeacf0a23bb9a911d675bd324754745)
* realtek: allow writing to "u-boot-env2"Bjørn Mork2021-04-185-5/+0
| | | | | | | | | U-Boot uses the "bootpartition" variable stored in "u-boot-env2" to select the active system partition. Allow updates to enable system switching from OpenWrt. Signed-off-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit 11d24ffe961570533a4fc54a7511d30c17290623)
* realtek: rename partitions in Netgear DTSIStijn Segers2021-04-181-5/+5
| | | | | | | | | | Switch the Netgear DTSI for the Realtek target from the OEM partition naming scheme to accepted OpenWrt naming practices. A quick git grep for 'u-boot-env' e.g. in the OpenWrt tree turns up almost 500 hits whereas grepping for 'bdinfo' (the OEM equivalent) returns a meagre 14. Signed-off-by: Stijn Segers <foss@volatilesystems.org> (cherry picked from commit 1601b39b6197963e85c441a043702e022779f371)
* realtek: add ZYXEL_VERS to DEVICE_VARSAdrian Schmutzler2021-04-181-0/+2
| | | | | | | | | Otherwise, the last defined value will be set for all devices. Fixes: c6c8d597e183 ("realtek: Add generic zyxel_gs1900 image definition") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit 851dadc257b7223f879a3733507e83cfcaae1af1)
* realtek: enable SerDes NWAY and SGMII negotiationBjørn Mork2021-04-182-3/+42
| | | | | | | | This allows copper SFPs to negotiate speeds lower than 1gig. Acked-by: Birger Koblitz <mail@birger-koblitz.de> Signed-off-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit 963b2ae702510c11e912c9438fdb9222763a22d5)
* realtek: enabled Marvell and Realtek PHYsBjørn Mork2021-04-181-0/+2
| | | | | | | | | | | The rtl83xx-phy driver is necessary for proper configuration of the PHYs if U-Boot hasn't done that. 1000Base-T SFPs often contains a Marvell 88E1111 and will not work without this driver. Include it by default to support copper SFPs. Signed-off-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit 07bf5aaa4c12d6e7eb797b3871a7586f90a46e67)
* realtek: enable HWMON for SFP sensorsBjørn Mork2021-04-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds SFP sensors as a hwmon device, allowing readout of temperatures, DOM and other sensor readings available from the SFP. Example from a ZyXEL GS1900-10HP with a DOM capable 1000Base-SX SFP: root@gs1900-10hp:~# grep . /sys/class/hwmon/hwmon0/* /sys/class/hwmon/hwmon0/curr1_crit:90 /sys/class/hwmon/hwmon0/curr1_crit_alarm:0 /sys/class/hwmon/hwmon0/curr1_input:4 /sys/class/hwmon/hwmon0/curr1_label:bias /sys/class/hwmon/hwmon0/curr1_lcrit:0 /sys/class/hwmon/hwmon0/curr1_lcrit_alarm:0 /sys/class/hwmon/hwmon0/curr1_max:85 /sys/class/hwmon/hwmon0/curr1_max_alarm:0 /sys/class/hwmon/hwmon0/curr1_min:0 /sys/class/hwmon/hwmon0/curr1_min_alarm:0 /sys/class/hwmon/hwmon0/in0_crit:3795 /sys/class/hwmon/hwmon0/in0_crit_alarm:0 /sys/class/hwmon/hwmon0/in0_input:3317 /sys/class/hwmon/hwmon0/in0_label:VCC /sys/class/hwmon/hwmon0/in0_lcrit:2805 /sys/class/hwmon/hwmon0/in0_lcrit_alarm:0 /sys/class/hwmon/hwmon0/in0_max:3465 /sys/class/hwmon/hwmon0/in0_max_alarm:0 /sys/class/hwmon/hwmon0/in0_min:3135 /sys/class/hwmon/hwmon0/in0_min_alarm:0 /sys/class/hwmon/hwmon0/name:sfp_p10 /sys/class/hwmon/hwmon0/power1_crit:708 /sys/class/hwmon/hwmon0/power1_crit_alarm:0 /sys/class/hwmon/hwmon0/power1_input:259 /sys/class/hwmon/hwmon0/power1_label:TX_power /sys/class/hwmon/hwmon0/power1_lcrit:89 /sys/class/hwmon/hwmon0/power1_lcrit_alarm:0 /sys/class/hwmon/hwmon0/power1_max:501 /sys/class/hwmon/hwmon0/power1_max_alarm:0 /sys/class/hwmon/hwmon0/power1_min:126 /sys/class/hwmon/hwmon0/power1_min_alarm:0 /sys/class/hwmon/hwmon0/power2_crit:1259 /sys/class/hwmon/hwmon0/power2_crit_alarm:0 /sys/class/hwmon/hwmon0/power2_input:404 /sys/class/hwmon/hwmon0/power2_label:RX_power /sys/class/hwmon/hwmon0/power2_lcrit:6 /sys/class/hwmon/hwmon0/power2_lcrit_alarm:0 /sys/class/hwmon/hwmon0/power2_max:794 /sys/class/hwmon/hwmon0/power2_max_alarm:0 /sys/class/hwmon/hwmon0/power2_min:10 /sys/class/hwmon/hwmon0/power2_min_alarm:0 /sys/class/hwmon/hwmon0/temp1_crit:100000 /sys/class/hwmon/hwmon0/temp1_crit_alarm:0 /sys/class/hwmon/hwmon0/temp1_input:22547 /sys/class/hwmon/hwmon0/temp1_label:temperature /sys/class/hwmon/hwmon0/temp1_lcrit:-50000 /sys/class/hwmon/hwmon0/temp1_lcrit_alarm:0 /sys/class/hwmon/hwmon0/temp1_max:85000 /sys/class/hwmon/hwmon0/temp1_max_alarm:0 /sys/class/hwmon/hwmon0/temp1_min:-40000 /sys/class/hwmon/hwmon0/temp1_min_alarm:0 /sys/class/hwmon/hwmon0/uevent:OF_NAME=sfp-p10 /sys/class/hwmon/hwmon0/uevent:OF_FULLNAME=/sfp-p10 /sys/class/hwmon/hwmon0/uevent:OF_COMPATIBLE_0=sff,sfp /sys/class/hwmon/hwmon0/uevent:OF_COMPATIBLE_N=1 Tested-by: Birger Koblitz <mail@birger-koblitz.de> Signed-off-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit 2a912fb63adc3fb3a1ee746589f6df4bb02e4296)
* realtek: re-enable sfp driver for ZyXEL GS1900-10HPBjørn Mork2021-04-181-18/+6
| | | | | | | | | | | | | | There is no need to define a static link or a phy for the sfp ports. Using phy-mode and managed properties to describe the link to the sfp phy. We have to keep the now unconnected virtual "phys" because the switch driver uses their "phy-is-integrated" property to figure out which ports to enable as fibre ports. Acked-by: Birger Koblitz <mail@birger-koblitz.de> Signed-off-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit e8d391bd4650418182d96ca06ccd10d636efcbc3)
* realtek: need to handle PHY_INTERFACE_MODE_NA for sfpsBjørn Mork2021-04-181-0/+1
| | | | | | | | | | | From the validate docs in include/linux/phylink.h: When state->interface is PHY_INTERFACE_MODE_NA, phylink expects the MAC driver to return all supported link modes. Tested-by: Birger Koblitz <mail@birger-koblitz.de> Signed-off-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit 785d830e889ba18793acf369e447d704269169af)
* realtek: fix link-state interruptBjørn Mork2021-04-181-4/+3
| | | | | | | | This bug was the root cause for the failing sfp driver. Acked-by: Birger Koblitz <mail@birger-koblitz.de> Signed-off-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit b8e473d18c6af2abf0d047247fdbe6d178228ac0)
* realtek: Add ZyXEL GS1900-8Hauke Mehrtens2021-04-182-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ZyXEL GS1900-8 is a 8 port switch without any PoE functionality or SFP ports, but otherwise similar to the other GS1900 switches. Specifications -------------- * Device: ZyXEL GS1900-8 v1.2 * SoC: Realtek RTL8380M 500 MHz MIPS 4KEc * Flash: Macronix MX25L12835F 16 MiB * RAM: Nanya NT5TU128M8GE-AC 128 MiB DDR2 SDRAM * Ethernet: 8x 10/100/1000 Mbit * LEDs: 1 PWR LED (green, not configurable) 1 SYS LED (green, configurable) 8 ethernet port status LEDs (green, SoC controlled) * Buttons: 1 on-off glide switch at the back (not configurable) 1 reset button at the right side, behind the air-vent (not configurable) 1 reset button on front panel (configurable) * Power 12V 1A barrel connector * UART: 1 serial header (JP2) with populated standard pin connector on the left side of the PCB, towards the back. Pins are labelled: + VCC (3.3V) + TX (really RX) + RX (really TX) + GND the labelling is done from the usb2serial connector's point of view, so RX/ TX are mixed up. Serial connection parameters for both devices: 115200 8N1. Installation ------------ Instructions are identical to those for the GS1900-10HP and GS1900-8HP. * 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-10HP is a dual-partition device, you want to keep the OEM firmware on the backup partition for the time being. OpenWrt can only boot off 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-8-initramfs-kernel.bin > bootm * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade /tmp/openwrt-realtek-generic-zyxel_gs1900-8-squashfs-sysupgrade.bin Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit e6ba970b6ef2289a2a4d3dd6c0c158ee8d10160f)
* realtek: Add generic zyxel_gs1900 image definitionHauke Mehrtens2021-04-181-13/+13
| | | | | | | | Add a new common device definition for the Zyxel GS1900 line of switches. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit c6c8d597e18300cd679bf5ea88a46ed18709da01)
* realtek: drop ethtool log noiseBjørn Mork2021-04-182-15/+15
| | | | | | | | | | | | | | Demote a number of debugging printk's to pr_debug to avoid log nosie. Several of these functions are called as a result of userspace activity. This can cause a lot of log noise when userspace does periodic polling. Most of this could probably be removed completely, but let's keep it for now since these drivers are still in development. Signed-off-by: Bjørn Mork <bjorn@mork.no> Tested-by: Stijn Tintel <stijn@linux-ipv6.be> (cherry picked from commit ba220ad2fd915aaed2e9c850a84078c5c5977d3e)
* ramips: mt7530 swconfig: fix race condition in register accessDENG Qingfang2021-04-181-6/+10
| | | | | | | | | | | | | | | | | The mt7530_{r,w}32 operation over MDIO uses 3 mdiobus operations and does not hold a lock, which causes a race condition when multiple threads try to access a register, they may get unexpected results. To avoid this, handle the MDIO lock manually, and use the unlocked __mdiobus_{read,write} in the critical section. This fixes the "Ghost VLAN" artifact[1] in MT7530/7621 when the VLAN operation and the swconfig LED link status poll race between each other. [1] https://forum.openwrt.org/t/mysterious-vlan-ids-on-mt7621-device/64495 Signed-off-by: DENG Qingfang <dqfext@gmail.com> (cherry picked from commit f99c9cd9c4d4c49a676d678327546fd41690fe2a)
* ath79: fix 10 Mbit PLL data for UniFi ACDavid Bauer2021-04-181-0/+2
| | | | | | | | Fix the PLL register value for 10 Mbit/s link modes on the UniFi AC Lite / Mesh / LR. Otherwise, 10 Mbit/s links do not transfer data. Signed-off-by: David Bauer <mail@david-bauer.net> (cherry picked from commit 956407292dc5fd41f2d8c7cc7e9ec77eb6444c1e)
* ath79: fix 10 Mbit PLL data for TP-Link EAP2xxDavid Bauer2021-04-181-0/+1
| | | | | | | | | | | | Fix the PLL register value for 10 Mbit/s link modes on TP-Link EAP boards using a AR8033 SGMII PHY. Otherwise, 10 Mbit/s links do not transfer data. Reported-by: Tom Herbers <freifunk@tomherbers.de> Tested-by: Tom Herbers <freifunk@tomherbers.de> Signed-off-by: David Bauer <mail@david-bauer.net> (cherry picked from commit bbff6239e2ea273388f4ca0f8586945ff5f36271)
* ramips: reduce spi-max-frequency for Xiaomi MI Router 4AGDavid Bentham2021-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Reduce spi-max-frequency for Xiaomi MI Router 4AG model Xiaomi MI Router 4AG MTD uses two flash chips (no specific on router versions when produced from factory) - GD25Q128C and W25Q128BV. These flash chips are capable of high frequency, but due to poor board design or manufacture process. We are seeing the following errors in the linux kernel bootup: `spi-nor spi0.0: unrecognized JEDEC id bytes: cc 60 1c cc 60 1c spi-nor: probe of spi0.0 failed with error -2` This causes the partitions not to be detected `VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6` Then creates a bootloop and a bricked router. The solution to limit this race condition is to reduce the frequency from 80 mhz to 50 mhz. Signed-off-by: David Bentham <db260179@gmail.com> (cherry picked from commit 17e690017d76c49070bc99d6a376b1926259c5ff)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-28 14:23:27 +0000