Difference between revisions of "Talk:Maintenance"
(→Charge thresholds under Linux) |
(→Charge thresholds under Linux) |
||
| Line 18: | Line 18: | ||
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 "<tt>out 0x66,0x81; out 0x62,EC_OFFSET; out 0x62,DATA</tt>"), I see that the following happens when changing the thresholds in Windows: | 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 "<tt>out 0x66,0x81; out 0x62,EC_OFFSET; out 0x62,DATA</tt>"), I see that the following happens when changing the thresholds in Windows: | ||
* There is always a write of 0x00 to EC offset 0x81. | * 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). | + | * 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. | * 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. | ||
| Line 24: | Line 24: | ||
So when charging doesn't start/stop immediately, there is nothing that tells the EC what the new values are! | 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. | ||
Possible explanations: | Possible explanations: | ||
* The EC uses additional, non-standard ports. | * The EC uses additional, non-standard ports. | ||
| + | * The Windows driver writes to the EC in a way I didn't look at (i.e., not the IO port access pattern given above). | ||
* 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. This contradicts my experience under Linux when rebooting from Windows, and it's still not clear how the charger is switched on/off. | * Charge control is actually done by the Windows software. This contradicts my experience under Linux when rebooting from Windows, and it's still not clear how the charger is switched on/off. | ||
| − | |||
--[[User:Thinker|Thinker]] | --[[User:Thinker|Thinker]] | ||
Revision as of 04:01, 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.
Possible explanations:
- The EC uses additional, non-standard ports.
- The Windows driver writes to the EC in a way I didn't look at (i.e., not the IO port access pattern given above).
- 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, and it's still not clear 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)
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)
