Asus RT-N66U

Post new topic   This topic is locked: you cannot edit posts or make replies.    DD-WRT Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3 ... 55, 56, 57 ... 167, 168, 169  Next
Author Message
ryzhov_al
DD-WRT Novice


Joined: 17 Jul 2012
Posts: 48
Location: Smolensk, Russia

PostPosted: Tue Jul 24, 2012 11:21    Post subject: Reply with quote
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.

Code:
$ nvram show | grep size:
size: 34868 bytes (30668 left)


Everything is OK.

Here is a part of /dev/mtd3ro dump:
Code:
...
0000FFD0 FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF
0000FFE0 FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF
0000FFF0 FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF
00010000 46 4C 53 48 ¦ 38 88 00 00 ¦ 6A 01 00 00 ¦ 00 00 00 00  FLSH8 ..j.......
00010010 00 00 00 00 ¦ 70 72 69 6E ¦ 74 65 72 5F ¦ 69 66 6E 61  ....printer_ifna
00010020 6D 65 3D 75 ¦ 73 62 00 77 ¦ 6C 31 2E 33 ¦ 5F 77 66 69  me=usb.wl1.3_wfi
00010030 5F 65 6E 61 ¦ 62 6C 65 3D ¦ 30 00 77 6C ¦ 30 2E 31 5F  _enable=0.wl0.1_
...
00018800 69 6D 65 6F ¦ 75 74 3D 33 ¦ 30 20 31 38 ¦ 30 00 77 6C  imeout=30 180.wl
00018810 5F 61 6E 74 ¦ 64 69 76 3D ¦ 2D 31 00 77 ¦ 6C 5F 72 61  _antdiv=-1.wl_ra
00018820 64 69 6F 5F ¦ 70 77 72 73 ¦ 61 76 65 5F ¦ 6C 65 76 65  dio_pwrsave_leve
00018830 6C 3D 30 00 ¦ 00 00 00 00 ¦ FF FF FF FF ¦ FF FF FF FF  l=0.....
00018840 FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF
00018850 FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF
...

Data stored with 64KB offset. 0x00018830 - 0x00010000 = 0x00008830 or 34864 bytes.

_________________
Entware team
Sponsor
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Tue Jul 24, 2012 14:16    Post subject: Reply with quote
ryzhov_al wrote:
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.


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.

ryzhov_al wrote:

Here is a part of /dev/mtd3ro dump:
Code:
...

00010000 46 4C 53 48 ¦ 38 88 00 00 ¦ 6A 01 00 00 ¦ 00 00 00 00  FLSH8 ..j.......




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!
Antilycus
DD-WRT Novice


Joined: 15 Jan 2010
Posts: 45

PostPosted: Tue Jul 24, 2012 15:35    Post subject: Reply with quote
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.
Dark_Shadow
DD-WRT Guru


Joined: 31 Aug 2009
Posts: 2448
Location: Third Rock from the Sun

PostPosted: Tue Jul 24, 2012 16:09    Post subject: Reply with quote
LOM wrote:
Do a long reset and watch what happens..
What exactly is a "Long Reset"? I am running tomato with 64k nvram. I'm not scared to test heheh
_________________
Peacock Thread-FAQ -- dd-wrt Wiki

Testing Multiple Routers -- Bootloader Collection Project -- My Wiki
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Tue Jul 24, 2012 16:27    Post subject: Reply with quote
Antilycus wrote:
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!
RMerlin
DD-WRT User


Joined: 05 Mar 2012
Posts: 273

PostPosted: Tue Jul 24, 2012 17:07    Post subject: Reply with quote
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.


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.
ryzhov_al
DD-WRT Novice


Joined: 17 Jul 2012
Posts: 48
Location: Smolensk, Russia

PostPosted: Tue Jul 24, 2012 17:19    Post subject: Reply with quote
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:
Code:
...
0000FFE0 FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF
0000FFF0 FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF
00010000 46 4C 53 48 ¦ E4 77 00 00 ¦ F2 01 00 00 ¦ 00 00 00 00  FLSH w.. .......
00010010 00 00 00 00 ¦ 70 72 69 6E ¦ 74 65 72 5F ¦ 69 66 6E 61  ....printer_ifna
00010020 6D 65 3D 75 ¦ 73 62 00 77 ¦ 6C 31 2E 33 ¦ 5F 77 66 69  me=usb.wl1.3_wfi
...
000177B0 65 6F 75 74 ¦ 3D 33 30 20 ¦ 31 38 30 00 ¦ 77 6C 5F 61  eout=30 180.wl_a
000177C0 6E 74 64 69 ¦ 76 3D 2D 31 ¦ 00 77 6C 5F ¦ 72 61 64 69  ntdiv=-1.wl_radi
000177D0 6F 5F 70 77 ¦ 72 73 61 76 ¦ 65 5F 6C 65 ¦ 76 65 6C 3D  o_pwrsave_level=
000177E0 30 00 00 00 ¦ FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF  0...
000177F0 FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF ¦ FF FF FF FF
...

Offset still remains on a 0x00010000. So, CFE on RT-N66u do not interfere with linux while using 64KB NVRAM.

_________________
Entware team
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Tue Jul 24, 2012 17:56    Post subject: Reply with quote
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.
You seem to have lost 4KB of variables compared to your previous memory dump, right?

_________________
Kernel panic: Aiee, killing interrupt handler!
RMerlin
DD-WRT User


Joined: 05 Mar 2012
Posts: 273

PostPosted: Tue Jul 24, 2012 18:07    Post subject: Reply with quote
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.
ryzhov_al
DD-WRT Novice


Joined: 17 Jul 2012
Posts: 48
Location: Smolensk, Russia

PostPosted: Tue Jul 24, 2012 18:15    Post subject: Reply with quote
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
RMerlin
DD-WRT User


Joined: 05 Mar 2012
Posts: 273

PostPosted: Tue Jul 24, 2012 18:19    Post subject: Reply with quote
ryzhov_al wrote:

If so, there is no way too see NVRAM right after CFE "defaults" it...


You would need a serial cable for this.
barryware
DD-WRT Guru


Joined: 26 Jan 2008
Posts: 13049
Location: Behind The Reset Button

PostPosted: Tue Jul 24, 2012 18:21    Post subject: Reply with quote
you need to stop the boot via serial.. then dump nvram.. before the firmware is allowed to run.

my 2 cents.. as I have worked on this router and already done the dumps (prolly in this thread), LOM is correct.

Summary.. The cfe has nothing to do with the extended nvram. That is being done in the kernel.

_________________
[Moderator Deleted] Shocked
RMerlin
DD-WRT User


Joined: 05 Mar 2012
Posts: 273

PostPosted: Tue Jul 24, 2012 18:26    Post subject: Reply with quote
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.

http://support.asus.com/Download.aspx?SLanguage=en&m=RT-AC66U&p=11&s=2
ryzhov_al
DD-WRT Novice


Joined: 17 Jul 2012
Posts: 48
Location: Smolensk, Russia

PostPosted: Tue Jul 24, 2012 18:30    Post subject: Reply with quote
barryware wrote:
my 2 cents.. as I have worked on this router and already done the dumps (prolly in this thread), LOM is correct.

Summary.. The cfe has nothing to do with the extended nvram. That is being done in the kernel.
Thank you. And thanks to LOM.
No more questions about CFE.

_________________
Entware team
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Tue Jul 24, 2012 19:29    Post subject: Reply with quote
RMerlin wrote:
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.

http://support.asus.com/Download.aspx?SLanguage=en&m=RT-AC66U&p=11&s=2



Looks like they have got it right this time:

#define NVRAM_SPACE 0x10000


that is for the cfe, 64KB

_________________
Kernel panic: Aiee, killing interrupt handler!
Goto page Previous  1, 2, 3 ... 55, 56, 57 ... 167, 168, 169  Next Display posts from previous:    Page 56 of 169
Post new topic   This topic is locked: you cannot edit posts or make replies.    DD-WRT Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum