OpenWrt Forum Archive

Topic: TP-Link TL-WR1043NDv1(AR9132) overclocking

The content of this topic has been archived on 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I tested and overclocked the TL-WR1043ND Router.
Basically I integrated the changes and fix the checksum on the main tplink factory images. (with uboot)
The max stable clock on my modified WR1043NDv1 (RAM Modded to 64MB) is 440MHZ.
Don't bother trying larger values because I already did.
At 460MHZ it fried my Serial Port (yes my serial port is no longer working)
At 450MHZ it crashes on heavy Network Traffic.
Luckily I modified the latest original tp-link images with the tftp to 192.169.0.66 recovery hence I saved it via blind tftpboot.
This mod also has the new tftp recovery feature.
To use it if you are already using TP-Link firmware simply flash it as you would for a firmware upgrade
If you are on OpenWRT use the sysupgrade_to_factory then flash the overclock_firmware then flash back openwrt factory.
More information here
I made 3 versions 440_440_220, 430_430_215 and 420_420_210.
I made the images available here
I already benchmarked the openssl performance and placed on the wiki.

(Last edited by alphasparc on 1 Aug 2014, 04:53)

Thanks for doing a u-boot mod for ar9132 400 mhz atheros.
I have a g300nh with the same cpu and was wondering what the performance could be.
I wonder if it is the chip itself or the buffalo with ar9132 could do better?

It has alway been about the chip.
My unit has been RAM Modded to a DDR400 (hence 200Mhz) 64MB chip
I am not sure how the original 32MB units would behave.
The PLL register is 0x18050000
Original value is 50 => 0101 0000 => 2^4+2^6 => 80 => 80*5 = 400Mhz
Therefore 420Mhz => 84*5 => 2^2 + 2^4 + 2^5 => 0101 0100 => 54
Therefore 440Mhz => 88*5 => 2^3 + 2^4 + 2^5 => 0101 1000 => 58
Basically I compiled the uboot with different frequency the check the changed bits.
After I know the bit position I modified TP-Link firmware with bootloader (because it is uncompressed uboot) then fix the checksum.
The reason why I decided to mod tp-link firmware is because
1)TP-Link don't provide the new source for the tftp 192.168.0.66 recovery we want the recovery
2)WR1043ND bootloader is serial locked means you cannot modify the bootloader via Serial Console but tp-link firmware allows it and is more convienient.

(Last edited by alphasparc on 26 May 2014, 17:11)

alphasparc wrote:

I already benchmarked the openssl performance and placed on the wiki.

Thanks for your work!

Though I couldn't find the benchmarks on either the OpenWRT wiki or your blog.
Think you could upload them somewhere?

It is on the wiki (OpenSSL Benchmark) fourth row from the top as of this post.

(Last edited by alphasparc on 28 Jun 2014, 17:20)

robnitro wrote:

Thanks for doing a u-boot mod for ar9132 400 mhz atheros.
I have a g300nh with the same cpu and was wondering what the performance could be.
I wonder if it is the chip itself or the buffalo with ar9132 could do better?

If you can pass me a copy of the bootloader I can patch it for you, but I can't test it since I do not have the device.

I saw you also posting on this thread about overclocking.

https://forum.openwrt.org/viewtopic.php?id=38777

I was wondering if you were never able to get the kernel-entry-init.h mod to work for you.  I assume not based on what you did here.

I am using AR7241 and when I try to write any value, even the standard value, Openwrt wont start.

Is this the same issue you saw?

Thanks for any advice as I really need to get something to underclock the device I am using, and there is nothing I can find besides the above post that seemed promising.

Thanks.

Here is what will definitely work.
Download the GPL tarball.
Build the uboot 2 times with 2 different clock value.
The file containing the clock register is ar7240_soc.h
Find the hex value difference.
Find the calculation required for different clocks.
Find the hexvalue offset responsible for the clock difference.
Backup your uboot
edit it using hexeditor with the modified hexadecimal value
Flash it back to the uboot.
If you are not confident of doing it you can pass me the uboot.

(Last edited by alphasparc on 29 Dec 2014, 07:06)

Thanks for the response.

The issue with this approach is we need to make this change on 100+ routers.

My understanding (which is limited), is that the u-boot partition contains information specfic to each router, i.e. MAC address.

So I don't think this approach would work for us unfortunately as would have to "patch" each router by hand.

I am unlear as to why the kernel init change would work on some routers, but not on others, but I am no MIPS expert.

The factory unique MAC address of each unit is in the art partition not the boot loader code.

mk24 wrote:

The factory unique MAC address of each unit is in the art partition not the boot loader code.

The MAC for the WLAN is in the ART, but I thought the MAC for the Ethernet is in U-Boot.

I am a bit confused by all this however....

It seems the first 64k is for U-Boot, the 2nd 64k is router specific (maybe u-boot environment as I have seen that term used also).  But when I compile and read about u-boot, they all talk about a 128k bin file.

Can I replace just the first 64k and leave the 2nd 64k alone?

There is an image about halfway down I am referring to.  It shows the flash layout.

"U-Boot code takes up to 64 KiB (free flash cells should be stored 0xFF), environmental variables (ie. Env) is sewn in the code (ie. Hard coded), and another 64 KiB flash memory are only 2/3 value (the MAC address of the router model and possibly pin for WPS). The rest of the area is empty! The following chart should explain the structure of the data in the flash memory, and it is worth to him carefully."

http://translate.google.com/translate?h … rev=search

Yes that is true I checked on a MR3420v1 and it is as the page you found described.  Except that the factory bootloader is much larger than 64K, it is almost all of both pages.  I have a Netgear which has the MAC addresses in the ART but apparently this is a TP-Link thing and not necessarily the same for all Atheros based routers.

You could write a script that extracts the factory data by reading the stock mtd0 and then stripping off all but the very end with dd.  Then that file would be cat'd to the end of a prepared file which is the new bootloader code padded out to almost 128k so the final result is the proper size to flash.

LZMA compressed boot loader is less than 64K hence most you need to overwrite 64K
Non LZMA compressed boot loader while bigger than 64K is definitely a lot smaller than 128K
You just need to mind the offset and the difference is definitely only a hex value and the offset is at a early section of the uboot.

Thanks for sticking with me here.

How do I know if the boot loader is LZMA compressed or not?  Where do I look to determine this?  I dont see anything in the serial console stating yes or no.

Also, although the router I am working on is based on MR3220V1, it is not a TP-Link router.  So I am not 100% sure if the u-boot is the same as GPL-TPLink, and in turn, if I compile U-Boot from TPLink's website, will it be the same as what I have.  I guess only one way to find out......

I will try to compile u-boot and compare to whats on the router and see what I find.  Will likely need some more help sorting the 2 .bin's out.

On the router, make a copy of your bootloader partition to a file:
dd if=/dev/mtd0 of=/tmp/u-boot.bin

Then scp this file to your PC and examine with hex editor.  An uncompressed u-boot will have readable text in it like the help text and error messages.  Look for your MAC address in the place the web page talks about.

Its not compressed.  Thanks for the pointer.

The mac address is at 0x0001FC00, as stated on the web page.

After it, is all FF, unused.  The other values are not present, which is fine.


If I compile a u-boot, can I make it only big enough to write to just before 0x0001FC00, and in turn leave everything after intact and simply replace the first part with the modified U-Boot?

The flash chip doesn't let you erase part of a 64k block.  If you're going to change anything in that second block (i.e. the new u-boot is larger than 64k) you have to prepare the whole block in a file and then write it.

Hi the reason why I suggested modifying the hex value instead of using the uboot compiled is that you can never be sure if it boots.
When you diff the uboot with different clock values you will only locate a few offset difference (minus the timestamp so compile the uboot in quick succession) and that is the value that sets the clock.
And using the series of hex value pattern you can locate the hex value in the original uboot.
Also this solves the problem of size truncation.


Fastest way backup uboot, mod hex value, flash back.
All your Mac Address, WPS and Model Number will be retained.

(Last edited by alphasparc on 30 Dec 2014, 11:12)

Thanks for the help.

I have 3 images from TPlink compiled with different clock speeds for AR7241, and have been able to locate the offset that changed (28 (400mhz) -> 1c (280mhz) -> 1a (260mhz), offset 0x0000d4fb).  This is compiled with 8meg flash set in the source code, not sure if that will matter in case this can help someone in the future.  The compiled u-boot is 124k.

And the different offset values match the values in the source code so it seems to be accurate.  I have no other differences in the 3 images.

I found the same sequence of hex from the 400mhz TPlink u-boot in the original u-boot from the router, and will change the value to one of the 2 other values.


Here is my only worry.

If something goes wrong, the router will be completely bricked this way, correct?  Since I am changing u-boot, if it fails to start at that clock speed for some reason, I assume u-boot will not start either?  or is that incorrect, and u-boot will be OK, but Linux/Openwrt may not start.

Thanks again before I try this.

(Last edited by JohnV on 30 Dec 2014, 22:38)

Messing with uboot always meant that if you did it wrongly it will not boot and you need a external flash programmer to recover.

Now I am at a loss.

I updated the u-boot, confirm that the byte has been changed, and when I boot the router, it remains in 400mHz, the default speed.

Here is what I have:

This is from TPLink U-Boot compiled for 400 mhz:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

0000D4F0   03 19 C0 24 3C 19 00 04  37 39 08 28 03 19 C0 25     À$<   79 (  À%
0000D500   AD F8 00 00 3C 0F B8 05  8D F8 00 00 3C 19 FF FE   ø  < ¸  ø  < ÿþ
0000D510   37 39 FF FF 03 19 C0 24  AD F8 00 00 10 00 00 33   79ÿÿ  À$ø     3
0000D520   00 00 00 00 00 00 00 00  3C 0F B8 05 8D F8 00 00           < ¸  ø  
0000D530   3C 19 FD FF 37 39 FF FF  03 19 C0 24 AD F8 00 00   < ýÿ79ÿÿ  À$ø  
0000D540   3C 0F B8 05 8D F8 00 00  3C 19 FF B3 37 39 C0 00   < ¸  ø  < ÿ³79À 
0000D550   03 19 C0 24 3C 19 00 04  37 39 08 28 03 19 C0 25     À$<   79 (  À%
0000D560   AD F8 00 00 3C 0F B8 05  8D F8 00 00 3C 19 FF FE   ø  < ¸  ø  < ÿþ
0000D570   37 39 FF FF 03 19 C0 24  AD F8 00 00 10 00 00 1B   79ÿÿ  À$ø      
0000D580   00 00 00 00 00 00 00 00  3C 0F B8 05 8D F8 00 00           < ¸  ø  
0000D590   3C 19 FD FF 37 39 FF FF  03 19 C0 24 AD F8 00 00   < ýÿ79ÿÿ  À$ø  
0000D5A0   3C 0F B8 05 8D F8 00 00  3C 19 FF B3 37 39 C0 00   < ¸  ø  < ÿ³79À 

This is from TPLink U-Boot compiled for 280 mhz:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

0000D4F0   03 19 C0 24 3C 19 00 04  37 39 08 1C 03 19 C0 25     À$<   79    À%
0000D500   AD F8 00 00 3C 0F B8 05  8D F8 00 00 3C 19 FF FE   ø  < ¸  ø  < ÿþ
0000D510   37 39 FF FF 03 19 C0 24  AD F8 00 00 10 00 00 33   79ÿÿ  À$ø     3
0000D520   00 00 00 00 00 00 00 00  3C 0F B8 05 8D F8 00 00           < ¸  ø  
0000D530   3C 19 FD FF 37 39 FF FF  03 19 C0 24 AD F8 00 00   < ýÿ79ÿÿ  À$ø  
0000D540   3C 0F B8 05 8D F8 00 00  3C 19 FF B3 37 39 C0 00   < ¸  ø  < ÿ³79À 
0000D550   03 19 C0 24 3C 19 00 04  37 39 08 28 03 19 C0 25     À$<   79 (  À%
0000D560   AD F8 00 00 3C 0F B8 05  8D F8 00 00 3C 19 FF FE   ø  < ¸  ø  < ÿþ
0000D570   37 39 FF FF 03 19 C0 24  AD F8 00 00 10 00 00 1B   79ÿÿ  À$ø      
0000D580   00 00 00 00 00 00 00 00  3C 0F B8 05 8D F8 00 00           < ¸  ø  
0000D590   3C 19 FD FF 37 39 FF FF  03 19 C0 24 AD F8 00 00   < ýÿ79ÿÿ  À$ø  
0000D5A0   3C 0F B8 05 8D F8 00 00  3C 19 FF B3 37 39 C0 00   < ¸  ø  < ÿ³79À 

The offset that changed is D4FB.  Changes from x28 to x1c.  This matches the source code.

Note however, that D4F0 and D550 are duplicate entries on the 400Mhz compile.  And the data below.  However, only the offset at D4FB is changing from comple to compile.

This is from my router's u-boot:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

0000D270   03 19 C0 24 3C 19 00 04  37 39 08 28 03 19 C0 25     À$<   79 (  À%
0000D280   AD F8 00 00 3C 0F B8 05  8D F8 00 00 3C 19 FF FE   ø  < ¸  ø  < ÿþ
0000D290   37 39 FF FF 03 19 C0 24  AD F8 00 00 10 00 00 33   79ÿÿ  À$ø     3
0000D2A0   00 00 00 00 00 00 00 00  3C 0F B8 05 8D F8 00 00           < ¸  ø  
0000D2B0   3C 19 FD FF 37 39 FF FF  03 19 C0 24 AD F8 00 00   < ýÿ79ÿÿ  À$ø  
0000D2C0   3C 0F B8 05 8D F8 00 00  3C 19 FF B3 37 39 C0 00   < ¸  ø  < ÿ³79À 
0000D2D0   03 19 C0 24 3C 19 00 04  37 39 08 28 03 19 C0 25     À$<   79 (  À%
0000D2E0   AD F8 00 00 3C 0F B8 05  8D F8 00 00 3C 19 FF FE   ø  < ¸  ø  < ÿþ
0000D2F0   37 39 FF FF 03 19 C0 24  AD F8 00 00 10 00 00 1B   79ÿÿ  À$ø      
0000D300   00 00 00 00 00 00 00 00  3C 0F B8 05 8D F8 00 00           < ¸  ø  
0000D310   3C 19 FD FF 37 39 FF FF  03 19 C0 24 AD F8 00 00   < ýÿ79ÿÿ  À$ø  
0000D320   3C 0F B8 05 8D F8 00 00  3C 19 FF B3 37 39 C0 00   < ¸  ø  < ÿ³79À 

This matches the 400mhz compile I did, but the offset is at D27B.

I changed this value to "1c".  And wrote the u-boot, and rebooted.

Dmesg:

[    0.000000] Linux version 3.10.49 (xxx@xxx-VirtualBox) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r371) ) #22 Mon Dec 29 13:25:06 TAHT 2014
[    0.000000] MyLoader: sysp=82408001, boardp=21452249, parts=a06c2203
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 00019374 (MIPS 24Kc)
[    0.000000] SoC: Atheros AR7241 rev 1
[    0.000000] Clocks: CPU:400.000MHz, DDR:400.000MHz, AHB:200.000MHz, Ref:5.000MHz

This is the memory location for the registers that control the clock speed, based on other threads:

root@x:~# io -4 0x18050000
18050000:  00040828

As you can see, the value is still 28........????

I then checked the byte from the u-boot that is on the flash:

root@x:~# cat /dev/mtd0 > /tmp/uboot_backup.bin
root@x:~# tmp=$(dd if=/tmp/uboot_backup.bin bs=1 skip=53883 count=1)
1+0 records in
1+0 records out
root@x:~# tmp=$(printf "%02x\n" "'$tmp")
root@x:~# echo $tmp
1c

And the value is as it should be, 1c.

Can anyone check they hex dump from u-boot against the offset I am changing, to confirm....

All very strange!

(Last edited by JohnV on 31 Dec 2014, 18:44)

The assumption you are making is that the TP-Link uboot source compiles to the same uboot as your device or there are many instance of the same byte pattern and you replaced only 1.
I remember my uboot on MR3420v1 (AR7241) has 2 instance of the byte pattern at very close offsets and I replaced both.

(Last edited by alphasparc on 31 Dec 2014, 18:45)

Thanks for the advice.

I changed it in both offest locations, and it is working now.


Still seems odd to me that the TP-Link compile only changes it in one place, but on my u-boot it needs it in both places.  Obviously there is some differnce I am not aware of.

Regardless, thank you for your help and time on this, now to see if it actually allows the CPU to run at a lower temperature, which is my actual goal.

Hi,does your uboot support 16MB flash such as mx25L128? and if it is have httpd ?

(Last edited by Davidwei on 20 Feb 2015, 02:07)

The discussion might have continued from here.