T40/p-T43/p, R50/p & R52 Embedded Controller Internals

mg · **Posted:** Mon Feb 20, 2006 6:10 pm

Recent ThinkPad notebooks contain an embedded controller (EC), a processor with its own RAM and ROM on-chip, that controls things like battery charging, keyboard scanning, volume change, LCD brightness change, status LEDs, and also the fan and reading of temperature sensors.

On a T43p (and at least since T40) this is a Renesas H8S/2161BV, a 16-bit single-chip micro-controller located below the ExpressCard/CardBus slots. It has its own OS in 128 KB flash memory and since this OS is available in the EC updates, it is possible to analyze and modify it. Or we will at least be able to better understand how it can be configured since there doesn't seem to be much documentation available about the EC.

For people willing to delve deeply into H8S assembly language, there is now a set of files that allows to customize the EC of all T4x and some R5x types. This is somewhat risky business and may lead to system board replacement if not done very carefully. However, in a collective effort, it will lead to improvements of the fan issues that some have.

Please take a look at it if interested and share your insights:

README.txt (assembling instructions)
1YHT29WW.html [255 KB] (pretty-printed code, version 1.06 for T43/p 26xx types only; takes some time to load)
ec.html [274 KB] (pretty-printed code, all versions/types combined; takes quite some time to load and run)
ec-18s.7z [468 KB] (all code, including above files; self-extracting 7-Zip archive if renamed to ec-18s.exe)
h8300-coff-as.pdf [520 KB] (GNU As manual)

Thinkerer · **Joined:** Mon Nov 28, 2005 6:04 am **Posts:** 46

Impressive in the extreme. Amazing work!

A few imagined uses:
* Change the fan thresholds algorithm
* Change the fan RPM values of (logical) fan levels
* Change the fan control code to avoid the (noisy!) momentary fan acceleration that occurs whenever the fan speed is decreased.
* Implement a accelerometer-based theft alarm that works in suspend mode too. Any idea if the accelerometer is (or can be) powered down in S3 sleep?

Perhaps the first step should be to find a way to make volatile updates (RAM-only, no changes to the non-volatile flash) to the EC software. There seems to be some kind of hook for that, but I don't understand how it's invoked.

GomJabbar · **Joined:** Tue Jun 07, 2005 6:57 am **Posts:** 9625

Looks like this has already been done. Take a look at Shimodax's thread in the ThinkPad Utility Work Area forum. He has started probably, the thread most read on this site. :shock:

http://forum.thinkpads.com/viewtopic.php?t=17715

Thinkerer · **Joined:** Mon Nov 28, 2005 6:04 am **Posts:** 46

GomJabbar wrote:

Looks like this has already been done.

Shmidoax's tool, and the script for Linux which inspired it, address only the first point above, and do it imperfectly - they don't change the EC firmware, but rather override it via software running on the CPU. This has many disadvantages (e.g., if your OS crashes, you may burn your systemboard).

GomJabbar · **Joined:** Tue Jun 07, 2005 6:57 am **Posts:** 9625

I imagine you are right. This is out of my ken. :oops:

mg · **Posted:** Tue Feb 21, 2006 2:04 pm

The first step was to make it reproduce exactly most available EC firmware images (1.02-3.04 for T40x-T43x/R50x/R51 18xx, 1.01-1.06 for T43x 26xx, 1.01-1.05 for T43 18xx/19xx, 1.01-1.05/1.02-1.06 for R52) to find the code relocations to decide what are tables and what is code. This is done.

Next steps are to identify subroutines and code fragments and rename the labels according to their functionality and add comments. This can be done from different directions, e.g. looking which pins are how and when accessed, or following the program flow of reset and interrupt routines. Or just use your intuition and follow things that look interesting.

What would help is to find out more about the surrounding hardware. South of the Southbridge is a MAX1989 that includes an internal temperature sensor and can also read 4 more sensors. It is probably connected to one of the two I²C/SMBus busses of the EC. There is a MAX1540 nordeast of the EC that can change voltage levels that could also used for different things than just RAM power supplies. Most interesting would be which circuit drives the fan and reads its tacho. It could well be the EC's internal A/D and D/A converters or PWM generators with some discreete components.

Some higher resolution photos of the system board, especially from the bottom side, would be helpful to trace the circuit tracks.

mg · **Posted:** Tue Feb 21, 2006 5:20 pm

Thinkerer wrote:

Perhaps the first step should be to find a way to make volatile updates (RAM-only, no changes to the non-volatile flash) to the EC software.

There are apparently some mechanisms to do that. There are some locations in the scheduler that call into the RAM to execute code there (by default it's just rts; look for "hook"). A certain access pattern of the EC allows to copy H8S code from the main CPU and execute it in the EC (look for "exec"). There are at least two more occasions where code in RAM can be executed. How to activate these mechanisms needs to be explored -- possibly they are only accessible if it's a debug or diag build (build id contains "?"). However, to patch in an own mechanism with some vectors in the RAM should be doable without moving code around in case not all relocations have been caught yet. There's still some unused ROM and (low and high) RAM.

mg · **Posted:** Sun Feb 26, 2006 6:33 pm

It actually seems the fan fix done for T40/p-T42/p (changes EC firmware 3.02 -> 3.03) is integrated into the T43/p firmware.

Thinkerer · **Joined:** Mon Nov 28, 2005 6:04 am **Posts:** 46

mg wrote:

Note what sub_13b74 does: it alternates between jumping to two routines that load the values 5000 (loc_13b3c) and 30000 (sub_13b48), respectively. These seem to be the delay values in ms (what the above mentioned fix on 3.03 basically does is, instead of jumping from the switch table directly to load 5000, to first compare some value to 3600 [it's an immediate value instead of one loaded from or through RAM] and then load the two different values as mentioned above).

That's funny, it seems to use essentially the same algorithm as the anti-pulse kludge in my ACPI fan control script (frequent sampling for a while to stabilize fan speed, then alternate between long and short sampling periods).

Sounds like you're zeroing in on the core of the fan control logic.

christopher_wolf · **Posted:** Sun Feb 26, 2006 8:13 pm

This is quite an interesting thread; would anybody mind if I moved it to the Thinkpad Utilities Forum?

Bols · **Joined:** Wed Jan 11, 2006 10:08 am **Posts:** 12

mg wrote:

It actually seems the fan fix done for T40/p-T42/p (changes EC firmware 3.02 -> 3.03) is integrated into the T43/p firmware. However, looking at sub_13b74, there seems to be a typo: er0 is loaded from RAM but then er1 is incremented and dereferenced, and a new value is loaded into r0 -- i.e. the previously loaded value in er0 is not used (r0 is the lower half of er0). Also, er1 contained the sign-extended distance loaded from jump table off_13a1a (by way of sub_13a04, which BTW contains a loop), so using it as a pointer wouldn't make sense. Note what sub_13b74 does: it alternates between jumping to two routines that load the values 5000 (loc_13b3c) and 30000 (sub_13b48), respectively. These seem to be the delay values in ms (what the above mentioned fix on 3.03 basically does is, instead of jumping from the switch table directly to load 5000, to first compare some value to 3600 [it's an immediate value instead of one loaded from or through RAM] and then load the two different values as mentioned above).

So it looks like the value should be moved into er1 at sub_13b74. Anybody care to verify?

*****Expletives removed by Moderator*****...'twas about time somebody showed up with some real hardcore programming here. It isn't the real thing until a bug will make your laptop spontanously burst into flames. Respect! :-)

mg · **Posted:** Mon Mar 06, 2006 12:55 pm

It now includes a cross-referenced HTML file for Firefox/Mozilla (very slow on IE) with highlighting, preview, program flow arrows and tooltips (JavaScript/ECMAScript) for easier navigation.

Thinkerer · **Joined:** Mon Nov 28, 2005 6:04 am **Posts:** 46

mg wrote:

It now includes a quick-and-dirty cross-referenced HTML file

Highly impressive! Did you do all of that by yourself especially for this project, or are there tools that help generate this?

Can you figure out where the "disengaged mode" described at ThinkWiki fits in? Maybe it's what ec.s calls "fan off"? I can't make sense of the confSpeedMode code.

mg · **Posted:** Mon Mar 06, 2006 2:00 pm

Thinkerer wrote:

Did you do all of that by yourself especially for this project, or are there tools that help generate this?

It was done with the included xref Perl script (it's in the public domain). There are also commercial products like IDA Pro that can do similar things (but differently).

Quote:

I can't make sense of the confSpeedMode code.

Most are guessed labels and might sometimes be inaccurate or too specific... Further investigation by the community required...

mg · **Posted:** Sun Apr 16, 2006 8:27 pm

Hmmm... Maybe one could replace the firmware with brickOS (Lego Mindstorms uses an older H8 controller)... :wink:

Thinkerer · **Joined:** Mon Nov 28, 2005 6:04 am **Posts:** 46

ThinkWiki page for this embedded controller (no new info yet...):

http://www.thinkwiki.org/wiki/Renesas_H8S/2161BV

mg · **Posted:** Sun Jul 23, 2006 3:40 pm

Updated to support more EC firmware versions. See top posting for download.

hmh · **Posted:** Fri Aug 04, 2006 10:59 am

Does anyone have an idea of whether the EC firmware exports the number of thermal sensors, or any other information that would allow us to know for sure that the secondary set of thermal readings (EC dump offset 0xC0-0xC7) are valid?

This could improve Linux' ibm_acpi support for the second set of thermal sensors a lot...

Thinkerer · **Joined:** Mon Nov 28, 2005 6:04 am **Posts:** 46

hmh wrote:

Does anyone have an idea of whether the EC firmware exports the number of thermal sensors, or any other information that would allow us to know for sure that the secondary set of thermal readings (EC dump offset 0xC0-0xC7) are valid?

Do you know of any case where 0xC0-0xC7 don't return either valid readouts or 0x80 (like nonexistent batteries in the 8 "standard" readings)?

Otherwise, ibm_acpi can just output them, same as for the 8 first readouts.

hmh · **Posted:** Sat Aug 05, 2006 8:30 am

Thinkerer wrote:

Do you know of any case where 0xC0-0xC7 don't return either valid readouts or 0x80 (like nonexistent batteries in the 8 "standard" readings)?

Otherwise, ibm_acpi can just output them, same as for the 8 first readouts.

We'd need ec-dump reports from a lot of ThinkPad models, including very ancient ones (since the ThinkPad 570 and 600) to know that. The legacy EC registers are supported since forever (I don't think the ThinkPad 570 even has an EC, it could be some sort of BIOS emulation).

The people working with the fan control loop must have done some work on the thermal sensor routines, and they might know enough already to find out if the EC firmware exports the number of sensors (or at least if the C0-C7 range is valid) somewhere in the EC register space. That's the reason for my question.

Thinkerer · **Joined:** Mon Nov 28, 2005 6:04 am **Posts:** 46

mg wrote:

http://s1.upload.sc/request/48b5ffc9eb87cec7cf0f5b8c37dd97a8 (ec-07.zip)

The upload.sc download fails with ""Incorrect Link. You have clicked on invalid or expired link."

mg · **Posted:** Tue Sep 05, 2006 10:55 pm

Thinkerer wrote:

The [...] download fails with "Incorrect Link. You have clicked on invalid or expired link."

New upload with a version that adds T40/p-T42/p, R50/p and R51 18xx support (see top posting for download). Some more JavaScript fun (control flow arrows when F2 is pressed; target preview when hovering on symbols). MD5 digests for verification. Conditional assembling still needs some more clean-up and tables of different types should be consolidated...

vpn-user · **Joined:** Thu May 20, 2004 5:56 am **Posts:** 168

Is there already an image available which fixes the fan problem?

mg · **Posted:** Wed Sep 06, 2006 7:07 am

vpn-user wrote:

Is there already an image available which fixes the fan problem?

Not that I know of. It currently produces 22 of the original images. Hopefully some will step in and start with modifying them...

vpn-user · **Joined:** Thu May 20, 2004 5:56 am **Posts:** 168

mg wrote:

vpn-user wrote:

Is there already an image available which fixes the fan problem?

Not that I know of. It currently produces 21 of the original images. Hopefully some might step in and start with modifying them...

I had an Assembler crashcourse at my university but not to that extent that I could do this.

mg · **Posted:** Wed Sep 06, 2006 9:02 pm

vpn-user wrote:

I had an Assembler crashcourse at my university but not to that extent that I could do this.

I'd guess most universities don't offer code analysis courses to such a degree (yet)...

So it's probably mostly a matter of diligence and dedication. The included documentation references and command line examples should allow a relative quick start. And I think the cross-referenced HTML version with tooltips for the mnemonics should make it easier to navigate, besides that the program flow arrows look cute...

mg · **Posted:** Mon Sep 11, 2006 9:04 pm

Merged 1RHT15WW (T40 EC version 1.02) with the rest, merged some tables, and added task symbols for the scheduler. This should make identification of recurring and delayed events like flashing LEDs and fan speed control loops easier. I think the hardest part is done and the general structure is visible. Now the more fun parts start... Please post or pm suggestions for (descriptive) label names and source code comments...

mg · **Posted:** Tue Sep 12, 2006 9:45 am

A schematic diagram (wiring of integrated circuits around the EC) of any of the T40, T40p, T41, T41p, T42, T42p, T43, T43p, R50, R50p, R51 18xx or R52 would be quite helpful. Or a (broken) system board. Any pointers?

christopher_wolf · **Posted:** Tue Sep 12, 2006 12:08 pm

mg wrote:

A schematic diagram (wiring of integrated circuits around the EC) of any of the T40, T40p, T41, T41p, T42, T42p, T43, T43p, R50, R50p, R51 18xx or R52 would be quite helpful.

That is difficult at best, a sheer Overused word if everything just goes "OK" and most of that information is for internal, non-general public use. The broken system board would be a better idea to garner information from given that we could accurately test it and get a useful response out of the parts we were concerned with. Naturally, this requires that we know precisely where the "broken" part is *not*.

I like the idea though; next time I come across a T4X series board that nobody wants, which is kinda difficult around here, I could inspect it in this manner.

mg · **Posted:** Tue Sep 12, 2006 12:30 pm

christopher_wolf wrote:

The broken system board would be a better idea to garner information from given that we could accurately test it and get a useful response out of the parts we were concerned with. Naturally, this requires that we know precisely where the "broken" part is *not*.

Even completely non-functional (well, maybe not lightning or hammer treatment) would be useful. But to trace the wires and tracks it would have to be completely removed (which I couldn't be bothered yet to do), and using a connection testing device could damage it anyways. High resolution pictures of a completely detached board might work also.

T40/p-T43/p, R50/p & R52 Embedded Controller Internals

Who is online