OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version openwrt-19.07
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by arminfuerst - 19.01.2020
Last edited by Adrian Schmutzler - 19.02.2020

FS#2753 - USB has no power on TP-Link TL-WR842ND v2.0 after upgrading to 19.07 (ath79)

After upgrading from 18.06 to 19.07 (ath97) the USB port of the device seems to provide no power at all. I have a simple device (TEMPer) I am using for this test. The device has a power LED which starts as soon as there is power on the USB port. The LED in on if I even only connect the device to an active USB hub not being connected to a computer.
I checked that the device has power just before the upgrade.
I made a factory reset of the device before the upgrade.
I tried with two identical devices and had the same effect.
When I run lsusb, I do see the USB hub, but no connected devices.
I applied 19.07 (ar71xx) on one of the devices and the USB port has power.
Can I provide any additional info to support working on this issue?

Closed by  Adrian Schmutzler
19.02.2020 22:38
Reason for closing:  Fixed
Project Manager
Adrian Schmutzler commented on 30.01.2020 12:47

It looks to me like the following command from ar71xx mach files is missing in ath79:

/* config gpio4 as normal gpio function */
	ath79_gpio_output_select(TL_MR3420V2_GPIO_USB_POWER,
				 AR934X_GPIO_OUT_GPIO);

with
#define TL_MR3420V2_GPIO_USB_POWER 4
#define AR934X_GPIO_OUT_GPIO 0

The gpio-export for USB power itself is there and looks correct to me.

References:
https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v8.c https://github.com/openwrt/openwrt/blob/openwrt-19.07/target/linux/ath79/dts/ar9341_tplink_tl-wr842n-v2.dts

Project Manager
Adrian Schmutzler commented on 30.01.2020 14:05

I think this can be solved by a pinmux:

&pinmux {
	pmx_usb_power: pinmux_usb_power {
		pinctrl-single,bits = <0x4 0x0 0xff>;
	};
};

I've built a patch (based on master), please build and test that:
https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/842v2

Please also check whether nothing else is broken.

arminfuerst commented on 09.02.2020 14:00

@Adrian Schmutzler: I don't know how to build a version. If someone could provide me with a build, I'd be happy to try and provide feedback.
In addition: I expected to get notifications for changes, but I obviously didn't get any, I just noticed your comment because I wanted to add that the issue still persists in 19.07.1.

Project Manager
Adrian Schmutzler commented on 09.02.2020 15:36

https://www.adrianschmutzler.net/upload/842-test1.zip

These images are built from master _without_ luci.

arminfuerst commented on 09.02.2020 15:51

Thanks for the fast support - I tried to flash the "sysupgrade"-version, but it doesn't seem to work. When the router reboots:
* The power-LED comes up steady
* After some time, the gear-LED lights steady
* Short after this, all LEDS light for about 1/2 second, then the process starts from the beginning.

Vova commented on 17.02.2020 20:39

I had same problem, pinmux as Adrian Schmutzler mentioned has working for me on wr842nd v2

Project Manager
Adrian Schmutzler commented on 17.02.2020 20:44

@Vova

Can you leave a

Tested-by: Full name <mailaddress>

here:
https://github.com/openwrt/openwrt/pull/2758

(Or e-mail me if you do not want to post your address there?)

@arminfuerst

Is it possible that your issue is due to flashing (now since @Vova says it's working)? Can you retry? (Do these have TFTP?)

Vova commented on 17.02.2020 21:16

Ok, I will. I'm just add

&gpio {
	pinctrl-names = "default";
	pinctrl-0 = <&jtag_disable_pins &pmx_usb_power>;
};

&pinmux {
	pmx_usb_power: pinmux_usb_power {
		pinctrl-single,bits = <0x4 0x0 0xff>;
	};
};

to ar9341_tplink_tl-wr842n-v2.dts, because I'm on stable branch. Will be okay, if I'm leave "Tested" in this case?

arminfuerst commented on 17.02.2020 22:07

@Adrian Schmutzler: I successfully recovered the device using TFTP, so doing another test is simple. What and how exactly shall I retry?
What I did:
1. I flashed the device with https://downloads.openwrt.org/releases/19.07.0/targets/ath79/generic/openwrt-19.07.0-ath79-generic-tplink_tl-wr842n-v2-squashfs-sysupgrade.bin and used the default settings
2. Through LuCI I uploaded the file openwrt-ath79-generic-tplink_tl-wr842n-v2-squashfs-sysupgrade.bin from your zip (SHA256: 4baf9957b35424557f849ed397164a88df0f6a4103c3802b338b6762740da624) without keeping the settings.
I just retried and got the same result. The flash process looks fine, the router restarts and the LEDs are as described in my comment from Feb 9th.

Project Manager
Adrian Schmutzler commented on 18.02.2020 12:26

@arminfuerst
https://www.adrianschmutzler.net/upload/842-test2.zip

I have created a series of images to test.

m0 is just current master and should serve as blind test (normal boot, but no USB power)
m1 to m4 are different setup variations to test.

If m0 does not work properly (except USB, as you would expect from current 19.07), you do not need to test the other images. You can just flash one after the other if nothing breaks in between. Thanks!

arminfuerst commented on 18.02.2020 18:18

@Adrian Schmutzler
Thank you, here are the (successful) results:

1. Started using OpenWRT 18.06.7, ar71xx

  1. > USB has power (expected)

2. Upgrade to 19.07.0, ath79, do not keep settings

  1. > USB has no power (expected)

3. Upgrade to m0-openwrt-ath79-generic-tplink_tl-wr842n-v2-squashfs-sysupgrade.bin

 (03fee64f542f86df4aa17f4351bc40d10f67b3c7083b3dadfb2c518276a29ed2), do not keep settings
 -> upgrade successful
 -> USB has no power (expected)

4. Upgrade to m1-openwrt-ath79-generic-tplink_tl-wr842n-v2-squashfs-sysupgrade.bin

 (13cc661d8eb36ae95b45f7a9b2deee6ad4bd80b2d8658d64300e0b6899d64d44) using
 "sysupgrade -n -v /tmp/m1-*.bin"
 -> upgrade successful
 -> USB has power
 -> USB LED is working (comment: I forgot to check after the first flash,
    I flashed the m1-version again after step 7 (m4 version) to find out)
 -> communication with USB-device is working

5. Upgrade to m2-openwrt-ath79-generic-tplink_tl-wr842n-v2-squashfs-sysupgrade.bin

 (4009989b646d7a1b56cbd072379d8e1852d3153b0709351a4b688db83bd7c6bd) using
 "sysupgrade -v -n /tmp/m2-*.bin"
 -> upgrade successful
 -> USB has power
 -> USB LED is working
 -> communication with USB-device is working

6. Upgrade to m3-openwrt-ath79-generic-tplink_tl-wr842n-v2-squashfs-sysupgrade.bin

 (780336d04ab6bf01d55d6f371e8756969108da25ac92a784396da2611f4942cb) using
 "sysupgrade -v -n /tmp/m3-*.bin"
 -> upgrade successful
 -> USB has power
 -> USB LED is working
 -> communication with USB-device is working

7. Upgrade to m4-openwrt-ath79-generic-tplink_tl-wr842n-v2-squashfs-sysupgrade.bin

 (6189e00da1584dab085e6ee0972b754e3d60d31f10d65310292dd822fd6ec1a1) using
 "sysupgrade -v -n /tmp/m4-*.bin"
 -> upgrade successful
 -> USB has power
 -> USB LED is working
 -> communication with USB-device is working
Project Manager
Adrian Schmutzler commented on 18.02.2020 19:22

Okay, thanks. m4 is actually the same config as the test1 image should have had.

But I just saw that the test1 sysupgrade image was also bigger than usual, maybe something went south during build there.

I have prepared a final image to test here:
https://www.adrianschmutzler.net/upload/842-test3.zip

It should be equivalent to m4.

If this works, please also post your Tested-by (syntax as above here).

Project Manager
Adrian Schmutzler commented on 18.02.2020 19:24

@Vova Yes.

arminfuerst commented on 18.02.2020 19:25

@Adrian Schmutzler
Is it enough to test "sysupgrade" or shall I test both?

Project Manager
Adrian Schmutzler commented on 18.02.2020 19:27

Just sysupgrade.

Project Manager
Adrian Schmutzler commented on 18.02.2020 19:28

But please check whether rest of the LEDs seems normal, too, and maybe test the reset button.

arminfuerst commented on 18.02.2020 20:15

I tested everything (incl. resetting to 19.07.1 using TFTP through the reset button, all LEDs, WLAN-button) successfully. I assume I shall leave the "Tested-by" comment at https://github.com/openwrt/openwrt/pull/2758 - correct?

Project Manager
Adrian Schmutzler commented on 18.02.2020 20:17

You can leave the Tested-by here, in the Pull Request, or send me an e-mail. I don't care, it's just where you want to have it crawled by bots :-)

arminfuerst commented on 18.02.2020 20:20

:D
One last question: I have two other devices I am also using USB, they are also based on ar71xx. I didn't try to upgrade those, because they are more important and I don't have spare devices to test with. They are "NETGEAR WNDR3800" and "TP-Link TL-WDR3600 v1". Is it very likely I might have similar issues with those devices when I upgrade them to ath79?

Project Manager
Adrian Schmutzler commented on 18.02.2020 20:33

Just look for bug reports on these devices. The issue discussed here should be specific to the three devices named in my patch, though.

I will prepare a test patch for the 19.07 backport soon.

Project Manager
Adrian Schmutzler commented on 18.02.2020 23:46

Images for 19.07 backport testing are put here:
https://www.adrianschmutzler.net/upload/842-test4.zip

For some strange reason, the image is bigger than the build from master...

arminfuerst commented on 19.02.2020 19:19

@Adrian Schmutzler
I just successfully tested 842-test4.zip (sysupgrade).

Project Manager
Adrian Schmutzler commented on 19.02.2020 22:38

Thanks, I will backport this to 19.07 later this week.

arminfuerst commented on 01.03.2020 15:30

I just tried with OpenWRT 19.07.2 and it is working with my testing device.
@Adrian Schmutzler Thanks again for your support!

Vova commented on 01.03.2020 17:02

Also, I'm found this in kernel log

[    0.148356] ath79-gpio 18040000.gpio: could not find pctldev for node /ahb/apb/pinmux@1804002c/pinmux_jtag_disable_pins, deferring probe

This is not critical, but as I'm understand, ar9341.dtsi doesn't have record like in ar9330.dtsi

      jtag_disable_pins: pinmux_jtag_disable_pins {
          pinctrl-single,bits = <0x0 0x1 0x1>;
      };
Project Manager
Adrian Schmutzler commented on 09.03.2020 15:45
Project Manager
Adrian Schmutzler commented on 09.03.2020 15:46

But this is an unrelated issue, please post separately if you can reproduce it.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing