Difference between revisions of "Talk:Maintenance"
(→Charge thresholds under Linux) |
(→Charge thresholds under Linux) |
||
| Line 26: | Line 26: | ||
Calling the _BTP ACPI EC method under Linux does not affect the charge thresholds (after setting them in Windows) or the aforementioned read-only start-charge threshold in EC offset 0x24. In fact the Linux driver (battery.c) calls _BTP on startup anyway. | Calling the _BTP ACPI EC method under Linux does not affect the charge thresholds (after setting them in Windows) or the aforementioned read-only start-charge threshold in EC offset 0x24. In fact the Linux driver (battery.c) calls _BTP on startup anyway. | ||
| + | |||
| + | After setting the thresholds there's also a bunch of port accesses done by TPPWRIF.SYS (on behalf of PWRMGRIF.DLL). It does the following: | ||
| + | * Read the HDAPS sensor data (i.e., accesses to I/O ports 0x1610-0x1620 in essentially the same pattern described for [http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html reading the HDAPS sensor]]). | ||
| + | * A write of 0x80 to port 0xB2 (this is the "APMC" port used by the ACPI DSDT "SMI" method, which also sets the LEDs and brightness and such! But the DSDT's SMI method always writes 0xF5 rather than 0x80 to that port; and here's there's no obvious transfer of arguments). | ||
| + | * A write of 0x80 to port 0x4F (huh?). | ||
Possible explanations: | Possible explanations: | ||
| − | * The EC uses additional, non-standard ports. | + | * The EC uses additional, non-standard ports. Which? |
| − | |||
* There's some autonomous charging circuitry independent of the EC which monitors the thresholds. How is it accessed? | * There's some autonomous charging circuitry independent of the EC which monitors the thresholds. How is it accessed? | ||
| − | * Charge control is actually done by the Windows software | + | * Charge control is actually done by the Windows software (this contradicts my experience under Linux when rebooting from Windows). How the charger is switched on/off. |
--[[User:Thinker|Thinker]] | --[[User:Thinker|Thinker]] | ||
| Line 59: | Line 63: | ||
--gst | --gst | ||
| + | ---- | ||
| + | |||
| + | I found the start-charge EC offset by (essentially) the method you suggested, but it didn't work for stop-charge. | ||
| + | |||
| + | About forgetting the threshold, one of the recent Battery Maximizer updates contained a fix for forgetting (or rather, not re-setting) the threshold on resume from hibernate. | ||
| + | --[[User:Thinker|Thinker]] 17:26, 2 Dec 2005 (CET) | ||
---- | ---- | ||
Revision as of 17:26, 2 December 2005
Charge thresholds under Linux
In regard to the question about controlling the charge threshold from Linux: apparently this isn't controlled by some standard means such as an ACPI method, but rather by direct I/O port tweaking done by the Battery MaxiMiser driver for Windows. It would be very hard to figure this out without specs.
--Thinker 17:56, 2 Oct 2005 (CEST)
maybe it would be possible to use a windows tool like SoftICE to capture the communication required to set the treshholds? as soon as we have some sort of specification adding support for it to the kernel should be rather trivial. --gst
http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-September/029556.html --gst
I see that when the charge threshold is set to a high value in Windows, charging is stopped even past reboots (including into Linux), battery changes and AC power loss. The only thing that resumes charging (other than changing the setting under Windows) is disconnection of the AC power while the laptop is turned off.
Another data point: it seems that charging enable/disable is done automatically in hardware based on the configured thresholds. Some forum posts suggested it's done by software monitoring, but I checked and it does work under Linux after rebooting from Windows.
Offset 0x24 in the embedded controller (i.e., /proc/acpi/ibm/ecdump) contains the "start charging" threshold, in percentage minus 1. You can see this by changing the threshold in Windows, rebooting to Linux and looking at /proc/acpi/ibm/ecdump. No idea how to change it, though: # echo 0x24 0x50 > /proc/acpi/ibm/ecdump has no effect. And I don't see anything obviously corresponding to the "stop charging" threshold.
When the charge thresholds are changed in Battery Maximizer, they take effect immediately but are not written to the embedded controller (or at least not through its standard interface). Looking at the writes to the EC's IO ports (and specifically for patterns of "out 0x66,0x81; out 0x62,EC_OFFSET; out 0x62,DATA"), I see that the following happens when changing the thresholds in Windows:
- There is always a write of 0x00 to EC offset 0x81.
- If the new thresholds cause charging to start or stop, there are also writes to EC offsets 0x81,0x14,0x2C,0x2D that look like the "_BTP" ACPI DSDT method (this causes the OS to be alerted when the battery passes a threshold).
- Sometimes there's also a bunch of writes to EC offsetx 0x50,0x52,0x53,0x54, but their arguments don't depend on the charge thresholds.
The SMBus isn't accessed either (i.e., no writes to the i801 SMBus chip at IO ports 0x18e8-0x18ff).
So when charging doesn't start/stop immediately, there is nothing that tells the EC what the new values are!
Calling the _BTP ACPI EC method under Linux does not affect the charge thresholds (after setting them in Windows) or the aforementioned read-only start-charge threshold in EC offset 0x24. In fact the Linux driver (battery.c) calls _BTP on startup anyway.
After setting the thresholds there's also a bunch of port accesses done by TPPWRIF.SYS (on behalf of PWRMGRIF.DLL). It does the following:
- Read the HDAPS sensor data (i.e., accesses to I/O ports 0x1610-0x1620 in essentially the same pattern described for reading the HDAPS sensor]).
- A write of 0x80 to port 0xB2 (this is the "APMC" port used by the ACPI DSDT "SMI" method, which also sets the LEDs and brightness and such! But the DSDT's SMI method always writes 0xF5 rather than 0x80 to that port; and here's there's no obvious transfer of arguments).
- A write of 0x80 to port 0x4F (huh?).
Possible explanations:
- The EC uses additional, non-standard ports. Which?
- There's some autonomous charging circuitry independent of the EC which monitors the thresholds. How is it accessed?
- Charge control is actually done by the Windows software (this contradicts my experience under Linux when rebooting from Windows). How the charger is switched on/off.
--Thinker
Well, you don't really need a stop charging threshold, and I think there might not be one on all ThinkPads. In fact, the X40 does not have any advanced battery control at all, for example.
I observed that once my T43 starts charging, it will charge to full if not under supervision by the battery charger software. My best guess is that you can tell the embedded controller the start charging threshold for each battery, and you can also command it to stop charging a battery and to switch to another battery. After you stop a battery from charging, it will only start charging again if it crosses the start charging threshold.
I have not done many experiments, though. e.g. I have no idea if the EC (embedded controller) will honour a stop-charging command below the start charging threshold.
--Hmh
Li-Ion batteries wear our quicker when at high charge, so a stop-charge threshold is very useful for increased battery life (as long as it doesn't make you discharge the battery too deply later). For example, my laptop is never without AC power for long, so I keep it between 40% and 70% charge. Sure, older models don't have it, but if it weren't useful they wouldn't add it to later models...
My experience is that when I set the thresholds in Windows and reboot into Linux (without powering off with AC unplugged - that resets things), then both thresholds are respected. It does stop charging when it reaches the high threshold, and it does start charging again when charge falls below the low threshold.
Do you know how to issue a stop-charging command (or any other charging-related command)? Are you sure these commands even go through the EC rather than some other autonomous circuitry? I can't figure this one out.
--Thinker 18:04, 1 Dec 2005 (CET)
How did you find the "start charging" offset? Shouldn't it be possible to find the "stop charging" offset by setting/checking the value to i.e. 70% then to 80% and finally back to 70% (and checking which of the values changed between 1 and 2 and which are the same on 1 and 3)?
Another thing which I noticed on a X41 running Windows: Sometimes (even when the notebook is started) the battery is charged to 100% although it is setup to only load up to 95%. I use suspend-to-disk and a dockingstation quite often so this may be a possible cause of the problem.
--gst
I found the start-charge EC offset by (essentially) the method you suggested, but it didn't work for stop-charge.
About forgetting the threshold, one of the recent Battery Maximizer updates contained a fix for forgetting (or rather, not re-setting) the threshold on resume from hibernate.
--Thinker 17:26, 2 Dec 2005 (CET)
Cleaning the Interior
The description in the article doesn't match the keyboard removal instructions for the T43. It's best to just link to IBM's on-line instructions (which, for the T43 at least, include a nifty video of the disassembly) and to the maintenance manuals.
--Thinker 23:47, 28 Nov 2005 (CET)
