Have you tried a USB hub in the working port? If you want to run a 4G modem, an externally powered hub would be prudent as many of those modems have power consumption that pushes USB ports to (and sometimes beyond) the limits.
Are the modems that power hungry? The PineA64 has 650mA per port, should be sufficient?
Since the device has 2 Type A connectors without ID pin, what means there will never be an automatic host mode in OTG functionality and client mode on a router would make less sense, at least for my opinion....
why the port is not simply set to standard host in the OpenWrt image? I don't get it what's the reason for that?
Older cat 4 & cat 6 modems should be ok - I have Huawei E3372 & E8372 4G dongles (both cat 4) which work ok on standard USB 2 ports in reasonable signal strength areas. Newer cat 12 and higher modems however require more power to drive the multichannel radios they use for carrier aggregation. Weak signal strength also increases power consumption. Random or frequent loss of connection is quite often due to inadequate power supply.
@pythonic Thank you for the important info! I already discarded the idea to replace my ISP router with the OpenWrt router completely. Means at the moment there is no need for a 4G modem.
Today I tried to install additional driver packages but second usb still dead....further investigation needed
Hi folks!
News from the usb front.
I tried to compile my kernel with the posted kernel config lines added in ~/openwrt/target/linux/sunxi/cortexa53/config-5.4 ...and surprisingly both usb ports are working 
Because I didn't include all needed packages into the build I made a new "menuekonfig", but the compiling failed with errors.
Well, on my first build, I set lan interface to "client" and tried to install the needed drivers in terminal.
That's what I got:
root@OpenWrt:~# opkg install kmod-rt2x00-usb
Unknown package 'kmod-rt2x00-usb'.
Collected errors:
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-cfg80211 found, but incompatible with the architectures configured
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-mac80211 found, but incompatible with the architectures configured
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-rt2x00-lib found, but incompatible with the architectures configured
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-nls-base found, but incompatible with the architectures configured
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-usb-core found, but incompatible with the architectures configured
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-rt2x00-usb found, but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package kmod-rt2x00-usb.
Now it was clear to me why my build failed (with the same errors). The wiki says:
snapshots are built daily, and that sets time limits to installing new packages with opkg. Due to kernel version checksums, you can only install “kmod” kernel modules and other kernel version dependent modules from the exactly same snapshot build. So, a few hours after flashing the firmware you may not be able to install new modules with opkg any more (as the next snapshot has been built into the download repo and has different checksums).
It means, I have only limited time to compile my package and...even worse...I can not install any package to my "custom" build from Luci.
Is this correct?
Edit: Please can you help me with making a *.ko file (module) with the required kernel settings, because I think it's the only clean solution!?
Yes, and no ... 
If you check out the source, you can fiddle with it for as long as you want.
If it's left untouched, and unupdated.
If you start applying later commits it'll sooner or later break its backward compatibility.
Starting from scratch, the image (kernel really) and the module have to come from your
own making, for the versions to match.
Usually it's the kernel and the modules that's picky with the version, the binaries aren't.
If the snapshot comes with a checkout ID (or whatever it's called), you should (at least in theory)
be able to check out the exact same version, build your modules from that, and get snapshot compatible modules.
And yes, every iteration of the snapshot, will invalidate the old snapshot and packages
So you only have a small window when you can install packages, before they are overwritten
by the next snapshot.
But there's nothing stopping you from making your own local copy of all packages available at a
given point in time, and having your own local repository.
I don't get it fully. Anyway. Is there a way to make a single *.ko file with the required settings and merge it into the official image? Will it survive until a major kernel update? Where to start? Can it be done in the "menueconfig"? Do you think that's doable for me?
Well, since you're using a Pine A64+, the OS is stored on a SD card.
You can either build a new image, with your .ko included, or just add your .ko to the SD card afterwards.
I noticed your device is fully supported, not only in snapshots.
I'd DL the latest stable, and check out the source for the specific release.
Make the config changes required, then (re)generate either the whole
image, or just the missing module.
Plus is, then you can use the openwrt module repository, and it won't go
away within 24hrs.
Everything's doable, it's just a matter of time, and money
You mean, build the image with my settings in a module!? Well but I have no idea how to do that. I added it into the "config-5.4" and it's merged into the "boot.scr" I guess. Where to write the config lines to have it as a module?
Build the image, or just the module, both should work.
After you've done a menuconfig, there will be a (hidden, use l -la ) file called .config created,
it contains all the settings used for generating the image/kernel.
That file would/should contain the parameters you listed in Pine A64 only one USB port working - #11 by gueni
When that's done you can try to create the image, or just the missing module.
I have changed the branch to stable. Compiling failed, also can't find a way to make my *.ko.
It's simply above my level. But now I have seen how, in general, compiling a image work and I have learned some.
I wanted an OpenWrt router with WIFI AP, and that's what I got 
At the moment I can live with a single usb port.
@frollic Thank you very much for your help!
Well,
Depending on where it failed, your module might have already been generated ,)
Hi,
Apparently this is the only board where one of the USB-A port is shared with OTG. As such, it wouldn't really make sense to compile it into the kernel, even for the cortexa53 subtarget only (although we're talking about devices where large storage space is usual) - I'll see on the weekend how this support could be packages as modules.
Regards,
-w-
Hi @wigyori
That would be really nice! If I can help in any way (data-sheets, etc.) please let me know!
Thank you very much!
Hi,
So, in the end I've skipped packaging this into modules as i.e. omap compiles the MUSB support into the kernel, so I did the same here - thanks for the initial pointers. 
I've also added support for the BT+wifi module - let's see if we're happy to use space for an optional expansion card.
Regards,
-w-
Hi @wigyori
That's great news! Thank you a lot for the improvements on the Pine devices!
For a noob like me..have I compile it from the snapshots or 19.07.7 branch? Is it included in the official builds -> https://firmware-selector.openwrt.org/?version=19.07.7&target=sunxi%2Fcortexa53&id=sun50i-a64-pine64-plus ?
Best regards, gueni
Edit: I see changes are made in "config-5.4", so only "snapshots", right? What I don't get...you changed to dual role
CONFIG_USB_MUSB_DUAL_ROLE=y
means OTG automatic mode? How to do without DT Pin on USB A? Do I misinterpret that?
Hi folks, final report:
I built an image from master with the settings from post #11 in
~/openwrt/target/linux/sunxi/cortexa53/config-5.4
and both usb ports working! Tested with my WIFI adapter which runs flawless.
I hope this thread will help some Pine users, although I guess there are not many
@wigyori @frollic @pythonic Thank you very much for your help on this topic!
1 Like
Yes, I've changed that - dual role is the default mode, so it works as both host and gadget. While you won't be able to do OTG on the Pine64 with this USB A-port, if we enable MUSB in this subtarget, it should be configured that would cater for most other devices in the subtarget.
Currently this would go into trunk i.e. snapshots, I don't think this would get backported into 19.07 - the 21.02-rc is a different story, I'm happy to put it in there as well.
Thank you for the reply! I's clear now.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.