[Solved] WRT3200ACM - Unable to flash LEDE successfully

@gvalkov
When the width of the band 80 MHz, it is necessary to use the following channels:

Channel = 36 (5180 MHz + 80 MHz), i.e. channels are used directly-[36, 40, 44 48], Vvht_oper_centr_freq_seg0_idx = 42;
Channel = 52 (5240 MHz + 80 MHz),--[52, 56, 60, 64], vht_oper_centr_freq_seg0_idx = 58;
Channel = 100 (5500 MHz + 80 MHz),--[100, 104, 108, 112], vht_oper_centr_freq_seg0_idx = 106;
Channel = 116 (5580 MHz + 80), [116,,,], vht_oper_= 122;
And so on through the channels.

Check your settings - https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
https://github.com/kaloz/mwlwifi/tree/master/test

Thank you for your kind help, @Valcher !
I have tried all possible channels and band widths. Sadly the support for DFS in OpenWRT is broken. At least for WRT3200ACM. As long as the driver thinks that a channel requires DFS it will not work.

Workaround: I just compiled a DFS free firmware.
I am finally able to use channel 100 which is allowed in Bulgaria. The signal is much stronger compared to channel 44 and the connection works better. Even the VHT160 works now. The linksys frmware did not work in 160 MHz mode.

Cheers!

As much as it may be “allowed” in Bulgaria, I’m certain that would still be under the caveat that if you detect a radar signal you vacate channel immediately.
So this isn’t the right solution, and you should be wary of the consequence of your actions.

I can run DFS channels on my WRT3200ACM no trouble on Openwrt.

@lantis1008
If your router does support DFS with the latest builds of OpenWRT, then I would assume the hardware differs. Was it manufactured before December 2017? Which country did you set?

I have spent many days testing all channels, countries and other settings, switching between different driver revisions and OpenWRT sources. Running without antennas, to make it harder for the device to detect radars if they exist. Nothing helps. Last night I called a friend who has long years of experience manufacturing RC air planes. He said that no radars here are operating on the 5 GHz bad, so there should be no issues with that. And since with the linksys firmware, the device can operate on DFS channels 52-140, I assume that support in OpenWRT drivers for DFS is incomplete for WRT3200ACM devices manufactured past December 2017. It would be interesting if anyone else has similar issues. Yet most people will simply leave it on auto or channel 36 and won't even notice.

I understand it is better to be compatible with the regulations. It is indeed a bad and dirty solution, but that is all I have until someone with more experience provides a solution.

Good luck!

@lantis1008
Can you please provide me with the output of the following commands:

iw reg get
iw phy0 info |grep MHz

There is something odd with iw reg get for me because the indicated countries are:

  • global: 98, phy#2: US, phy#1: FR, phy#0: FR.

I'm not sure why it decided to use values inconsistent with one another. I purchased my device through the official distributor and it is manufactured for the EU region (Europe).

I remember a few years ago when I first installed OpenWRT on my previous router, I could not use channel 13, because someone decided to apply hard-codded US restriction on top of the Bulgarian that I had selected. The way restrictions are applied in the code is very dirty and more restrictive than they should be. It was trying to get region from EPROM, user config, and hard coded and allowed the minimum.

It wouldn’t be of use to you, because I loaded it with a custom firmware with region checking disabled so I could use it in the AU region.

Your device is locked to use the Region defined in hardware for your device. As are ALL WRT3200ACM’s. Have you read the following?

Note for DFS of WRT3200ACM (88W8964):

All WRT3200ACM devices are programmed with device power table. Mwlwifi driver will base on region code to set country code for your device and it will not allow you to change country code. There are another wifi (phy2) on WRT3200ACM which is not mwlwifi. It will allow you to change country code. Under this case, country code setting will be conflicted and it will let DFS can't work.

There are two ways to resolve this problem:

a. Please don't change country code and let mwlwifi set it for you.

b. Remove phy2. Under this case, even though you change country code, mwlwifi will reject it. Because phy2 is not existed, country code setting won't be conflicted.

@lantis1008

Very good point! I searched the description you provided and found this thread, where the issue is described in details:

The following two conditions must be met to enable support for the DFS channels in OpenWRT for WRT3200ACM:

  1. @Valcher was right that the driver for phy#2 has to be uninstalled. It conflicts, because it is set to US region, while phy#1 and phy#0 are set to FR. It should be noted that simply setting all radios to FR does not help, unless the driver is uninstalled:

opkg remove kmod-mwifiex-sdio
opkg remove mwifiex-sdio-firmware

  1. The country for all radios must be set to FR. If the country setting is removed, the radio will not work on DFS channels.

Note: after boot, the radio will be disabled. It will be re-enabled after exactly 90 seconds. Then everything just works.

It is very unfortunate that regulations require such extreme measurements to be taken in order to make OpenWRT FCC compliant. Because of this reason, this broken behaviour will probably not be resolved. Yet this makes it impossible for most people to use what they are allowed to. Consider all of the effort that we made to get this far. This is not right! It should be simple to use our devices within regulations!

On top of that manufacturers hard-code incorrect regions, because it is cheaper to have it changed for every country. So it is not even possible to use the devices according to our local regulations. In Bulgaria we are allowed more channels and higher TX power for certain channels, compared to France. I'm feeling offended by this design preventing me to use that!

Once again, thank you very much to everyone here, who spend you precious time to help me install OpenWRT on my new device, and resolve the most important issues!

I wish you all the best! I will try to monitor and participate in this thread if anything new comes out, or if I need to help test something.

Open issues from post 111:

  1. The MAC addresses for eth0 and eth1 should be swapped: workaround is provided, this should be integrated in the sources.
  2. File copy over SCP from router to computer is limited to exactly 499 974 144 bytes - fix needed.

@hnyman
Linksys have provided the GPL sources of the 1.0.6.186168 firmware for WRT3200ACM:

https://www.linksys.com/us/support-article?articleNum=114663

As a summary - sounds like the GPL sources have been posted, so it might give us a fighting chance to flash the current stable build, once the dev folks have had a chance to go through it? I'm wanting to purchase the WRT3200ACM... but I can wait for see how this unfolds. Don't really care about DFS atm ...

Sorry, but I do not get it... I have been using LEDE in a WRT3200ACM since the first 17.01 release, and the mwlwifi drivers (the only piece of hardware specific to this device) have been available for ages. What are you exactly expecting to happen from those sources?

The solution by Linksys for supporting the Winbond flash chip in newer WRT3200ACM (that do require the quite newest Linksys firmware). Their GPL sources of their own firmwares show the modifcations that they have done. (They used to have only the old firmware's sources available, and that version did not yet support Winbond chips.)

However, Kaloz posted the probable solution in his staging repo in the meanwhile, so that is probably the needed part for Winbond. Hopefully that gets merged to the main Openwrt source soon.

Which change exactly in their GPL?
I had a look and found nothing that stood out, and that was with the prior knowledge of Kaloz’s solution so I knew somewhat what I was looking for

Things like this...

I downloaded the GPL source myself, and briefly looked into it.
Their own solution for the Winbond support:

src/linux/patches/linux-3.10.70_080_2ndNandSource.patch

--- linux-3.10.70_WNC/drivers/mtd/nand/mvebu_nfc/hal/mvNfc.c	2016-01-11 17:31:05.000000000 +0800
+++ 20160111/drivers/mtd/nand/mvebu_nfc/hal/mvNfc.c	2017-05-26 13:59:50.000000000 +0800
@@ -320,6 +320,52 @@
 	.bb_page = 0,		/* Manufacturer Bad block marking page in block */
 	 .flags = NFC_CLOCK_UPSCALE_200M
 	},
+	{			/* WNC_Gary Winbond 2Gb */
+	.tADL = 70,		/* tADL, Address to write data delay */
+	.tCH = 5,		/* tCH, Enable signal hold time */
+	.tCS = 15,		/* tCS, Enable signal setup time */
+	.tWC = 25,		/* tWC, ND_nWE cycle duration */
+	.tWH = 10,		/* tWH, ND_nWE high duration */
+	.tWP = 12,		/* tWP, ND_nWE pulse time */
+	.tRC = 25,		/* tWC, ND_nRE cycle duration */
+	.tRH = 15,		/* tRH, ND_nRE high duration */
+	.tRP = 12,		/* tRP, ND_nRE pulse width */
+	.tR = 25000,		/* tR = data transfer from cell to register, maximum 60,000ns */
+	.tWHR = 60,		/* tWHR, ND_nWE high to ND_nRE low delay for status read */
+	.tAR = 10,		/* tAR, ND_ALE low to ND_nRE low delay */
+	.tRHW = 100,		/* tRHW, ND_nRE high to ND_nWE low delay 32 clocks */
+	.pgPrBlk = 64,		/* Pages per block - detected */
+	.pgSz = 2048,		/* Page size */
+	.oobSz = 64 ,		/* Spare size */
+	.blkNum = 2048,		/* Number of blocks/sectors in the flash */
+	.id =0xDAEF,		/* Device ID 0xDevice,Vendor */ 
+	.model = "Winbond  2Gb 8bit",
+	.bb_page = 0,		/* Manufacturer Bad block marking page in block */
+	 .flags = NFC_CLOCK_UPSCALE_200M
+	},	
+	{			/* WNC_Gary MXIC 2Gb 20150518*/
+	.tADL = 70,		/* tADL, Address to write data delay */
+	.tCH = 5,		/* tCH, Enable signal hold time */
+	.tCS = 15,		/* tCS, Enable signal setup time */
+	.tWC = 20,		/* tWC, ND_nWE cycle duration */
+	.tWH = 7,		/* tWH, ND_nWE high duration */
+	.tWP = 10,		/* tWP, ND_nWE pulse time */
+	.tRC = 20,		/* tWC, ND_nRE cycle duration */
+	.tRH = 60,		/* tRH, ND_nRE high duration */
+	.tRP = 10,		/* tRP, ND_nRE pulse width */
+	.tR = 25000,		/* tR = data transfer from cell to register, maximum 60,000ns */
+	.tWHR = 60,		/* tWHR, ND_nWE high to ND_nRE low delay for status read */
+	.tAR = 10,		/* tAR, ND_ALE low to ND_nRE low delay */
+	.tRHW = 60,		/* tRHW, ND_nRE high to ND_nWE low delay 32 clocks */
+	.pgPrBlk = 64,		/* Pages per block - detected */
+	.pgSz = 2048,		/* Page size */
+	.oobSz = 64 ,		/* Spare size */
+	.blkNum = 2048,		/* Number of blocks/sectors in the flash */
+	.id =0xDAC2,		/* Device ID 0xDevice,Vendor */ 
+	.model = "MXIC  2Gb 8bit",
+	.bb_page = 0,		/* Manufacturer Bad block marking page in block */
+	 .flags = NFC_CLOCK_UPSCALE_200M
+	},	
 	{			/* Micron 4Gb */
 	.tADL = 70,		/* tADL, Address to write data delay */
 	.tCH = 5,		/* tCH, Enable signal hold time */

(I didn't compare yet all all sources to the previous version, but just looked at the core patch directory src/linux/patches/ where most of the interesting stuff is.)

The solution proposed by Kaloz seems much shorter, as it onyl sets a few key parameters. This seems like a full chip database entry.

Looks like they have added the patch src/linux/patches/linux-3.10.70_080_2ndNandSource.patch supporting two new flash chips and have upgraded dnsmasq from 2.55 to 2.78, but otherwise their firmware v1.0.6.186168 looks pretty similar as the previous v1.0.6.181063

I must have downloaded an old or incorrect source. I don’t have that patch. Will check again later. Thanks!

https://cdn.corifeus.com/openwrt/SNAPSHOT/targets/mvebu/generic/

1 Like

I actually registered just to follow this thread. I just purchased a WRT3200 about 3 weeks ago and I am glad i found this forum as i was about to try LEDE tonight. So its my understanding that as of right now, LEDE is not fully functioning on the new 3200's correct?

This post above...

...indicates that Linksys made the GPL sources available a little over 2 weeks ago.

So, my understanding is that the developers would need to start with that, in order to create supported firmware.

Fair enough. Thank you for the quick response. i will keep a watch for updates.

Have not yet seen any negative accounts regarding patch not addressing new flash units on rango devices.