CFE bootloader update
- Thread starter ryzhov_al
- Start date
- Status
Lost_Animal
Occasional Visitor
Thanks again for your help....
My system logs showning....
Jan 1 02:00:10 kernel: _nvram_init: allocat header: 2280783872, size= 65536
And still i am on old CFE 1.0.1.2.
So maybe asus did the trick on newer versions of Fw and upgraded the nvram to 64k without change the version header on CFE.
Nope that is still the "firmware hack" and it works as well.
The only reason for doing this update is for making the CFE able to see 64kB nvram variables at boot. (if you want to overclock, or do something else very advanced.)
Okay, I'm trying to use a borrowed cfe version 1.0.1.2. Following this procedure, I now have the borrowed nvram.txt file from cfe version 1.0.1.2, where I can modify it to match my router. My understanding is that I need to get my router's MAC address into where the one from the router was borrowed. I see these MAC addresses in nvam.txt:
et0macaddr=
pci/1/1/macaddr=
pci/2/1/macaddr=
Of these, et0macaddr and pci/1/1/macaddr are the same, this might be the main MAC address of the router.
But pci/2/1/macaddr is a different MAC address, all the hex digit pairs are the same except the last one, that's different by 4 from the other two MAC addresses (that were the same *smile*).
So, it looks like all I need to do is get the right MAC addresses into these variables. Can anyone help as to what each of these variables represents? There's a chance that this might be:
et0macaddr= Main router MAC address?
pci/1/1/macaddr= 2.4 GHz. wireless MAC address?
pci/2/1/macaddr= 5.0 GHz. wireless MAC address?
Since what I'm seeing in the nvram.txt file looks like three separate functional units, I'm guessing that the above may be correct.
ryzhov_al - or someone else who might know
I did a successful update of my CFE before the latest version which added "vlan1ports=1 2 3 4 8*". All went well and I've been running Stock firmware, Merlins firmware, tomato and dd-wrt on my unit since then.
Now I wanted to flash an updated CFE as I want a working recovery mode. But, the output from the script is now different, and what it tells you to check is not what it outputs. This is my result when creating a new cfe:
***
[4/4] Checking differences between NVRAM from old and new CFE's
2d1
< Ate_power_on_off_ret=2
4c3
< bl_version=1.0.1.2
---
> bl_version=1.0.1.3
176d174
< wait_time=3
If you see only two differences: one is for 'bl_version' and second is a new 'odmpid=ASUS' variable then all step are done! New CFE image 'cfe.64k' is prepared for flash.
***
I see *three* differences as shown above, and it does not match what the text in your scripts asks me to look for. Two variables I didn't see before and I no longer see the 'odmpid=ASUS' variable that your script asks me to look for.
A "strings cfe.64k | grep odmpid" returns nothing so the odmpid variable has not been included in the new cfe generated by your script.
I already upgraded to your previous version with no problems, but I don't dare flashing the resulting CFE this time until you clearify.
I see others both here and over at the dd-wrt forum that are confused by this, and nobody has so far clearified the situation.
To me it seems like the new version of your script is somehow broken, and the cfe generated by your new script has more differences than just "vlan1ports=1" replaced by "vlan1ports=1 2 3 4 8*".
Please clearify the situation.
I did a successful update of my CFE before the latest version which added "vlan1ports=1 2 3 4 8*". All went well and I've been running Stock firmware, Merlins firmware, tomato and dd-wrt on my unit since then.
Now I wanted to flash an updated CFE as I want a working recovery mode. But, the output from the script is now different, and what it tells you to check is not what it outputs. This is my result when creating a new cfe:
***
[4/4] Checking differences between NVRAM from old and new CFE's
2d1
< Ate_power_on_off_ret=2
4c3
< bl_version=1.0.1.2
---
> bl_version=1.0.1.3
176d174
< wait_time=3
If you see only two differences: one is for 'bl_version' and second is a new 'odmpid=ASUS' variable then all step are done! New CFE image 'cfe.64k' is prepared for flash.
***
I see *three* differences as shown above, and it does not match what the text in your scripts asks me to look for. Two variables I didn't see before and I no longer see the 'odmpid=ASUS' variable that your script asks me to look for.
A "strings cfe.64k | grep odmpid" returns nothing so the odmpid variable has not been included in the new cfe generated by your script.
I already upgraded to your previous version with no problems, but I don't dare flashing the resulting CFE this time until you clearify.
I see others both here and over at the dd-wrt forum that are confused by this, and nobody has so far clearified the situation.
To me it seems like the new version of your script is somehow broken, and the cfe generated by your new script has more differences than just "vlan1ports=1" replaced by "vlan1ports=1 2 3 4 8*".
Please clearify the situation.
Thanks, very helpful, I think that I may be set then. I'll just put in my MAC addresses, and may just decide to go for it *smile*. I need to look at the final 1.0.1.3 that I get and make sure that the differences are reasonable. I don't feel that this is something that I have to do, but I'd like to get this issue taken care of.
Nope, haven't gotten that far yet. Just got the new nvram.txt with my MAC addresses in it and am now ready to go onto the next step. I'm happy to go slow on this one, and verify everything. I'm going to be doing some poking around on the internet, and I also noticed that someone else posted recently about the same diffs that you and I have. Maybe their questions will get answered in the interim, which will answer ours, too *smile*.
Pierino
Very Senior Member
Using a different linux distro did not make a difference. Still got that extra line. The first time I did this, I installed ubuntu as dual boot on my laptop, now I am doing it using a live cd.
I wonder if that makes any difference. I removed the Ubuntu install after the last conversion, maybe I should install it again?
I wonder if that makes any difference. I removed the Ubuntu install after the last conversion, maybe I should install it again?
You should not run the script, the nvsimple included has bugs
Here is an updated one: http://forums.smallnetbuilder.com/showpost.php?p=53840&postcount=272
Okay, new idea. I've extracted my current cfe (1.0.1.3) on my router. If the only thing wrong with it is this:
vlan1ports=1
in the nvram.txt that I got using nvsimple-32 (the latest version), why can't I just change this to:
vlan1ports=1 2 3 4 8*
and then put it back into the blank 1.0.1.3 cfe (cfe_n66u-1.0.1.3.empty.bin) and go from there with a cfe that I'm pretty sure will have the right MAC addresses, secret_code, etc. that will work with my router?
Would this work? Seems easier and safer for those of us (probably just me, actually *smile*) that don't have their cfe.original or cfe.old.
Is there anything that I haven't thought of or am not aware of?
Sounds good to me, anyways.
Thanks.
vlan1ports=1
in the nvram.txt that I got using nvsimple-32 (the latest version), why can't I just change this to:
vlan1ports=1 2 3 4 8*
and then put it back into the blank 1.0.1.3 cfe (cfe_n66u-1.0.1.3.empty.bin) and go from there with a cfe that I'm pretty sure will have the right MAC addresses, secret_code, etc. that will work with my router?
Would this work? Seems easier and safer for those of us (probably just me, actually *smile*) that don't have their cfe.original or cfe.old.
Is there anything that I haven't thought of or am not aware of?
Sounds good to me, anyways.
Thanks.
Pierino
Very Senior Member
I ran the script using the new nvsimple and I get the same output.
RT-N66R CFE Update
NOTE: as ifbb pointed out, my script below does not fix the vlan1ports issue, it will likely brick your CFE recovery. DO NOT USE the script below. I will leave it here as a reference so someone can develop a patch to support the RT-N66R.
I took the plunge to update my CFE on a RT-N66R (RT-N66U models sold retail and were supposedly "identical"). I realized quickly that there was an issue when the diff between the two nvram files were not as expected. It looked like this:
Looking at nvram.old:
I modified the cfe_update.sh to replace the odmpid value with "ASUS":
Once I made this modification cfe_update worked as advertised:
I flashed the cfe.new image onto the pmon MTD block and everything worked fine. I make no guarantees that this will work on all RT-N66Rs, but it worked for me. I am now running the 64k DD-WRT 20202 build from the barrywares FTP server.
I hope this helps people that might have RT-N66Rs...
NOTE: as ifbb pointed out, my script below does not fix the vlan1ports issue, it will likely brick your CFE recovery. DO NOT USE the script below. I will leave it here as a reference so someone can develop a patch to support the RT-N66R.
I took the plunge to update my CFE on a RT-N66R (RT-N66U models sold retail and were supposedly "identical"). I realized quickly that there was an issue when the diff between the two nvram files were not as expected. It looked like this:
Looking at nvram.old:
I modified the cfe_update.sh to replace the odmpid value with "ASUS":
Once I made this modification cfe_update worked as advertised:
I flashed the cfe.new image onto the pmon MTD block and everything worked fine. I make no guarantees that this will work on all RT-N66Rs, but it worked for me. I am now running the 64k DD-WRT 20202 build from the barrywares FTP server.
I hope this helps people that might have RT-N66Rs...
Last edited:
Okay, changed the nvram.txt that I extracted from my current CFE on the router (1.0.1.3 as mentioned above), modified the "vlan1ports" variable, are putting it back into the blank 1.0.1.3 cfe resulted in:
which is a bit shorter in the header area than I was expecting.
I also extracted the nvram.txt parts of the orginal cfe from the router, and the new, modified cfe, and the only difference was the one change in vlan1ports mentioned above. No surprise, but good to verify that I didn't change anything else.
But I'm thinking that this is going to work *smile*.
Any comments?
Yes I was *just* looking at that. I did this before the code was updated. I believe my CFE recovery is bricked... I was just lucky that I didn't need it. I am going to download the new code and fix my CFE.
Lost_Animal
Occasional Visitor
Add another happy owner of a cfe 1.0.1.3 bl_version.
I followed the instructions of 1st post and all procedure was fine.
Uploaded the cfe.new to my router and make the flash.
And after a complete vnram delete - reboot - and upload my saved CFG , now i get
So .... all are fine and now i'm free to Upload any firmware i like (Including all DD-WRT ones) without any danger to kill my router (Or NOT ?).
Thanks for your help ...
PS... Currently running Merlin's ASUS_WRT latest FW....
UPDATE....
Tested also the 20Sec boot delay test and passed with success....
I am able to access the CFE miniWeb Server and no problem to report so far....
I followed the instructions of 1st post and all procedure was fine.
Uploaded the cfe.new to my router and make the flash.
And after a complete vnram delete - reboot - and upload my saved CFG , now i get
So .... all are fine and now i'm free to Upload any firmware i like (Including all DD-WRT ones) without any danger to kill my router (Or NOT ?).
Thanks for your help ...
PS... Currently running Merlin's ASUS_WRT latest FW....
UPDATE....
Tested also the 20Sec boot delay test and passed with success....
I am able to access the CFE miniWeb Server and no problem to report so far....
Last edited:
Damn, I'm having problems with that. When I press 'reset+power on' the router enters rescue mode but I can't access it via 192.168.1.1
Is there another way to exit rescue mode besides using Firmware Restoration tool?
- lfbb
- Status
Similar threads
