Hate to ask, but just in case by corrupt do you mean you can't log into 192.168.1.1? If so that's normal, there's no user interface on the trunk builds so you need to install it separately.
Yes, corrupt, (green flashing power light, to no power light). Can't SSH in or ping 192.168.1.1. So i'm wondering if one of the partitions has gone bad or anything like that, guess that's what I get for buying off ebay. I'm building my own images right now to try those next.
Ahh ok, I still (link removed) I made in December if you want to try that instead of waiting for your own compile, I can't remember what packages are on it, but it's just for installation anyway.
Thanks. I'll try that one. The "upgrade status bar" never makes it to 100% when I click start upgrade. It mostly hits 40% then throws the "rebooting" pop up.
Hmm, the only thing I can think of is flashing stock linksys just to see if any flash will work, if it does work you could flash stock linksys again just to make sure both partitions are ok. I know that first .bin worked for me on the latest ea3500 stock which I think is from 2014, I can't remember if my build from December worked from stock or not.
Probably not relevant to tahjr13's case, but for anyone who's trying to flash the EA3500 from scratch, the current OpenWrt trunk build still will not allow you to subsequently flash the latest LEDE firmware. You have to grab the trunk build that's dated Dec 6, 2017 here. I successfully flashed mine minutes ago.
Flashing old stock and new stock both works (the classic stock firmware and the smart wifi firmware), so I guess that means both partitions work and i've confirmed i can bounce back and forth between them doing a "restore to previous firmware" from both. But i've tried all of the openwrt trunks I can find (including menkatek's link, thanks though). Menkatek, when you succesfully flash, does the upload status bar get to 100% or does it stop at 40% and then reboot? Shouldn't matter, but i've tried flashing from multiple browsers, windows 10 and debian.
I don't recall the progress bar reaching 100%. More like half-way.
I did my flash on a new unit using macOS 10.13 and Safari.
I've done several (3x) successful installations from Linksys firmware:
- flash with openwrt-kirkwood-linksys-audi-squashfs-factory.bin (the progress bar for the flash will never reach 100%; the device will reboot before 50%; this is consistent behavior, I've observed each time).
- Set your NIC to 192.168.1.10/24 connect to LAN port on device.
- SSH to device at 192.168.1.1 and install LUCI; reboot device.
- HTTP to 192.168.1.1 and flash with lede-17.01.4-kirkwood-linksys-audi-squashfs-sysupgrade.tar.
That's what worked for me each time.
I've tried this, but no luck. When you flash, does the power LED turn off after the reboot? What's happening is I have the stock firmware up, i flash openwrt-kirkwood-linksys-audi-squashfs-factory.bin, progress bar goes to ~50% and reboot message comes up. Router reboots, power LED blinks for restart, but then turns off. Cannot ping router (using pull DHCP or static IP). Essentially a fail.
Then unplug power, plug power in, power led blinks, then goes null again. no activity (1)
Then unplug power, plug power in, power led blinks, then goes null again. no activity (2)
Then unplug power, plug power in, power led blinks, then goes null again. no activity (3)
Then unplug power, plug power in, power led blinks, then goes full on, and we are back to stock firmware.
This sounds all normal. After the power LED stops blinking it should remain solid after the reboot.
I've never experienced that. So no LED lights on at this point? None?
This is consistent behavior, as in always 1 - 4?
Can you try a different, compatible power adapter (I have a e1200 that sporadically turned itself off when plugged in to a powerstrip; when the adapter is plugged in to the wall outlet directly, no such behavior)?
Have you tried 30-30-30 to clear the NVRAM (please confirm this would apply to your model of router, so you don't brick it).?
That's all I can think of.
I was able to test today, so I put stock linksys back on my ea3500 (the latest one from 2014 - 1.1.40) and flashed the OpenWrt trunk I saved from November (the first one I linked) and it's still working fine on my ea3500, the progress bar did only go halfway and the led sequence was - blinking rapidly, turn off for a second, blink slowly, then solid green. So at this point i'm just not sure what's going on, you might try waiting a little longer after you flash, I usually wait 5 minutes before I do anything after a flash, along with z0rk's suggestion of another power supply, but other than that I'm out of ideas.
1 Like
The only LED light on after the power LED turns off is the green lan port I'm plugged into (no orange for TX activity though). Yes 1-4 are consistent as those steps are simply forcing the boot partition to change I believe. I have tried multiple power adapters, with and without power strips involved. Thanks for suggestions though, seems like I just have a bad unit somewhere. I did try 30-30-30 just for the hell of it, but no help.
Thanks, I actually let it sit all night last night just incase it was a timing issue, no help. I've got a TTL cable on the way now just because it's a prove it type scenario now, I'll either force it on there, or break the PCB trying.
Ha, ha... that's a exactly what I would try and do. I hope this works for you!
Thanks for all the insight everyone. I gained access thru TTL, celebrated with some beers, then screwed up the flashing using TTL methods. There were LOTS of bad blocks in this unit once I saw the console, which I'm guessing was causing a lot of the issues. So EA3500 #1 died for learning purposes. EA3500 #2 showed up today and everything worked like you would expect. Flash openwrt trunk from linksys, then install luci, then flash lede, bing bang boom.
Just updated Bug FS#505 - Can't install LEDE on Linksys EA3500:
Flashed snapshot r9886-399aa0b in the Linksys stock firmware's web UI. OpenWRT failed to boot with "ubi0 error: validate_ec_hdr: bad VID header offset 512, expected 256". It used to work with the pre-merged OpenWRT snapshot r50107. Not sure where the different code resides.
[ 1.459990] UBI: auto-attach mtd4
[ 1.463377] ubi0: attaching mtd4
[ 1.467004] ubi0 error: validate_ec_hdr: bad VID header offset 512, expected 256
[ 1.474473] ubi0 error: validate_ec_hdr: bad EC header
[ 1.479633] Erase counter header dump:
[ 1.483421] magic 0x55424923
[ 1.487185] version 1
[ 1.490184] ec 0
[ 1.493167] vid_hdr_offset 512
[ 1.496323] data_offset 2048
[ 1.499568] image_seq 423893825
[ 1.503271] hdr_crc 0x7678fd1d
[ 1.507032] erase counter header hexdump:
[ 1.511107] CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.111 #0
[ 1.517052] Hardware name: Marvell Kirkwood (Flattened Device Tree)
[ 1.523364] Backtrace:
[ 1.525842] [<c010530c>] (dump_backtrace) from [<c01055f4>] (show_stack+0x18/0x1c)
[ 1.533472] r7:00000000 r6:00000000 r5:c3078000 r4:c31f3600
[ 1.539175] [<c01055dc>] (show_stack) from [<c058c320>] (dump_stack+0x20/0x28)
It was fixed as of r11203-e11fc8439c on the master branch. Not sure it will be cherry-picked onto release branches, i.e. 18.06 and 19.07.
1 Like