Ok, i have tried this cable with 3 different Operatiing Systems(OSX, Ubuntu, and Windows10) and the associated procedure for each.

Everytime I boot the router with the cable connected to usb port, the router power and esata light stay on solid and I get nothing on the serial console. 

Without the cable the router seems to be going thru some kind of boot cycle but power light keeps blinking and the one LAN port LED blinks as if responding to network connectivity but no ssh, ping.

(Last edited by kirkgbr on 23 Dec 2015, 19:33)

Reverse the Tx Rx connections. Assuming Gnd is right.

Edit: The wiki appears to be from the perspective of how you should connect to the device, rather than what those connections are on the device.

(Last edited by anomeome on 23 Dec 2015, 19:53)

That picture is not quite correct. The red wire is providing power from the USB cable to the board, which you definitely don't want. You should hook up only the black, green and white wires.

kirkgbr, some cables have Tx/Rx reversed. Try swapping the green and white wires, and make sure red is not connected.

OMG, you guys rock!!!  Swapping the tx/rx worked and it is alive on usb console.  Now it's time to get this thing back.

Thanks for chiming in @leitec !!!
Another shining example of "If it's on the internet, it must be true" ;-)  Or, don't trust every image you find, no matter how helpful it seems.

(Last edited by wrtpat on 23 Dec 2015, 20:07)

It's completely restored now. 

root@routi:~# uptime
 13:51:52 up 3 min,  load average: 0.41, 0.92, 0.44

Big, HUGE thanks to leitec , wrtpat, and anomeome.  I don't think I could have done it without you. 

What would I do without the net

(Last edited by kirkgbr on 23 Dec 2015, 21:26)

Was curious to see if anyone else was having issues with latest trunk and wifi?

DESIGNATED DRIVER (Bleeding Edge, r48005)

I compiled today, and flashed the firmware, but there is something strange going on with the "wifi" screen.

There is now radio 0 through 3, but only 2 are configurable.

This is what the form looks like on the two that do not work.

Has anyone seen anything like this before?

Just in case anyone else wants to try the build ---  This is for v1 and luci is included in the build.

http://personalpages.tds.net/~davidc502 … actory.img

(Last edited by davidc502 on 26 Dec 2015, 03:48)

I did have a similar experience.  I had done a 'sysupgrade' w/ keep settings.  I was upgrading from CC 15.05 (w/ a 3.18 kernel), to a DD bleeding edge (w/ a 4.4 kernel).  I believe (but not absolutely certain) it was ultimately due to a pathing change.

Have a look at /etc/config/wireless.
Compare the path names of the wifi-devices
I bet you'll find that the path names for radio2 & radio3 have 'platform' prepended, whereas the others don't.

Anyhow, I was able to get around the whole thing by doing a sysuprade WITHOUT keep settings.  And then configuring from scratch.

(Last edited by wrtpat on 26 Dec 2015, 03:35)

Appears you are correct -- Can I delete radio0 and 1 entries directly? The keep settings box was checked before flashing.

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11g'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
        option country 'US'
        option channel 'auto'
        option txpower '30'
        option htmode 'HT40'

config wifi-iface
        option device 'radio0'
        option mode 'ap'
        option ssid 'TDSFiberOptics'
        option encryption 'psk2+ccmp'
        option key 'omit'
        option network 'lan'
        option disassoc_low_ack '0'
        option skip_inactivity_poll '1'
        option ap_max_inactivity '30'
        option macfilter 'deny'
        list maclist 'd0:df:9a:b7:ca:5e'
        option macaddr '94:10:3e:8c:f4:94'
        option disabled '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11a'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
        option country 'US'
        option distance '10'
        option txpower '30'
        option htmode 'VHT80'
        option channel '161'

config wifi-iface
        option device 'radio1'
        option mode 'ap'
        option ssid 'TDSFiberOptics_5GHz'
        option encryption 'psk2+ccmp'
        option key 'omit'
        option network 'lan'
        option disassoc_low_ack '0'
        option skip_inactivity_poll '1'
        option ap_max_inactivity '30'
        option macaddr '94:10:3e:8c:f4:95'
        option disabled '1'

config wifi-device 'radio2'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
        option htmode 'HT40'
        option txpower '20'
        option country '00'

config wifi-iface
        option device 'radio2'
        option network 'lan'
        option mode 'ap'
        option encryption 'psk2+ccmp'
        option key 'omit'
        option ssid 'TDSFiberOptics'

config wifi-device 'radio3'
        option type 'mac80211'
        option hwmode '11a'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
        option htmode 'VHT80'
        option txpower '20'
        option country '00'
        option channel '48'

config wifi-iface
        option device 'radio3'
        option network 'lan'
        option mode 'ap'
        option ssid 'TDSFiberOptics_5GHz'
        option encryption 'psk2+ccmp'
        option key 'omit'

(Last edited by davidc502 on 26 Dec 2015, 03:56)

Just edit the /etc/config/wireless file....

The option path lines in radio0 and radio 1 should match the radio2/3 and then delete all of radio2/3 sections

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
        option htmode 'HT40'
        option country 'CA'
        option txpower '24'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option macaddr 'xxxxxxxxxxxxxxxxxxxx'
        option ssid 'xxxxxxxxxxxxxxxxxx'
        option encryption 'psk2'
        option key 'xxxxxxxxxxxxxxxx'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
        option country 'CA'
        option hwmode '11a'
        option channel '161'
        option htmode 'VHT80'
        option txpower '26'

config wifi-iface
        option device 'radio1'
        option mode 'ap'
        option network 'lan'
        option encryption 'psk2'
        option key 'xxxxxxxxxxxxxxxxxxxx'
        option ssid 'xxxxxxxxxxxxxxxxxxxxxx'
        option wds '1'

once done.... 

wifi down
wifi

and you should be good to go

Cheers

Thanks! That worked to clean it up.

So far so good on .15 wifi driver.... Time will tell though... I did noticed the highest frequency on 5ghz didn't work, but when moved down to one of the lowest frequencies, it started working normally.

looks as though irqs on cpu0 remain high.

(Last edited by davidc502 on 26 Dec 2015, 04:33)

NP... 

I am pretty happy with 4.4rc5 and .15 but it has crashed a few times....

Due to my nand issues things are far from stable...  basically 50/50 in terms of if it will boot each time

Firmware Version OpenWrt Designated Driver r47961 / LuCI (git-15.343.57108-63155e9) 
Kernel Version 4.4.0-rc5
Local Time Fri Dec 25 22:33:48 2015
Uptime 2d 8h 49m 23s
Load Average 0.00, 0.01, 0.05

tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1:        +38.7°C
temp2:        +38.8°C

armada_thermal-virtual-0
Adapter: Virtual device
temp1:        +50.1°C

Cheers

It's kind of interesting about the boot thing... I've never had issues booting... however with the latest build, I noticed several times where it wouldn't boot(just sits at blinking light), and one time it booted from secondary flash, and had to flash again.

Did this problem start with 4.4rc5?

By the way -- Just ran a NAT test and CPU0 was 100% utilized, and CPU1 sat at 2% the entire time. This was downloading a 10Gig movie from NAS. The best speed I could do was around 650mbps. However, the same movie downloaded from the LAN had no issues hitting 900mbps.

2nd NAt test

Separated Ethernet from Wifi
root@OpenWrt:~# echo 2 > /proc/irq/27/smp_affinity
root@OpenWrt:~# echo 2 > /proc/irq/28/smp_affinity

Ran the same NAT test, and it ran no issues at 900mbps. Processor was pretty evenly distributed between 0 and 1.

(Last edited by davidc502 on 26 Dec 2015, 04:54)

I noticed the problem about 2 weeks ago while still on 4.1.13, so I would guess it was introduced in the last 3 weeks or so.

With the nand patch 4.1.13 is rock stable but 4.4rc5 seems to be better off without the patch.

Stock and everything older like CC and McWRT are good.  My go to build is one of the last 3.18.23 with the .13 driver

If I remember correctly if it fails to boot 3 or 5 times in a row, it switches to the other region.

The only way to tell what is going on is to watch it via TTL.

Cheers

Interesting....  my concern is not so much the speed, but rather the latency that some of us have noted....

It seems to be gone for the most part with the latest .15 but I have seen it jump around

Cheers

Thanks for the nand patch heads-up... I was reading a little about it on this page -
https://forum.openwrt.org/viewtopic.php … &p=366

but appears some where having issues getting the image to compile?

Was there a solution? If so, where is the source located so I can go ahead and re-compile.

@wrtpat: trying to understand the nand-patch discussion. Would i need to add the nand patch for the default 4.1.13 trunk build as well? seeing some contradictory statements here. I would have expected the dev-team to add that patch fairly quickly to trunk if it really was needed as well (and over the days I haven't seen it yet).

I have experienced the router not wanting to boot once, since i'm on 4.1.13 though, which matches the issues as described above

(Last edited by JohnnySL on 26 Dec 2015, 13:55)

https://dev.openwrt.org/ticket/21404 << Submitted by doITright.

EDIT: I have witnessed this with both kernels 4.1.13 and 4.4.  To see the errors you have to either use a serial console or remote logging.

(Last edited by kirkgbr on 26 Dec 2015, 16:06)

I am having problems with kernel 4.4 as well here with my WRT1200AC, I am pretty sure it has to do with how USB storage is handled. When I boot without any USB devices connected, everything boots fine and reboots are prefectly fine as well, but when I attach my external 2TB USB 3.0 drive or a USB stick with lots of data on it, it won't boot correctly after a reset/powerdown most of the time. Disconnect the storage, and it boots fine.

My experience is that there's still approximately 2K interrupts per second (for each of the two wifi interfaces). 

root@OpenWrt:~# grep mwlwifi /proc/interrupts; sleep 1 ; grep mwlwifi /proc/interrupts  
 90:  375337437          0  armada_370_xp_irq  59 Level     mwlwifi
 91:  368033880          0  armada_370_xp_irq  60 Level     mwlwifi
 90:  375339527          0  armada_370_xp_irq  59 Level     mwlwifi
 91:  368035913          0  armada_370_xp_irq  60 Level     mwlwifi

However, sirq CPU utilization is now just under %1 at idle.  This is a massive improvement compared to what I was seeing in the 10.3.0.14 driver (where it was over %40).  The overall instruction path length of the interrupt handler appears to have been reduced dramatically.

root@OpenWrt:~# mpstat -P ALL 10 1
Linux 4.4.0-rc5 (OpenWrt)     12/26/15     _armv7l_    (2 CPU)

08:28:43     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
08:28:53     all    0.05    0.00    0.10    0.00    0.00    0.60    0.00    0.00    0.00   99.25
08:28:53       0    0.10    0.00    0.20    0.00    0.00    1.00    0.00    0.00    0.00   98.70
08:28:53       1    0.00    0.00    0.00    0.00    0.00    0.20    0.00    0.00    0.00   99.80

Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:     all    0.05    0.00    0.10    0.00    0.00    0.60    0.00    0.00    0.00   99.25
Average:       0    0.10    0.00    0.20    0.00    0.00    1.00    0.00    0.00    0.00   98.70
Average:       1    0.00    0.00    0.00    0.00    0.00    0.20    0.00    0.00    0.00   99.80

For posterity

root@OpenWrt:~# uname -a
Linux OpenWrt 4.4.0-rc5 #3 SMP Thu Dec 24 06:51:02 MST 2015 armv7l GNU/Linux

root@OpenWrt:~# strings /lib/modules/4.4.0-rc5/mwlwifi.ko | grep 10.3
10.3.0.15-20151208
/home/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.11_eabi/linux-mvebu/mwlwifi-10.3.0.15-20151215/mac80211.c
/home/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.11_eabi/linux-mvebu/mwlwifi-10.3.0.15-20151215/fwcmd.c
/home/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.11_eabi/linux-mvebu/mwlwifi-10.3.0.15-20151215/tx.c

(Last edited by wrtpat on 26 Dec 2015, 17:11)

I'm sorry, i don't have any direct experience with the 4.1.x kernel, so can't really speak to that.
Based on @doITright's 4.1.x experiences tho, it appears the patch needs to be applied on 4.1.x kernels as well.

I do think it's odd that the nand patch is needed at all.  In my experience, on 3.18.x kernel there's no problem.  As soon as I started running an image based on a 4.4 kernel, I started seeing nand timeouts early in the kernel boot sequence (at which point my router was basically bricked).  Adding in the nand patch (which effectively sets a couple timeout thresholds higher in the pxa3xx driver) immediately resolves the nand timeout issues for me.
I don't quite understand what has ultimately caused this.  But, for now I'm happy to manually add the nand patch until I have time to delve deeper.

As @kirkgbr has indicated, a ticket has already been opened to have the patch incorporated into trunk.

(Last edited by wrtpat on 26 Dec 2015, 16:54)

Yes, I'm experiencing the same issue on 4.1.13.  You said "manually add the nand patch"...

Where is it, and what do I need to do to manually add it to a new build?

Best Regards,

There is a version of the patch here -> LINKY based on a 4.3 kernel.
After downloading, drop the file in [build_root]/target/linux/mvebu/patches-4.1

Note: You may need to make minor adjustments for a 4.1.x kernel.

EDIT: See doITright's dropbox link in the post below

(Last edited by wrtpat on 26 Dec 2015, 17:36)

My issues with the patch were copy/paste related...  illegal/extra characters were killing me

Once you have the file(s), drop into the corresponding patch directory:

/openwrt/target/linux/mvebu/patches-4.1 or patches-4.4

You can grab the patch files from here (they are kernel level specific):

https://www.dropbox.com/sh/ff57qijgv9w3 … iGnOa?dl=0

Cheers