Jump to content

HP DVx ACPI 3.x/4.x Battery Driver (10.6/10.7)

gsly

By gsly,
in New Releases and Updates

 Share
229 posts in this topic

Recommended Posts

chinmaya__swarup
chinmaya__swarup
Posted
Posted

i have successfully edited my DSDT, converted registers to 8 bit, battery is being detected, but not properly.

i have attached screenshots and my dsdt.

 

Problem is that i am getting

1. Charge Remaining wrong figures

2. Amperes remaining in -ve figures

3. Battery at 20:00 remaining at full charge.

 

same in both SL 10.6.8 and Lion 10.7.3

 

Please help me to rectify these errors.

 

Thanks in advance.

DSDTx.aml.zip

post-902922-0-40068200-1333385008_thumb.png

post-902922-0-76755700-1333385011_thumb.png

post-902922-0-91800500-1333385020_thumb.png

Link to comment
Share on other sites
gsly
gsly
Posted
  • Author
Posted

i have successfully edited my DSDT, converted registers to 8 bit, battery is being detected, but not properly.

i have attached screenshots and my dsdt.

 

Problem is that i am getting

1. Charge Remaining wrong figures

2. Amperes remaining in -ve figures

3. Battery at 20:00 remaining at full charge.

 

same in both SL 10.6.8 and Lion 10.7.3

 

Please help me to rectify these errors.

 

Thanks in advance.

Your Charge Remaining numbers are too high so I'd suggest the DSDT code is incorrectly converting the units. If you read the SBS specification, the power units to be used are specified in the first index of the package returned by _BIF. The driver uses this information and has to assume the units passed to it are in the correct units as specified. Look at the calculations in UBST().

Link to comment
Share on other sites
chinmaya__swarup
chinmaya__swarup
Posted
Posted

Your Charge Remaining numbers are too high so I'd suggest the DSDT code is incorrectly converting the units. If you read the SBS specification, the power units to be used are specified in the first index of the package returned by _BIF. The driver uses this information and has to assume the units passed to it are in the correct units as specified. Look at the calculations in UBST().

 

i guess i have ACPI 2.0 system ????

 

Thank for reply, as per your advice i am working with this method UBST().

 

Can you please tell me what information is stored _BST(0x02) (in my dtdt) ?

 

whether it is remaining current (mAmp) or remaining power (mWatt) ?

 

i guess it is a mathematical calculation error which i think i can solve.

Link to comment
Share on other sites
gsly
gsly
Posted
  • Author
Posted

Can you please tell me what information is stored _BST(0x02) (in my dtdt) ?

whether it is remaining current (mAmp) or remaining power (mWatt) ?

According to the ACPI specification, the value returned in offset 0x02 of package from _BST is:

 

Returns the estimated remaining battery capacity. The Battery Remaining Capacity value is expressed as power [mWh] or current [mAh] depending on the Power Unit value. Batteries that are rechargeable are required to return a valid Battery Remaining Capacity value.

0x00000000 – 0x7FFFFFFF in [mWh] or [mAh]

0xFFFFFFFF – Unknown capacity

 

As you are not using a smart battery interface (that would tell you the units) but rather the embedded controller hard-wired lines, you are going to figure out what information type is being returned from those registers and make it adhere to the ACPI specification. Once you do that, the driver will properly interpret the values and pass them on to the OS.

Link to comment
Share on other sites
chinmaya__swarup
chinmaya__swarup
Posted
Posted

According to the ACPI specification, the value returned in offset 0x02 of package from _BST is:

 

Returns the estimated remaining battery capacity. The Battery Remaining Capacity value is expressed as power [mWh] or current [mAh] depending on the Power Unit value. Batteries that are rechargeable are required to return a valid Battery Remaining Capacity value.

0x00000000 – 0x7FFFFFFF in [mWh] or [mAh]

0xFFFFFFFF – Unknown capacity

 

As you are not using a smart battery interface (that would tell you the units) but rather the embedded controller hard-wired lines, you are going to figure out what information type is being returned from those registers and make it adhere to the ACPI specification. Once you do that, the driver will properly interpret the values and pass them on to the OS.

 

 

Thanks for for reply gsly

 

 

i am currently focussing following regiters :

BPR, BPV and BDV (in my DSDT,)

 

 

as these registers are used for calculating values inside BSTB function.

 

out of which:

BDV is returning battery design voltage - which is OK.

BPV is returning battery present voltage - which is OK.

but unable to recognize what BPR is returning ?

 

i am having doubt what BPR i returning ???? (63666@100% full)

 

if i can identify this then i guess my problem will be solved.

 

i am continuing experiments.

 

Please tell me whether i am moving in the right direction !!!

Link to comment
Share on other sites
chinmaya__swarup
chinmaya__swarup
Posted
Posted

@gsly

 

here are the results :

 

BDV is returning battery design voltage - which is OK.

BPV is returning battery present voltage - which is OK.

 

BPR is returning following values: (Dualboot MAC OS Lion & Window 7; Battery status% checking was done in Win-7)

 

Battery status BPR Value

100 % 63666

80% 63395

64% 63230

60% 63135

58% 62960

19% 62882

 

in My DSDT the balance power remaining is calculated as :

 

[(BFC X BDV) / 1000] X BPR / 100

 

[(4840 X 1080) / 1000 ] X BPR / 100

 

= 5227 X BPR / 100 = Wrong figures

 

As BPR is always remaining>=62000, hence the balance power remaining is coming very high...!!!!

 

Can you suggest any solution ?

Link to comment
Share on other sites
gsly
gsly
Posted
  • Author
Posted
@gsly here are the results : BDV is returning battery design voltage - which is OK. BPV is returning battery present voltage - which is OK. BPR is returning following values: (Dualboot MAC OS Lion & Window 7; Battery status% checking was done in Win-7) Battery status BPR Value 100 % 63666 80% 63395 64% 63230 60% 63135 58% 62960 19% 62882 in My DSDT the balance power remaining is calculated as : [(BFC X BDV) / 1000] X BPR / 100 [(4840 X 1080) / 1000 ] X BPR / 100 = 5227 X BPR / 100 = Wrong figures As BPR is always remaining&--#62;=62000, hence the balance power remaining is coming very high...!!!! Can you suggest any solution ?

 

BPR = Battery Present Rate (of charge or discharge)

 

This implies that the number can be positive or negative (i.e. signed) and this is confirmed by this snippit of your DSDT:

 

Method (UBST, 0, NotSerialized)
{
Store (B1B2 (^^PCI0.LPCB.EC.BST1, ^^PCI0.LPCB.EC.BST2), Index (BSTB, Zero)) // Battery state
Store (B1B2 (^^PCI0.LPCB.EC.BPR1, ^^PCI0.LPCB.EC.BPR2), Local0)	// BAT present rate (A)
Store (B1B2 (^^PCI0.LPCB.EC.BDV1, ^^PCI0.LPCB.EC.BDV2), Local1)	// BAT voltage (V)
If (LGreaterEqual (Local0, 0x8000))		   // If rate >= 32768, high bit is set and as signed 16-bit, it means negative or discharging
{
	Subtract (0x00010000, Local0, Local0)   // Correct for negative sign (-65535)
	Multiply (Local0, Local1, Local0)	   // A * V = W
	Divide (Local0, 0x03E8, Local2, Local0) // W / 1000 = mWh
}
Else
{
	Multiply (Local0, Local1, Local0)  // A * V = W
	Divide (Local0, 0x03E8, Local2, Local0) // W / 1000 = mWh
}
Store (Local0, Index (BSTB, One)) // BAT present rate (mWh)
...

Link to comment
Share on other sites
chinmaya__swarup
chinmaya__swarup
Posted
Posted

BPR = Battery Present Rate (of charge or discharge)

 

This implies that the number can be positive or negative (i.e. signed) and this is confirmed by this snippit of your DSDT:

 

Method (UBST, 0, NotSerialized)
{
Store (B1B2 (^^PCI0.LPCB.EC.BST1, ^^PCI0.LPCB.EC.BST2), Index (BSTB, Zero)) // Battery state
Store (B1B2 (^^PCI0.LPCB.EC.BPR1, ^^PCI0.LPCB.EC.BPR2), Local0)	// BAT present rate (A)
Store (B1B2 (^^PCI0.LPCB.EC.BDV1, ^^PCI0.LPCB.EC.BDV2), Local1)	// BAT voltage (V)
If (LGreaterEqual (Local0, 0x8000))		   // If rate >= 32768, high bit is set and as signed 16-bit, it means negative or discharging
{
	Subtract (0x00010000, Local0, Local0)   // Correct for negative sign (-65535)
	Multiply (Local0, Local1, Local0)	   // A * V = W
	Divide (Local0, 0x03E8, Local2, Local0) // W / 1000 = mWh
}
Else
{
	Multiply (Local0, Local1, Local0)  // A * V = W
	Divide (Local0, 0x03E8, Local2, Local0) // W / 1000 = mWh
}
Store (Local0, Index (BSTB, One)) // BAT present rate (mWh)
...

 

:| i am now confused.....

 

then which register will return balance Ampere/power remaining ??? :blink:

Link to comment
Share on other sites
  • 3 weeks later...
THe KiNG
THe KiNG
Posted
Posted

Sure THe KiNG. I've been meaning to set up a repository someplace and upload the source there now that it's stable. FWIW, the source is just the usual AppleACPIBattery code that has been floating around the net. I just fixed some bugs, restored some original code that handles the different units of the ACPI standard, and of course added code to support ACPI 4.x and additional non-standard information (i.e. Temp)

Cool!

 

Lemme know when is avail.

 

Thanks.

Sorry if I 'push' things, a simple upload here will do just fine.

I was hopping to take a look before I will trash this laptop...

 

Thanks.

Link to comment
Share on other sites
gsly
gsly
Posted
  • Author
Posted

Sorry if I 'push' things, a simple upload here will do just fine.

I was hopping to take a look before I will trash this laptop...

 

Thanks.

Sorry about that THe KiNG, been busy. I figured out the setup for github and uploaded the source code there and updated the original post with the link.

  • Like 1
Link to comment
Share on other sites
  • 3 weeks later...
BuXb
BuXb
Posted
Posted

why not include patches known to be required for Hackbooks into Apple's PowerManagement Sources as has been done before (last time I know of in Leopard) instead of all this complicated DSDT stuff, which in addition is different for each Laptop .. ?? The modded PM.bundle worked so well back then in all sorts of mobile PCs ..

Link to comment
Share on other sites
gsly
gsly
Posted
  • Author
Posted

why not include patches known to be required for Hackbooks into Apple's PowerManagement Sources as has been done before (last time I know of in Leopard) instead of all this complicated DSDT stuff, which in addition is different for each Laptop .. ?? The modded PM.bundle worked so well back then in all sorts of mobile PCs ..

Each laptop's interface to it's battery subsystem will be different so there is no way to support every laptop without system specific code, in this case at the DSDT level. This is what the DSDT is all about. The ACPI standard provides a way to return that manufacturer specific hardware data and this driver then passes that information to the PM system. In fact, the battery driver here replaces a portion of the PM bundle (AppleSmartBatteryDriver) so we are in fact doing what you mention.

Link to comment
Share on other sites
  • 2 weeks later...
gsly
gsly
Posted
  • Author
Posted

Could be useful to some: When just the _BIF method is used the empty ManufacturerData that's set by the kext seems to be what causes the System Profiler's Power section to fail. Commenting out that line fixed it for me.

Thanks for the detail, it sounds like a bug that should be fixable and something I hadn't tested (in a while). What OSX version was this?

Link to comment
Share on other sites
alianyn
alianyn
Posted
Posted

First and foremost, thanks @gsly for this really wonderful and informative work, and all the time you've dedicated to this.

 

Thanks also goes to Jingu & 18seven for adapting this to Asus laptops (which i am also an owner of).

 

I'm encountering a very strange problem - which no one else has reported, so i'm assuming it's something i'm doing wrong.

No matter how i play with the info.plist inside the kext - i can't get it to use _BIF, only _BIX

I always get this in the kernel log:

Jun 13 15:52:04 localhost kernel[0]: AppleSmartBattery: Using ACPI extended battery information method _BIX

 

I've tried setting UseExtendedBatteryInformationMethod & UseExtraBatteryInformationMethod to false (both as booleans and as strings), but the result is always the same.

 

Since no one else is reporting this - i'm assuming it's some stupid mistake i'm making, but i'll take my chances and post the kext i'm using (i put it in S/L/E - replacing the original) - can anyone help?

AppleSmartBatteryManager.kext.zip

Link to comment
Share on other sites
apramorbis
apramorbis
Posted
Posted
Thanks for the detail, it sounds like a bug that should be fixable and something I hadn't tested (in a while). What OSX version was this?

 

It was 10.7.4

Also fixed up the kext for watt mode somewhat.

Works pretty well with my thinkpad using mostly original DSDT battery code (as far as the actual battery values). Do have some ugly hacks in place for the strings though.

 

batterye.jpg

 

 

Thanks for making this and releasing the source :)

AppleSmartBatteryManager_WATTS.kext.zip

AppleSmartBatterycpp.txt

thinkpad_r61_battery_dsdt.txt

Link to comment
Share on other sites
apramorbis
apramorbis
Posted
Posted

...

 

Since no one else is reporting this - i'm assuming it's some stupid mistake i'm making, but i'll take my chances and post the kext i'm using (i put it in S/L/E - replacing the original) - can anyone help?

 

You appear to have redeclared the keys. You can find the ones being used under the IOKitPersonalities. Both are set to true.

Deleting the ones you added and setting those to false should do it.

  • Like 2
Link to comment
Share on other sites
alianyn
alianyn
Posted
Posted

You appear to have redeclared the keys. You can find the ones being used under the IOKitPersonalities. Both are set to true.

Deleting the ones you added and setting those to false should do it.

Thanks @apramobis - that's so embaracing... was going nuts here, though what i ended up doing was open the source code and hard code it to work with _BIF.

Link to comment
Share on other sites
gsly
gsly
Posted
  • Author
Posted

It was 10.7.4

Also fixed up the kext for watt mode somewhat.

Works pretty well with my thinkpad using mostly original DSDT battery code (as far as the actual battery values). Do have some ugly hacks in place for the strings though.

 

Thanks for making this and releasing the source :)

Thanks aprmorbis for revising the watts related code, when I get some time I'll integrate your changes into the code base as well as fix that bug with the manufacturer data. The original code I used as a base had the watts code commented out, but I really can't test it on my laptop (uses amps) but it should be included as the ACPI standard supports and allows it. I should be able to test the manufacturer data bug though as I've updated to 10.7.4 recently but I haven't reinstalled this battery kext yet as I wanted to play around with my next idea for getting the native Apple battery driver to work via DSDT changes only. :moil:

Link to comment
Share on other sites
alianyn
alianyn
Posted
Posted

Reverted back to using the gsly's kexts (changed the correct parameters) and made the changes to the dsdt.

Now i have both percentage AND estimated times showing correctly (yay)

 

BUT when i go to the "about this mac" power descriptor - i get "there was an error while gathering this information".

 

post-273104-0-86035200-1339684252_thumb.png

 

 

kernel log:

14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager: Version 2011.0802 starting
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager: Battery Supported Count(s) 1.
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice: Using ACPI regular battery information method _BIF
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::clearBatteryState: do_update = false
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager::setPowerState: which = 0x1
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::rebuildLegacyIOBatteryInfo called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::pollBatteryState: path = 0x2
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::pollBatteryState: path = 0x1
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager::getBatterySTA called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatterySTA: battery_status = 0x1f
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager::getBatteryBIF called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBIF: acpibat_bif size = 13
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager::getBatteryBST called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: acpibat_bst size = 4
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fPowerUnit	   = 0x1
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: currentStatus    = 0x1
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fCurrentRate	 = 0x758
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fCurrentCapacity = 0x981
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fCurrentVoltage  = 0x37b2
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fAverageRate = 0x758
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice: Battery is discharging.
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::constructAppleSerialNumber called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::rebuildLegacyIOBatteryInfo called

Link to comment
Share on other sites
gsly
gsly
Posted
  • Author
Posted

Reverted back to using the gsly's kexts (changed the correct parameters) and made the changes to the dsdt.

Now i have both percentage AND estimated times showing correctly (yay)

 

BUT when i go to the "about this mac" power descriptor - i get "there was an error while gathering this information".

 

This sounds like the bug with Manufacturer data being blank that apramorbis reported. I've added this to the issues list on github and I might be able to look into this on the weekend.

Link to comment
Share on other sites
alianyn
alianyn
Posted
Posted (edited)

This sounds like the bug with Manufacturer data being blank that apramorbis reported. I've added this to the issues list on github and I might be able to look into this on the weekend.

How can i find out which data is missing? is it something in the _BIF package? i'd like to try and fix it in the dsdt.

 

[EDIT:] i just noticed it's something in the driver. just to check, i switched back to the default appleacpibattery kext - and it happens there as well - so i'm guessing it's something that's in the code of the original driver as well? or is it something i can add to the _BIF method? or another method?

 

[EDIT #2:]can anyone also explain the difference between AppleAcpiBatteryManager(AAPM) & AppleSmartBatteryManager(ASBM)? is ASBM the older one? or is the one being loaded dependent on some dsdt naming convention? or is dependent on smbus/ec? i could not find any details on this anywhere.

Edited by alianyn
Link to comment
Share on other sites
gsly
gsly
Posted
  • Author
Posted

How can i find out which data is missing? is it something in the _BIF package? i'd like to try and fix it in the dsdt.

 

[EDIT:] i just noticed it's something in the driver. just to check, i switched back to the default appleacpibattery kext - and it happens there as well - so i'm guessing it's something that's in the code of the original driver as well? or is it something i can add to the _BIF method? or another method?

 

[EDIT #2:]can anyone also explain the difference between AppleAcpiBatteryManager(AAPM) & AppleSmartBatteryManager(ASBM)? is ASBM the older one? or is the one being loaded dependent on some dsdt naming convention? or is dependent on smbus/ec? i could not find any details on this anywhere.

I have confirmed that the issue in 10.7.4 is an issue with the driver when using the ACPI standard _BIF and _BIX standard. When using these, the driver sets the Manufacturer data to an empty array as its not part of the ACPI standard and it looks like 10.7.4 doesn't like this (I believe it was fine previously). As the manufacturer data is highly dependent on the battery controller used in the battery, I think the best solution is to remove the setting of this attribute. Although my current battery returns some data from this API call, I don't really know what it means as I haven't been able to find a datasheet for it. Also, whatever controller(s) Apple is using returns specific information that System Profiler uses for the Pack Lot Code, PCB Lot Code, Firmware Revision, Hardware Revision and Cell Revision fields. Other controllers would likely not return the same information.

 

In terms of this driver, the original code base was AppleACPIBatteryManager. There are several 3rd party battery related applications that expect to find the battery data under the AppleSmartBatteryManager I/O registry entry as that is where the vanilla Apple driver places it. I simply renamed all of the classes/references to match the Apple driver and magically, all (ones I've tested) of the 3rd party applications now work with this driver. Search this thread for more details.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...