Janusz Dziedzic [Mon, 24 Jun 2024 16:48:46 +0000 (18:48 +0200)]
mac80211: ath12k: prevent ltssm crash
Fix ltssm crashes on BPI-Rx boards.
Seems read32/write32 using wrong address which
is not a problem on x86/64 PCI controllers.
But have issues on BPI-Rx boards.
Shiji Yang [Fri, 13 Sep 2024 11:52:30 +0000 (19:52 +0800)]
ath79: disable ath79 USB phy drivers by default
We already have an kernel module package "kmod-phy-ath79-usb" to
drive the ath79 USB. It will be selected by the usb base package
"kmod-usb2" and "kmod-usb-ohci".
Shiji Yang [Fri, 13 Sep 2024 11:52:30 +0000 (19:52 +0800)]
kernel: usb: improve support for ath79 target
1. Remove outdated symbol CONFIG_USB_OHCI_ATH79.
The ath79 OHCI USB was already supported by the generic driver
kmod-usb-ohci. And this kernel symbol has been dropped since
upstream commit: 53d473fc1e38 ("usb: host: Remove the deprecated ATH79 USB host config options")
2. Add ath79 USB phy package to the OHCI dependencies.
Both EHCI and OHCI require it on the ath79 target.
Chris Webb [Mon, 10 Jun 2024 08:54:23 +0000 (09:54 +0100)]
uboot-mediatek: support GL.iNet GL-X3000 and GL-XE3000
Add u-boot support based on the kernel dts introduced in d1016446 and
the GL-MT6000 u-boot support in fe10f974.
The pcie-mediatek-gen3 kernel driver doesn't like hotplug, so to work in
PCIe mode, the 5G modem on this device needs to be switched on by u-boot
before starting the kernel. Include an init_modem step in the boot_system
action to set the relevant gpios. (The factory bootloader does the same,
using Mediatek SDK-specific gpio_power_clr and gpio_pull_up.)
Ideally the modem would be started using gpio-hog in the device tree, but
this will need to wait until mediatek gpio-hog support is fixed upstream:
The bootloader can be replaced using the built-in web interface of the
factory bootloader. Hold the reset button for five seconds while powering
on the device and it will boot into a recovery http server.
http://192.168.1.1/uboot.html and http://192.168.1.1/bl2.html can then
be used to upload openwrt-mediatek-filogic-glinet_gl-x3000-bl31-uboot.fip
and openwrt-mediatek-filogic-glinet_gl-x3000-preloader.bin respectively.
Alternatively, from a root shell on the running system, unlock the boot
partition with
echo 0 >/sys/block/mmcblk0boot0/force_ro
then write openwrt-mediatek-filogic-glinet_gl-x3000-bl31-uboot.fip to
/dev/mmcblk0p4 and openwrt-mediatek-filogic-glinet_gl-x3000-preloader.bin
to /dev/mmcblk0boot0.
Alan Luck [Wed, 10 Jul 2024 11:57:11 +0000 (21:57 +1000)]
ramips: Add support for D-Link DIR-2150-R1
Hardware Specification:
SoC: Mediatek MT7621DAT (MIPS1004Kc 880 MHz, dual core)
RAM: 128 MB
Storage: 128 MB NAND flash
Ethernet: 5x 10/100/1000 Mbps LAN1,LAN2,LAN3,LAN4 & WAN
Wireless: 2.4GHz: Mediatek MT7603EN up to 300Mbps (802.11b/g/n MIMO 2x2)
Wireless: 5GHz: Mediatek MT7615N up to 1733Mbps (802.11n/ac MU-MIMO 4x4)
LEDs: Power (white & amber), Internet (white & amber)
LEDs: 2.4G (White), 5Ghz (White)
Buttons: WPS, Reset
USB: Front V3.0 & Rear V2.0
MAC Table
Label xx:xx:xx:xx:xx:38
LAN xx:xx:xx:xx:xx:39
2.4Ghz xx:xx:xx:xx:xx:3A
5Ghz xx:xx:xx:xx:xx:3C
WAN xx:xx:xx:xx:xx:38
Flash Instructions:
D-Link normal OEM firmware update page
1. upload OpenWRT factory.bin like any D-Link upgrade image
D-Link Fail Safe GUI:
1. Push and hold reset button (on the bottom of the device) until power led starts flashing (about 10 secs or so) while plugging in the power cable.
2. Give it ~30 seconds, to boot the fail safe GUI
3. Connect your client computer to LAN1 of the device
4. Set your client IP address manually to 192.168.0.2 / 255.255.255.0
5. Call the fail safe page for the device at http://192.168.0.1/
6. Use the provided fail safe web GUI to upload the factory.bin to the device
Download and flash image
On computer:
python -m http.server
On router:
cd /tmp
wget http://:8000/factory.bin
mtd -r write factory.bin firmware
Device should reboot at this point.
Reverting to stock:
Download archive with firmware from Ruijie's site and
get .bin file from it. Then write that binary to firmware
partition. After reboot, factory-reset the router using
reset button.
1. Boot WMC-X1800GST normally
2. Access to "http://192.168.2.1/" and open firmware update page
("ファームウェア更新")
3. Select the OpenWrt initramfs-factory image and click apply ("適用")
button
4. On initramfs image, download sysupgrade image to the device and
perform sysupgrade with that image
5. Wait ~120 seconds to complete flashing
Notes:
- The "firmware" partition on the stock image is only 0xF00000 (15 MiB)
and it's too small for the current OpenWrt firmware with UBI format.
So use the unused area at the end of NAND flash for rootfs (UBI).
1. Boot WMC-X1800GST normally with "Router" mode
2. Access to "http://192.168.2.1/" and open firmware update page
("ファームウェア更新")
3. Select the OpenWrt initramfs-factory image and click apply ("適用")
button
4. On initramfs image, download sysupgrade image to the device and
perform sysupgrade with that image
5. Wait ~120 seconds to complete flashing
Notes:
- The "firmware" partition on the stock image is only 0xF00000 (15 MiB)
and it's too small for the current OpenWrt firmware with UBI format.
So use the unused area at the end of NAND flash for rootfs (UBI).
Antonio Flores [Mon, 2 Sep 2024 02:24:35 +0000 (22:24 -0400)]
rockchip: rework LED configurations for the NanoPi R6C/R6S
This commits fixes the LED on the NanoPi R6 series
after changes in the DTS
https://lore.kernel.org/all/20240612205056.397204-4-seb-dev@mail.de
Reported by Github user: gSpotx2f
Antonio Flores [Tue, 27 Aug 2024 20:36:02 +0000 (16:36 -0400)]
rockchip: add FriendlyElec NanoPi R6C
Hardware Spec
-SoC: Rockchip RK3588S
CPU: Quad-core ARM Cortex-A76(up to 2.4GHz) and quad-core Cortex-A55 CPU (up to 1.8GHz)
GPU: Mali-G610 MP4, compatible with OpenGLES 1.1, 2.0, and 3.2, OpenCL up to 2.2 and Vulkan1.2
VPU: 8K@60fps H.265 and VP9 decoder, 8K@30fps H.264 decoder, 4K@60fps AV1 decoder, 8K@30fps H.264 and H.265
NPU: 6TOPs, supports INT4/INT8/INT16/FP16
-RAM: 64-bit 4GB/8GB LPDDR4X at 2133MHz
-Flash: 32GB/None eMMC, at HS400 mode
-Ethernet: one Native Gigabit Ethernet, and one PCIe 2.5G Ethernet
-USB: one USB 3.0 Type-A and one USB 2.0 Type-A
-PCIe: one M.2 Key M connector with PCIe 2.1 x1
-HDMI:
compatible with HDMI2.1, HDMI2.0, and HDMI1.4 operation
support up to 7680x4320@60Hz
Support RGB/YUV(up to 10bit) format
-microSD: support up to SDR104 mode
-GPIO:
30-pin 2.54mm header connector
up to 1x SPI, 3x UARTs, 3x I2Cs, 2x SPDIFs, 1x I2Ss, 3x PWMs, 20x GPIOs
-Debug: UART via 3-Pin 2.54mm header, or on-board USB-C to UART
-LEDs: 4 x GPIO Controlled LED (SYS, WAN, LAN, LED1)
-others:
2 Pin 1.27/1.25mm RTC battery input connector for low power RTC IC HYM8563TS
MASK button for eMMC update
one user button
-Power supply: USB-C, support PD, 5V/9V/12V/20V input
-PCB: 8 Layer, 62x90x1.6mm
-Ambient Operating Temperature: 0℃ to 70℃
Installation:
Uncompress the OpenWrt sysupgrade and write image to the SD card using dd (dd if=*.img of=/*)
eMMC Installation:
Boot from the SD card
Uncompress the OpenWrt sysupgrade image
fash to eMMC : dd if=*.img of=/dev/mmcblk1
sync
remove SD card
reboot
Antonio Flores [Tue, 13 Aug 2024 02:15:28 +0000 (22:15 -0400)]
uboot-rockchip: add FriendlyElec NanoPi R6C
1- The NanoPi R6C is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, optional 32GB eMMC
storage, one M.2 M-Key connector, one RTL8211F 1GbE and one RTL8125
2.5GbE Ethernet port, one USB 2.0 Type-A and one USB 3.0 Type-A port, a
HDMI port, a 30-pin GPIO header as well as multiple buttons and LEDs.
2- Renamed 000-backport-upstream-dts-sync.patch -> 000-v2024.10-rc1-backport-upstream-dts-sync.patch
to add the version when was applied upstream
mvebu: improve sysupgrade for FortiGate/FortiWiFi devices
Update sysupgrade script (fortinet.sh) for Fortinet devices in
mvebu/cortexa9 and fix the following issues,
- Some individuals of FortiGate/FortiWiFi 30E/5xE devices has wrong
kernel/rootfs offsets in "firmware-info" partition and they are not
updated with the current sysupgrade script for Fortinet devices
(fortinet.sh).
As a result, the bootloader tries to load kernel data from the wrong
address and boot with it after OpenWrt installation.
The new script handles offsets in addition to length values.
and improve the following points.
- Only 2 bytes are handled with the current sysupgrade script
(fortinet.sh) for kernel/rootfs length. The new script handles 4 bytes
instead.
- The image names of image0/image1 are not handled and not updated when
sysupgrade. The new sysupgrade script handles it and update to
"<dist> <version> <revision>" if firmware metadata is available.
(ex.: "OpenWrt SNAPSHOT r27440-25384026")
log of new sysupgrade script (fortinet.sh):
Tue Sep 17 10:29:16 UTC 2024 upgrade: Performing system upgrade...
Image Index: 0
Image Name : "OpenWrt SNAPSHOT r27440-25384026"
--> "OpenWrt SNAPSHOT r27441-b3a0806a05"
mvebu: update triggers of "SPEED" LEDs on FortiGate/FortiWiFi devices
The mdio bus number of mv88e6xxx was changed to '0' from '1' and the
"mv88e6xxx-1:<addr>:<speed>" triggers are unavailable now.
Update triggers for "SPEED" LEDs to make working that LEDs again.
The sysupgrade-tar image build is not defined for this target, do not
add a build instruction for it. The build system will use the definition
from the dna_valokuitu-plus-ex400 board and the build will fail.
This fixes the build of the ramips target.
Fixes: 665c2154ef12 ("ramips: add basic support for tp-link er605-v2") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Robert Marko [Sat, 21 Sep 2024 11:31:28 +0000 (13:31 +0200)]
config: build: make STRIP_KERNEL_EXPORTS depend on BROKEN
STRIP_KERNEL_EXPORTS is currently broken on kernel 6.6 and since this
is the only kernel currently supported, we should rather make it depend
on BROKEN instead of a kernel version until its fixed.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: usb: schedule rx work after everything is set up
Right now it's possible to hit NULL pointer dereference in
rtw_rx_fill_rx_status on hw object and/or its fields because
initialization routine can start getting USB replies before
rtw_dev is fully setup.
So while we do the async stuff rtw_usb_probe continues and calls
rtw_register_hw, which does all kinds of initialization (e.g.
via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.
Fix this by moving the first usb_submit_urb after everything
is set up.
For me, this bug manifested as:
[ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped
[ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status
because I'm using Larry's backport of rtw88 driver with the NULL
checks in rtw_rx_fill_rx_status.
The Linux kernel CVE team has assigned CVE-2024-46760 to this issue.
Affected and fixed versions
===========================
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2024-46760
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
drivers/net/wireless/realtek/rtw88/usb.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/c83d464b82a8ad62ec9077637f75d73fe955635a
https://git.kernel.org/stable/c/25eaef533bf3ccc6fee5067aac16f41f280e343e
https://git.kernel.org/stable/c/adc539784c98a7cc602cbf557debfc2e7b9be8b3
Daniel Golle [Tue, 20 Aug 2024 22:14:30 +0000 (23:14 +0100)]
mediatek: add Adtran SmartRG SDG-8733A
Specification is similar to other devices of the MT Stuart series:
* Mediatek MT7988D (3x Cortex-A73, up to 1.8 GHz clock speed)
* 8 GiB eMMC
* 2 GiB DDR4 RAM
* 2500M/1000M/100M LAN port
* 10000M/5000M/2500M/1000M/100M/10M WAN port
* MT7992 Tri-band (2.4G, 5G, 6G) 2T2R+3T3R+3T3R 802.11be Wi-Fi
* Renesas DA14531MOD Bluetooth
* 2 buttons (Reset, Mesh/WPS)
* uC-controlled RGB LED via I2C
* 2x LED for the 2.5G port, 3x LED for the 10G port
* 3.3V-level 115200 baud UART console via 4-pin Dupont connector
exposed at the bottom of the device
* USB-C PD power input
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
David Bauer [Sat, 14 Sep 2024 17:10:10 +0000 (19:10 +0200)]
ipq40xx: add PoE passthrough GPIO
Add the GPIO pin of the PoE passthrough switch on the Aruba AP-303H.
Power is activated when the pin is low. It enables a PSE chip, so power
is only supplied to downstream devices when they are 802.3af/at
compliant devices.
Ensure you use a sufficient power supply when chaining a consuming
device after the AP.
Daniel Golle [Wed, 18 Sep 2024 01:12:24 +0000 (02:12 +0100)]
generic: 6.6: mtk_eth_soc: reset all TX queues on DMA free
The purpose of resetting the TX queue is to reset the
byte and packet count as well as to clear the software
flow control XOFF bit.
MediaTek developers pointed out that netdev_reset_queue would only
resets queue 0 of the network device.
Queues that are not reset may cause unexpected issues.
Packets may stop being sent after reset and "transmit timeout" log may
be displayed.
Import fix from MediaTek's SDK to resolve this issue.
Installation
------------
1. Update the router using stock firmware web interface and OpenWrt
factory.bin image.
Recovery and return to stock
----------------------------
1. Assign your PC a static IP 192.168.1.2 and connect to the router using
the ethernet cable;
2. Power off the router;
3. Press Reset button, power on the router and wait until ethernet led
start blinking;
4. Release the button;
5. Open http://192.168.1.1/ (N6 System Recovery Mode) in your browser;
6. Upload OpenWrt factory.bin (or stock firmware *.bin) image and proceed
with upgrade.
MAC addresses
-------------
+---------+-------------------+
| | MAC example |
+---------+-------------------+
| LAN | dc:xx:xx:49:xx:04 |
| WAN | dc:xx:xx:49:xx:05 |
| WLAN 2g | dc:xx:xx:19:xx:06 |
| WLAN 5g | dc:xx:xx:79:xx:06 |
+---------+-------------------+
The WLAN MAC prototype was found in 'Factory', 0x4
The LAN MAC was found in 'Factory', 0x7ef20
The WAN MAC was found in 'Factory', 0x7ef26
Known issue
-----------
2.4 GHz WLAN doesn't start with mt76 driver.
Probable reason:
Original Netis N6 EEPROM contains wrong MT_EE_WIFI_CONF value (0xd2).
Other routers with the same WLAN hardware (e.g., Routerich AX1800)
have MT_EE_WIFI_CONF = 0x92.
Workaround (already included in this commit):
Extract EEPROM to a file at the first time boot and change
MT_EE_WIFI_CONF (offset 0x190) value from 0xd2 to 0x92. See
/etc/hotplug.d/firmware/11-mt76-caldata for details.
projects / thirdparty / openwrt.git / log
