Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
openwrt-bot opened this issue Jan 19, 2020 · 27 comments
Labels

Comments

@openwrt-bot
Copy link

arminfuerst:

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?

@openwrt-bot
Copy link
Author

adrianschmutzler:

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

@openwrt-bot
Copy link
Author

adrianschmutzler:

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.

@openwrt-bot
Copy link
Author

arminfuerst:

@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.

@openwrt-bot
Copy link
Author

adrianschmutzler:

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

These images are built from master without luci.

@openwrt-bot
Copy link
Author

arminfuerst:

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.

@openwrt-bot
Copy link
Author

zvova7890:

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

@openwrt-bot
Copy link
Author

adrianschmutzler:

@vova

Can you leave a
Tested-by: Full name
here:
#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?)

@openwrt-bot
Copy link
Author

zvova7890:

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?

@openwrt-bot
Copy link
Author

arminfuerst:

@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.

@openwrt-bot
Copy link
Author

adrianschmutzler:

@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!

@openwrt-bot
Copy link
Author

arminfuerst:

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

  1. Started using OpenWRT 18.06.7, ar71xx
    -> USB has power (expected)

  2. Upgrade to 19.07.0, ath79, do not keep settings
    -> 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

@openwrt-bot
Copy link
Author

adrianschmutzler:

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).

@openwrt-bot
Copy link
Author

adrianschmutzler:

@vova Yes.

@openwrt-bot
Copy link
Author

arminfuerst:

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

@openwrt-bot
Copy link
Author

adrianschmutzler:

Just sysupgrade.

@openwrt-bot
Copy link
Author

adrianschmutzler:

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

@openwrt-bot
Copy link
Author

arminfuerst:

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 #2758 - correct?

@openwrt-bot
Copy link
Author

adrianschmutzler:

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 :-)

@openwrt-bot
Copy link
Author

arminfuerst:

: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?

@openwrt-bot
Copy link
Author

adrianschmutzler:

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.

@openwrt-bot
Copy link
Author

adrianschmutzler:

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...

@openwrt-bot
Copy link
Author

arminfuerst:

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

@openwrt-bot
Copy link
Author

adrianschmutzler:

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

@openwrt-bot
Copy link
Author

arminfuerst:

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

@openwrt-bot
Copy link
Author

zvova7890:

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>; };

@openwrt-bot
Copy link
Author

@openwrt-bot
Copy link
Author

adrianschmutzler:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant