221 replies to this topic

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

 DSDT ComplianceVersion.png   227.6KB   49 downloads

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

Attached Files

•  dsdt.zip   40.68KB   7 downloads

[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)

 ML_Battery.png   347.18KB   94 downloads

[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)

 ML_Battery.png   347.18KB   94 downloads

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.

[Alex Auditore]

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.

Attached Files

•  AppleSmartBatteryManager.kext.zip   19.99KB   13 downloads

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

[Alex Auditore]

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);
    }

 Screen Shot 2013-01-20 at 3.12.53 PM.png   90.15KB   37 downloads

Attached Files

•  Ver2_AppleSmartBatteryManager.kext.zip   19.58KB   25 downloads

[Alex Auditore]

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.insanelym...batterymanager/
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...

Attached Files

•  DSDT_SRSR333.dsl.zip   23.48KB   3 downloads

[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)

 ML_Battery.png   347.18KB   94 downloads

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

[Alex Auditore]

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