Embedded Controller Firmware

From ThinkWiki
Revision as of 22:20, 27 October 2006 by Hmh (Talk | contribs) (Bug: Advanced battery query causes EC hang: improve text)
Jump to: navigation, search

ThinkPad Embedded Controller Firmware

The ThinkPad has an embedded microcontroller (EC) which is responsible for many of the background tasks on a laptop. Embedded Controller Chips lists the different embedded microcontrollers found on various ThinkPads. This page concerns itself with the various embedded controller firmwares.

The more precise way to refer to a particular instace of the ThinkPad firmware is not the ThinkPad name (ThinkPad T43) or model number (2668-XXX), but rather by the firmware model string, which is unique to BIOS-and-firmware-image-compatible ThinkPads. E.g. there are both R52 and T43 ThinkPads with firmware model TP-70: they share the same BIOS and EC firmware, and also the same bugs... There is a list of the ThinkPad BIOS/EC types in the BIOS Upgrade Downloads page.

The firmware model string is "TP-" and the two first characters of the BIOS/EC version strings (e.g. BIOS 1YET29WW and EC 1YHT29WW are for the firmware model TP-1Y, which happens to be some of the T43, and the T43p).

As a rule, if you are not using the latest available firmware for your ThinkPad, you are likely to be the unlucky chap that will find out some new code hits a firmware bug that was fixed by IBM or Lenovo. Do yourself a favour and always keep your ThinkPad's firmware up-to-date.

Old-style ThinkPad EC firmware

Not much is known about the ECs on the older numeric-series ThinkPads, or the early A, X and T-series models. These microcontrollers do support field-upgradeable firmware which is distributed along with the BIOS upgrades. The BIOS SMAPI, DSDT ACPI and a very small subset of the EC ACPI interfaces are available for driver writers.

  • Interfaces:
    • EC register map (very model-specific)
    • SMAPI
    • CMOS memory map

New-style ThinkPad EC firmware

Apparently, all newer ThinkPad ECs are a Renesas H8S/2161BV or another compatible H8S/300 microcontroller with very similar firmware.

  • Interfaces:
    • Forward-compatible EC register map
    • ACPI DSDT, APM (deprecated in newer models)
    • Renesas H8S LPC3A (?), LPC3B (HDAPS firmware, Battery information)
    • ACPI SMAPI methods
    • SMAPI
    • CMOS memory map
tpctl, tpb and other drivers, please someone expand on how well they work with the new ThinkPads

Firmware issues

Various bugs have been observed in the ThinkPad EC firmware of various models. Most of them were fixed in later revisions, but a few are either very dangerous and driver writers need to always work around them, or have never been fixed. One must keep in mind that many of the bugs fixed by IBM or Lenovo could cause serious problems, but might never be noticed by driver developers, because they usually keep their ThinkPads up-to-date. People that don't keep their ThinkPad firmware up-to-date are excellent guinea pigs...

Bug: Advanced battery query causes EC hang

  • Severity: critical
  • Linux annoyance level: harmless
  • Windows annoyance level: unknown
  • Fix: available from IBM, but not for all affected models
  • Information: thread in linux-thinkpad ML
  • Models affected:
    • TP-1R (T40, T40p, T41, T41p, T42, T42p): no fix available
    • TP-1Y (T43 26xx, T43p): fixed by firmware 1YHT28WW (1.05) and newer
    • TP-70 (T43 18xx, R52), TP-76 (R52), TP-78 (R51e): likely buggy, unknown status (might be fixed in latest firmwares)
    • other ThinkPads featuring advanced battery queries: unknown status; every model supported by tp_smapi advanced battery information is a candidate for this bug

The EC LPC3B advanced battery query function 0x0B (acessed by earlier versions of tp_smapi) has a hideous bug that causes the EC to misbehave and crash (usually hanging the entire ThinkPad). This function must never be called on a buggy firmware: after you called it even once, all is lost the the box will crash and burn shortly. A full power down is the only think that will fix it, as we don't know how to cause an immediate EC reboot.

No Linux drivers use this function, as the meaning of the data it returns is currently unknown.

Bug: Fan control loop status is not initialized

  • Models affected (confirmed):
  • Models NOT affected (confirmed):
    • TP-7C (R60), TP-79 (T60/p), TP-7B (X60/s), TP-1A (T23), TP-1G (A31), TP-1V (R51), TP-1R (T40/p,T41/p,T42/p,R50/p,R51)

The EC does not correctly initializes its 0x2f (fan control) register, so ibm-acpi cannot determine the correct status of the fan control until something writes to the fan control register for the first time.

Writes to the fan control register in their ACPI DSDT methods provides a work-around. This usually fixes the issue during suspend and wakeup.

So far, there are only reports of wrong readings of 0x07, no other wrong value has been observed. Note that 0x07 might be a correct value if the system is in emergency fan mode (level 7).

Bug: Fan control loop pulses the fan in an annoying pattern

  • Models affected:
    • TP-1R (T40, T40p, T41, T41p, T42, T42p): fixed by firmware 1RHT70WW (3.03) and later
    • TP-1Y and TP-70 (T43, T43p, R52): IBM provided a broken firmware fix, so they are all affected
    • other newer models: unknown status

The fan control loop will vary the fan speed quite a lot, in a very annoying pattern. The broken fix on the T43 firmware causes very loud and annoying pulses every 30s.

People have reportedly returned ThinkPads because of this bug.

Bug: Tachometer registers not invalidated in disengaged mode

  • Severity: low
  • Linux annoyance level: minor
  • Windows annoyance level: minor
  • Fix: none available
  • Models affected:
    • Unknown (disengaged mode might not be supported on all ThinkPads)

When the fan control loop is placed in disengaged mode (bit 6 of EC register 0x2f is set) where no tachometer readings take place, the EC does not set the tachometer registers (0x84, 0x85) to 0xFF to signal an invalid reading. Instead, the registers are simply not updated anymore and retain the last tachometer reading that took place.

This bug can be easily worked around in drivers.

See also