[Solved] DSDT vs. Laptop Battery

[LeXa2]

Colleagues, I've got a question about the laptop battery recognition by the Mac OS X.

 

ACPI specs state that there are two types of battery access interfaces out there: "Smart Battery" and "Control Method Battery". First one should be controlled over SMB and Embeded Controller with a special OS-specific driver, second one is a pure ACPI/AML solution that is expected to be coded in DSDT. Which of these does the original Apple hardware employ?

 

My problem is that I've got a notebook which I had managed to install OS X on and now the battery isn't being detected and I have got no battery meter shown in the top bar. I know that I may want try to use Kext-based solutions like VoodooBattery but it seems to me that it would be better to patch DSDT to make vanilla OS X able to detect and show the battery status. So I'm trying to figure out if is this possible.

[3.14r2]

As for MacBook1,1 it has

SMB and Embeded Controller with a special OS-specific driver

I'm saying this by looking in to MacBook1,1 DSDT. As there are references to "EC.SMB0" in methods used inside Device(BAT0). Also there is an AppleSmartBatteryManager.kext inside /S/L/E. So it is clear which method is used.

 

As for patching DSDT... If you have a PC with the same chipset, CPU, VGA as in a Mac, then there is a chance to get it working via DSDT.

 

I have HP dv1660se. The hardware is similar to MacBook1,1. By comparing both DSDTs (from Mac and from HP) and replacing/adding some parts the battery indicator can be made visible for a second (but doesn't appear in it's place permanently; it can be a hardware (power jack) problem though). I assume a better result can be achieved by further investigation.

 

A very important step before editing DSDT, is to set the correct system type, so the PC would be detected as a notebook. Use

<key>SystemType</key>
<string>2</string>

boot flag. This fix alone can make the battery indicator visible.

[LeXa2]

Thanks for the quick answer. As you made clear that the original Apple's hardware uses SmartBattery protocol to communicate with the battery over the SMB (so looks like that there's a "vendor-specific Embeded Controller" in original Mac hardware with the integrated SMBus controller that may be accessed using EC-SMB access protocol defined in the ACPI specs) now it is obvious that I wouldn't have a chance to correct the situation using the DSDT patch - it is generally possible to implement Control Method Battery in AML using accesses to the EC-SMB-SB, but not the vice-versa.

 

Notebook I'm trying to "fix" is the pretty old Toshiba laptop and it incorporates it's own EC plus a lot of the ATK-ACPI stuff coded in AML that works with it's own proprietary protocol accessing EC and doing the fun stuff. Battery access is also implemented over the ATK/EC, but the communication protocol is not the SmartBattery-complaint and the battery interface provided to the OSPM is the ACPI Control Method one. I had installed the VoodooBattery kext few minutes ago and it seems to be working quite good.

 

Once again, thanks for the quick answer. As for your advice to set the SystemType=2 - I had already done this just right after the installation of AnVAL edition of the Chameleon 2 bootloader. Looks like that it hadn't been required though because AnVAL seems to be smart enough to detect that the system it is running at is a laptop and to set the system-type=2 automatically.