[Solved] WRT3200ACM - Unable to flash LEDE successfully

Big request.

Please, who has the modification of WRT3200ACM with NAND chip Winbond, please make a copy of the boot partition and put the public resource. A copy is needed to restore the router.
You can make a copy with a command from openwrt/lede-
dd if=/dev/mtd0 of=/tmp/mtd0.bin

Thats the problem. AFAIK there is no working OpenWRT/LEDE image available at the moment.

@Valcher
See here: https://github.com/ValCher1961/McDebian_WRT3200ACM/issues/1#issuecomment-359667138

I've not personally tested it yet but I'll have a go once I come back from work tonight.

Edit: Just tested it's just the same 0.0.4 bootlaoder it wont work either. :confused:

It may be faster for someone to simply compile the u-boot spi and uart bins with support for the newer Winbond flash. Uboot will have instructions on how to do so either in their repo README. or in their site docs

  • Needed commands will likely be similar to:
    • export CROSS_COMPILE=<insert-gcc-toolchain>
    • make armada_38x_<insert_boardname>_config
    • make u-boot-a38x-spi-uart.bin
      and possibly
    • make u-boot-a38x-spi.bin
  • Once those are generated, one can simply follow the instructions laid out in Corrupt Bootloader Recovery

I see no one has opened an issue on nitroshift's GitHub, which I would encourage doing since he was the one who worked directly with Stefan Roese of uboot.

  • He also recommended joining #u-boot on freenode servers as a place to also garnish information on what needs to be done

@JW0914

Edit: My post above is just the same image which is available elsewhere. Just tested it and it's version 0.0.4 we need 1.0.0 boot loader. I've also opened an issue with nitroshift now but I don't know if he is still active or not.

Can you try this one mtd0.bin

If @gameno's upload doesn't help, I would encourage someone contacting U-Boot directly via IRC (#u-boot @ irc.freenode.net). Compiling U-Boot is super simple, but you need the mvebu arch files and boardname specific for the WRT3200ACM.

  • I highly doubt those files are proprietary to Linksys since Stefan Roese worked with nitroshift for the XP & 385 boards. U-Boot may also simply provide compiled uart and spi bins, versus providing source files to compile against... either way, once reached out to, one should get a fairly fast response.

@gameno, Thank you, let's hope this will help someone else.

@Valcher Thanks for hosting the WRT3200ACM and WRT32X mtd0 bins, and I've added the info to the WRT AC Series Corrupt Environment Recovery section.

  • I plan to have all WRT AC Series mtd0 bins hosted on GitHub and linked to under that section.

Something just occurred to me, as I didn't fully read your ReadMe the first time around:

  • Can dd [if loading a initramfs, or is it impossible to boot a device with a corrupted mtd0 partition altogether] or mmc write be utilized to write the bin, or must nandwrite be utilized?

Sorry, not very clear question.

Yeah I didn't articulate that very well did I

  • On a device with this issue, is it possible to boot it from an initramfs image (i.e. to have access to dd)?

  • If utilizing kwboot to access U-Boot, can mmc commands be utilized in lieu of nand commands, or must nand be utilized?

About the first question, yes, I guess can use the DD command.
On the second question, I did not investigate the capabilities of the MMC command. I only used NAND commands, but I think it's possible to use any command from Uboot.

Hi Guys, count me in on the issue. My router only boots to Linksys firmware successfully.
Same as @Ritty, I tried multiple third party images with no luck.

I was verifying sha256sums before flashing and was using cable connection with the router.
I have also read all the resources linked in this thread. I did not try using serial connection with the router.

What I tried:
lede-17.01.4-mvebu-linksys-wrt3200acm-squashfs-factory.img
lede-mvebu-linksys-wrt3200acm-squashfs-factory.img (davidc502)
openwrt-mvebu-linksys-wrt3200acm-squashfs-factory.img
factory-to-ddwrt.bin (multiple revisions including r34876 released yesterday)
FW_WRT3200ACM_1.0.6.184351_prod.img
FW_WRT3200ACM_1.0.6.186168_prod.img

Flashing third party firmware results in unit restarting, power led blinking multiple times to stall after few seconds (dd-wrt images will also make eSATA led to turn on) to eventually return to previous partition after three failed attempts to boot.

Linksys images flash and boot as expected, flashed from newer to older and vice versa, verifying that the partition I'm on changed after flashing on http://192.168.1.1/sysinfo.cgi
Version of linksys firmware or partition I'm flashing from doesn't make any difference in results of the flash.

Router info:

modelNumber = WRT3200ACM-EU
hw_version = 48SAM203.0GA
manufacturer_date = 2017/12/05
1 Like

As I've mentioned numerous times in this thread, how exactly do you believe you can troubleshoot without connecting via serial? There's a reason the recommendation to buy a USB-TTL cable is the second bullet in the WRT AC Series wiki's Introduction...

  • Until you do this, there is no way to help you

I do understand and I know that you mentioned this numerous times. I did read this topic before commenting. I really did. In fact, I even knew this is the answer I will get from you. Still, choose to comment as a report for you guys, to let you know about possibly another case of the same issue with the newer version of the router. Not really looking for help as I think I know what I need on this stage. Would you be able to just confirm one thing for me, as I didn't find a conclusion here or information on what stage is @MacKlappstuhl issue currently on, which I would find more helpful than a reminder that I should have used serial cable. Is the last thing he said in this thread:

AFAIK there is no working OpenWRT/LEDE image available at the moment.

is the current state of things?

Also, I do understand where you're coming from with this TTL cable and want to let you know that I do have a lot of appreciation for people like you who spend their own time to work on open source projects and as an effect make our lives better, but please understand more basic users too.

Not every one can/is capable of becoming a beta tester. Not everyone wants/can/is comfortable with opening a €200 device, even if this doesn't mean immediate warranty void. I'm a user familiar with dd-wrt from 10 years ago. I remember hassle free installation of said firmware on wrt54gl/s which wasn't officially marketed as an open source friendly device. I never needed serial cable to troubleshoot anything there, it just worked.
After buying a device that says on the box "Customize your router with OpenWRT or DD-WRT right out of the box" people can expect it to work right out of the box, but what you say is that I should have serial cable instead. As I said, I know where you're coming from, but I do not agree. While I do understand that's how you get hardware diagnosed and problems solved, I do not feel like this is how "out of the box" solutions should work. There's no mention about TTL cable neither on the box, nor on the short instruction attached to the router and the only reason I bought the thing is to run custom firmware on it.

Now, having said the above. I commented here to let you know about another instance of the problem and possibly provide a bit of help I can. So please let me know if I can give you any more info that might be helpful. I could attach a dump of http://192.168.1.1/sysinfo.cgi or some other info before I put the router back to it's box and return it since it doesn't currently do what I bought it for...

1 Like

You do not need a serial cable to find the answer to the cause of the problem; a search of the forum should yield that for you. And no, the fix is not in, yet.

That's what I managed to figure out and the exact confirmation I wanted. Thank you.

Serial access does not make one a beta tester... perhaps you believe SSH is for beta testers as well?

You have to remove a whopping two screws, with the directions clearly laid out in the WRT AC Series wiki under Serial Header.

  • It doesn't void the warranty (see the warranty T&C, which clearly you haven't)
    • I'm a bit exasperated at this point of users claiming, or believing, a WRT AC Series device's warranty is voided by opening the case, as Linksys intended the user to access the serial header, and is why they moved the header to make it more convenient for users after the release of the WRT1900AC v1.
      • Please, do everyone a favor and take the time to actually read the warranty terms and conditions before providing a supposition that the warranty is/could be voided by accessing the serial header.

      • Additionally, no user, and especially not the OpenWrt/LEDE maintainers, would allow instructions on a ToH [Table of Hardware] wiki page that voided a user's warranty (due to simple common decency, but also for legal reasons).

In order to troubleshoot a SBC (which is what most routers are), you only have two options to gain access to the firmware when SSH and WebUI access is inaccessible, either IPMI [which consumer routers will never have] or serial (via USB-TTL, USB-to-UART, an SBC like an Arduino, a breakout board such as a MAX232, etc.)

A USB-TTL cable enables one to access the firmware (as well as bootloader) when (1) ssh is not working, and (2) WebUI is inaccessible.

  • Trying to troubleshoot any issue without access to the above and no way to connect via serial, in order to view the boot and system logs, is a waste of everyone's time, but most of all, your own... without that information, (1) you have no clue what the actual issue is, (2) you'll be fielding guesses for days.

There's a reason specific things are recommended in the WRT AC Series' ToH wiki page... when a user refuses to follow an important recommendation, such as investing in a USB-TTL cable, it's only going to make the user's life far more difficult, potentially with more than a week of down time when an issue occurs since most electronic stores do not carry USB-TTL cables or USB-to-UART boards in stock (if they carry them at all).

1 Like

My new WRT3200ACM was manufactured on 2017/12/26. I have compiled OpenWRT 4.9.77 from source code – not working. The official images do not work either. I see comments that in the new kernel 4.14, there should be support for the new flash chip.

  • How do I compile OpenWRT with the new kernel or how do I integrate the required patches to compile and test?
  • Can I compile a RAM image, then upload and boot it? How? If yes, then I will be able to extract the u-boot that @GaZaai needs.
  • If anyone has ideas to test, we can experiment on my device. Serial logs will be provided as a feedback.

With the image I compiled, OpenWRT flashes successfully, then it fails to boot three times in a row and I'm back to factory. I have attached to the UART header, here are some logs:

2018-02-06 WRT3200ACM OpenWRT 4.9.77 flash and boot
https://pastebin.com/p7xg22RA

2018-02-06 WRT3200ACM sysinfo.cgi
https://pastebin.com/AaGUezSN

BTW when I open the case, the front part slides easily so attaching to the UART was easy, but I can't disassemble the back of the case. I bought this device for software development and I might want to solder a jTAG header one day. How do I open that?

The OP of this thread tried a 4.14 image (4.14.11??) some time back to no avail. I have not seen anything come in at kernel.org since to indicate that the fix is in. The 4.14.x patches are now in master so compiling an image is not an issue.