221 replies to this topic

[gsly]

gsly,

I am very interested in porting this to HP Probook 6560b and SONY VPCSE laptops. Using your kext, the battery is detected less than 40% of time during boot up. I don't know what's causing the battery not to be detected the rest of the time. All I changed was the 16 to 8 bit DSDT mod. Any suggestion would be greatly appreciated. I will post the original battery codes if you have time to quickly glance at them for me.

Thanks,

wadalada

Oh my... You have some work to do now that I see the HP DSDT. I didn't think HP could make a DSDT any more buggy than what I found in my DV8, but in looking at this one is just painful...

Ok, the first issue I see is likely related to the kext not seeing your battery (on the HP). Your laptop has two batteries and if you search this thread, you'll see that the kext only supports one battery so you have to modify the DSDT to enable only one of them. Various timing/contention issues during boot likely allows one of the batteries to be seen some of the time (your 40%). Explicitly defining it should fix it.

The second problem I see is that for Device BAT0, the _STA method (Device STAtus) is actually calling Windows Management Instrumentation (WMI) to get the battery's status! In fact, there are a whole bunch of methods that are just calling WMI underneath... Usually a driver under Windows will call WMI to get information, etc. but this is the first time I've seen other devices in the DSDT calling methods in the WMID device. So basically, when this kext on OSX calls the ACPI _STA method on BAT0 (which if finds via the PNP ID in the Info.plist and the Device), ACPI is then calling WMI! Who knows if WMI is breaking the ACPI rules (I bet you it does!) I would suggest you try to determine what it is doing and either replace/rip it out of all the BAT methods and then see how it goes.

As for the Sony, again, two batteries some one needs to be disabled and the EC registers split to 8-bit access.

[wadalada]

gsly,

I don't mind the work as long as there is a general direction. By leaning on experts in this field, I have managed to turned off the ati card to reduce power drain and make a decent working setup. Thanks to you, I have a general direction to start having consistent battery status and will let you know if I make any progress.

Your help is greatly appreciated,

wadalada

[// KURU]

Hello everybody!

First of all thank you for all the great work going on here ;-)
For the first time it seems DSDT edit *must* be used to get proper battery detection and functionality in Lion.

I tried several times to follow your instructions, but I get lost after a while...
my laptop is an HP dv5 1120el.

Is there any DSDT wizard who can check and fix my extracted dsdt.aml ?
Hope so :-D

Thank you ...have a nice day!
[K]

Can't attach with uploader, here's the file: http://www.mediafire...rmycuzry1uoamg4

Edited by KURUKURU, 10 July 2012 - 09:11 AM.

[syntesys]

Hi to all. I have a HP DV5-1013el running OSX Lion. I have problems to apply this dsdt patch to my dsdt file. When i compile i have this error: "Object not found or not accessible from scope ( PCI0.LPCB.EC0.MBST)". When i go in the Lion support section and i have to do the pass "So we can see the SMBus Data Register starts at offset 0x04, so under the EC device add:", i search for EC Device but i have LPC Device and not LPCB. I Attach my dsdt.dsl file. Thanks.

EDIT: I changed values with LPCB with LPC. The compiler doesn't show errors but, on reboot, the "Loading screen" show me a message like this: "Reboot the system. Hold on the power button and restart" but, on restart, it show always this message (also in safemode).

Attached Files

•  mydsdt.dsl.txt   404.21KB   4 downloads

[gsly]

Hi to all. I have a HP DV5-1013el running OSX Lion. I have problems to apply this dsdt patch to my dsdt file. When i compile i have this error: "Object not found or not accessible from scope ( PCI0.LPCB.EC0.MBST)". When i go in the Lion support section and i have to do the pass "So we can see the SMBus Data Register starts at offset 0x04, so under the EC device add:", i search for EC Device but i have LPC Device and not LPCB. I Attach my dsdt.dsl file. Thanks.

Your device path is PCI0.LPC.EC0 but I see you found this. Your SMBus data (SMD0) does in fact start at offset 0x04 as well.

EDIT: I changed values with LPCB with LPC. The compiler doesn't show errors but, on reboot, the "Loading screen" show me a message like this: "Reboot the system. Hold on the power button and restart" but, on restart, it show always this message (also in safemode).

You need to boot in verbose mode (-v) and see what the real issue it. Also, your battery methods are accessing some 16-bit registers which has been known to cause issues on Lion (search this thread) and probably Mountain Lion as well (untested by me). Your GBAI (Get Battery/Adapter Information) method is reading information from the Smart Battery controller via the SMBus, but this is only being used via the Windows WMI functions. Your battery methods are all using registers hard-wired to the embedded controller. So your options are to re-write the existing battery methods to be 8-bit friendly and return the data in the correct units according to the standards defined in the referenced documentation or replace all of that with the methods I have posted specific to HP changing the references to match your device names, etc.

[syntesys]

Your device path is PCI0.LPC.EC0 but I see you found this. Your SMBus data (SMD0) does in fact start at offset 0x04 as well.

Thank you for this!

You need to boot in verbose mode (-v) and see what the real issue it. Also, your battery methods are accessing some 16-bit registers which has been known to cause issues on Lion (search this thread) and probably Mountain Lion as well (untested by me). Your GBAI (Get Battery/Adapter Information) method is reading information from the Smart Battery controller via the SMBus, but this is only being used via the Windows WMI functions. Your battery methods are all using registers hard-wired to the embedded controller. So your options are to re-write the existing battery methods to be 8-bit friendly and return the data in the correct units according to the standards defined in the referenced documentation or replace all of that with the methods I have posted specific to HP changing the references to match your device names, etc.

The PC hangs up when run the kext in the first post. Verbose mode show to me "AppleACPIBat" and it stops. Now, i have to change this:

Field (ERAM, ByteAcc, Lock, Preserve)
{
	    SMPR,   8,							    // SMBus Protocol Register
	    SMST,   8,							    // SMBus Status Register
	    SMAD,   8,							    // SMBus Address Register
	    SMCM,   8,							    // SMBus Command Register
	    SMD0,   256,						    // SMBus Data Register[0-31] ( 32 byte buffer)
	    BCNT,   8,							    // SMBus Block Count Register
	    SMAA,   8,							    // SMBus Alarm Address Register
	    SAD0,   8,							    // SMBus Alarm Data Register[0]
	    SAD1,   8,							    // SMBus Alarm Data Register[1]
	    ...

with this?:

// Define 8-bit fields for accessing SMBus data registers [0-31]
Field (ERAM, ByteAcc, Lock, Preserve)
{
					    Offset (0x04),
	    SM00,   8,
	    SM01,   8,
	    SM02,   8,
	    SM03,   8,
	    SM04,   8,
	    SM05,   8,
	    SM06,   8,
	    SM07,   8,
	    SM08,   8,
	    SM09,   8,
	    SM10,   8,
	    SM11,   8,
...

Thank you.

[s.goten]

after adding codes in dsdt now I have wrong informations about my my battery (wrong % charging, wrong time charging and message: battery is damaged)

[syntesys]

Thank you for this!


The PC hangs up when run the kext in the first post. Verbose mode show to me "AppleACPIBat" and it stops. Now, i have to change this:

Field (ERAM, ByteAcc, Lock, Preserve)
{
	 SMPR, 8,							 // SMBus Protocol Register
	 SMST, 8,							 // SMBus Status Register
	 SMAD, 8,							 // SMBus Address Register
	 SMCM, 8,							 // SMBus Command Register
	 SMD0, 256,						 // SMBus Data Register[0-31] ( 32 byte buffer)
	 BCNT, 8,							 // SMBus Block Count Register
	 SMAA, 8,							 // SMBus Alarm Address Register
	 SAD0, 8,							 // SMBus Alarm Data Register[0]
	 SAD1, 8,							 // SMBus Alarm Data Register[1]
	 ...

with this?:

// Define 8-bit fields for accessing SMBus data registers [0-31]
Field (ERAM, ByteAcc, Lock, Preserve)
{
					 Offset (0x04),
	 SM00, 8,
	 SM01, 8,
	 SM02, 8,
	 SM03, 8,
	 SM04, 8,
	 SM05, 8,
	 SM06, 8,
	 SM07, 8,
	 SM08, 8,
	 SM09, 8,
	 SM10, 8,
	 SM11, 8,
...

Thank you.

Up!

[RehabMan]

You guys may have noticed this already, but I thought I'd mention my fork of glsy's excellent battery manager. My version fixes some bugs (two of which are mentioned as issues on glsy's original github repo). The activity level on glsy's github looked pretty dormant, so I just went ahead made a fork and fixed them.

In addition, I merged some of the features in zprood's ACPI battery manager (see: http://www.insanelym...nager-for-lion/). And added a few features of my own.

The fixes are mostly documented in the source as are the additional features. I also tried to commit each change to the repo as separate, small changes so it is easy to see what the changes are.

This has been well tested on the ProBook forum on tonymacx86.com. Here is the link for tracking: http://www.tonymacx8...-batteries.html

GitHub link: https://github.com/R...-Battery-Driver
(builds are available in the 'Downloads' section)

Here is a rundown:

Fixes:
- If no battery was present at the time of startup, status would incorrectly display "Power Source: Battery" instead of "Power Source: Power Adapter"
- There was an error in the handling of the fInitialPollCountdown where it was never decremented, causing full battery info to be retrieved each time. The intention was to only poll 5 times after driver start.
- Calculations were incorrect if ACPI methods return data in milliwatts as allowed by ACPI spec.
- System Profiler shows an error instead of battery information. Removed some unnecessary code that caused this error.
- Battery charged percentage was shown as 100% even if not fully charged. There are several valid reasons why the battery may be "not charging" but not fully charged. One is to reduce unnecessary cycles on the battery. Others would be battery mal-function or overheating.

Added features:
- Add zprood's technique of adding battery cycle count as extra field in _BIF return package. This allows easy add of cycle count using only a DSDT edit to _BIF method.
- Used similar technique to add battery temperature as extra field in _BIF return package.
- Added code to test for existence of _BIX and _BBIX methods before using them, even if the Info.plist says "Yes." This allows the same Info.plist to be used in laptops that both have _BIX/_BBIX methods and those that don't (for a while I kept a separate branch for ProBook with just a different Info.plist -- it became a pain to maintain the two separate branches, so I did this to avoid it)
- Added code to set low/critical battery alarms as battery is discharged beyond these levels as specified by ACPI _BIF method.

As these changes were made I attempted to always bring each fix to the _BIX/_BBIX related code. But I have to admit I have not been able to test them as I do not have these methods in my ProBook 4530s DSDT. My ProBook DSDT also does not use watts, so I have not been able to personally test my code for converting watts to amps. This code has been verified as working by at least one Sony laptop user though.

[gsly]

You guys may have noticed this already, but I thought I'd mention my fork of glsy's excellent battery manager. My version fixes some bugs (two of which are mentioned as issues on glsy's original github repo). The activity level on glsy's github looked pretty dormant, so I just went ahead made a fork and fixed them.

Thanks RehabMan. I actually stumbled across your thread and repo last week while researching some ML booting issues on my new Ultrabook. As mentioned, I had noted a couple of bugs on my repo that I was planning to fix once I can get ML stable on the new laptop. I briefly reviewed your fixes and they look good so if you don't mind, I'll probably use your fixes in my repo with credit of course.

In addition, I merged some of the features in zprood's ACPI battery manager (see: http://www.insanelym...nager-for-lion/). And added a few features of my own.

I don't quite agree with the zprood changes to _BIF as this violates the ACPI standard. On of the primary goals of this driver is to read the information from the battery in a standard/documented way via _BIF, _BST and _BIX. By doing this, users just have to make the DSDT return the information as required by the spec and it should work on any laptop.
However, as the ACPI standard doesn't support some of the battery information that is available from the SBS standard, I did implement the non-standard BBIX optional method in the driver for those users that have SBS and wanted to return the additional information. Even without SBS, if a laptop EC returns extra information, it should be placed in the BBIX information structure.
I hope this makes sense, but if not you might want to read the ACPI/SBS specification documents referenced in the original post.

The fixes are mostly documented in the source as are the additional features. I also tried to commit each change to the repo as separate, small changes so it is easy to see what the changes are.

Thanks, yes I was able to follow what you did in your repo commits. Good job.

This has been well tested on the ProBook forum on tonymacx86.com. Here is the link for tracking: http://www.tonymacx8...-batteries.html

GitHub link: https://github.com/R...-Battery-Driver
(builds are available in the 'Downloads' section)

Here is a rundown:

Fixes:
- If no battery was present at the time of startup, status would incorrectly display "Power Source: Battery" instead of "Power Source: Power Adapter"
- There was an error in the handling of the fInitialPollCountdown where it was never decremented, causing full battery info to be retrieved each time. The intention was to only poll 5 times after driver start.
- Calculations were incorrect if ACPI methods return data in milliwatts as allowed by ACPI spec.
- System Profiler shows an error instead of battery information. Removed some unnecessary code that caused this error.
- Battery charged percentage was shown as 100% even if not fully charged. There are several valid reasons why the battery may be "not charging" but not fully charged. One is to reduce unnecessary cycles on the battery. Others would be battery mal-function or overheating.

Added features:
- Add zprood's technique of adding battery cycle count as extra field in _BIF return package. This allows easy add of cycle count using only a DSDT edit to _BIF method.
- Used similar technique to add battery temperature as extra field in _BIF return package.
- Added code to test for existence of _BIX and _BBIX methods before using them, even if the Info.plist says "Yes." This allows the same Info.plist to be used in laptops that both have _BIX/_BBIX methods and those that don't (for a while I kept a separate branch for ProBook with just a different Info.plist -- it became a pain to maintain the two separate branches, so I did this to avoid it)
- Added code to set low/critical battery alarms as battery is discharged beyond these levels as specified by ACPI _BIF method.

As these changes were made I attempted to always bring each fix to the _BIX/_BBIX related code. But I have to admit I have not been able to test them as I do not have these methods in my ProBook 4530s DSDT. My ProBook DSDT also does not use watts, so I have not been able to personally test my code for converting watts to amps. This code has been verified as working by at least one Sony laptop user though.

Up!

Yes, if you are running Lion or ML, you'll need to access the SMBus data via the EC in an 8-bit fashion, otherwise the Apple ACPI kext will throw and error. Boot in verbose or debug mode and look at the system logs. All of this has been posted in this thread.

after adding codes in dsdt now I have wrong informations about my my battery (wrong % charging, wrong time charging and message: battery is damaged)

Then you'll have to fix that. If your DSDT returns bogus values to the driver, the driver will publish (within the specs) what it gets to the Apple power management layer and its this layer that calculates the "health" of your battery. For example, if you return a cycle count of >100, the power management layer is going to calculate your battery health as bad and tell you you need to replace the battery because clearly any battery that has >100 recharge cycles is likely kaput!

[RehabMan]

Thanks RehabMan. I actually stumbled across your thread and repo last week while researching some ML booting issues on my new Ultrabook. As mentioned, I had noted a couple of bugs on my repo that I was planning to fix once I can get ML stable on the new laptop. I briefly reviewed your fixes and they look good so if you don't mind, I'll probably use your fixes in my repo with credit of course.

Don't mind at all. It is what open source is about.

I don't quite agree with the zprood changes to _BIF as this violates the ACPI standard. On of the primary goals of this driver is to read the information from the battery in a standard/documented way via _BIF, _BST and _BIX. By doing this, users just have to make the DSDT return the information as required by the spec and it should work on any laptop.
However, as the ACPI standard doesn't support some of the battery information that is available from the SBS standard, I did implement the non-standard BBIX optional method in the driver for those users that have SBS and wanted to return the additional information. Even without SBS, if a laptop EC returns extra information, it should be placed in the BBIX information structure.
I hope this makes sense, but if not you might want to read the ACPI/SBS specification documents referenced in the original post.

It makes sense... it was a conscious decision to deal with a practical matter.

I don't 100% agree with the zprood extensions, but the pragmatist in me says that it is an easier way to implement the functionality and it does no harm (you don't have to return the extra information in _BIF -- it is an option). In particular, I don't really want to explain to a bunch of people how to code the extra DSDT methods. Plus, I was dealing with a bit of history there (the folks on the ProBook forum were already using the zprood technique and their DSDTs were already out there). It was the easy way without providing a bunch of churn for people who don't know how to deal with it.

One of these days, I'll sit down and write the extra DSDT methods for the ProBook and put them in my set of patches.

Thanks for the feedback and good luck on merging...

[RehabMan]

... I actually stumbled across your thread and repo last week while researching some ML booting issues on my new Ultrabook. As mentioned, I had noted a couple of bugs on my repo that I was planning to fix once I can get ML stable on the new laptop. I briefly reviewed your fixes and they look good so if you don't mind, I'll probably use your fixes in my repo with credit of course.

BTW, what Ultrabook did you buy? I'm contemplating purchasing one as well, and might try to hack it. But so far I'm undecided on which one I'm going to purchase. At this point, even a MBA is a possibility (no hacking necessary there, but I'm worried it will suck as a Windows machine).

And... sorry for the off-topic...

[syntesys]

Yes, if you are running Lion or ML, you'll need to access the SMBus data via the EC in an 8-bit fashion, otherwise the Apple ACPI kext will throw and error. Boot in verbose or debug mode and look at the system logs. All of this has been posted in this thread.

I didn't understand... I have to substitute the code of first quote with the code of second quote? Thanks.

[gsly]

BTW, what Ultrabook did you buy? I'm contemplating purchasing one as well, and might try to hack it. But so far I'm undecided on which one I'm going to purchase. At this point, even a MBA is a possibility (no hacking necessary there, but I'm worried it will suck as a Windows machine).

And... sorry for the off-topic...

I've got the Asus UX32VD, upgraded to 10GB RAM and a 512GB SSD. Super fast with these mods and at the moment I have Windows 7 x64, Ubuntu x64 and Mountain Lion booting on it using Clover (full UEFI) and GPT. Clover is the future as everything is going UEFI but its still a work in progress but I already think its better than Chameleon now, but there is still a bunch of work to get the UX32VD booting 100% with all hardware, but it should be doable, including smart battery support.

I didn't understand... I have to substitute the code of first quote with the code of second quote? Thanks.

If your DSDT has the first quote, leave it. Add the second quote and change all of the methods that are called from _BST, _BIF, _BIX to access the registers in the second quote (i.e. in 8-bit fashion) and not the SMD0 register (256 bit). If you don't understand this, you need to read and understand the documentation quoted in the first post first.

[Alex Auditore]

Could you help me to solve my abominable problem with the battery? -> http://www.insanelym...batterymanager/

[Jingu]

Would it be difficult to create a 64-bit version of AppleSmartBatteryManager?

It works flawless for me in 32-bit in Lion with my Asus Core i7 laptop, but in Mountain Lion everything has to be 64-bit. Battery meter is about the only thing that I don't have working in Mountain Lion.

[RehabMan]

Would it be difficult to create a 64-bit version of AppleSmartBatteryManager?

It works flawless for me in 32-bit in Lion with my Asus Core i7 laptop, but in Mountain Lion everything has to be 64-bit. Battery meter is about the only thing that I don't have working in Mountain Lion.

I thought this version here was both 32-bit and 64-bit...

But my version is working fine in ML: https://github.com/R...river/downloads

[gsly]

Would it be difficult to create a 64-bit version of AppleSmartBatteryManager?

It works flawless for me in 32-bit in Lion with my Asus Core i7 laptop, but in Mountain Lion everything has to be 64-bit. Battery meter is about the only thing that I don't have working in Mountain Lion.

As mentioned in the first post, this is a 32/64-bit binary. Perhaps in Lion you didn't fix your DSDT but rather used an AppleACPIPlatform "roll-back" to make it work? The ML ACPI support is even stricter so you likely need to do some DSDT work.

[Jingu]

gsly, you're right. I re-read the first post and it does say that AppleSmartBatteryManager was compiled for 32/64 bit.

Rehabman, thanks for the 32/64 bit version, but I believe the problem is in the calculations part in my dsdt.

So, my problem is adjusting the dsdt to read the battery characteristics in 64-bit. It works perfect in Lion 32-bit, but It seems that the battery characteristics are read differently in 64-bit. I imagine that if I can get it to work in Lion 64-bit, then I stand a good chance to get it to work in Mountain Lion 64-bit too.

Debug version of AppleSmartBatteryManager in Lion 32-bit and 64-bit:

Lion 32-bit
kernel[0]: AppleSmartBattery::pollingTimeOut called
kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x2
kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x1
kernel[0]: AppleSmartBatteryManager::getBatterySTA called
kernel[0]: AppleSmartBattery::setBatterySTA: battery_status = 0x1f
kernel[0]: AppleSmartBatteryManager::getBatteryBIF called
kernel[0]: AppleSmartBattery::setBatteryBIF: acpibat_bif size = 13
kernel[0]: AppleSmartBatteryManager::getBatteryBBIX called
kernel[0]: AppleSmartBatteryManager::getBatteryBST called
kernel[0]: AppleSmartBattery::setBatteryBST: acpibat_bst size = 4
kernel[0]: AppleSmartBattery::setBatteryBST: fPowerUnit	 = 0x1
kernel[0]: AppleSmartBattery::setBatteryBST: currentStatus = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentRate	 = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0x48c
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentVoltage = 0x30bd
kernel[0]: AppleSmartBattery::setBatteryBST: adjusted fCurrentRate = 0x246
kernel[0]: AppleSmartBattery::setBatteryBST: fAverageRate = 0x246
kernel[0]: AppleSmartBattery: Battery is charged.
kernel[0]: AppleSmartBattery::constructAppleSerialNumber called
kernel[0]: AppleSmartBattery::rebuildLegacyIOBatteryInfo called

Lion 64 bit
kernel[0]: AppleSmartBattery::pollingTimeOut called
kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x2
kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x1
kernel[0]: AppleSmartBatteryManager::getBatterySTA called
kernel[0]: AppleSmartBattery::setBatterySTA: battery_status = 0x1f
kernel[0]: AppleSmartBatteryManager::getBatteryBIF called
kernel[0]: AppleSmartBattery::setBatteryBIF: acpibat_bif size = 13
kernel[0]: AppleSmartBattery: Error: Capacity Read Zero (0)
kernel[0]: AppleSmartBatteryManager::getBatteryBBIX called
kernel[0]: AppleSmartBatteryManager::getBatteryBST called
kernel[0]: AppleSmartBattery::setBatteryBST: acpibat_bst size = 4
kernel[0]: AppleSmartBattery::setBatteryBST: fPowerUnit	 = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: currentStatus = 0x2
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentRate	 = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentVoltage = 0xffffff01
kernel[0]: AppleSmartBattery::setBatteryBST: Calculating for WATTS
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentRate = 0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0
kernel[0]: AppleSmartBattery::setBatteryBST: adjusted fCurrentRate = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fAverageRate = 0x0
kernel[0]: AppleSmartBattery: Battery is charging.
kernel[0]: AppleSmartBattery::constructAppleSerialNumber called
kernel[0]: AppleSmartBattery::rebuildLegacyIOBatteryInfo called

[RehabMan]

It is weird -- seems like you are using a different DSDT in 32-bit vs. 64-bit. Your 32-bit install DSDT is working. And your 64-bit is broken...

Are you sure you are using the same DSDT in each case??
I would check your bdmesg to be sure your DSDT is loading from where you think it is and that it is the same as the one your 32-bit install is using...

I don't really know too much about changes to ACPIPlatform that might have happened between 32-bit and 64-bit. But that could be the issue as well... maybe the 32-bit ACPI code in even Lion is "more capable" than the 64-bit code.

But this thread covers the main known issue pretty well: where 16-bit EC registers cannot be accessed and must be converted to access 8-bits at a time. This requires a close look at the DSDT code involved in battery status, and a little bit of experimentation with DSDT code changes...

gsly, you're right. I re-read the first post and it does say that AppleSmartBatteryManager was compiled for 32/64 bit.

Rehabman, thanks for the 32/64 bit version, but I believe the problem is in the calculations part in my dsdt.

So, my problem is adjusting the dsdt to read the battery characteristics in 64-bit. It works perfect in Lion 32-bit, but It seems that the battery characteristics are read differently in 64-bit. I imagine that if I can get it to work in Lion 64-bit, then I stand a good chance to get it to work in Mountain Lion 64-bit too.

Debug version of AppleSmartBatteryManager in Lion 32-bit and 64-bit:

Lion 32-bit
kernel[0]: AppleSmartBattery::pollingTimeOut called
kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x2
kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x1
kernel[0]: AppleSmartBatteryManager::getBatterySTA called
kernel[0]: AppleSmartBattery::setBatterySTA: battery_status = 0x1f
kernel[0]: AppleSmartBatteryManager::getBatteryBIF called
kernel[0]: AppleSmartBattery::setBatteryBIF: acpibat_bif size = 13
kernel[0]: AppleSmartBatteryManager::getBatteryBBIX called
kernel[0]: AppleSmartBatteryManager::getBatteryBST called
kernel[0]: AppleSmartBattery::setBatteryBST: acpibat_bst size = 4
kernel[0]: AppleSmartBattery::setBatteryBST: fPowerUnit	 = 0x1
kernel[0]: AppleSmartBattery::setBatteryBST: currentStatus = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentRate	 = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0x48c
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentVoltage = 0x30bd
kernel[0]: AppleSmartBattery::setBatteryBST: adjusted fCurrentRate = 0x246
kernel[0]: AppleSmartBattery::setBatteryBST: fAverageRate = 0x246
kernel[0]: AppleSmartBattery: Battery is charged.
kernel[0]: AppleSmartBattery::constructAppleSerialNumber called
kernel[0]: AppleSmartBattery::rebuildLegacyIOBatteryInfo called

Lion 64 bit
kernel[0]: AppleSmartBattery::pollingTimeOut called
kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x2
kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x1
kernel[0]: AppleSmartBatteryManager::getBatterySTA called
kernel[0]: AppleSmartBattery::setBatterySTA: battery_status = 0x1f
kernel[0]: AppleSmartBatteryManager::getBatteryBIF called
kernel[0]: AppleSmartBattery::setBatteryBIF: acpibat_bif size = 13
kernel[0]: AppleSmartBattery: Error: Capacity Read Zero (0)
kernel[0]: AppleSmartBatteryManager::getBatteryBBIX called
kernel[0]: AppleSmartBatteryManager::getBatteryBST called
kernel[0]: AppleSmartBattery::setBatteryBST: acpibat_bst size = 4
kernel[0]: AppleSmartBattery::setBatteryBST: fPowerUnit	 = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: currentStatus = 0x2
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentRate	 = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentVoltage = 0xffffff01
kernel[0]: AppleSmartBattery::setBatteryBST: Calculating for WATTS
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentRate = 0
kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0
kernel[0]: AppleSmartBattery::setBatteryBST: adjusted fCurrentRate = 0x0
kernel[0]: AppleSmartBattery::setBatteryBST: fAverageRate = 0x0
kernel[0]: AppleSmartBattery: Battery is charging.
kernel[0]: AppleSmartBattery::constructAppleSerialNumber called
kernel[0]: AppleSmartBattery::rebuildLegacyIOBatteryInfo called