CFE bootloader update

[lfbb]

No, something went wrong. If script output is different then expected, please do not flash new CFE.

I flashed it and the only thing I notted is I can't access CFE miniWeb Server.

- lfbb

 

[Lost_Animal]

Hello all there...

ASUS claimed that on new FWs got fixed the 64K issue.
I am using the Merlin's latest release btw with 64K nvram.

But when i use nvram get bl_version command, still gives me 1.0.1.2 version of cfe.

Now i'm just asking ..... i have 64K nvram or 32K nvram ?

Maybe ASUS upgraded the nvram to 64K on old 1.0.1.2 cfe release ?

OMG what a mess !!!!

I really don't want to brick my router upgrading manually the CFE.

 

[lfbb]

Now i'm just asking ..... i have 64K nvram or 32K nvram ?

You have 64K, don't worry. This thread is about another method that gives 64K too.

- lfbb

 

[ryzhov_al]

ASUS claimed that on new FWs got fixed the 64K issue.
I am using the Merlin's latest release btw with 64K nvram.

But when i use nvram get bl_version command, still gives me 1.0.1.2 version of cfe.

nvram get bl_version prints variable, stored in NVRAM, you may set any value you want, thats NOT a CFE version.

You may look into CFE itself to get real version:

$ strings /dev/mtd0ro | grep bl_version

 

[lfbb]

pci/1/1/regrev=3
wait_time=3

What's the purpose of this two variables? Can't find nothing on Google.

- lfbb

 

[Lost_Animal]

nvram get bl_version prints variable, stored in NVRAM, you may set any value you want, thats NOT a CFE version.

You may look into CFE itself to get real version:

Thanks for your quikck reply.....

The printout of strings /dev/mtd0ro | grep bl_version command, still gives me the same as nvram bl_version=1.0.1.2.

I assume that i still have the old 32k nvram limit or ASUS done some magic tricks to have 64k nvram partition without change the real bl_version srting ?

How can i check the real size of nvram partition ?

 

[lfbb]

How can i check the real size of nvram partition?

You can see that in system log. Search for this string:

_nvram_init: allocat header: 2183725056, size= 65536

- lfbb

 

[lfbb]

I think I found the problem with the script. Take a look at this image which shows 'nvram.txt' and 'cfe_new.bin' side by side.

As you can see there are parts missing from the cfe file, the 'pci/1/1/regrev=3' is incomplete and the other two simply do not appear. The code that handles the creation of the updated cfe is this:

echo [3/4] Creating new CFE...
start=1024
count=4092
dd if=/dev/zero of=$2 bs=1 seek=$start count=$count
./nvserial -i cfe_n66u-1.0.1.3.empty.bin -o $2 -b $start -c $count nvram.txt

The bug is in this code, but I'm not an expert in scripts and C language, etc. I hope some other experienced user finds a solution. In the mean time I have a question... Can we hack the (bad) updated cfe file with an Hex editor and add the missing variables?

Last question... I can't acess the CFE miniWeb Server. The 3 missing highlighted variables have something to do with it?

- lfbb

 

[Koenig]

Which distro are you using?

- lfbb

Linux Mint 14 32bit this time.

I can see a difference in your log and mine... This line:
nvsimple 0.2 (c) theMIROn <-- From my log
nvsimple 0.2b (c) theMIROn <-- Your log

EDIT: Downloaded it again and now I get same output as you. Might the b suggest a slightly newer script...?

Is that the updated tool package?

Looks like the previous version of nvsimple to me, maybe the reason for a different output than ifbb's and mine.

Yes it is the updated package in the original package this line was not included:
nvsimple 0.2 (c) theMIROn

For reference look at my log posted here: Post 26

EDIT: As a side note I must say I like Mint (Cinnamon) a little better than Ubuntu, feels somewhat "snappier" and got a look that I fell for.

 

[lfbb]

I can see a difference in your log and mine... This line:
nvsimple 0.2 (c) theMIROn <-- From my log (tool downloaded and tried this very day still gives me this result)
nvsimple 0.2b (c) theMIROn <-- Your log

I downloaded the archive again and it still gives me 'nvsimple 0.2b'. Don't know what's happening here.

- lfbb

 

[RMerlin]

Thanks for your quikck reply.....

The printout of strings /dev/mtd0ro | grep bl_version command, still gives me the same as nvram bl_version=1.0.1.2.

I assume that i still have the old 32k nvram limit or ASUS done some magic tricks to have 64k nvram partition without change the real bl_version srting ?

How can i check the real size of nvram partition ?

The partition has always been 64 KB. The original bug was that the CFE (the boot loader) only initialized 32 KB of it, so the firmware was only seeing 32 KB.

Asus devised a fix in the firmware that would basically move the signature 32 KB further down, to let the firmware address the whole 64 KB.

However, firmwares that do NOT have that fix in their code will only be able to use what the CFE sets up for them: 32 KB. This is the case for DD-WRT, for example.

The CFE update fixes the nvram partition initialization so it sets up the whole 64 KB, meaning that all firmwares even without the fix in the firmware itself will be able to see and use the whole 64 KB.

So if you are using either Asuswrt, Asuswrt-Merlin or Tomato, you do not have to worry about this: your firmware is already using 64 KB of NVRAM.

 

[themiron]

okie, folks, here's new solution
https://wl500g.googlecode.com/files/nvsimple-0.3d.tar.gz inc. source, x86, x64 and mipsel binaries
examples, how to use it:

# show help
./nvsimple -h
# extarct nvram from flash to text file with offset autodetection (on router)
./nvsimple -e /dev/mtd0 nvram.txt -v
# extarct nvram from binary cfe to text file with offset autodetection
./nvsimple -e cfe_old.bin nvram.txt -v
# extarct nvram from binary cfe to text file with exact offset specified
./nvsimple -e cfe_old.bin nvram.txt -v -o 1024
# install nvram from text file into existing binary cfe at offset with max length
./nvsimple -i nvram.txt cfe_new.bin -v -o 1024 -l 4092

calculations seems ok comparing nvserial, not well tested.
have fun, but handle with care.

 

[Koenig]

I downloaded the archive again and it still gives me 'nvsimple 0.2b'. Don't know what's happening here.

- lfbb

I did too and this time I got this:

koenig@Virtualbox-Mint ~/N66U/Updated.CFE.Tools.3 $ ./cfe_update.sh cfe.original cfe.new
[1/4] Dumping default NVRAM settings from your CFE...
nvsimple 0.2b (c) theMIROn
can't open file: No such file or directory <---- What is this now (My bad, forgot to put cfe.original in that directory
[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,031986 s, 128 kB/s
[4/4] Checking differences between NVRAM from old and new CFE's
0a1,5
> odmpid=ASUS
> sdram_config=0x0000
> sdram_init=0x0419
> sdram_ncdl=0x00000000
> sdram_refresh=0x8040
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.

Did it again and it worked:

koenig@Virtualbox-Mint ~/N66U/Updated.CFE.Tools.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 0x1388
nvram len 3956
nvram crc 0xc2
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,0400025 s, 102 kB/s
[4/4] Checking differences between NVRAM from old and new CFE's
1c1
< bl_version=1.0.1.2
---
> bl_version=1.0.1.3
16a17
> odmpid=ASUS
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.

 

[themiron]

I did too and this time I got this:
Did it again and it worked:

forget about nvsimple 0.2*, unfortunately, it's buggy.

 

[lfbb]

examples, how to use it:

# show help
./nvsimple -h
# extarct nvram from flash to text file with offset autodetection (on router)
./nvsimple -e /dev/mtd0 nvram.txt -v
# extarct nvram from binary cfe to text file with offset autodetection
./nvsimple -e cfe_old.bin nvram.txt -v
# extarct nvram from binary cfe to text file with exact offset specified
./nvsimple -e cfe_old.bin nvram.txt -v -o 1024
# install nvram from text file into existing binary cfe at offset with max length
./nvsimple -i nvram.txt cfe_new.bin -v -o 1024 -l 4092

What's the best option for this situation? Could you rewrite the cfe_update.sh for us?

- lfbb

 

[Koenig]

okie, folks, here's new solution
https://wl500g.googlecode.com/files/nvsimple-0.3d.tar.gz inc. source, x86, x64 and mipsel binaries
examples, how to use it:



calculations seems ok comparing nvserial, not well tested.
have fun, but handle with care.

I tried extracting from binary cfe, but it doesn't really add up, when opening the original cfe in a hex-editor the first text-line after "FLSH" is:
boardtype=0xF5B2

But when dumping these lines comes in first:
sdram_init=0x0000
sdram_config=0x0000
sdram_refresh=0x0000
sdram_ncdl=0x00000000

It seems it does something more than just dump the settings...

 

[themiron]

What's the best option for this situation? Could you rewrite the cfe_update.sh for us?

- lfbb

assuming you have 1.0.1.2 cfe in cfe_old.bin:
1. extract nvram from the origianl cfe to nvram.txt, using offset autodetection

$ ./nvsimple-32 --extract cfe_old.bin nvram.txt -v
nvram header found:
start 0x400
end 0x13c4
len 4036
crc 0x3f
ver 0x01

2. edit nvram.txt as you like (replace bl_version and add odmpid, for example)
3. prepare new 1.0.1.3 cfe with no nvram embedded

$ cp -f cfe_n66u-1.0.1.3.empty.bin cfe_new.bin

4. install modified nvram.txt into new cfe, using offset 0x400 and length 4092 (suitable for 1.0.1.3 cfe)

$ ./nvsimple-32 --install nvram.txt cfe_new.bin -o 0x400 -l 4092 -v
nvram header created:
start 0x400
end 0x13c8
len 4040
crc 0xcc
ver 0x01

5. do something on your own with cfe_new.bin

I tried extracting from binary cfe, but it doesn't really add up, when opening the original cfe in a hex-editor the first text-line after "FLSH" is:
boardtype=0xF5B2

But when dumping these lines comes in first:
sdram_init=0x0000
sdram_config=0x0000
sdram_refresh=0x0000
sdram_ncdl=0x00000000

It seems it does something more than just dump the settings...

yes, these sdram* values are reserved in header and may not appear in embedded nvram, if not used.

 

[Pierino]

Still no answer. Can I write back the 1.0.1.2 cfe? So the router be back to original?

 

[Koenig]

Still no answer. Can I write back the 1.0.1.2 cfe? So the router be back to original?

Yes, no problems

 

[jakey]

assuming you have 1.0.1.2 cfe in cfe_old.bin:
1. extract nvram from the origianl cfe to nvram.txt, using offset autodetection

2. edit nvram.txt as you like (replace bl_version and add odmpid, for example)
3. prepare new 1.0.1.3 cfe with no nvram embedded

4. install modified nvram.txt into new cfe, using offset 0x400 and length 4092 (suitable for 1.0.1.3 cfe)

5. do something on your own with cfe_new.bin



yes, these sdram* values are reserved in header and may not appear in embedded nvram, if not used.

Thanks for this, makes the whole process a lot easier.

For the novices here like me using this method you can do the whole job on-board the router itself from windows with the likes of putty and an ftp client using the mipsel nvsimple, no need for Linux installation.

I've yet to write the updated cfe back because I use Tomato and that doesn't allow writing to the cfe partition afaik so for me it means installing original firmware.