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

[Jingu]

It's indeed strange that battery readings cannot be accessed in 64 bit for some reason. I've successfully converted the 16 bit EC register access to 8-bit at a time access.

 

I'm certain it is the same dsdt for both 32 bit and 64 bit. As you mentionned, the 32-bit code might be more forgiven with inaccuracies.

[RehabMan]

It's indeed strange that battery readings cannot be accessed in 64 bit for some reason. I've successfully converted the 16 bit EC register access to 8-bit at a time access.

 

I'm certain it is the same dsdt for both 32 bit and 64 bit. As you mentionned, the 32-bit code might be more forgiven with inaccuracies.

 

Did you check your bdmesg output. 'bdmesg | grep -y dsdt' would be a good idea...

[gsly]

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...

Also review any register manipulation in the DSDT (bit shifting, masking, multiplication, division, etc) to ensure it is 64-bit compliant. Also compile the DSDT with the latest IASL compiler (64-bit) to ensure the AML is 64-bit aware. Look at the Revision field for the DSDT (See section 5.2.11.1 of the ACPI 5.0 specification) as well.

[Jingu]

gsly and Rehabman,

 

Thanks. I did "bdmesg -y | grep -y dsdt". I can confirm that the same dsdt is loading in 32-bit and 64-bit. Normally, the problem is with a kext not being 64-bit compatible. This is the first I'm seeing that the problem might be in the dsdt.

 

** EDIT ** Bad news. I consulted the ACPI Spec 5.0 document. It says that the DSDT ComplianceRevision sets the global integer width for all integers, including integers in the SSDTs. My DSDT ComplianceRevision is 1, so all integers are restricted to 32-bit width.

 

Original reference from ACPI Spec v5.0

Note: For compatibility with ACPI versions before ACPI 2.0, the bit width of Integer objects is dependent on the ComplianceRevision of the DSDT. If the ComplianceRevision is less than 2, all integers are restricted to 32 bits. Otherwise, full 64-bit integers are used. The version of the DSDT sets the global integer width for all integers, including integers in SSDTs.

 

[Jingu]

Okay. I made some progress with getting AppleSmartBatteryManager to work in Lion 64-bit.

 

My dsdt ComplianceRevision is 1 (32-bit width integers). However, I discovered that I can force the dsdt header ComplianceRevision to any number I want.

 

From the iasl instructions:

 

AML Code Generation:

-r<Revision> Override table header Revision (1-255)

 

So with:

 

iasl -r2sa dsdt.dsl

 

I forced the dsdt header ComplianceRevision to 2. But it's still not working. At least with ComplianceRevision 2, now I get battery numbers instead of zeros like in revision 1, but it's still the wrong numbers.

 

It should have worked even with ComplianceRevision 1, because according to the ACPI Spec manual, the battery specs are in DWORD format (32-bit).

 

I decided to try an old Snow Leopard install in 64-bit and surprise!: AppleSmartBatteryManager works fine in Snow Leopard 64-bit, whether the ComplianceRevision is 1 or 2.

 

Now, the only difference between the Snow Leopard dsdt and the Lion dsdt is that in Lion there is a conversion to 8-bit EC access with Zprod's formula:

 

Method (B1B2, 2, NotSerialized)
{
 Or (ShiftLeft (Arg1, 0x08), Arg0, Local0)
 Return (Local0)
}

 

Where Arg1 is the high 8-bit EC number and Arg0 is the low 8-bit EC number. Those are 8-bit numbers.

 

Maybe that's where the problem is in Lion. But, I'm using the same formula in Lion to read the fan rpm with 8-bit EC access and fan rpm reading works fine in lion 32-bit or 64-bit.

 

Something tells me that the problem is still with the conversion to 8-bit EC access. Maybe that conversion adds extra bits that throw off the calculations.

 

Like for example, the formula to retrieve the power units is:

 

Method (BIF0, 0, NotSerialized)
 {
	 If (ECAV ())
	 {
		 If (BSLF)
		 {
			 Store (B1MD, Local0)
		 }
		 Else
		 {
			 Store (B1B2 (BMD0, BMD1), Local0)
		 }
		 If (LNotEqual (Local0, 0xFFFF))
		 {
			 ShiftRight (Local0, 0x0F, Local1)
			 And (Local1, One, Local1)
			 XOr (Local1, One, Local0)
		 }
	 }
	 Else
	 {
		 Store (Ones, Local0)
	 }
	 Return (Local0)
 }

 

Where BMD0 and BMD1 are the low and high 8-bit EC numbers for the power units and the value is returned in Local0. Works fine in Lion 32-bit, but doesn't work in Lion 64-bit.

[RehabMan]

Okay. I made some progress with getting AppleSmartBatteryManager to work in Lion 64-bit.

 

My dsdt ComplianceRevision is 1 (32-bit width integers). However, I discovered that I can force the dsdt header ComplianceRevision to any number I want.

 

From the iasl instructions:

 

 

 

So with:

 

 

 

I forced the dsdt header ComplianceRevision to 2. But it's still not working. At least with ComplianceRevision 2, now I get battery numbers instead of zeros like in revision 1, but it's still the wrong numbers.

 

It should have worked even with ComplianceRevision 1, because according to the ACPI Spec manual, the battery specs are in DWORD format (32-bit).

 

I decided to try an old Snow Leopard install in 64-bit and surprise!: AppleSmartBatteryManager works fine in Snow Leopard 64-bit, whether the ComplianceRevision is 1 or 2.

 

Now, the only difference between the Snow Leopard dsdt and the Lion dsdt is that in Lion there is a conversion to 8-bit EC access with Zprod's formula:

 

Method (B1B2, 2, NotSerialized)
{
 Or (ShiftLeft (Arg1, 0x08), Arg0, Local0)
 Return (Local0)
}

 

Where Arg1 is the high 8-bit EC number and Arg0 is the low 8-bit EC number. Those are 8-bit numbers.

 

Maybe that's where the problem is in Lion. But, I'm using the same formula in Lion to read the fan rpm with 8-bit EC access and fan rpm reading works fine in lion 32-bit or 64-bit.

 

Something tells me that the problem is still with the conversion to 8-bit EC access. Maybe that conversion adds extra bits that throw off the calculations.

 

Like for example, the formula to retrieve the power units is:

 

Method (BIF0, 0, NotSerialized)
 {
	 If (ECAV ())
	 {
		 If (BSLF)
		 {
			 Store (B1MD, Local0)
		 }
		 Else
		 {
			 Store (B1B2 (BMD0, BMD1), Local0)
		 }
		 If (LNotEqual (Local0, 0xFFFF))
		 {
			 ShiftRight (Local0, 0x0F, Local1)
			 And (Local1, One, Local1)
			 XOr (Local1, One, Local0)
		 }
	 }
	 Else
	 {
		 Store (Ones, Local0)
	 }
	 Return (Local0)
 }

 

Where BMD0 and BMD1 are the low and high 8-bit EC numbers for the power units and the value is returned in Local0. Works fine in Lion 32-bit, but doesn't work in Lion 64-bit.

 

Without seeing the definition for the EC registers, I can't be sure, but what about the access to B1MD above??

[Jingu]

Thanks. Here's my full dsdt.

 

My BAT0 is a little complex. It's doing all kinds of calculations based on what it detects.

dsdt.zip

[RehabMan]

Thanks. Here's my full dsdt.

 

My BAT0 is a little complex. It's doing all kinds of calculations based on what it detects.

 

B1MD is a 16-bit field into the same structure where BMD0 and BMD1 are. Seems you have more 16-bit to 8-bit conversion to do on this DSDT... Unless you are certain the code that touches these is not being executed.

 

The best way to do this is to convert all these to 8-bit by renaming / splitting into two parts:

               // example

               //B1VL,   16, 
               B1V0, 8, B1V1, 8
               B1RC,   16, 
               B1FC,   16, 
               B1MD,   16, 
               B1ST,   16, 
               B1CC,   16, 
               B1DC,   16, 
               B1DV,   16

 

Then fix all the code that references them. Read access is easy, because you just call B1B2 method. Write access requires a bit more coding...

[Jingu]

The original 16-bit EC registers: B0VL, B0RC, B0FC, B0MD, B0ST, B0CC, B0DC, B0DV are mirrored into

 

B1VL, B1RC, B1FC, B1MD, B1ST, B1CC, B1DC, B1DV

 

But these B1 series are not used. That's why I did not convert them to 8-bit EC registers. It works fine in Lion 32-bit without the conversion.

 

I also tried the dsdt with all those B1 variables converted to 8-bit. It still did not work in Lion 64-bit or Mountain Lion.

 

A system kext regression is never optimal, but in the meantime until permanent solution, I found an old AppleACPIPlatform kext v1.3.5 from 10.6.7 (Snow Leopard):

 

http://www.osx86.net...8_mount_...html

 

With that, AppleSmartBatteryManager works fine in Lion 64-bit and Mountain Lion. The problem could be with the recent AppleACPIPlatform kexts in 64-bit. I had AppleSmartBattery working fine in 64-bit in Snow Leopard 10.6.8. So, it really looks like the problem in 64-bit is with the recent AppleACPIPlatform kexts, at least for me.

 

Screenshot of AppleSmartBatteryManager working in Mountain Lion with AppleACPIPlatform v1.3.5 (from Snow Leopard 10.6.7)

 

[RehabMan]

The original 16-bit EC registers: B0VL, B0RC, B0FC, B0MD, B0ST, B0CC, B0DC, B0DV are mirrored into

 

B1VL, B1RC, B1FC, B1MD, B1ST, B1CC, B1DC, B1DV

 

But these B1 series are not used. That's why I did not convert them to 8-bit EC registers. It works fine in Lion 32-bit without the conversion.

 

I also tried the dsdt with all those B1 variables converted to 8-bit. It still did not work in Lion 64-bit or Mountain Lion.

 

A system kext regression is never optimal, but in the meantime until permanent solution, I found an old AppleACPIPlatform kext v1.3.5 from 10.6.7 (Snow Leopard):

 

http://www.osx86.net...8_mount_...html

 

With that, AppleSmartBatteryManager works fine in Lion 64-bit and Mountain Lion. The problem could be with the recent AppleACPIPlatform kexts in 64-bit. I had AppleSmartBattery working fine in 64-bit in Snow Leopard 10.6.8. So, it really looks like the problem in 64-bit is with the recent AppleACPIPlatform kexts, at least for me.

 

Screenshot of AppleSmartBatteryManager working in Mountain Lion with AppleACPIPlatform v1.3.5 (from Snow Leopard 10.6.7)

 

 

Yes, the new 64-bit AppleACPIPlatform.kext is a lot more picky. You have to go over things in your DSDT with a fine-tooth-comb. Usually this involves actually reviewing the DSDT code, and trying to understand it as much as you can. Then you can start to eliminate non-critical parts (ie. hard coding results), to simplify, find problem areas, etc. It requires a lot of time, trial-and-error style, and a lot of studying the code to discern its intent.

[tvcat]

Hi, gsly.

Im trying to fix the UTF-8 string error but my DSDT have no ITOS() / GBFE / PBFE.

I search for similar method but not found.

My laptop is HP Folio 13

 

Is there other way to fix this? thanks.

[Alex009988]

http://www.osx86.net...ini_for_ml.html

Hello. I made new SmartBattery(mini) for Mountain Lion and Lion of these sourses.

https://github.com/R...-Battery-Driver

The new driver working better and it has smaller size. Just 81 kb

All driver of first message of this topic doesn't fit to me. On my computer they doesn't work.

AppleSmartBatteryManager.kext.zip

[RehabMan]

http://www.osx86.net...ini_for_ml.html

Hello. I made new SmartBattery(mini) for Mountain Lion and Lion of these sourses.

https://github.com/R...-Battery-Driver

The new driver working better and it has smaller size. Just 81 kb

All driver of first message of this topic doesn't fit to me. On my computer they doesn't work.

 

Just an FYI. It does work on SL (10.6). This one is smaller than those previous because it is built- for 64-bit only...

[Alex009988]

Hi. I added to SmartBattery the one thing -> Approximation of the number of cycles.

It gives me condition my battery

I found on AppleSmartBattery.cpp this thing

   //rehabman: zprood's technique of expanding the _BIF to include cycle count
   uint32_t cycleCnt = 0;
   if (acpibat_bif->getCount() > BIF_CYCLE_COUNT) {
    cycleCnt = GetValueFromArray(acpibat_bif, BIF_CYCLE_COUNT);
   }
   setCycleCount(cycleCnt);

correct cycleCnt = 0 to -1, and remove setCycleCount(cycleCnt);

Because the actual number of cycles can be 0, if the battery is new, but the -1 is unlikely.

then add

/* If the cycle count can not be obtained through _BIF, it will be estimated according to the design capacity and maximum capacity, otherwise will be set based on the acquired cycle count from _BIF*/
   if (-1 == cycleCnt) {
    if (fDesignCapacity > fMaxCapacity) {
	    setCycleCount((fDesignCapacity - fMaxCapacity) / 7);
    } else {
	    setCycleCount((fMaxCapacity - fDesignCapacity) / 7);
    }
   } else {
    setCycleCount(cycleCnt);
   }

Ver2_AppleSmartBatteryManager.kext.zip

[Alex009988]

RehabMan

Hello. Do you know that in Mountain Lion the DVDPlayer doesn't work with any battery kext. It only happens with ATI cards and only in ML, not Lion.

I've known three people with this problem. Two with Acers, one with Toshiba. But everybody of us has ATI card.

DVDPLayer starts up at that time everything is OK. But when I put in any DVD disk or try to do it straight with hard disk, I get the error as this http://www.insanelymac.com/forum/topic/283052-appledvdplayer-and-applesmartbatterymanager/

But if I delete battery-kext, DVDPlayer is playing well and excelent

Let's think together how to fix it.

At first, we have to find a connection between DVDPlayer and SmartBattery, VoodooBattery, ACPIBatery.

Year, Year All of these drivers break my DVDPlayer. Without them everything(DVDPlayer) works well and good.

Wait your Answer!

[SRSR333]

Hey guys. I own a Samsung RF 411, where I use VoodooBattery.kext (I try not to use anymore Voodoo kexts, except PS2) and it's very glitchy- sometimes, an installed battery is not detected (X on the battery icon), or the battery is shown to have 100% all the time. Is it possible for me to add this driver in my system? My edited DSDT is attached, patched for brightness and certain other devices. I can't seem to find some devices and methods in my DSDT (I think it's v3.X, as it has a _BIF Method under Device BAT0) which the edits need. Can someone please help? Thanks in advance...

DSDT_SRSR333.dsl.zip

[tical2k]

The original 16-bit EC registers: B0VL, B0RC, B0FC, B0MD, B0ST, B0CC, B0DC, B0DV are mirrored into

 

B1VL, B1RC, B1FC, B1MD, B1ST, B1CC, B1DC, B1DV

 

But these B1 series are not used. That's why I did not convert them to 8-bit EC registers. It works fine in Lion 32-bit without the conversion.

 

I also tried the dsdt with all those B1 variables converted to 8-bit. It still did not work in Lion 64-bit or Mountain Lion.

 

A system kext regression is never optimal, but in the meantime until permanent solution, I found an old AppleACPIPlatform kext v1.3.5 from 10.6.7 (Snow Leopard):

 

http://www.osx86.net...8_mount_...html

 

With that, AppleSmartBatteryManager works fine in Lion 64-bit and Mountain Lion. The problem could be with the recent AppleACPIPlatform kexts in 64-bit. I had AppleSmartBattery working fine in 64-bit in Snow Leopard 10.6.8. So, it really looks like the problem in 64-bit is with the recent AppleACPIPlatform kexts, at least for me.

 

Screenshot of AppleSmartBatteryManager working in Mountain Lion with AppleACPIPlatform v1.3.5 (from Snow Leopard 10.6.7)

 

 

Did you ever get anywhere with this without rolling back the ACPIPlatform.kext? I think I have a similar, if not exact problem.

[Alex009988]

 

 

Did you ever get anywhere with this without rolling back the ACPIPlatform.kext? I think I have a similar, if not exact problem.

Sorry don't understand what did you mean.

Did you mean whether it possible to set up Battery-driver without replacing of ACPIPlatform from Snow Leopard, right?

In this case it is posiible. See link below for ML.

http://www.osx86.net/view/3558-applesmartbatterymanagermini_for_ml.html

[tical2k]

Oh sorry that was directed at Jingu. I was reading this thread because I believe I have a similar problem that he had relating to the DSDT. Thanks for the input though, I'll try that kext. I was using RehabMan's branch.

[qwerty12]

18seven's patch works to get battery status with 10.8.* AppleACPIPlatform.kext with my N55SL: #116

 

I still, personally, use an older AppleACPIPlatform.kext all the same as I get working sleep when the lid is closed and my brightness keys still work.

[Jingu]

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.

[RehabMan]

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.

[fingerr]

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.

 

Asus_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.

 

Asus_Coreix_Lion_Edits.zipAsusM60J_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.

DSDT2IGPUBAT2.dsl.zip

Asus_Coreix_Lion_Edits.zip

[wrk73]

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

[gsly]

 

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.