The only real user of this patch was removed and migrated to the
upstream friendly regulator. Remove this hack.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17356
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently, an OpenWrt hack is used to turn the GPIO on in terms of the
PHY driver when it should be the USB driver that controls it. The
chipidea USB2 driver has support for a vbus-supply property. Use it
instead of the local OpenWrt solution that just turns on the GPIO.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17356
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The chipidea USB2 driver used on this platform supports controlling GPIO
through regulators. This is the upstream friendly solution.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17356
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Subtarget xrx200_legacy supports only a few devices. They all use
the integrated Lantiq GSWIP switch and lantiq xway PHYs. The atheros
and icplus PHYs can be safely disabled.
Switches used by individual devices are listed below.
Device Switch PHY
Alpha ASL56026 Lantiq GSWIP int. switch
Arcadyan VG3503J Lantiq GSWIP int. switch
Netgear DM200 Lantiq GSWIP int. switch
TP-LINK TD-W8970 Lantiq GSWIP Lantiq PEF7071V
TP-Link TD-W8980 Lantiq GSWIP Lantiq PEF7071V
Reduces uncompressed kernel size by 16 kB.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/17581
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This was done by executing these command:
$ make kernel_oldconfig CONFIG_TARGET=subtarget
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/17581
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Plusnet Hub One and BT Business Hub 5A have the same hardware as
the BT Home Hub 5A. This commit adds alternative names so that both
devices can be easily found in the firmware selector.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/17583
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The TP-Link TD-W9980(B) shares the same hardware with the TP-Link TD-W8980.
The only difference is that the TD-W8980 does not support VDSL. This is a
software limitation and once the software is changed, both work equally
supporting VDSL. This commit adds alternative names for devices so they
can be easily found in the firmware selector.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/17583
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
A new syntax for LEDs was used, and migration of the LEDs configuration was
added. Used lower case hex characters for the addresses. Fixed a USB port
power issue.
Signed-off-by: Anton Yu. Ivanusev <ivanusevanton@yandex.ru>
Link: https://github.com/openwrt/openwrt/pull/17521
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Update the base DTS file for the 16 and 24 port HPE 1920 devices
(JG923A, JG924A, JG925A, JG926A), causing the new RTL8231 MFD driver to
be loaded at start-up.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Update the base DTS file for the 8 port HPE 1920 devices (JG920A,
JG921A, JG922A), causing the new RTL8231 MFD driver to be loaded at
start-up.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The manufacturer Cudy usually releases signed openwrt firmware, to
facilitate the migration from the proprietary version to the official
versions of openwrt. In contact with the manufacturer tells me that only
releases the firmware of the WR3000H if and only if
there is an official version. With this proposal I pretend to have an
initial operative version so that they do their part, and facilitate to
the users the possibility of using openwrt. In the present state, it is
only possible to use this firmware by uploading and installing it with
UART connection.
AX3000 2.5G Dual Band Wi-Fi 6 Mesh Router (WR3000H)
Hardware
--------
MediaTek MT7981 WiSoC
256MB DDR3 RAM
128MB SPI-NAND (XMC XM25QH128C)
MediaTek MT7981 2x2 DBDC 802.11ax 2T2R (2.4 / 5)
4 LAN MediaTek MT7531 PHY
1 WAN RTL8221B-VB-CG 2.5Gbps PHY (C22)
2 Radios MT7976CN
UART: 115200 8N1 3.3V
MAC:
LAN MAC: label mac
WAN MAC: label mac + 1
2.4G MAC: label mac
5G MAC: label mac + 1 with LA bit set
Installation
------------
1. Connect to the serial port as described in the "Hardware" section.
2. Power on the device + press reset pin. Keep pressing reset pin to
enter the U-Boot shell (The recovery.bin image load process must fail).
3. Download the OpenWrt initramfs image. Place it on an TFTP server
connected to the Cudy LAN ports. Make sure the server is reachable at
192.168.1.88. Rename the image to "cudy3000h.bin"
4. Download and boot the OpenWrt initramfs image.
$ tftpboot 0x46000000 cudy3000h.bin; bootm 0x46000000
5. IMPORTANT: Make backup from original firmware. System -> Backup
/Flash Firmware -> Save mtdblock contents. All mtdblock one by one,
keep unaltered (BL2, u-boot-env, Factory, bdinfo, FIP, and ubi).
6. Transfer the OpenWrt sysupgrade image to the device using scp.
Install with sysupgrade.
Warning for BL2 and U-BOOT developers
-------------------------------------
The nand partition layout from vendor is slightly diferent from "standard".
The FIP partition starts at 0x3c0000 be carefull with BL2 to BL31.
The UBI partition start at 0x5c0000 be carefull.
DO NOT OVERWRITE bdinfo partition it contains hardware MAC definition
Layout is start-end (not start size)
- 0x000000000000-0x000007800000 : "nmbm0"
- 0x000000000000-0x000000100000 : "bl2"
- 0x000000100000-0x000000180000 : "u-boot-env"
- 0x000000180000-0x000000380000 : "factory"
- 0x000000380000-0x0000003c0000 : "bdinfo"
- 0x0000003c0000-0x0000005c0000 : "fip"
- 0x0000005c0000-0x0000045c0000 : "ubi"
ALLWAYS for U-BOOT operations check this
setenv mtdids nmbm0=nmbm0
setenv mtdparts nmbm0:1024k(bl2),512k(u-boot-env),2048k(factory),256k(bdinfo),2048k(fip),65536k(ubi)
Signed-off-by: Juan Pedro Paredes Caballero <juanpedro.paredes@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17458
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
TP-Link EAP610-Outdoor is a 802.11ax AP claiming AX1800 support. It is
wall or pole mountable, and rated for outdoor use. It can only be
powered via PoE.
Specifications:
---------------
* CPU: Qualcomm IPQ6018 Quad core Cortex-A53
* RAM: 512 MB
* Storage: ESMT PSR1GA30DT 128MB NAND
* Ethernet:
* Gigabit RJ45 port with PoE input
* WLAN:
* 2.4GHz/5GHz
* LEDs:
* Multi-color System LED (Green/Amber)
* Buttons:
* 1x Reset
* UART: 4-pin unpopulated header
* 1.8 V level, Pinout 1 - TX, 2 - RX, 3 - GND, 4 - 1.8V
Installation:
=============
Web UI method
-------------
Set up the device using the vendor's web UI. After that go to
Management->SSH and enable the "SSH Login" checkbox. Select "Save".
The connect to the machine via SSH:
ssh -o hostkeyalgorithms=ssh-rsa <ip_of_device>
Disable signature verification:
cliclientd stopcs
Rename the "-web-ui-factory" image to something less than 63
characters, maintaining the ".bin" suffix.
* Go to System -> Firmware Update.
* Under "New Firmware File", click "Browse" and select the image
* Select "Update" and confirm by clicking "OK".
If the update fails, the web UI should show an error message.
Otherwise, the device should reboot into OpenWRT.
TFTP method
-----------
To flash via tftp, first place the initramfs image on the TFTP server.
setenv serverip <ip of tftp server>
setenv ipaddr <ip in same subnet as tftp server>
tftpboot tplink_eap610-outdoor-initramfs-uImage.itb
bootm
This should boot OpenWRT. Once booted, flash the sysupgrade.bin image
using either luci or the commandline.
The tplink2022 image format
============================
The vendor images of this device are packaged in a format that does
not match any previous tplink formats. In order for flashing to work
from the vendor's web UI, firmware updates need to be packaged in
this format. The `tplink-mkimage-2022.py` is provided for this
purpose.
This script can also analyze vendor images, and extract the required
"support" string. This string is checked by the vendor firmware, and
images with a missing or incorrect string are rejected.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14922
Signed-off-by: Robert Marko <robimarko@gmail.com>
This setting is more suitable for device running OpenWRT.
Most OpenWRT targets are already default to this configuration,
and it has shown better performance in VPN (wireguard).
Fix: #17454
Signed-off-by: Kien Truong <duckientruong@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17575
Signed-off-by: Robert Marko <robimarko@gmail.com>
OpenWRT on the WNDAP6x0 refuses to sysupgrade to itself
due to a compat_version imbalance. The Image is generated
with version 2.0, but the uci-defaults says that it needs
to be at 3.0 for the device.
Fix this by downgrading WNDAP6x0 05_fix-compat-version's
values back to 2.0 so it matches what we use.
Fixes: 5815884c3a2a ("apm821xx: migrate to DSA")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This adds a new port for the above device.
Currently, there is no easy installation method except
opening the device up and soldering a UART header on and
getting u-boot shell access. You boot the initramfs version
first using tftpboot, then once booted, you sysupgrade.
Shell access to root on vendor firmware:
admin:1234
To get U-Boot console, spam '4' into the serial console at boot.
with LEDs on the left, serial pinout is:
o - tx
o - rx
o - gnd
x - 3v3
server ip for tftpboot
192.168.0.225
The initramfs-kernel version boots without touching onboard flash with:
MT7628# tftpboot 0x80000000 openwrt-ramips-mt76x8-tplink_archer-mr200-v6-initramfs-kernel.bin
MT7628# bootm 0x80000000
Then when it boots off RAM, you copy
openwrt-ramips-mt76x8-tplink_archer-mr200-v6-squashfs-sysupgrade.bin
to /tmp/sysupgrade.bin of the device and run:
root@OpenWrt:/tmp# sysupgrade -n sysupgrade.bin
- [x] LEDs working
- [x] Buttons working
- [x] wlan detected
- [x] wwan detected
- [x] initramfs image working
- [x] sysupgrade working
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Link: https://github.com/openwrt/openwrt/pull/15610
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Refresh DTS with required changes for cpufreq, MTD and MMC. While at it
also fix wrong speed for MAC.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add patch fixing support for MMC. Additional clock are needed for MMC to
work and some small fixup to make the Mediatek MMC driver on Airoha SoC.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
ChromiumOS's vboot_reference tooling [1] provides convenient access to
various firmware and hardware details via its `crossystem` tool.
crossystem currently:
(1) relies on the v1 GPIO cdev API to read GPIOs; and
(2) expects gpio-line-names properties.
Enable the kernel config, and document a few pins for OnHub devices.
I only go so far as to pull two relevant names out of the vendor device
tree. Others could perhaps be backfilled if the info is available and
useful.
[1] https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/HEAD/README
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16014
Signed-off-by: Robert Marko <robimarko@gmail.com>
ChromiumOS's vboot_reference tooling [1] provides convenient access to
various firmware and hardware details via its `crossystem` tool.
crossystem currently:
(1) relies on the v1 GPIO cdev API to read GPIOs; and
(2) expects gpio-line-names properties.
Enable the kernel config, and document a few pins for Google WiFi
devices.
I only go so far as to pull two relevant names out of the vendor device
tree. Others could perhaps be backfilled if the info is available and
useful.
[1] https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/HEAD/README
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16014
Signed-off-by: Robert Marko <robimarko@gmail.com>
These flash chips are used on Google / TP-Link / ASUS OnHub devices, and
OnHub devices are write-protected by default (same as any other
ChromeOS/Chromebook system).
This patch has been submitted upstream, per the notes in the patch file.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16014
Signed-off-by: Robert Marko <robimarko@gmail.com>
The label MAC address is written inside the case of the whw03 v2 at the bottom.
Similar fix as to the 4040 in b22d382ae4eaa1af42930115d91855f402314cac
Signed-off-by: Florian Maurer <f.maurer@outlook.de>
Link: https://github.com/openwrt/openwrt/pull/17535
Signed-off-by: Robert Marko <robimarko@gmail.com>
This patch is also needed on bmips since it fixes issues with GPIOs not being
properly configured due to gpio_request_enable not being called on bcm63xx
devices. Therefore we can now drop the bcm63268 gpio function patch.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
ath79 uses the generic-ehci driver, which does not support regulators
using vbus-supply.
dr_mode is also not useful as the driver does not support multiple
modes.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17486
Signed-off-by: Robert Marko <robimarko@gmail.com>
Update the devicetree files to switch the GS1900 devices over to the new
pinctrl and GPIO driver. Enable the drivers to ensure the nodes can be
used.
This may fix issues caused by bad RMW behaviour on the GPIO data lines,
or glitches due to setting the pin direction before the pin level.
Although the driver supports retaining GPIO state after a warm boot,
some bootloaders appear to apply a default configuration on boot, which
may cause an interrupt in PoE-PSE support.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Add pending patches to add RTL8231 support as a MDIO-bus attached
multi-functional device. This includes subdrivers for the pincontrol and
GPIO features, as well as the LED matrix support.
Leave the drivers disabled until required by a device.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Add a disabled node for the auxiliary MDIO bus, used to manage the
RTL8231 expanders. A simple-mfd parent node is added, at the same
(implied) address as the switch@1b000000 node, as the switch drivers
should anyway transistion to MFD subdivices at some point.
Additionally, two pinctrl-single node are added to allow the MDX pins to
be muxed correctly, in case the bootloader leaves these unconfigured.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Add a driver that exposes the auxiliary busses, used for the RTL8231
expanders, as a proper MDIO controller. The device must be instantiated
under an MFD device, so the driver should also be compatible with SoC
managed by an external CPU via SPI.
Leave the driver disabled in builds until required.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Run 'make kernel_oldconfig' to get an up-to-date config.
"# CONFIG_I2C_MUX_RTL9300 is not set" is retained, as the kernel module
build will selects CONFIG_I2C_MUX=m, on which this symbol depends.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Updating the driver patches for ipq40xx (correctly) removed the
ethernet0 alias from qcom-ipq4019.dtsi; however, on some devices this
alias is needed for the bootloader to set MAC addresses in the FDT.
As it is unknown which devices actually need the alias, simply add it to
all devices trees for now that enable the &gmac now to avoid regressions
from previous OpenWrt releases. The additional alias should not cause any
issues even when it is not needed.
A TODO comment is added to the same Device Trees to document that the
alias may not be needed (hopefully preventing it from being copied
unnecessarily to newly added devices in the future). The following
devices are known to need the alias for correct MAC address assignment,
so no TODO comment is added:
- FRITZ!Box 4040
- FRITZ!Box 7530
Fixes: cd9c7211241e ("ipq40xx: 6.1: use latest DSA and ethernet patches")
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Link: https://github.com/openwrt/openwrt/pull/17442
Signed-off-by: Robert Marko <robimarko@gmail.com>
According to datasheet, on AR9344 the switch and switch analog need to
be reset first before initiating a full reset.
Resetting these systems fixes spurious reset hangs on Atheros AR9344
SoCs.
Link: https://github.com/freifunk-gluon/gluon/issues/2904
Signed-off-by: David Bauer <mail@david-bauer.net>
This reverts commit 7ce4ed4829fafdd37a57681304ea91e3749bc3c8.
Turns out that this requires more work, so revert to prevent making the
LED uncontrollable.
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Linksys MX4200v2 doesn't have the same LED controller as the MX4200v1 or MX4300. It comes with the STMicroelectronics LED1202 while the others come with the NXP PCA9633.
This LED controller has a driver under development which is currently being reviewed by the respective kernel maintainers. They are currently on v11.
Apart from the changes needed on the MX4200v2, this commit also amends the configuration of other devices affected by this change as the LED controller is no common to all of them as it was originally thought.
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/17451
Signed-off-by: Robert Marko <robimarko@gmail.com>
This LED controller has a driver under development which is currently being reviewed by the respective kernel maintainers. They are currently on v11 which is included here.
The LED1202 is a 12-channel low quiescent current LED driver with:
* Supply range from 2.6 V to 5 V
* 20 mA current capability per channel
* 1.8 V compatible I2C control interface
* 8-bit analog dimming individual control
* 12-bit local PWM resolution
* 8 programmable patterns
If the led node is present in the controller then the channel is
set to active.
The output current can be adjusted separately for each channel by 8-bit
analog (current sink input) and 12-bit digital (PWM) dimming control. The
LED1202 implements 12 low-side current generators with independent dimming
control.
Internal volatile memory allows the user to store up to 8 different patterns,
each pattern is a particular output configuration in terms of PWM
duty-cycle (on 4096 steps). Analog dimming (on 256 steps) is per channel but
common to all patterns. Each device tree LED node will have a corresponding
entry in /sys/class/leds with the label name. The brightness property
corresponds to the per channel analog dimming, while the patterns[1-8] to the
PWM dimming control.
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/17451
Signed-off-by: Robert Marko <robimarko@gmail.com>
I think I implemented the U-Boot handling incorrectly on M30 (saw the issue while porting M60 to OpenWrt). Maybe someone with more U-Boot experience can have a look at it.
What I understood until now:
Before flashing, `sw_tryactive` must be set to 0 because OpenWrt runs on partition 0
During reset after flashing, U-Boot executes the following line:
`boot_rd_auto_sw_img=if itest.s ${sw_tryactive} == 2; then run boot_by_part; else run boot_by_tryactive; fi`
As `sw_tryactive` was set to 0 before flashing, `boot_by_tryactive` will be executed:
`boot_by_tryactive=if itest.s ${sw_tryactive} == 0; then setenv sw_tryactive 2; setenv sw_active 1; saveenv; run ub0; else setenv sw_tryactive 2; setenv sw_active 2; saveenv; run ub1; fi`
As `sw_tryactive` was set to 0 before flashing, `sw_active` will be set to 1 and `ub0` will be executed:
`ub0=setenv bootpart 0; mtkboardboot; run ub0to1; uip main; reset`
If the OpenWrt boot is successful, `ub0to1` and `uip` main will never be executed. Only in case OpenWrt cannot be loaded, `mtkboardboot` will return and the fallback `ub0to1` is executed.
Conclusion: It's sufficient to set `sw_tryacitve` to 0 before flashing, the added code in `target/linux/mediatek/filogic/base-files/etc/init.d/bootcount` is useless.
In the worst case (/proc/cmdline doesn't contain `bootpart=ubi0` as expected), the bootpart variable would be set to 1 and causes starting the firmware from the second partition instead of the one on the first partition.
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17298
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Images for certain devices are staring to become too large, as some
device only have 6MB available in their vendor partition layout for the
initial install. This is especially pressing for bootloaders only
supporting gzip compression.
Drop some packages from DEFAULT_PACKAGES that aren't strictly required
for a factory install. The user can always install more packages later
using opkg/apk, or via a sysupgrade to a custom build.
firewall4 is kept to ensure the most recent firewall package is selected
in builds including LuCI.
ethtool is kept as a frequently used diagnostics tool.
Link: https://github.com/openwrt/openwrt/pull/17450
Signed-off-by: Sander Vanheule <sander@svanheule.net>
We can use a package for the MV88E6060 DSA switch on the single
ath79 device that uses it, saving around 600 KB of memory on
all other devices (for the DSA infrastructure, mainly).
As far as I can see the TP-Link TL WR941 v2 is the only device
using MV88E6060 and the only device with a DSA switch overall.
However the ath79 people should look at this so I'm not
mistaken.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.ozlabs.org/project/openwrt/patch/20250102-ath79-mv88e6060-module-v1-1-c2a8e31e72fc@linaro.org/
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
