OpenWrt Forum Archive

Topic: openwrt on linksys WRT3200ACM

The content of this topic has been archived between 29 Mar 2018 and 24 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

@Chadster766

Pull request submitted.

nitroshift

@max2344

I am also running r2544-a032940 on my wrt3200acm.  When I run swconfig list, I also get nothing.  Three links below (I cant post clickable links, sry).  First is an article that gives a list of hardware supported by the swconfig command, and our Marvell 88E6352 switch is not on the list.  Second is a section on the same page that discusses DSA, but not how to use it.  Third is an article about Marvell which briefly mentions DSA with a broken link. 

If you figure out what we should be using instead of swconfig, please let me know.  Hows everything else running for you?  I am having helacious issues with vLans and the dhcp-relay option in dnsmasq.

wiki.openwrt.org/doc/techref/swconfig
wiki.openwrt.org/doc/techref/swconfig#distributed_switch_architecture_vs_swconfig
wiki.openwrt.org/doc/hardware/soc/soc.marvell

(Last edited by numbers on 20 Dec 2016, 09:23)

@numbers

yeah I see; I am currently investigating the issue. My understanding so far is that the current kmod-switch-mvsw61xx doesn't support 88E6352 as used on the WRT3200ACM. There is DSA support which is kinda rudimentary. As far as I understand the kernel docs we won't be able to use VLAN tagging even if we build it for the current OpenWRT/LEDE release. We will get all 5 interfaces separately untagged like lan1, lan2...5. As far as I looked in the docs/source the fancy stuff including 802.1q tagging etc isn't supported (I think by the framework). It could be faster path to integrate with swconfig infrastructure than waiting for LK to gain the needed features in DSA. I haven't look at the Linksys/Cisco sources yet and I am yet to find a reasonable datasheet for the 88E6352. As far as I understand it will need to be written separately from mvsw61xx cause they use a different MII interface on the 6352.

As far as I understand the current switch configuration the ports of the 3200ACM are configured in the same way as left before the upgrade to OpenWRT/LEDE. That means in the normal case eth0 is connected with the WAN port and eth1 as plain ethernet switch on rear ports LAN1-4. As far as I can understand the tagged frames are dropped. This is at least the current running configuration. Wireless works good for me, no flaws though atm N-only with WPA2-EAP-TLS. Quagga ospf6d isn't starting properly. Except these I haven't experience other issues.

Sorry can't help with dhcp-relay, we're banned its use wherever possible XD Though I guess about wild issues cause the frames are partly broadcast and then unicast... if you send them tagged though... parts of the dhcp traffic may arrive or may not, I guess thats what you're seeing.

Regards,
-max2344

@Chadster766

Can you try the changes in the dts and see if the LED's issue is solved? I don't have a Rango yet. Thanks.

nitroshift

@nitrosift

Will do.

Is the dts you mention in the LEDE repo?

@Chadster766

No. It's just a pull request in OpenWRT tree at the moment.

nitroshift

Ok thanks smile

nitroshift wrote:

@Chadster766

Can you try the changes in the dts and see if the LED's issue is solved? I don't have a Rango yet. Thanks.

nitroshift

The power led works properly but not the wireless leds.

Below is a diff of the McDebian boot after the led dts change.

--- C:/Users/chad/Desktop/led-change2.txt    Fri Dec 23 02:45:46 2016
+++ C:/Users/chad/Desktop/led-change.txt    Fri Dec 23 02:45:21 2016
@@ -2,12 +2,18 @@
  sdhci-pltfm: SDHCI platform and OF driver helper
  NET: Registered protocol family 17
  ThumbEE CPU extension supported.
- ata2: SATA link down (SStatus 0 SControl 300)
  ata1: SATA link down (SStatus 0 SControl 300)
+ ata2: SATA link down (SStatus 0 SControl 300)
  Registering SWP/SWPB emulation handler
  xhci-hcd f10f8000.usb3: xHCI Host Controller
  xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 2
  xhci-hcd f10f8000.usb3: hcc params 0x0a000990 hci version 0x100 quirks 0x00010010
+ random: fast init done
+ mmc0: new high speed SDIO card at address 0001
+ mwifiex: rx work enabled, cpus 2
+ mwifiex_sdio mmc0:0001:1: Direct firmware load for mrvl/sd8887_uapsta.bin failed with error -2
+ mwifiex_sdio mmc0:0001:1: Falling back to user helper
+ Bluetooth: vendor=0x2df, device=0x9136, class=255, fn=2
  xhci-hcd f10f8000.usb3: irq 44, io mem 0xf10f8000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 1 port detected
@@ -26,8 +32,12 @@
  sd 2:0:0:0: [sda] Write Protect is off
  sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
   sda: sda1
- random: fast init done
  sd 2:0:0:0: [sda] Attached SCSI removable disk
+ mwifiex_sdio mmc0:0001:1: Failed to get firmware mrvl/sd8887_uapsta.bin
+ mwifiex_sdio mmc0:0001:1: info: mwifiex_fw_dpc: unregister device
+ Bluetooth: request_firmware(firmware) failed, error code = -2
+ Bluetooth: Failed to download firmware!
+ Bluetooth: Downloading firmware failed!
  EXT4-fs (sda1): couldn't mount as ext3 due to feature incompatibilities
  EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
  VFS: Mounted root (ext4 filesystem) on device 8:1.

Interesting that the Bluetooth chip activated (which is cool) and the mwifiex_sdio driver.

After boot nandwrite would no longer work.

MCDEBIAN login: [  386.725083] pxa3xx-nand f10d0000.flash: Wait time out!!!
[  386.945078] pxa3xx-nand f10d0000.flash: Ready time out!!!
root@MCDEBIAN:/# nandwrite -p /dev/mtd7 McDebian-WRT3200ACM-V1-FW_VER1_kernel_4_8_15.img
Writing data to block 0 at offset 0x0
libmtd: error!: cannot write 2048 bytes to mtd7 (eraseblock 0, offset 0)
        error 5 (Input/output error)
Erasing failed write from 00000000 to 0x01ffff
Writing data to block 1 at offset 0x20000
libmtd: error!: cannot write 2048 bytes to mtd7 (eraseblock 1, offset 0)
        error 5 (Input/output error)
Erasing failed write from 0x020000 to 0x03ffff
Writing data to block 2 at offset 0x40000
libmtd: error!: cannot write 2048 bytes to mtd7 (eraseblock 2, offset 0)
        error 5 (Input/output error)
nitroshift wrote:

@Chadster766

Thanks for the info. Will do more work on it when I get a device myself (that's if Linksys keep their promises, see https://forum.openwrt.org/viewtopic.php?id=68624 ).

nitroshift

Your change "gpios = <&gpio1 24 GPIO_ACTIVE_HIGH>; " is good but under the dts gpio_keys button@1 section needs to be commented out because it also uses the same gpio pin 24.

The current dts value for the sata led is good changing it to 22 causes it to fail.

Now with power led working all that's left is the wireless 2.4 and 5Ghz leds.

@Chadster766

They're different gpio's: 0 and 1.

nitroshift

@nitroshift

What does the 24 represent in that gpio line?

@Chadster766

Power LED fix has been upstreamed. WiFi leds require more work as even the official firmware uses a modified driver for them.

nitroshift

Thanks for the update.

WiFi leds patch prepared, waiting for a device to test it.

nitroshift

@nitroshift I could test it for you in the meantime.

@Chadster766, In case you're still trying to sort this.

@Villeneuve thank so much for providing the dts fix link smile

Any news about the Wifi Issue on the mac80211 driver for the wrt3200acm?
The wireless working only for 2 hours then no connection to the lan or wan possible. Router restart is needed that it work again for only 2 hours....

Might want to give this image a shot: http://lantisproject.com/gargoyle_ispyi … 017/mvebu/

it is based on Openwrt and has the latest drivers.

initial password is "password ", you will be prompted to change it.

(Last edited by mojolacerator on 24 Jan 2017, 15:52)

Just received a WRT3200ACM, and the devices regulatory region is hardcoded to US (0x10). Everything I've tried to get it to AU (0x81) hasn't worked.

Does anyone have any clever ideas?

My current thoughts are to compile a modified regdb which makes US the same as AU.
But I'm thinking the power table itself may also be hardcoded.

@Lantis

You are correct: powertables are indeed hardcoded.

nitroshift

So an 'illegal' gift from Linksys USA? sad
Since the powertables etc. are hardcoded, you have to use the FCC regulatory info.

(Last edited by adri on 30 Jan 2017, 13:39)

@adri

Powertables were hardcoded to comply with FCC regulations.

nitroshift

@Chadster

Have your modification of the cable routing yielded any negative interference?