Quick update: I have to apologise to @NoTengoBattery for suggesting earlier today I had not not yet heard back from him.
It transpires I did receive a very detailed email which includes the 21MB sysupgrade image with full instructions, which I have yet to digest.
It looks like Yahoo is having problems today because this and a couple of other emails arriving in my Inbox this evening were delayed by over 12 hours.
Update 15 Aug 2019: I'm informed by @NoTengoBattery that he plans to upload his prebuilt sysupgrade to GitHub.
I have also been reviewing the instructions included with the prebuilt sysupgrade image, and to hopefully use it as a basis for writing a short guide to help newbies, and to also update the wiki for the ea6350v3 later. (Similar to PDF guides I have written for BT Home Hub 5A)
I am hoping to test the prebuilt image and linksys FW restoration procedure at the weekend if not sooner.
Scroll through the page and locate this particular release which I can confirms is working.
Under 'Assets', download and extract contents of the highlighted tar.bz2 file to obtain the squashfs-sysupgrade.bin image:
Link to my PDF instructions based on above release using SFTP and USB.
For NoTengoBattery builds v1.x or later, Windows users will require Peazip, MacOS users will require Keka (beta) to extract the .tar.zst archives.
NoTengoBattery's Github page no longer hosts the v0.1x sysupgrade images. If you cannot extract .tar.zst archive files of the latest v1.x images or wish to use the older images, then you can find zipped up copies of the original v0.11 and v0.14 sysupgrade images in my Dropbox folder. Look in 'Old NoTengo v0.1x builds' folder
I had been using 19.07 r10269 snapshot for over a week. I installed 19.07 r10302 today using LuCI, and can confirm when I perform the 3x power On/Off reset sequence, I can toggle between both versions of 19.07, similar behaviour as reported by @zakporter.
I can confirm my EA6350v3 has been returned to running Linksys OEM firmware. I have written a PDF describing how to do it step by step using above NoTengoBattery's prebuilt sysupgrade image.
The script has proven to work out of the box and no extra configuration is needed when using my prebuilt. As for the origin of the script, it is inspired on the script found inside the original firmware, it’s not a surprise for me.
And instead of adapting the script it to the standard OpenWrt, is always better to modify OpenWrt to make the script work. It needs a custom configuration for Busybox, which forces people to build it’s own image.
As the whole purpose of my work is to make OpenWrt easier and more accesible, it makes the whole process as easy as installing, transferring and executing 2 commands (one of which is “sudo”), rather than cloning, configuring, building, uploading, testing and finding a random misconfiguration to repeat the whole process.
I said in the other thread that the script itself is a nice added value, but they just made fun of me. I don’t understand it but... hey, enjoy my work anyway.
fwiw, while I had stock Linksys firmware reinstalled on my ea6350v3, I thought I'd try to use a TFTP client to send OEM fw to the router at 192.168.1.1. No luck using Linksys windows tftp.exe, or with TFTPD64 client with ethernet switch in between laptop and router.
@bill888@NoTengoBattery Thankyou ever so much for your time spent on this as i'm now back on stock firmware on both partitions , NoTengos firmware works perfectly and Bills PDF is really easy to follow.
Cheers to everyone that contributed to this thread and i hope one day NoTengoBattery feels welcome here as his way doing things could help lots of other people on other Linksys models seeing as TFTP doesn't seem to work.
fwiw, when comparing the OEM bootlogs of EA8300 vs EA6350v3 posted in openwrt wiki, I have a suspicion the bootlog for the EA6350v3 may be incomplete (or invisible).
No mention of Uboot at all.
In ART, mac0=0xFFFFFFFFFFFF, mac1=0xFFFFFFFFFFFF, mac2=0x6038E08B6235, mac3=0x6038E08B6236
get_eth_mac_address@1407: the base hw_mac_addr='60:38:E0:8B:62:33' is valid!
Using machid 0x8010100 from environment
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.14.43 (root@build-vm) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.01 r40864) ) #1 SMP PREEMPT Sat Jul 1 06:01:09 PDT 2017
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
(Above is copied from wiki for EA6350v3)
I may one day open up my EA6350v3 and hook up a serial console connection to confirm Uboot is the same as for EA8300, but not at this moment in time.
For my information, did you have to use the 'Reset' button as described in the guide to clear settings, after first flash of the Linksys firmware to your EA6350v3 to be able to bring up the linksys web UI password box?
Yeah , i had a blank blue Linksys Web UI so i powered off and rebooted as per your PDF , when i retried it had hung again but while i was away from the PC trying to find something for the pinhole reset the login had appeared.
I logged into the web UI and done a software reset and when i rebooted i got the first time welcome screen asking you to agree with their terms.
I then done the standard factory firmware update and i then swapped to the other partition and done the same, i then swapped and done both again to be sure it was embedded correctly, no blank screens after that.
Sorry for late response...
TFTP will not work on LAN for me, and I would like to reverse engineer the firmware (just like I did with the script that is proven to work) to see if I can make it work, but I only have one device and I’m using it for production (it’s my NAS for Time Machine).
As for the procedure in both my script and it’s inspiration, the Linksys OEM update script, boot sector is not touched at all.
The only thing that is done is to enable the autorecovery feature (not needed in OpenWrt as it’s always enabled) and to switch the boot partition to the one which is not booted. It uses the default uboot-env-tools available in OpenWrt.
An extra step made by my script is wiping the “syscfg” partition, where the OEM firmware stores it’s settings. Nothing else is done.
But, as far as I understand (did not test), TFTP should be usable on LAN (Linksys even provided the tools). More research is needed, but as long as the device is not hard bricked, the BackToStock method should always work.
Any bug reports are welcome, but you should use the Issues feature on my repository on GitHub to grab my attention regarding to the prebuilt, the scripts and it’s documentation.
I've opened a thread about the custom build, for the convenience of all of the new users that want to try OpenWrt with less problems and risks (as you know that reverting to stock is almost trivial, and actually trivial if you don't flash twice) for this particular device. Give it some love ...