What's new

CFE bootloader update

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Then try to clean (potentially) corrupted NVRAM: push and hold WPS button then turn N66 on.
Edit: Ops, you already done this.

It reads lan_ipaddr variable on my RT-N66U, here is an example.

In that case this is bad design on Broadcom's part IMHO. What happens if lan_ipaddr contains garbage? Or an IP that people can't remember anymore? (tho there are ways to work around that, as long you know the MAC address and are willing to do some ARP fiddling).

Hopefully the WPS reset code is being applied before the LAN IP gets configred, so one would be able to at least reset to factory default even tho the lan_ipaddr is corrupted.
 
Hi, is here someone who can me do update CFE across WAN port? Someone with XP :) THX

I dont think so dont you think that would be pretty dangerous ?
It aint that hard to do it yourself with proper instructions and i think it would be a lot safer to
 
bl_version reports cfe as ~.3 but after power cycle... No comms available.

Hi. After reading up on the cfe upgrade procedure, I decided to go ahead with it. I was able to extract my cfe from the rt-n66u that was running ddwrt 20202 mega (32k nvram version). I had to alter my approach slightly, as some locations and commands were different than described.
For instance; instead of reading cfe from /dev/mtd0, I had to get it from /dev/mdt/0
Also, commands such as write-mtd had to be replaced with write mtd (space no dash) and the switches -i and -d were not required.

So, after obtaining cfe.original, running the script, scp'ing the cfe.new back to the router, and writing the new file (133.4k) to mtd/0... I was then able to confirm the transfer by checking with grep the bl_version returns 1.0.1.3.

Then I did the nvram erase step. Oops. I no longed have communications to the router.
I've power cycled. I've 30/30/30'd using wps button. The power led and the wired LEDs and the two wifi LEDs come on, but no ip's are handed out. Set static ip ~.12. No comms... Can't ping, can't start ssh session.

So now try cfe recovery mode... Power cycle, while holding reset button.
I expect the power led to start blinking slowly. That is not happening. The power led goes on solid and the wired lan port shows that a device is present and flickers when I try to communicate on that port. Nothing is working.

Hoping I didn't screw-up really badly by attempting this under 20202 ddwrt f/w.
Let me know your thoughts.
 
This doesn't look good :( According to the folks on the DD-WRT forum, you cannot mix the new CFE with a 32KB build of DD-WRT - it will brick your router.

You might need a serial cable to be able to recover from this, sorry.
 
That sounds like fun, but I'm wondering if someone could chime in on a reason that my cfe won't bring about recovery mode.
 
That sounds like fun, but I'm wondering if someone could chime in on a reason that my cfe won't bring about recovery mode.

You would have to ask the folks on the DD-WRT forum who have actually looked into this. I don't have a serial cable, and I'm sticking to my original CFE myself.
 
While creating your new CFE did you see any errors at all?

I've done two CFE updates and haven't had a brick yet.

To create the new CFE without errors I had to change the CFE_rtn66u-1.0.1.3 folder and files permissions with chmod +x.
 
@Gingernut
I think that setting permissions on that folder would be LINUX os flavour and folder location dependant. However, I ran the script as recommended and verified the results with what other successful upgrader's have reported. I got the same results after the script. cfe.new turned out as 133.4 kb.

I think my problem is that I have an un-tried firmware installed while I updated the cfe.

@lfbb
I'm not really sure what you are getting at...

Situation update:
I have tried many different power cycling/reset procedures.
With wps held down while turning on power, I can get the power LED to flash quickly. Also, it seems that I'm able to 30/30/30 using wps. That said, nothing happens after the process, no communication via static IP, and the wifi radios are not broadcasting an ssid, even though the wifi LEDs are illuminated.
At one point, after many unsuccessful attempts, I held down the reset button while applying power and the power LED began to flash slowly. Am I foolish to think this is a sign of life from my cfe recovery mode? I was unable to ping or get connected with static IP 192.168.1.12, is there anything else I should try?
I have no idea what I'm doing when it comes to JTAG. I can build a cable just fine, but then what, do I use putty to issue commands?

I really appreciate any help or insight you can give.
 
i got as far as creating a new cfe.new but its only 5.1kb, can someone help me create it? i will upload if it someone is willing to help me. Thanks!
 
Situation update:
I have tried many different power cycling/reset procedures.
With wps held down while turning on power, I can get the power LED to flash quickly. Also, it seems that I'm able to 30/30/30 using wps. That said, nothing happens after the process, no communication via static IP, and the wifi radios are not broadcasting an ssid, even though the wifi LEDs are illuminated.
At one point, after many unsuccessful attempts, I held down the reset button while applying power and the power LED began to flash slowly. Am I foolish to think this is a sign of life from my cfe recovery mode? I was unable to ping or get connected with static IP 192.168.1.12, is there anything else I should try?
I have no idea what I'm doing when it comes to JTAG. I can build a cable just fine, but then what, do I use putty to issue commands?

I really appreciate any help or insight you can give.

In your dd-wrt thread (http://www.dd-wrt.com/phpBB2/viewtopic.php?t=164763) you can find the link to the way how a similar issue was solved: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=163975

There is no JTAG support available yet for RT-N66U, but if you can set up a working serial console connection, then maybe you are lucky and can unbrick your router through the CFE serial connection shell.

It looks like the 64kB CFE leaves the nvram in an "inconsistent" state, when resseting the nvram after an incompatible firmware flash or failed firmware flash. This then leads to an unreachable router.
If the CFE itself is OK, i.e. you can access the serial CFE shell, then you might write some dummy nvram values, which sometimes results in a reachable router afterwards.
 
Last edited:
It looks like the 64kB CFE leaves the nvram in an "inconsistent" state, when resseting the nvram after an incompatible firmware flash or failed firmware flash. This then leads to an unreachable router.
It is very hard to brick an Asus router. If something goes wrong during flashing, you can put your router in Recovery mode by powering it on while you keep Reset pressed. After your release it, the power LED will either blink or stay off (depending on the model). At that point, you can either access it through http://192.168.1.1 (make sure you first set your PC on a static IP within the same range, i.e. 192.168.1.100 for example), or through the Firmware Recovery Tool provided on Asus's support CD. You will then be able to flash a working firmware.
https://github.com/RMerl/asuswrt-merlin/wiki/Installation

- lfbb
 
I forgot to say that when I flashed the Merlin 3.0.0.4.246.20 build for the first time it failed. I followed the Merlin wiki and all went fine. And I have the 64K bootloader.

- lfbb
 

In my case no conventional nvram resetting has made the router reachable.
asuswrt-merlin was also used and everything went fine, until a flash of tomato-usb failed: Router was unreachable and neither the WPS nvram reset nor the recovery mode did help.

It looks like unless people really get the symptom, they do not believe it exists and point to the supposedly working recovery mode.

But fortunately the CFE serial shell helped: just play around with the nvram command and power cycle often the device to see if you get it reachable.
 
That's one of the reasons why I like the fact that the original CFE just ignored the nvram settings. I don't trust the fact that it's supposed to reset it to correct values if they are "corrupted", since that corruption might prevent the CFE from even working properly.

A boot loader shouldn't rely on *any* dynamic data to reach its recovery stage. If the WPS button handling gets done after the nvram gets accessed, then the CFE design is seriously flawed IMHO.
 
A boot loader shouldn't rely on *any* dynamic data to reach its recovery stage. If the WPS button handling gets done after the nvram gets accessed, then the CFE design is seriously flawed IMHO.
Yes, definitely. On one hand:) On another hand — readable NVRAM is the only way to put Linux kernel boot time parameters, for example. for external rootfs.
 
If the WPS button handling gets done after the nvram gets accessed, then the CFE design is seriously flawed IMHO.
Let me ask something about the WPS button...

I remember clearing the NVRAM of my RT-N16 (dd-wrt) with the 'erase nvram' command and the output showed a 131072 block size. Maybe it has something to do with the WPS button and the amount of NVRAM it can address.

6. The flash memory partition table is in /proc/mtd. On the RT-N16 it looks like this:

dev: size erasesize name
mtd0: 00040000 00020000 "pmon"
mtd1: 01fa0000 00020000 "linux"
mtd2: 0061bc00 00020000 "rootfs"
mtd3: 018a0000 00020000 "jffs2"
mtd4: 00020000 00020000 "nvram"

Note that the RT-N16's NVRAM partition has 131072 bytes, but only the last 32768 bytes are used for NVRAM. Note also that the smallest amount of data that can be written (flashed) is one erase-block. Note that in the above example, the erase-block size is 131072 bytes. Thus, when only one bit in the NVRAM is changed (and "committed"), the entire partition is re-flashed.
http://tomatousb.org/forum/t-459992
If the last 32768 bytes are used for NVRAM 32K then the last 65536 are used for NVRAM 64K, am I right? And the 'WPS+power on' procedure clears the 131072 bytes block size. Am I right?

- lfbb
 
Last edited:
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top