OpenWrt/LEDE Project

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

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.

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

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

These images are built from master _without_ luci.

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.

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

@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?)

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?

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

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

@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

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

@Vova Yes.

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

Just sysupgrade.

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

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?

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

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

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.

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

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

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

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

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

The pins are there: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar934x.dtsi#L105

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