Overclocking the Toshiba AC100

I mentioned in a recent post that I have put together an overclocking kernel for the AC100. Now that I have dialed it in completely and verified the stability and required voltages on all of my AC100s, it is time to share the details.

Before I continue the usual disclaimer applies: if you are doing this – on your head be it. I am not responsible for what you do to your hardware and am making no promises that doing this will not damage it, destroy it, shorten it’s life, or cause you injury in some way. And it most definitely WILL void your warranty.

Software-only OC

This part you can achieve purely by modifying the kernel. It is assumed here that the kernel you are using is Marc Dietrich’s 2.6.38 ChromeOS kernel modified specifically for the AC100. You will need the following patches:

1) Toshiba AC100 Tegra2 Overclocking Patch, the common part – this only adds additional clock speeds and makes an increased range of voltages available. You will need to apply this regardless of whether you are aiming for a 1200MHz software-only overclock or a full overclock to 1404MHz which requires a hardware modification to improve the CPU core cooling. This patch doesn’t apply any overclocking on it’s own and shouldn’t break any existing functionality of the kernel if applied on it’s own.

2.1) AC100 1200MHz Patch – this only adds a 1200MHz mode on top of the standard 1000MHz mode. I tested this on 5 AC100s so far and have found no stability problems with the settings in the patch. Temperatures are only slightly higher than at 1000MHz and there is no need to open the AC100 to modify it.

2.2) AC100 1404MHz Patch – This adds additional overclock speeds: 1248MHz, 1352MHz, and 1404MHz. For this you WILL need to modify your AC100.

You can only apply one of the latter two patches – either the 1200MHz patch or the 1404MHz patch.

Both of these patches only apply to the two SKUs of Tegra2 found in the AC100:

Tegra Revision: A02 SKU: 8 CPU Process: 2 Core Process: 1 Speedo ID: 0; these are found in the models with Micron memory. These run at lower voltages (975mV@1000MHz).

Tegra Revision: A02 SKU: 8 CPU Process: 1 Core Process: 1 Speedo ID: 0; these are found in the models with Hynix memory. These seem to run at higher voltages (1100mV@1000MHz, but they also, bizzarely, often run cooler.

If your AC100 has a different SKU, please leave a comment with the details.

Hardware Modification to Improve Cooling

The modification is very simple. The standard cooling setup inside in AC100 is no good. It’s fine for the standard clock speeds, since the CPU will never get hot, but for anything significantly faster it desperately needs to be improved. The standard setup only has some thermal putty between the CPU core and the spring plate above it.

You will need:

1) Good thermal grease (I used Arctic Silver 5)

2) Good thermal epoxy (I used Arctic Silver Thermal Adhesive)

3) 2 copper shims, each measuring 25mm x 25mm x 1.2mm

Take a look at this excellent, detailed article on how to disassemble the bottom half of the AC100.

Once you get to the CPU, remove the thermal putty and VERY carefully clean up the top of the CPU core. I cannot stress enough the amount of care you have to take. There are tiny capacitors on top of the CPU package and if you damage any of them it will never work again.

Toshiba AC100 CPU Core

Toshiba AC100 CPU Core

Then apply some thermal compound (not adhesive!) to the top of the CPU.

Tegra2 CPU Core in Toshiba AC100 with thermal compound applied

Tegra2 CPU Core in Toshiba AC100 with thermal compound applied

Look at the underside of the panel to which the spring plate is attached. Clean up the underside of the spring plate. Mix up enough thermal epoxy to do two copper shims. Use it to attach a copper shim to the the underside of the spring plate. I have found the position in the following photo to be optimal.

Toshiba AC100 CPU-side shim in place on the spring plate

Toshiba AC100 CPU-side shim in place on the spring plate

Before the epoxy starts to set use it to glue the other copper shim to the top of the spring plate.

Keyboard side copper shim on the Toshiba AC100

Keyboard side copper shim on the Toshiba AC100

Apply good pressure to the two copper shims and wait for the adhesive to set. It typically takes about 5 minutes from the point of mixing, so you have to work reasonably quickly.

Replace the top half of the AC100 casing, make sure all the clips have clicked into position, and apply reasonable pressure to the shim you can see to make sure that the stack is making good thermal contact with the CPU.

Apply a reasonably generous amount of thermal grease (not adhesive!) to the top of the copper shim. This will transfer heat to the underside of the keyboard. Re-attach the ribbon cables and clip the keyboard back into position. Apply a bit of pressure to the are on top of where the shim is to make sure the thermal compound makes good contact.

Re-fit the 5 screws on the bottom of the AC100, and the two screws at the back that hold the back of the keyboard in place.

Power back up and verify that the temperatures under load are now at least 10-20C lower. Apply patches 1) and 2.2), and verify the temperatures under load.

Overheat Protection Shutdown

AC100 has a thermal protection shutdown feature built in. If the CPU core hits 100C, the machine will power off and will not let you power it back on until the CPU temperature drops below 90C. If you find that you are getting over 90C under load, there is a 3rd, still somewhat experimental solution to this.

The idea is simple. We have a userspace daemon that checks the temperature once per second and if the temperature exceeds a certain configurable threshold (default is 90C), it will reduce the maximum clock speed to a configurable level (default is 1000MHz). Once the temperature drops below the threshold, the daemon will re-enable the configurable top speed (default is whatever the kernel says is the maximum available, in the case of patch 3 that is 1456MHz).

The concept of the throttling daemon is similar to Intel’s Turbo Boost technology in the Core i series of processors. When the thermal limits allow, it can boost the speed, as long as the CPU doesn’t overheat. It took me a while to come up with a name for this daemon, but seen as it is for an Nvidia chip, and considering that they used to write their name on the logo as nVIDIA, I called this daemon nITRO. You can download nITRO here.

In the ideal world, the thermal throttling could more cheaply be done in the kernel. The current version of nITRO is written in bash and typically consumes approximately 0.3% of CPU, whereas the kernel implementation would be almost free (assuming you consider 0.3% to be expensive). Unfortunately, the thermal throttling for Tegra in the current ChromeOS kernel is stubbed out at the moment.

If you experience a stability issue that you can verifiably and repeatably pin on the overclock, please post what you did to create the load that causes the stability problem and I will try to reproduce it and adjust the patches accordingly.

7 thoughts on “Overclocking the Toshiba AC100

  1. Pingback: Alleviating Memory Pressure on Toshiba AC100 | altechnative.net

  2. Very cool info +)

    but for 3.0.8, at least for now to apply patch, you need to change in this line 1275 to 1300

    -static struct regulator_init_data sm0_data = REGULATOR_INIT(sm0, 725, 1275, true);

    maybe i am not completely understand all data in dvfs_cpu structure in tegra2_dvfs.c, but i’ve made some experiments with this data:

    CPU_DVFS("cpu", MHZ, 314, 314, 314, 456, 456, 456, 608, 608, 608, 760, 817, 817, 912, 1000),
    CPU_DVFS("cpu", MHZ, 314, 456, 456, 618, 618, 770, 827, 922, 1000, 1248, 1248, 1248, 1352, 1352, 1404, 1456),
    CPU_DVFS("cpu", MHZ, 494, 675, 817, 817, 922, 922, 1000, 1200, 1200, 1248, 1352, 1404, 1404, 1456),
    CPU_DVFS("cpu", MHZ, 730, 760, 845, 845, 940, 1000),

    basically i removed few entries from second and third line +)
    so.. as far as i understand, sm1 is cpu voltage regulator, then if i am correct:

    $ cat /sys/class/regulator/regulator.2/microvolts
    1150000
    $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
    1456000
    $ cat /sys/class/hwmon/hwmon0/device/temp2_input
    63500

    1150 mv with 1456MHz. 63C at full load with sysbench benchmark.

    But really, why there is so many `MHz’ lines in dvfs_cpu structure ?

    • I haven’t looked at how the clock management is done on the 3.0.8+ kernels.

      If you remove entries you will run the subsequent clock speeds at lower voltages. The voltages are defined in a different array (check the common patch). Having extensively tested what is actually stable and what isn’t, I strongly advise against reducing voltages for any of OC speeds. What boots and what is actualy stable are NOT the same thing.

      For example, create a 700KB file using content from /dev/urandom. Compute the sha512sum of it. Write a script that runs 4 loops in parallel, and on every pass of each loop computes the hash and compares it to the original value. Leave this running for 24 hours. If no errors are detected, then you have a system stable enough for further testing.

      I removed the 1456MHz entry from the patches because I have found that although the CPU computations were stable, strange things were happening at 1456MHz that weren’t happening at 1404MHz, e.g. network drop-outs when using USB networking.

      All the AC100s I have are pretty consistent WRT speeds and voltages required, so if you are very lucky you might have one that manages to be stable at 25mV less at some of the OC speeds, but I would be very surprised if you actually manage to get it working stably at lower voltages.

      sysbench is no good for stability testing – AFAIK it doesn’t do any error checking. It isn’t even any good at temperature limit testing, it just doesn’t produce a high enough load.

      The reason why there are so many lines in the dvfs structure is because there are multiple different process IDs and multiple different speedo IDs that the Tegra2 chips wome with. I have only found two particular lines to be relevant to the AC100s. No doubt other devices have chips that were binned differently.

  3. Wow this one is impressive, very cool (pun intended). But I am concerned about the battery life as I only get a not so good 3-4 hours from ubuntu.

    Also what kind of operative system do you use?

    • To clarify: I get 3-4 hours of batterylife on stock clock speed, I have not tried your mod yet 🙂

      • That is quite odd. I generally get 6+ hours out of my AC100. The OC to 1404MHz doesn’t really make much observable difference to the battery life because most of the time in normal use the machine is idling at 216MHz anyway. Of course, if you are hammering it all the time with Quake 3, then yes, it will affect the battery life by (guessing!) anything up to about 25%.

        Do you have power management enabled? Are you using the ondemand CPU scaler? Which kernel are you running? Are there processes in the background that eat a lot of CPU?

        I use RedSleeve Enterprise Linux 6 (RSEL6 for short, my port of RHEL6 for ARM). It is similar to Fedora 12/13. It will be available for a public beta test by the end of January if you are interested.

Comments are closed.