Any chance 1043N v5 can be added to ath79 ?
I see all other sister routers already with snapshots, but not v5
Check Porting guide ar71xx to ath79?, maybe it has a PR pending already; if not, you could ask in that same thread. Nothing won't be accepted without testing though, so you'll need to volunteer or find someone to do so.
I'm not sure whether this is the correct place to post but I want to share my Kernel Log Errors on the ath79 Snapshots with the Developers.
Kernel Log on Archer C7 v2 ath79 Snapshot from Wed Nov 28 Ubuntu Pastebin expires on 2019-01-03
This is probably related to the patch mentioned in @juppin Post.
did anyone try to make dts for Atheros DB120 reference board?
If anyone make for dir505l and wndr4300 I can test thx
1 Like
FYI
I have created a new target page to reflect the status of ar71xx->ath79 migration:
https://openwrt.org/docs/techref/targets/ar71xx-ath79 - shows ar71xx-ath79 only (=migrated devices)
The already existing pages for ar71xx + ath79 have been modified to show both, ar71xx + ath79:
https://openwrt.org/docs/techref/targets/ar71xx - shows ath79 + ar71xx
https://openwrt.org/docs/techref/targets/ath79 - shows ath79 + ar71xx
I updated the status of the devices listed further above accordingly.
For already existing (ar71xx-) devices, you can update the status yourself by editing the respective dataentry:
- Set target = ath79 → devices with this target can be found only in ath79
- Set target = ar71xx-ath79 → devices with this target can be found in both, ar71xx and ath79
- Set Unsupported functions =
ath79 WIP→ incomplete ath79 migration; work in progress - Set Unsupported functions =
<empty>→ 100% complete ath79 migration; no manual adjustment of configuration necessary when migrating from ar71xx to ath79
2 Likes
Just to add on here, USB for myself with WDR3600, I only get USB 1.1 "Full Speed" throughput on the ath79 platform. On the ar71xx platform, I get USB2/"High Speed" throughput. I have spent some time trying to fix it for ath79, but no progress so far.
The ath79 kernel does give the warning about bus speed, and testing throughput it aligns with what is expected of a Full Speed device.
Thanks for the confirmation, haven't looked into it much as I don't use USB on these devices normally
I haven't progressed much with slow USB on the TP-Link WDR3600. My current thoughts are that it may be related that the ar71xx has the usbgadget feature/driver included, but I've still got a long way to go to learn how to test this hypothesis. I don't know if I should be modifying the dts, or just trying to find a driver etc. The USB root port can function as either a client, or a host, on ar71xx it seems to initialise as a USB2 root hub, and then the on board USB hub shows up. On ath79, the root port initialises as USB2, then a single port full speed USB hub, then the on board USB2 hub.
If this is the case, it will likely affect all AR9344 devices, as well as similar SoC's.
(Unfortunately I lost where I had saved the different kernel logs, and won't be able to go back on forth with firmware builds for a while still.)
Hi @phizev
I checked on ar9344 (dir-825-c1) and it doesn't seem to be a general issue. ath79 image running and getting below.
lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
1 Like
A post was merged into an existing topic: Porting guide ar71xx to ath79?
I faced the same problem in my NEC Aterm WR8750N.
The USB port of this device is internally connected as follows, but the High-Speed hub is connected to AR9344 with Full-Speed in OpenWrt.
AR9344 ---> μPD720114 (hub) ---> USB port
log:
[ 27.888998] usb 1-1: new full-speed USB device number 2 using ehci-platform
[ 28.641313] usb 1-1: not running at top speed; connect to a high speed hub
[ 28.811826] hub 1-1:1.0: USB hub found
[ 28.908943] hub 1-1:1.0: 4 ports detected
However, if I boot OpenWrt after executing tp usb command in the bootloader on this device, the hub was connected with High-Speed.
Therefore, when examining various registers such as GPIO and USB, I noticed that the value of the "Reset" register (addr: 0x1806001c) on AR9344 changed before and after executing that command.
As a result of further checking, when OpenWrt was started with bit 11 of this register set to 0, the hub was correctly connected with High-Speed.
For the ar71xx target, this bit is processed during USB setup in the case of ar934x SoC, but seems to be missing in the ath79 target.
I think this problem will occur if the bootloader does not completely initialize the USB phy.
Hello @musashino, thanks for the feedback. At 0x1806001c I got 0x20004008, which should be
0001 1000 0000 0110 0000 0000 0001 1100
For me USB is high speed. Maybe we can come up with a pinmux alias that boards can use?
Bit 3: Used to set the USB suspend state
Bit 4: Used to reset the USB PHYs
Bit 5: Used to reset the USB Host Controller
Bit 11: Resets the USB PHY’s analog
Bit 15: Used to power down the USB PHY PLL
Those are the bits of the register that deal with USB.
What difference did you spot?
Kind regards,
Seb
Couldn`t get USB drive working on TP-Link WR842v2 (AR9341) on ath79 target also. Good to see some progress
I got 0x24044008 from 0x1806001c when connected with High-Speed. The bits related to USB are the same as you.
IMO, I think that instead of within pinmux, it is appropriate to implement it in Ath79 (ar7200) USB phy driver as well as other bits.
I made following changes in my repo:
(the line 27 in that patch is my mistake, perhaps it should be "assert")
Compile & run tested, and it works. The hub was connected with High-Speed.
However, since I do not have much knowledge of C and Kernel modules, I'm not sure if this is the correct implementation method.
I did look in that direction initially, the bootloader shouldn't have to do any initialisation I believe: https://github.com/pepe2k/u-boot_mod/issues/221
I looked up your device, and judging by the FCC filings, it does not have a USB hub on board. It only has the USB port built in to the AR9344 SOC brought out to an external port. As such, it won't exhibit the behaviour we are seeing.
The output of your lsusb -t only shows the root port/hub (the one in the SOC), and the connected USB drive.
The TP-Link WDR3600/WDR4300 devices have a 4 port USB hub chip on the PCB, with 2 ports usable on the back of the device. The other ports can used with hardware modifications.
1 Like
Of course, I also think that initialization should be done by the Kernel as you say.
My comment above
focuses on "Why there are devices that this problem surfaced and not surfaced one" and there is no intention to "should be initialized by the bootloader".
By the way, are you using u-boot_mod in your TL-WDR3600 v1?
In my I-O DATA WN-AG300DGR (AR9342), if I set the Reset register to 0x24044808 in U-Boot, this issue is occurred. This device does not have the hub chip.
U-Boot 1.2.6 (Jun 29 2012 - 16:01:45)
Hit any key to stop autoboot: 0
ar7240> md.l 0x1806001c 1 <--- read from 0x1806001c
1806001c: 24044008 $.@.
ar7240> mw.l 0x1806001c 0x24044808 <--- set "1" to bit 11
ar7240> md.l 0x1806001c 1
1806001c: 24044808 $.H.
ar7240> boot
## Booting image at 9f040000 ...
when connected the USB device to the port on WN-AG300DGR:
[ 89.984418] usb 1-1: new full-speed USB device number 2 using ehci-platform
[ 90.200008] usb 1-1: not running at top speed; connect to a high speed hub