Joined: 17 Jul 2012 Posts: 48 Location: Smolensk, Russia
Posted: Tue Jul 24, 2012 11:21 Post subject:
LOM wrote:
The CFE is made for and compiled for 32KB nvram and it can not handle 64KB, it will not find a 64KB nvram since that one starts on a different offset in the last flash block. The cfe does also only allocate 32KB of ram for copying the nvram variables from flash.
May be it's right for RT-N16, but seems not for RT-N66u.
Here is my test:
0) On the stock f/w NVRAM was 32KB, too small for me:
Code:
$ nvram show
...
size: 31403 bytes (1365 left)
1) I've flashed Merlin's build with 64KB NVRAM support (Thanks Eric, great job!). Please note that the only a kernel/userspace change, CFE is not touched.
2) filled NVRAM over 32KB.
3) saved NVRAM and test it integrity after reboot.
The CFE is made for and compiled for 32KB nvram and it can not handle 64KB, it will not find a 64KB nvram since that one starts on a different offset in the last flash block. The cfe does also only allocate 32KB of ram for copying the nvram variables from flash.
May be it's right for RT-N16, but seems not for RT-N66u.
The CFE of RT-N66U is made for 32KB nvram and expects to find the nvram marker at offset 0x18000 in the last flash block.
and there your flash marker is at offset 0x10000 so you have 64KB nvram but the CFE will not find it.
Since it can't find nvram in flash it will instead use the embedded nvram variables contained in the beginning of the CFE.
There is now no correlation at all between what nvram variables the CFE sees and what the firmware sees.
Even more remarkable is that if the CFE decides to repair the nvram in flash then it will erase the whole 128KB flash block, insert the nvram marker at offset 0x18000 and then copy variables from embedded nvram to flash.
Do a long reset and watch what happens.. _________________ Kernel panic: Aiee, killing interrupt handler!
Couldn't someone just re-write the marker into a a different spot? After all, CPU's are stupid. If it's processing a loop until FLSH8 is found, move FLSH8 to the end of the 64k block.
Couldn't someone just re-write the marker into a a different spot? After all, CPU's are stupid. If it's processing a loop until FLSH8 is found, move FLSH8 to the end of the 64k block.
There is a search loop but it doesn't search every byte in flash.
It searches the 4 bytes at start of last 32KB in flash and the loop is only for different flash sizes, ie last 32KB of 2MB flash, last 32KB of 4MB flash, last 32KB of 8MB flash, and so on.
That position, start of last 32KB, is hardcoded in the CFE, and is calculated from a build config value for nvram size. _________________ Kernel panic: Aiee, killing interrupt handler!
The CFE is made for and compiled for 32KB nvram and it can not handle 64KB, it will not find a 64KB nvram since that one starts on a different offset in the last flash block. The cfe does also only allocate 32KB of ram for copying the nvram variables from flash.
That makes sense. I was just wondering why they were bricking RT-N16s when trying to apply the same workaround Asus did in kernel space for the RT-N66U. Might have been something else then.
Joined: 17 Jul 2012 Posts: 48 Location: Smolensk, Russia
Posted: Tue Jul 24, 2012 17:19 Post subject:
LOM wrote:
There is now no correlation at all between what nvram variables the CFE sees and what the firmware sees.
Sure? On my RT-N16 i was able set NVRAM variable from linux, that says CFE to boot kernel with some parameters or point kernel to external rootfs, i.e.
Code:
$ nvram set boot_dev="/dev/scsi/host0/bus0/target0/lun0/part1"
And CFE used it on next boot.
LOM wrote:
Even more remarkable is that if the CFE decides to repair the nvram in flash then it will erase the whole 128KB flash block, insert the nvram marker at offset 0x18000 and then copy variables from embedded nvram to flash.
If so, why CFE do not "correct" "wrong" 64KB NVRAM, saved from linux?
LOM wrote:
Do a long reset and watch what happens..
Oh, my. Thats was a bit tricky: after clean boot Asus's "3 steps Wizard" starts. If you complete all three steps then NVRAM will be rewrited from booted linux. So i:
1) caught CFE Web-interface and cleaned NVRAM from here,
2) allowed the system to boot,
3) jumped from Wizard's html page directly to "Run command" page,
4) Started telnetd and dumped NVRAM to USB drive:
Of course it is, you let the firmware boot and it recreates it there if it isn't there after boot.
You seem to have lost 4KB of variables compared to your previous memory dump, right? _________________ Kernel panic: Aiee, killing interrupt handler!
The RT-AC66U also has the NVRAM_64K=y build time flag set in the firmware source. That seems to imply that Asus went the same route with the RT-AC66U as with the RT-N66U.
We'll have to wait for those routers to hit the street to know for sure if they are 100% relying on the kernel code, or they actually have a 64KB-aware CFE in place in addition to that.
Joined: 17 Jul 2012 Posts: 48 Location: Smolensk, Russia
Posted: Tue Jul 24, 2012 18:15 Post subject:
LOM wrote:
ryzhov_al wrote:
Offset still in a 0x00010000.
Of course it is, you let the firmware boot and it recreates it there if it isn't there after boot.
If so, there is no way too see NVRAM right after CFE "defaults" it...
LOM wrote:
Even more remarkable is that if the CFE decides to repair the nvram in flash then it will erase the whole 128KB flash block, insert the nvram marker at offset 0x18000 and then copy variables from embedded nvram to flash.
Do a long reset and watch what happens..
...and there is no way to check it. Nothing happens:)
LOM wrote:
You seem to have lost 4KB of variables compared to your previous memory dump, right?
Right. Previous memory dump contained all my settings, last one is clean default NVRAM. _________________ Entware team
If you really want to start digging into this, the latest GPL release for the RT-AC66U contains some CFE-related source code in the release/src-rt-6.x/cfe/ directory.
If you really want to start digging into this, the latest GPL release for the RT-AC66U contains some CFE-related source code in the release/src-rt-6.x/cfe/ directory.