Built OpenWrt either with master or 19.07 and the topmost patch from the referenced staging tree applied.
Ok, I will try this, if I can revive my device.
Latest development snapshot bricked it again and unbricking is currently failing ...
In worst case I can build and provide an image, but I'd be happy to save the time for that.
Sadly I gave my TL-WR810N to a friend who needed an AP to cover a part of his apartment not covered by his router
I will try to test, but now that he is used to it, not sure that he will allow some downtime. But first I will have to get at his place.
Thanks!
I can confirm that the fix worked for me.
I added the patch to the latest development version.
Built the openwrt-ath79-generic-tplink_tl-wr810n-v1-squashfs-sysupgrade.img and flashed it successfully.
Thanks, I'll merge the patch then and backport it to 19.07 right away, so it comes in time for the next point release.
Thanks for the ath79 fixes.
Hello and thanks for keeping this device relevant.
Due to the release notes for OpenWRT 19.07.7 I gave ath79 on my TP-Link WR810N a go (coming from ar71xx). The device boots, connects as wireless WDS client and overall it is working OK, except for the USB. The USB bus seems to provide no power (confirmed with a simple LED light and also a USB soundcard) and just the bus controller itself looks as if being recognized:
logread | grep usb says:
# logread | grep usb
Tue Feb 23 21:51:01 2021 kern.err kernel: [ 0.271389] ar7200-usb-phy 18030000.usb-phy: phy reset is missing
Tue Feb 23 21:51:01 2021 kern.info kernel: [ 1.933916] usb_vbus: disabling
Tue Feb 23 21:51:01 2021 kern.info kernel: [ 3.717235] usbcore: registered new interface driver usbfs
Tue Feb 23 21:51:01 2021 kern.info kernel: [ 3.723085] usbcore: registered new interface driver hub
Tue Feb 23 21:51:01 2021 kern.info kernel: [ 3.728735] usbcore: registered new device driver usb
Tue Feb 23 21:51:01 2021 kern.info kernel: [ 3.756567] ehci-platform 1b000000.usb: EHCI Host Controller
Tue Feb 23 21:51:01 2021 kern.info kernel: [ 3.762586] ehci-platform 1b000000.usb: new USB bus registered, assigned bus number 1
Tue Feb 23 21:51:01 2021 kern.info kernel: [ 3.770861] ehci-platform 1b000000.usb: irq 3, io mem 0x1b000000
Tue Feb 23 21:51:01 2021 kern.info kernel: [ 3.797955] ehci-platform 1b000000.usb: USB 2.0 started, EHCI 1.00
Tue Feb 23 21:51:01 2021 kern.info kernel: [ 12.042266] usbcore: registered new interface driver snd-usb-audio
I am comfortable with TFTP and available for testing. I assume the DTS file needs to be edited but since I wanted to see if I can power on the USB manually I first tried to override the GPIO and simply bang it to high, but GPIO remains low:
./gpiocontrol.sh 11 out 1
./gpiocontrol.sh 8 out 1
I assume this is because the usb module already claims this GPIO as defined in the DTS, right?
I am open for hints on how to proceed!
Kind regards,
Torxgewinde
Fixed it, USB power must be "always-on":
$ cat qca9531_tplink_tl-wr810n-v1.dts
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include "qca953x_tplink_tl-wr810n.dtsi"
/ {
compatible = "tplink,tl-wr810n-v1", "qca,qca9531";
model = "TP-Link TL-WR810N v1";
reg_usb_vbus: reg_usb_vbus {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
gpio = <&gpio 11 GPIO_ACTIVE_HIGH>;
enable-active-high;
regulator-always-on;
startup-delay-us = <1000000>;
};
};
&usb0 {
status = "okay";
vbus-supply = <®_usb_vbus>;
};
&usb_phy {
status = "okay";
};
Can you add "regulator-always-on;" to reg_usb_vbus please? This brings the USB bus to life.
Would you please submit a patch via patchwork or GitHub
Thank you Adrian, the nightly-build picked it up and it is working now:
ssh root@192.168.1.1
BusyBox v1.33.0 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r15992-cbcac4fde8
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:~# ls
root@OpenWrt:~# uname -a
Linux OpenWrt 5.4.100 #0 Fri Feb 26 20:11:19 2021 mips GNU/Linux
root@OpenWrt:~# logread | grep usb
Fri Feb 26 20:11:25 2021 kern.info kernel: [ 3.879393] usbcore: registered new interface driver usbfs
Fri Feb 26 20:11:25 2021 kern.info kernel: [ 3.885235] usbcore: registered new interface driver hub
Fri Feb 26 20:11:25 2021 kern.info kernel: [ 3.890895] usbcore: registered new device driver usb
Fri Feb 26 20:11:25 2021 kern.info kernel: [ 3.927560] ehci-platform 1b000000.usb: EHCI Host Controller
Fri Feb 26 20:11:25 2021 kern.info kernel: [ 3.933524] ehci-platform 1b000000.usb: new USB bus registered, assigned bus number 1
Fri Feb 26 20:11:25 2021 kern.info kernel: [ 3.941808] ehci-platform 1b000000.usb: irq 3, io mem 0x1b000000
Fri Feb 26 20:11:25 2021 kern.info kernel: [ 3.962475] ehci-platform 1b000000.usb: USB 2.0 started, EHCI 1.00
Sunshine!
I still wonder why this would be the only device needing this parameter.
I have a v1 US device, and had to use a hex-editor to make the firmware work. See my post:
Well, if partitioning etc. are the same, you probably need to play with
TPLINK_HWID or TPLINK_HWREV
...
Agreed - but for those who aren't compiling their own firmware, shouldn't the image file already reflect this hardware, especially for a file that is being labelled as one that can be installed from the stock firmware in US v1 devices? The hex edit trick achieves the same thing after the fact and I wanted to share how I got it working, in case there are others in a similar situation.
Yes, so you could try to find the correct values and then send a Pull Request for a tplink_tl-wr810n-v1-us if this really makes sense eventually.