Posted: Sat Mar 09, 2013 5:28 Post subject: RT-N66U - Bad CFE / Flash Recovery
I'm back! Thanks to all those that have been patient while I dealt with a family emergency.
Recovery Method (RTN66U with 3 steady lights or bad CFE flash).
You will require the following before attempting this recovery (when in doubt, search the forums) :
2. Original CFE (If you remembered to backup it up before flashing) or an edited CFE of another RT-N66U firmware with your MAC ids and place it in your zjtag folder ie. CFE.BIN
3. TUMPA Board with device software (USB) installed - IMP: Verify that TTL-OUT is selected/enabled on the board and do not connect the board to the router with RS232-OUT enabled as you may cause damage to the board and/or router (see TUMPA PDF Manual)
4. 'Proper' soldering of JTAG J2 Pinouts (verify with ohm/voltmeter) including pinout diagram for Serial/Parallel connections and connecting wires should be no more than 45cm (for J2)
5. Windows XP/7 x86 - may work on x64
6. Latest version of zjtag - I remember also using tjtag/brjtag/xjtag at some point but we will try to first recover with zjtag (I believe the later progs were used for analysis)
7. Network cable with the static ip 192.168.1.10 set on your local network adapter
8. ASUS CFE Recovery software (preferred) or CFE recovery page available at 192.168.1.1
9. Latest merlin or asus firmware (if you are restoring a 32k CFE then stick with a 32k firmware and the same applies to 64k CFEs)
10. Latest CFE conversion script (if you wish to attempt to convert the CFE to 64k again)
My Logic & Method
Current jtag software zjtag, tjtag, brjtag do not properly support the flash type SPANSION S29GL256P (missing device id / improper CPU detection / initialization) or CPU type BROADCOM BCM4706 and after analysing the source code of brjtag and zjtag and going over the technical documentation of the spansion chip, I understood how flash / CPU chip support was built into the software and was able to identify a hack that would allow us to use zjtag with the nearest supported spansion flash chip type and unsupported CPU through a 2-step initialization process using the /noreset switch to maintain the active status of the first initialization (CPU) while carrying out a second initialization to activate the spansion chip and make it ready for command processing.
This was not easy as I had to first identify the actual instruction length that made our CPU tick and after attempting over 300 possible combinations of instrlen and divider values, I was able to initialize the CPU using:
Now that I have flashed the CFE, I connected my network cable to the router and windows box/vm and then proceeded to manually powering off the router, disconnecting the power cable and pressing the power button to the on position (I saw a quick 3-light flash/blimp) followed by pressing the power button again to the off position.
I then connected the power cable and powered on. The router booted to CFE with a quick all light flash followed by a slowly glowing power led light which is an indicator that the router is now ready to accept new firmware. I proceeded with restoring the firmware and carried out a final reboot.
I was able to verify that the CFE was booting and the firmware flash was executed properly via the Serial connection.
Follow these instructions and your RT-N66U will be resurrected
Posted: Sun Sep 08, 2013 3:18 Post subject: JTag or another way?
So I got a new RT-N66U today, and pulled it out and loaded up dd-wrt right away without looking to deeply at the forums. Turns out I should have read a bit more and I flashed the wrong version. Bricked my router right out of the gate.
So here is where I am right now. I have serial access to the router and can log in to dd-wrt locally. I get lights coming on when I plug in network cables, but not connectivity. From the CFE prompt it says there are no network devices. It shows a network device when I first boot into dd-wrt, but then it seems to disappear when they are initialized. I tried moving a CFE patch script to an SD card, but the SD card doesn't mount. I even tried an old ZModem style file transfer over serial as a last ditch effort, but no joy. I guess there is still the option of making the changes to the CFE manually, but I haven't found a good understanding yet as to exactly what I need to do.
As compared to the JTAG method, which would be more trouble? I don't have any JTAG hardware, but I can snag some this coming weekend if I have to. I'd REALLY like a way to fix this from the serial console if at all possible. If anyone can point me in the right direction, that would be awesome.
Posted: Sun Sep 08, 2013 17:06 Post subject: which problem
Another thing I'm not sure about as I examine this is which problem I have, and how to identify it. I don't know if I have a 32k CFE and 64k dd-wrt image, or a 64k CFE and a 32k dd-wrt image. I initially installed the dd-wrt image straight from the dd-wrt router database when I bricked the router (dd-wrt.v24-18702_NEWD-2_K2.6_mini_RT-N66U.trx). I think that means I have a 64k CFE and a 32k dd-wrt, so the problem becomes, how do I modify dd-wrt to read the 64k nvram. Any suggestions would be helpful.
Posted: Sun Sep 08, 2013 18:03 Post subject: Thanks
Thanks for the pointer, can you point me in the direction of how to write a new image over serial? Looks like everything is TFTP and without the network ports active that is impossible. Looks like I might be stuck with JTAG repair after all, though from what I've read it would take weeks to flash a whole image over JTAG. I'm still hoping there is a way to repair this image, but I'm not finding much information out there on it. Thanks for your help.