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
No, something went wrong. If script output is different then expected, please do not flash new CFE.
You have 64K, don't worry. This thread is about another method that gives 64K too.Now i'm just asking ..... i have 64K nvram or 32K nvram ?
nvram get bl_version prints variable, stored in NVRAM, you may set any value you want, thats NOT a CFE version.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.
$ strings /dev/mtd0ro | grep bl_version
What's the purpose of this two variables? Can't find nothing on Google.pci/1/1/regrev=3
wait_time=3
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:
You can see that in system log. Search for this string:How can i check the real size of nvram partition?
- lfbb_nvram_init: allocat header: 2183725056, size= 65536
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?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
Which distro are you using?
- lfbb
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.
I downloaded the archive again and it still gives me 'nvsimple 0.2b'. Don't know what's happening here.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
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 ?
# 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
I downloaded the archive again and it still gives me 'nvsimple 0.2b'. Don't know what's happening here.
- lfbb
Terminal said: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.
Terminal said: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.
I did too and this time I got this:
Did it again and it worked:
examples, how to use it:
What's the best option for this situation? Could you rewrite the cfe_update.sh for us?# 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
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.
What's the best option for this situation? Could you rewrite the cfe_update.sh for us?
- lfbb
2. edit nvram.txt as you like (replace bl_version and add odmpid, for example)$ ./nvsimple-32 --extract cfe_old.bin nvram.txt -v
nvram header found:
start 0x400
end 0x13c4
len 4036
crc 0x3f
ver 0x01
4. install modified nvram.txt into new cfe, using offset 0x400 and length 4092 (suitable for 1.0.1.3 cfe)$ cp -f cfe_n66u-1.0.1.3.empty.bin cfe_new.bin
5. do something on your own with cfe_new.bin$ ./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
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...
Still no answer. Can I write back the 1.0.1.2 cfe? So the router be back to original?
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.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!