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.
what exactly issues do you have with nvsimple? it's totally unclear what you're afraid of, please clarify. thanks.
lfbb@ubuntu:~/Desktop/cfe$ ./cfe_update.sh cfe_old.bin cfe_new.bin
[1/4] Dumping default NVRAM settings from your CFE...
nvsimple 0.2 (c) theMIROn
nvram start 0x400
nvram end 0x13d8
nvram len 4036
nvram crc 0x3f
nvram ver 0x01
[2/4] Modifying NVRAM settings (silent step)...
[3/4] Creating new CFE...
4092+0 records in
4092+0 records out
4092 bytes (4.1 kB) copied, 0.0188702 s, 217 kB/s
[4/4] Checking differences between NVRAM from old and new CFE's
0a1,7
> @=
> �=
> �@=
> =
><�=
> =
> �2=
4c11
< bl_version=1.0.1.2
---
> bl_version=1.0.1.3
64c71
< pci/1/1/regrev=3
---
> pci/1/1/regre�����=
176d182
< 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_new.bin' is prepared for flash.
I get this on the console when I try to update cfe. Is this working as expected?

- lfbb
 
can't say, but output is broken. what's your system?
lfbb@ubuntu:~$ uname -a
Linux ubuntu 3.2.0-34-generic-pae #53-Ubuntu SMP Thu Nov 15 11:11:12 UTC 2012 i686 i686 i386 GNU/Linux

lfbb@ubuntu:~$ gcc -dumpmachine
i686-linux-gnu

lfbb@ubuntu:~$ ls /lib/*libc*
/lib/klibc-LZ1cv1NoEVO2ugnvqTw3e4qPc8Y.so /lib/libcryptsetup.so.4.0.0
/lib/libcryptsetup.so.4
Hope this helps.

- lfbb
 
The CFE will be different based on which region you are in (i.e. the US CFE will be different from a EU one).
CFE update script will take all variables from old CFE to new one, no matter US or EU specific.

rhyzov, can you post what the output should be with this new code? Which Linux distro are you using?
Done! Sticked to first post.

I downloaded the archive at this link:
...
I got the same results:
Oh, looks like a github cloud bug: it does not update uploaded file on every server if it has the same name. I've changed the archive name, please, follow a link from the first post.
 
Last edited:
Oh, looks like a github cloud bug: it does not update uploaded file on every server if it has the same name. I've changed the archive name, please, follow a link from the first post.
Already done it, same errors.

- lfbb
 
"nvsimple-0.2b.tgz" extracts to "nvsimple-0.2b.tgz.out", using Winrar. Using tar returns an error and it can't be decompressed.

- lfbb
 
theMIROn, I used the 32 bit nvsimple but still got the same errors.

- lfbb

I'd say it's kinda imposible due just no code could generate your output.

"nvsimple-0.2b.tgz" extracts to "nvsimple-0.2b.tgz.out", using Winrar. Using tar returns an error and it can't be decompressed.

tgz is tar.gz, so using free tar tool is highly recommended
can't reproduce with winrar, just because it's non-free and I need to buy it first, sorry.
 
Can I email you my cfe and you return back the updated one? If so please send me your email by PM.

- lfbb
 
theMIROn, I used the 32 bit nvsimple but still got the same errors.

- lfbb

reproduced related error, nvsimple generates cfe nvram dump longer, than original (due sdram_* values for nvserial), and it can't fit to enbedded nvram space.
probably, rewrite nvserial would be good idea to fix that.
 
Can't we do it rewriting cfe_update.sh as suggested by a dd-wrt forum user? I tried it with no luck.
sed -i 's/vlan1ports=1/vlan1ports=1\ 2\ 3\ 4\ 8*/g' nvram.txt
- lfbb
 
Can't we do it rewriting cfe_update.sh as suggested by a dd-wrt forum user?
in short - nope.
just because vlan1ports, vlan2ports, landevs and pmon_ver vars need to be rewriten/expanded with related embedded nvram overflow issue.
nvserial needs sdram_* values be specified in txt file, or nvram header will contain garbage. since txt file contains sdram_* values - they will be added to embedded nvram.
 
in short - nope.
just because vlan1ports, vlan2ports, landevs and pmon_ver vars need to be rewriten/expanded with related embedded nvram overflow issue.
nvserial needs sdram_* values be specified in txt file, or nvram header will contain garbage. since txt file contains sdram_* values - they will be added to embedded nvram.
Ok.

Did you try already my CFE file? Did it work?

- lfbb
 
I am getting confused by this thread. It seems that people that have already converted their cfe to the new one are wanting an original to convert it again.
Is there a reason for this?
I converted mine and it went well, is there a reason to do it again?
Btw if it is needed I kept my original cfe if anyone needs it.
 
Yes I have 1.0.1.3 on mine. I even tried the dd-wrt that fractal made for the 64k version but I'm using RMerlin fw.
 
I will try again with the updated archive.

For step 3, how to I "Place cfe.new back to router"?

3. Flashing new CFE.
Place cfe.new back to router and run:

$ mtd-write -i cfe.new -d pmon


Thanks in advance
 
I am getting confused by this thread. It seems that people that have already converted their cfe to the new one are wanting an original to convert it again.
Is there a reason for this?
I converted mine and it went well, is there a reason to do it again?
Btw if it is needed I kept my original cfe if anyone needs it.

All the talk is about an error found in the update script that passes over information to build the new cfe with all needed nvram code.

The update script has been fixed and users are trying to reupdate their cfe's.

So, even though you've already updated to 1.0.1.3 you should do the whole process again, in your case you already have a copy of the your original 1.0.1.2 cfe so you can skip that part.

Pierino, did you update your CFE successfully?

- lfbb

I've just reupdated my two units without problems but haven't done a nvram wipe, just a reboot after the cfe flash.

ginger@ginger-VirtualBox:~/cfe_n66u-1.0.1.3-3$ ./cfe_update.sh cfe.original cfe.new
[1/4] Dumping default NVRAM settings from your CFE...
nvsimple 0.2b (c) theMIROn
nvram start 0x400
nvram end 0x13d8
nvram len 4036
nvram crc 0x5b
nvram ver 0x01
[2/4] Modifying NVRAM settings (silent step)...
[3/4] Creating new CFE...
4092+0 records in
4092+0 records out
4092 bytes (4.1 kB) copied, 0.00795659 s, 514 kB/s
[4/4] Checking differences between NVRAM from old and new CFE's
4c4
< bl_version=1.0.1.2
---
> bl_version=1.0.1.3
64d63
< pci/1/1/regrev=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.new' is prepared for flash.
 
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