CFE bootloader update

[lfbb]

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

 

[themiron]

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?

uname -a
gcc -dumpmachine
ls /lib/*libc*

 

[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

 

[ryzhov_al]

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.

 

[lfbb]

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

 

[themiron]

Already done it, same errors.

- lfbb

try nvsimple binaries from here
https://wl500g.googlecode.com/files/nvsimple-0.2b.tgz
replace your nvsimple with appropriate arch one from the archive

 

[lfbb]

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

- lfbb

 

[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]

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.

 

[lfbb]

Can I email you my cfe and you return back the updated one? If so please send me your email by PM.

- lfbb

 

[themiron]

Can I email you my cfe and you return back the updated one? If so please send me your email by PM.

- lfbb

ok, np, themiron_at_mail.ru

 

[themiron]

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.

 

[lfbb]

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

 

[themiron]

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.

 

[lfbb]

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

 

[Pierino]

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.

 

[lfbb]

Pierino, did you update your CFE successfully?

- lfbb

 

[Pierino]

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.

 

[jbombs16]

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

 

[Gingernut]

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.