Did you try to flash the Linksys firmware from the ddwrt ui? that does it for me. Has worked on my 1900acv2 multiple times. For me, it looks like the Linksys software is flashing normally(from the ddwrt screen), then quickly, the connection is interrupted. Then it boots into Linksys. Very wierd.
BTW- I am running LEDE on my 3200acm, 1900acv1 and v2
Just tried installing linksys stock firmware file from within DD-WRT, it flashed quicker than a dd-wrt image as you mention, but it came right back up to the same DDWRT install again. Is this a problem with the NVRAM or something which doesn't seem to take the boot_part parameter and I just got lucky one time to go from stock->ddwrt?
do you perhaps have ddwrt on both partitions? If you flashed the initial file, then the second one, you have ddwrt on both 1 and 2.
I was checking with ubootenv get boot_part after each reboot, and it's staying static at "1". It's simply never switching to "2".
In addition, I renamed the DD-WRT install through the webpage so that I'd be able to identify it on reboot, it's coming up with the same name. Unless that data is shared across partitions, I don't think it would identify the wrong install. The only time it gets wiped is when I say "delete settings when flashing firmware", in that case, it nukes everything, the name and also the password, so on next reboot, I have to set a new password as well as re-enable SSH again.
It's almost like it's flashing over and over into the same partition because the switching between partitions is buggy/broken somehow. I know I got it to work at least once which is what enabled my ddwrt install over stock in the first place, so am wondering if there is a way to get more debug info about how that worked.
Is bootcmd changing on a new flash:
run nandboot
run altnandboot
or if you have serial access can you explicitly execute those.
I will check when I get a chance. Is it ok to run this command over SSH? I don't have a serial cable set up yet, so am relying on wired ethernet to run console commands.
Yes over ssh is fine.
Haven't had a chance to try it yet since my router is at home and I'm at work. I am wondering now if the flashing is failing with an error for some reason, and the "fw_setenv auto_recovery yes" ("auto_recovery=yes" from "ubootenv list" in my ddwrt case) is causing my ddwrt install to not boot from the other partition. Are there logs generated somewhere when auto_recovery is triggered?
That environment variable tells uboot to switch partitions on three failed attempts; i.e. support of the power cycle to other partition. So yes supports that feature, setting to no means that it will stick to only one partition, whichever is currently set in the other environment variables.
Oh ok, then I probably want the auto_recovery on then.
Is there a place that will log if my flashing through the ddwrt webUI fails? Doing all of these blind reboots makes me nervous. If I happen to get back to the linksys FW with the same luck that happened to allow ddwrt flash to work (while LEDE builds were failing), I might get stuck again without a way to debug (no SSH access on linksys vs SSH on ddwrt).
It always says "bootcmd=run nandboot" when I run ubootenv list after setting the boot_part to 2 and rebooting. Does that mean it's not rebooting to the right partition?
Will try applying the image using SSH and report back on if I bricked it or not:
https://wiki.openwrt.org/toh/linksys/wrt_ac_series#tab__flash
Flash image
SSH Terminal:
cd /tmp ; sysupgrade -n -v image-name
-n = do not save configuration over reflash
-v = more verbose
Ok, so on ddwrt, there is no "sysupgrade" binary. I tried again using the ddwrt gui, and it did the same thing, rebooting back into boot_part 1. I noticed something strange about bad nandblocks in dmesg in dd-wrt:
[ 1.025467] Bad block table found at page 65472, version 0x01
[ 1.031475] Bad block table found at page 65408, version 0x01
[ 1.037361] nand_read_bbt: bad block at 0x000000fa0000
Is this significant, and is it possible to work around this? I don't mind flashing over my current ddwrt image and not using boot_part 2 at all, that's no problem to me as long as I have at least 1 working partition on LEDE for cake/piece of cake.qos.
Also does that mean something is wrong in the hardware itself? This is a refurb unit that I got directly from Linksys on eBay, so it's possible they're dumping bad inventory on the market with stock firmware. Ugh, and the return procedure has me paying return shipping, what a scam. Can I complain to eBay and have them make Linksys pay for the return shipping label?
full dmesg output below:
[ 0.174445] mvebu-pcie soc:pcie-controller: PCI host bridge to bus 0000:00
[ 0.174453] pci_bus 0000:00: root bus resource [io 0x1000-0xfffff]
[ 0.174458] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
[ 0.174463] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.174477] pci 0000:00:01.0: [11ab:6820] type 01 class 0x060400
[ 0.174562] pci 0000:00:02.0: [11ab:6820] type 01 class 0x060400
[ 0.174642] PCI: bus0: Fast back to back transfers disabled
[ 0.174648] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 0.174655] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 0.174714] pci 0000:01:00.0: [11ab:2a55] type 00 class 0x020000
[ 0.174736] pci 0000:01:00.0: reg 0x10: [mem 0x40000000-0x400fffff 64bit pref]
[ 0.174751] pci 0000:01:00.0: reg 0x18: [mem 0x40100000-0x401fffff 64bit pref]
[ 0.174818] pci 0000:01:00.0: supports D1 D2
[ 0.174823] pci 0000:01:00.0: PME# supported from D0 D1 D3hot D3cold
[ 0.174906] PCI: bus1: Fast back to back transfers disabled
[ 0.174913] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 0.174975] pci 0000:02:00.0: [11ab:2a55] type 00 class 0x020000
[ 0.175002] pci 0000:02:00.0: reg 0x10: [mem 0x42000000-0x420fffff 64bit pref]
[ 0.175020] pci 0000:02:00.0: reg 0x18: [mem 0x42100000-0x421fffff 64bit pref]
[ 0.175112] pci 0000:02:00.0: supports D1 D2
[ 0.175117] pci 0000:02:00.0: PME# supported from D0 D1 D3hot D3cold
[ 0.175204] PCI: bus2: Fast back to back transfers disabled
[ 0.175210] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
[ 0.175254] pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xe01fffff]
[ 0.175259] pci 0000:00:02.0: BAR 8: assigned [mem 0xe0200000-0xe03fffff]
[ 0.175266] pci 0000:01:00.0: BAR 0: assigned [mem 0xe0000000-0xe00fffff 64bit pref]
[ 0.175278] pci 0000:01:00.0: BAR 2: assigned [mem 0xe0100000-0xe01fffff 64bit pref]
[ 0.175289] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 0.175295] pci 0000:00:01.0: bridge window [mem 0xe0000000-0xe01fffff]
[ 0.175302] pci 0000:02:00.0: BAR 0: assigned [mem 0xe0200000-0xe02fffff 64bit pref]
[ 0.175317] pci 0000:02:00.0: BAR 2: assigned [mem 0xe0300000-0xe03fffff 64bit pref]
[ 0.175330] pci 0000:00:02.0: PCI bridge to [bus 02]
[ 0.175335] pci 0000:00:02.0: bridge window [mem 0xe0200000-0xe03fffff]
[ 0.175426] mv_xor f1060800.xor: Marvell shared XOR driver
[ 0.211308] mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
[ 0.251253] mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
[ 0.251309] mv_xor f1060900.xor: Marvell shared XOR driver
[ 0.291256] mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
[ 0.331249] mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
[ 0.331369] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 0.331623] console [ttyS0] disabled
[ 0.351655] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 44, base_baud = 12500000) is a 16550A
[ 0.990713] console [ttyS0] enabled
[ 0.994672] pxa3xx-nand f10d0000.flash: This platform can't do DMA on this device
[ 1.002323] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
[ 1.008703] nand: AMD/Spansion S34ML01G2
[ 1.012647] nand: 128MiB, SLC, page size: 2048, OOB size: 64
[ 1.018331] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step size 2048
[ 1.025467] Bad block table found at page 65472, version 0x01
[ 1.031475] Bad block table found at page 65408, version 0x01
[ 1.037361] nand_read_bbt: bad block at 0x000000fa0000
[ 1.042525] nand_read_bbt: bad block at 0x000001260000
[ 1.047684] nand_read_bbt: bad block at 0x0000026c0000
[ 1.052845] nand_read_bbt: bad block at 0x000002e20000
[ 1.058002] nand_read_bbt: bad block at 0x0000032a0000
[ 1.063246] found commandline
[ 1.066224] rename part 5 to ubi
[ 1.069314] 11 ofpart partitions found on MTD device pxa3xx_nand-0
[ 1.075709] Creating 11 MTD partitions on "pxa3xx_nand-0":
[ 1.081222] 0x000000000000-0x000000200000 : "u-boot"
[ 1.086474] 0x000000200000-0x000000240000 : "u_env"
[ 1.091590] 0x000000240000-0x000000280000 : "s_env"
[ 1.096704] 0x000000900000-0x000000a00000 : "devinfo"
[ 1.102001] 0x000000a00000-0x000003200000 : "linux"
[ 1.107143] 0x000000d00000-0x000003200000 : "ubi"
[ 1.112118] 0x000003200000-0x000005900000 : "linux2"
[ 1.117353] 0x000003500000-0x000005900000 : "rootfs2"
[ 1.122680] mtd: partition "rootfs" set to be root filesystem
[ 1.128571] split_squashfs: no squashfs found in "pxa3xx_nand-0"
[ 1.134612] 0x000005900000-0x000005940000 : "nvram"
[ 1.139748] 0x000005a00000-0x000007f00000 : "ddwrt"
[ 1.144908] 0x000000280000-0x000000900000 : "unused_area"
[ 1.150930] libphy: Fixed MDIO Bus: probed
[ 1.155051] tun: Universal TUN/TAP device driver, 1.6
[ 1.160122] tun: (C) 1999-2004 Max Krasnyansky maxk@qualcomm.com
[ 1.166452] libphy: orion_mdio_bus: probed
It looks like you have some nand badblocks which aren't getting marked a bad and added to the badblock tables.
If you create a McDebian rootfs and chroot to it via DD-WRT you can use the below command to flash the firmware to both image locations. McDebian kernel would update the badblock table during firmware write and I believe DD-WRT kernel will most likely do the same. You really should have a USB to TTL cable in case you make a mistake.
Well, now I have my wrt1900acv2 stuck in a boot loop somehow. RIP $75. Cant' get to DDWRT or anything really anymore.
It starts up, flashes the power and LAN lights... few seconds later, it reboots again. So... I've broken out a USB-Serial cable, but the ports on this board are differently aligned than what the documentation shows on the OpenWRT page. The Serial connector is perpendicular to the board instead of parallel to it, so I'm going to have to guess which pin is which. It matches the picture that's in this other forum post:
http://fabianlee.org/2016/07/20/ubuntu-serial-level-access-to-your-linksys-wrt1x00acs/
Edit: And have u tried this? https://wiki.openwrt.org/doc/howto/generic.failsafe
To enter failsafe, turn on router, continually press the WPS key on the back as fast as you can until the power light begins flashing rapidly.
Edit2: This is for openwrt/lede not ddwrt...
Edit3: You have spammed the crap out of this very useful thread over the past few days with things completely off topic! GO AWAY!
Careful USB to TTL is very different from USB to RS232 (null modem cable).
Sorry I mixed up DD-WRT and LEDE 
Sorry, was not knowingly spamming offtopic --- initially I was installing cybernook's build on my WRT1200AC, which worked amazing. So when I got my refurb WRT1900ACv2, I wanted to do the same. Then it didn't work, so I thought I would ask the people in this thread since I thought they might be most knowledgable (and all of you certainly are!). I can go away and start a new thread, but then I'd have to repeat the context again. I'm new to the forum, so I will acquiesce to whatever you would like -- I assumed there would be no more threads here since the builds are discontinued so it was OK to continue in here.
Also I've started the serial process, took a little bit of doing, but I'm at the point I can get serial boot output. Going to try and dig myself out of this nice hole I've made for myself.
1.389171] Waiting 1 sec before mounting root device...
[ 2.401321] VFS: Cannot open root device "ubiblock0_0" or unknown-block(0,0): error -6
[ 2.409255] Please append a correct "root=" boot option; here are the available partitions:
[ 2.417634] 1f00 2048 mtdblock0 (driver?)
[ 2.422711] 1f01 256 mtdblock1 (driver?)
[ 2.427784] 1f02 256 mtdblock2 (driver?)
[ 2.432859] 1f03 1024 mtdblock3 (driver?)
[ 2.437931] 1f04 40960 mtdblock4 (driver?)
[ 2.443006] 1f05 37888 mtdblock5 (driver?)
[ 2.448077] 1f06 39936 mtdblock6 (driver?)
[ 2.453152] 1f07 36864 mtdblock7 (driver?)
[ 2.458223] 1f08 256 mtdblock8 (driver?)
[ 2.463298] 1f09 37888 mtdblock9 (driver?)
[ 2.468370] 1f0a 6656 mtdblock10 (driver?)
[ 2.473531] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 2.481814] CPU1: stopping
[ 2.484529] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.18.25 #23
[ 2.490634] Backtrace:
[ 2.493100] [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
[ 2.500685] r6:00000000 r5:00000000 r4:c04cec10 r3:00000000
[ 2.506401] [] (show_stack) from [] (dump_stack+0x8c/0x9c)
[ 2.513642] [] (dump_stack) from [] (handle_IPI+0xe8/0x174)
[ 2.520966] r5:c04b78ac r4:00000001
[ 2.524569] [] (handle_IPI) fr
Ok, Thanks to the USB-to-TTL instructions, I was able to flash OEM Linksys firmware back using a TFTP server setup. I used FW_WRT1900ACv2_2.0.7.167471_prod.img from the Linksys website, renamed it as cobra.img, and the update went well from Putty serial port.
Since then, I have tried to use the Linksys GUI to try and load different versions of LEDE, I've tried Cybernook's last build of
lede-stable-17.01-snapshot-r3383-8011215-mvebu-linksys-wrt1900acv2-squashfs-factory.img
and also davidc's build of a couple days ago
lede-mvebu-linksys-wrt1900acv2-squashfs-factory.img
Both seem to end with a failure to boot. I am able to recover it since I'm still connected to serial by using "run altnandboot", which puts me back in Linksys firmware. What am I doing wrong here?
[ 1.400866] armada38x-rtc f10a3800.rtc: setting system clock to 2089-01-04 16:00:27 UTC (3755692827)
[ 1.410345] Waiting 1 sec before mounting root device...
[ 2.481469] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 2.488968] Please append a correct "root=" boot option; here are the available partitions:
[ 2.497354] 1f00 2048 mtdblock0 [ 2.501370] (driver?)
[ 2.503742] 1f01 256 mtdblock1 [ 2.507758] (driver?)
[ 2.510122] 1f02 256 mtdblock2 [ 2.514142] (driver?)
[ 2.516506] 1f03 1024 mtdblock3 [ 2.520522] (driver?)
[ 2.522890] 1f04 40960 mtdblock4 [ 2.526906] (driver?)
[ 2.529270] 1f05 34816 mtdblock5 [ 2.533289] (driver?)
[ 2.535653] 1f06 40960 mtdblock6 [ 2.539668] (driver?)
[ 2.542035] 1f07 34816 mtdblock7 [ 2.546050] (driver?)
[ 2.548414] 1f08 38912 mtdblock8 [ 2.552433] (driver?)
[ 2.554796] 1f09 6656 mtdblock9 [ 2.558811] (driver?)
[ 2.561175] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 2.569459] CPU1: stopping
[ 2.572174] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.20 #0
[ 2.578107] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 2.584052] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[ 2.591816] [] (show_stack) from [] (dump_stack+0x7c/0x9c)
[ 2.599057] [] (dump_stack) from [] (handle_IPI+0xcc/0x184)
[ 2.606384] [] (handle_IPI) from [] (gic_handle_irq+0x78/0x94)
[ 2.613971] [] (gic_handle_irq) from [] (__irq_svc+0x6c/0x90)
[ 2.621469] Exception stack(0xdf475f90 to 0xdf475fd8)
[ 2.626532] 5f80: 00000001 00000000 00000000 c001b160
[ 2.634729] 5fa0: 00000000 df474000 c061efe4 00000002 c0619138 00000000 df475fe8 00000001
[ 2.642925] 5fc0: df46c040 df475fe0 c000f808 c000f80c 60000013 ffffffff
[ 2.649556] [] (__irq_svc) from [] (arch_cpu_idle+0x2c/0x38)
[ 2.656974] [] (arch_cpu_idle) from [] (cpu_startup_entry+0xf0/0x19c)
[ 2.665173] [] (cpu_startup_entry) from [<000095ac>] (0x95ac)
[ 2.672203] Rebooting in 1 seconds..
BootROM - 1.73
You should try loading the LEDE trunk firmware.
Ok I will try that. I created a new thread to stop spamming in here:
Apologies to everyone here, what started out as a small question ballooned into a big mess. Hopefully the mess is now contained in my own thread.