Jump to content

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


  • Please log in to reply
227 replies to this topic

#221
Jingu

Jingu

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 119 posts
Okay. For my Asus M60J:

Rehabman's new AppleSmartBatteryManager works perfect in Mountain Lion and Lion 64-bit, but only if I use the Snow Leopard 10.6.8 AppleACPIPlatform.

AppleSmartBatteryManager just doesn't work in 64-bit with vanilla AppleACPIPlatform from Lion and Mountain Lion, but it works in 32-bit with Vanilla Lion AppleACPIPlatform.

#222
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 1,356 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

Okay. For my Asus M60J:

Rehabman's new AppleSmartBatteryManager works perfect in Mountain Lion and Lion 64-bit, but only if I use the Snow Leopard 10.6.8 AppleACPIPlatform.

AppleSmartBatteryManager just doesn't work in 64-bit with vanilla AppleACPIPlatform from Lion and Mountain Lion, but it works in 32-bit with Vanilla Lion AppleACPIPlatform.


It is because newer versions of 64-bit AppleACPIPlatform.kext are very picky that EC access from DSDT code is only 8-bit. So you have to change the DSDT to convert all access to EC registers larger than 8-bit to use only 8-bit access. See post #1 of this thread for examples. The specifics will depend on the code in your DSDT.

#223
fingerr

fingerr

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 260 posts
  • Gender:Male
  • Location:Poland

ASUS NOTEBOOK. Working both in Snow Leopard 10.6.8 and Lion 10.7.2

Yes. Got gsly's AppleSmartBatteryManager to work on my Asus M60J.

In the interest of helping other Asus notebook owners with similar dsdts, I'll provide how I made it happen. But, it is not my intent to steal gsly's glory. All this was made possible thanks to him. I'm only adapting his project to my Asus notebook. Also thanks to bcc9 for deriving the formula for taking a 16-bit reference and breaking it down into high-byte and low-byte to do byte (8-bit) references.

Back in post# 47, gsly provided abundant comments for another Asus notebook dsdt, the G53S. My BAT0 dsdt is nearly identical. So, all those comments on that Asus dsdt were really helpful in helping me figuring out what was going on with my own dsdt. Thanks gsly for doing that.

My Asus doesn't seem to use much SMBus access to the battery register sensors. It's making much use of EC access to the battery registers.

The Asus notebook BAT0 dsdt is quite different from the HP BAT0 dsdt. It has several more Method subroutines and it does all kinds of calculations based on what it detects. In the end, it does quite a good job of returning the battery values in accordance with the ACPI 3.x specs. The problem is that it was set to convert the units mAh to mWh and 2 things were happening wrong with that conversion. Design Capacity and Last Full Charge Capacity were kept in mAh and were 1000 times too small while the Current Capacity was converted to mWh. That created remaining percentages of over 115,000% and the inability to calculate remaining time. So, my goal was to prevent the conversion and fix it so it returns mAh units.

If the original Methods FBIF, CBIF and CBST in your Asus dsdt look like below, then the modification should work for you.

CODE

// If the Methods FBIF, CBIF and CBST in your original Asus notebook battery look like below, the
// recommended modifications shoud work for you

Method (FBIF, 5, NotSerialized)
{
Store (Arg0, PUNT)
Store (Arg1, Local1)
Store (Arg2, Local2)
If (LEqual (PUNT, 0x00))
{
Multiply (Local1, 0x0A, Local1)
Multiply (Local2, 0x0A, Local2)
}

Store (Arg0, Index (PBIF, 0x00))
Store (Local1, Index (PBIF, 0x01))
Store (Local2, Index (PBIF, 0x02))
Store (Local2, LFCC)
Store (Arg3, Index (PBIF, 0x03))
Store (Arg4, Index (PBIF, 0x04))
Divide (Local1, 0x0A, Local3, Local5)
Store (Local5, Index (PBIF, 0x05))
Divide (Local1, 0x64, Local3, Local6)
Store (Local6, Index (PBIF, 0x06))
Store (Local6, LOW2)
Divide (Local1, 0x64, Local3, Local7)
Store (Local7, Index (PBIF, 0x07))
Store (Local7, Index (PBIF, 0x08))
}

Method (CBIF, 0, NotSerialized)
{
If (PUNT)
{
Store (DerefOf (Index (PBIF, 0x04)), Local0)
Add (Local0, 0x01F4, Local0)
Divide (Local0, 0x03E8, Local1, DVOT)
Store (Zero, Index (PBIF, 0x00))
Multiply (DerefOf (Index (PBIF, 0x01)), DVOT, Index (PBIF, 0x01
))
Multiply (DerefOf (Index (PBIF, 0x02)), DVOT, Index (PBIF, 0x02
))
Multiply (DerefOf (Index (PBIF, 0x05)), DVOT, Index (PBIF, 0x05
))
Multiply (DerefOf (Index (PBIF, 0x06)), DVOT, Index (PBIF, 0x06
))
Multiply (DerefOf (Index (PBIF, 0x07)), DVOT, Index (PBIF, 0x07
))
Multiply (DerefOf (Index (PBIF, 0x08)), DVOT, Index (PBIF, 0x08
))
}
}

Method (CBST, 0, NotSerialized)
{
If (PUNT)
{
Multiply (DerefOf (Index (PBST, 0x01)), DVOT, Index (PBST, 0x01
))
Multiply (DerefOf (Index (PBST, 0x02)), DVOT, Index (PBST, 0x02
))
}
}


1) IN SNOW LEOPARD

-mWh Units
If you're fine with having the units in mWh, then all you need to do is change Store (Zero, Index (PBIF, 0x00)) to Store (One, Index (PBIF, 0x00)) in the Method CBIF. That's it! iStat will report a battery current about 10 times too high, but the capacity values and remaining times and percentages will all be accurate.

-mAh Units
This is the preferred unit in Mac OS X. It requires a little editing of Methods FBIF, CBIF and CBST. For some reason, when retrieving values in mAh, the capacities will be 1.85% too small. 1.85% doesn't sound like much, but my capacities are in the 4000 mAh range. That was causing them to be about 79 mAh too small compared to the mAh values in Windows 7 with BatteryEater Pro. It was also causing a little percentage anomaly. Percentages would go straight from 100% down to 97% when discharging and straight from 97% to 100% when recharging, never seeing 98% and 99%. That's why I'm applying a 1.85% correction (that's times 185 divided by 10,000)

Here's the Mehod FBIF, CBIF and CBST edits to accurately have to units in mAh. Just replace your Methods FBIF, CBIF and CBST with my corrected ones.

attachicon.gifAsus_SnowLeo_Corrected.dsl.zip


2) LION 10.7.2

-mAh Units
Okay. I was in for a surprise on this one. My battery EC registers are all 16-bit at Offset (0xA0) from B0VL to B0DV. They're all mirrored by B1VL to B1DV also 16-bit. But those B1xx variables are never executed in the conditional loops, so the battery EC registers that matter are the B0xx. I converted all of those to 8-bit reference based on bcc9's method.

I did this for the all 8 battery B0xx registers and one B0SN register. With all that conversion to 8-bit, gsly's AppleSmartBattery was still working flawless in Snow Leopard, as a testimony that my 8-bit conversion was done correctly. But it wasn't working Lion, all I had was 0, -1 and unknown for the values.

Then I made a puzzling discovery. I discovered that the only reason why the Fill Battery Information Method (Method FBIF) or Method _BIF was failing in Lion, was not because the battery EC registers were accessed in 16-bit, but because the Method that extracts the Battery OEM information string (Method BIF9) has an incompatibility with Lion and that alone was causing the whole Method FBIF or Method _BIF to fail. There's something incompatible with this Method BIF9

CODE
Method (BIF9, 0, NotSerialized)
{
Name (BSTR, Buffer (0x20) {})
Store (SMBR (RDBL, BADR, 0x21), Local0)
If (LNotEqual (DerefOf (Index (Local0, Zero)), Zero))
{
Store (MNAM, BSTR)
Store (Zero, Index (BSTR, 0x04))
}
Else
{
Store (DerefOf (Index (Local0, 0x02)), BSTR)
Store (Zero, Index (BSTR, DerefOf (Index (Local0, One))))
}

Return (BSTR)
}

I don't know how to fix that one.

*** EDIT 26 Nov **: SOLVED!! With the help of gsly rewriting Method SMBR to read Word and Block (string) 8-bit at a time, combined with deleting one line in Method SMBR, SmartBattery fully works now in Lion and can extract the battery name string without crashing.

Below is my dsdt corrected for Lion on my Asus M60J. Attached are also the complete edit instructions that should apply to all Asus core i3/i5/i7 Notebooks.

attachicon.gifAsus_Coreix_Lion_Edits.zipattachicon.gifAsusM60J_Lion.zip

 

 

Hi all,

 

I've tried to modify DSDS of my Asus U30Jc i5-560M equipped notebook for Mountain Lion and result is battery showing 0% and remaining time says "Calculating", but I can see info about battery in system profiler. Values in system profiler seems to be cosmic:

- Charge remainig: 429445

- Amperage (mA): 429645937

- Voltage (mV): -230

 

Without any changes made to stock DSDT battery shows 0%, no battery information in system profiler, but remaining time seems to be caltulated properly.

 

Can someone have a look at my DSDT (DSDT2IGPUBAT2.dsl) and check what can be the cause?

 

Thanks in advance and best regards,

fingerr.

Attached Files



#224
wrk73

wrk73

    InsanelyMac Protégé

  • Members
  • Pip
  • 29 posts

This is an old thread, does it still work on 10.9?



#225
gsly

gsly

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:The Great White North
 

This is an old thread, does it still work on 10.9?

 
You tell us! The hardware in your machine hasn't changed so as long as Apple hasn't deprecated anything in the API used, you should be able to get it to work from the information in this thread.

I hope to upgrade my development laptop to 10.9 in the near future and when I do, I'll try to make an effort to incorporate the various fixes (RehabMan) and compile a new fresh version.

#226
TheTourist

TheTourist

    InsanelyMac Protégé

  • Members
  • Pip
  • 31 posts
  • Gender:Male
  • Location:Boston

Running last version.

Doesn't show current battery level.

 

Attached Files



#227
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 1,356 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

Running last version.
Doesn't show current battery level.


You need DSDT patches. And it looks like the ASUS patch I wrote is a match. See: https://github.com/R...ptop-DSDT-Patch

#228
gsly

gsly

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:The Great White North

I installed 10.9 Mavericks on my HP DV8 today, removed the Apple kext and dropped in the kext from this thread and it worked fine.  I'll try to get my development environment upgraded, apply RehabMan's patches/fixes, update the source repo and compile an upgrade. Might get it done by Xmas :(







0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy