Asus rt-n66r and NVRAM

Discussion in 'Tomato Firmware' started by RonV, Jun 22, 2013.

  1. RonV

    RonV Network Guru Member

    I was able to score anew asus rt-n66r on Newegg for $100. Even though it is labeled n66-r it's really a n66u. How would I know if the CFE is the 32 or 64 for NVRAM. Some sites I have read stated that older n66u's would brick with the 64kb firmware when you exceeded the 32kb. I already flashed it with 1.28.0502.8 MIPSR2Toastman-RT-N K26 USB VPN but if it does support the larger NVRAM I would want to go with that version.

  2. kthaddock

    kthaddock Network Guru Member

  3. RonV

    RonV Network Guru Member

    Thanks for the info. I verified my CFE was but running the script I get a message "system is busy" and it doesn't write the new CFE.


    A bit more research and I think I found out why. Lots of comments that Tomato doesn't allow the pmon partition to be written to. Some people have flashed back to Merlin's firmware to do this procedure and then flashed back. I guess I will just forego the 64K NVRAM access.

    I think the issue is the execution of this command:

  4. jerrm

    jerrm Network Guru Member

    Shibby/Toastman's and I would assume Victek's 64K builds will work with the CFE and allow access to the full 64K. No need to jump through hoops.
  5. Victek

    Victek Network Guru Member

    Sure but better upgrade .. root@RT-N66:/tmp/home/root# strings /dev/mtd0ro | grep bl_version
  6. RMerlin

    RMerlin Network Guru Member

    Personally I recommend that people don't upgrade unless they have a valid reason to. Upgrading the CFE is a risky thing - a failed CFE upgrade will terminally brick your router. No recovery possible without JTAG, and I'm not even sure if anyone got JTAG working on the RT-N66U yet.
  7. RonV

    RonV Network Guru Member

    I agree the update is risky that is why Asus didn't do a field upgrade. I even looked at the script that was at:

    And he has some rudimentary error handing but leaves it up the user to determine if they should commit the CFE that the script created. There is no real way of verifying if the MTD is writeable etc.

    One thing that is skipped is once the MTD write is done it needs to be verified before the next reboot, if it doesn't verify you must immediately restore the old and re-verify the MTD write. If that fails you got a brick on your hands. But you know this used to be the same issues with BIOS on motherboards and other devices. We learned to take acceptable risks.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice