First of all, beware, this is going to be a very long post, but I strongly suggest you to read it all. The largest part of the entire "100% Vanilla /System/Library/Extensions" idea is DSDT editing, and to make it work you need to actually understand what you are doing. If you have a slightly different system, you can't just blindly apply patches, you need to know what they do and adjust the code for your machine (but don't worry, it's not that hard).

You also need to prepare yourself for a probably very long and enduring polishing process. Yes, you only have to do it once, in the future you can use already prepared and patched DSDT and other files, but you still will probably reboot a hundred times and will see a hundred of kernel panics before your have your own perfect DSDT and other fixes.

I base this guide on my ThinkPad T60p, but I suppose most of my DSDT examples will work on any ThinkPad 60/61-series machine, because their DSDT should be very similar (I've compared T60p to T61 DSDT-wise, and they were almost identical). Anything older or newer should be double checked before applying any patches. But in general this guide should help owners of any laptops.

The goal of this guide is not to keep /System/Library/Extensions 100% vanilla, but also to reduce the amount of custom kexts to a bare minimum making as many things work "out of the box" as possible.

Updates

I will update this guide with new techniques and fixes as long as I keep finding the ones worth using, and I will list here any updates I've made so that you don't have to read this entire thing again to find out what's new.

Kext - kernel extension or a driver in the world of OSX. Essentially every kext is a folder with .kext "extension" containing xml and binary files.

/System/Library/Extensions (further /S/L/E) - system folder with all OSX kexts.

/Extra/Extensions (further /E/E) - a separate folder for custom kexts to separate them from vanilla kexts.

Patched kext - original system driver that is modified to work for us. You can either modify some xml settings or patch the binary code. Usually stored in /S/L/E replacing original kext.

Custom kext - a kext that is not a part of original OSX package. It can be stored in both /E/E and /S/L/E, but in the latter case it doesn't replace anything.

Why bother?

So, let me start with a brief explanation why should you bother with that DSDT patching and entirely 100% vanilla /S/L/E folder when there's a bunch of guides with patched kexts available, which work without too much hassle.

The problem with patched kexts is that they are not upgrade-proof. Yes, they work in a given OSX version, but when Apple releases an upgrade, all patched kexts in /S/L/E are overwritten and some kexts in /E/E might stop working or even raise kernel panics. And you will then need to look for newer versions of those kexts, and also need to remember what you have to patch in /S/L/E. And if you put a custom kext to /S/L/E it's hard to find it later if you suddenly need to remove it or change (our memory is a tricky thing).

As an example, current patched version of IOATAFamily.kext that works well with 10.6.2 is reported to raise kernel panic in 10.6.3 beta, so there you go, already a problem.

DSDT patching makes your system look to OSX more Mac-like. Of course, since you are not using original Mac, there's no 100% guarantee that any future system updates won't break your setup. With hackintoshes one always has to read what other people saying about a fresh system update before proceeding. But vanilla /S/L/E and minimal amount of custom kexts in /E/E significantly raise your chances of successful update.

Overview

I've mentioned that DSDT patching is only a part of what we are going to do to achieve as vanilla OSX as possible. Some other things that I'm going to cover here:

Latest/patched Chameleon bootloader

Custom Mac model in SMBIOS and other information there

EFI strings injection

Legacy kext creation

Prerequisites

Before you continue with full scale DSDT patching (and all other things) you need to do the following:

Upgrade your BIOS to the latest version if you haven't already. Often BIOS upgrades contain fresh version of DSDT, because it is a part of BIOS. For T60p the latest version (the one I use as reference) is 2.25, but it's not very different from 2.23, DSDT is the same for both versions.

Change BIOS options to make them as final as possible for you. With some laptops/motherboards changes in BIOS enable or disable parts of code in DSDT (DSDT tables are regenerated when you make changes). It doesn't look to be the case with ThinkPads, but still.

It's better to have a couple of other systems you can boot into. I have Windows Vista and Leopard 10.5.6 on an internal drive and I was installing Snow Leopard to external USB drive. Booting to Leopard can solve some of your problems when you can't boot to SnowLeo after some nasty changes you've made.

Some guides about installation of Snow Leopard on PC using vanilla installer. There's a bunch of those guides in your Google, I've used that one, but feel free to look for more detailed guides.

You will also need a bunch of software tools to help you along the way, but that's an easy part. Simply Google or download using links provided.

My configuration

I have ThinkPad T60p which I've upgraded over the years, so the model number is irrelevant.

Please note that the bare minimum of kexts in /E/E that you can boot with to SnowLeo and have pretty stable and working system is this: FakeSMC.kext, AppleACPIPS2Nub.kext and ApplePS2Controller.kext, VoodooHDA.kext, LegacyT60p.kext. You will have everything working including video, but with some mouse tearing, and you will not see battery icon. Overall I think this is an impressive result for our ThinkPads.

The following is working:

Video works (QE/CI and resolution change) with ATI EFI strings injected through com.apple.Boot.plist and legacy ATI framebuffers in ATINDRV.kext.

Both 32-bit and 64-bit modes work fine (with Core2Duo CPU), but proper ATI framebuffer is not available for x64. Shame.

What's not working or not checked:

Sleep. I've spent two weeks chasing this one, but no luck. If I have more news, I will update this post.

Firewire. Do not have it, so can't check. Post your solution here if you find it.

External display. Didn't check, but I expect it to be broken/buggy, need to play with ATI EFI strings to make it 100% functional.

BIOS configuration

Here's my BIOS configuration:

SATA is set to AHCI mode.

In Power settings Intel Speed Step is enabled with both AC and Battery set to Automatic.

Thermal settings are all set to Maximize Performance.

CPU Power Management is set to Automatic.

Display brightness is set to Normal.

And Memory Protection (under Security) is enabled.

Disabled InfraRed, Serial Port and COM port.

Extracting ACPI tables

Before patching you need to prepare your own ACPI tables (DSDT is only a part of entire ACPI tables list, and you will need to have all of them). I strongly advise against blindly using someone else's DSDT, even if they have the same ThinkPad model as you.

To extract ACPI tables (including DSDT) I suggest to use Everest Lavalys utility which is shareware and works in Windows. After you install it and run, right click on the bottom status bar, select "ACPI Tool" and then "Extract table". There's a large list of tables, you need to extract them all one by one. Then put them on a USB drive or somewhere you can access from your OSX. They will be in the binary form (not readable in text editor), but you shouldn't worry.

Snow Leopard installation

You can install Snow Leopard any way you prefer, but it's important to use vanilla installation DVD image and not a pre-packaged (hacked) one. You can either install SnowLeo from Leopard to an external USB drive, or you can prepare a USB drive with an installer and then boot to this USB drive to install.

Most of the guides include some custom and patched kexts to put to /S/L/E, which we want to keep vanilla. Not to worry, you can make a copy of either entire /S/L/E or only of those kexts you are overwriting. I use the following commands to do that:

When your patched DSDT is ready and other fixes applied, you can delete patched kexts and move originals back.

You can also start patching from existing Leopard installation or from Windows, but in this guide I'm relying on OSX tools, so you need to download some tools for Windows yourself. Patching from Leopard also works fine, but the problem is that it's difficult to test if your changes work, you need to apply many patches all together before trying to boot, and if it doesn't work you will not understand which of the applied patches failed. So I suggest to have a SnowLeo installation you can boot into and then proceed with experiments.

Bootloader

Many people, who decide to jump into the wonderful world of hackintoshes, underestimate the importance of a bootloader they choose. Now it seems that Chameleon v2 is the bootloader of choice. At the moment of writing its latest version is RC4. But there are a lot of people who use Chameleon source code to create their own patches and fixes. And since Chameleon has a lot of bugs on its own, some people also decide to fix Chameleon bugs to make it more stable and reliable.

I've come across a brilliant new bootloader that is based on Chameleon code. A man named AsereBLN did a great job fixing original code and introduced some great automatic fixes, like restart fix and SMBIOS values automatic detection. Follow the link below to the original forum thread with a full description of what has been done.

I know that some of us prefer to have better control of what is happening during boot and don't trust a bootloader to do something automatically. I'm on the other side, and the less things I have in my /Extra the better, because it means the less things I have to change/check if something is wrong.

Get the latest version of AsereBLN Booter (1.1.9 at the time of writing) here. Unpack it somewhere and then install from your Terminal with the commands below. Make sure you don't type my comments into terminal, they are only for your better understanding of the process.

If you have your OSX installed to /dev/disk0s2, change rdisk1 to rdisk0 in the above example in both places.

By default AsereBLN Booter doesn't include any GUI theme inside its code to make it lighter. If you want to use a theme, place it into your /Extra/Themes and then update your com.apple.Boot.plist to include that theme's name:

AsereBLN Booter also allows you to set the system type. By default all Chameleon versions assume that you have a desktop computer, which means Energy Saver preferences won't contain any trace of your Battery settings. SO you need to set your system type to laptop by adding the following parameter to your com.apple.Boot.plist:

Code:

<key>system-type</key><string>2</string>

My full com.apple.Boot.plist is in the archived /Extra copy attached at the end of this guide.

Tools to use

DSDTSE - this is a brilliant tool for DSDT compilation/decompilation. It contains a small database of fixes, an editor with syntax highlighting and a comparison tool. It doesn't patch DSDT automatically. The editor is a bit slow, so I use it only for minor fixes, but I use DSDTSE for easy DSDT compilation. There's now a Windows version available, but I haven't tried it yet. For all the latest updates check www.osx86.es.

Any advanced text editor with syntax coloring, I use TextMate. I've mentioned DSDTSE is a bit slow, so what I do is I open a DSDT.dsl (decompiled) file in TextMate, make changes, save it, then double click on DSDT.dsl and DSDTSE opens. I then click "Compile", and DSDT.aml (compiled) file is produced in the same folder I have DSDT.dsl in. I then copy it to /Extra and reboot.

IORegistryExplorer - this is part of Xcode, but you can download it separately (for example here). I use this tool to analyze if the changes to DSDT worked and to see if I need to make any other changes. I also use it to analyze original Macs' IOReg dumps.

pfix - this is great little utility for generation of kext caches and fixing permission. The way OSX works with drivers it doesn't read them one by one during boot. It loads single Extensions.mkext file. System usually generates this file automatically for /S/L/E if you touch it, but it's not generated for /E/E. A lot of custom and patched kexts, if placed in /E/E, can only be loaded as a part of pre-generated Extensions.mkext file for /E/E, but you need to do it yourself manually. Simply run pfix from your Terminal and follow simple instructions. Download pfix from here.

5. Click "Compile" button. DSDSE will tell you that DSDT needs to be saved first. Decompiled version will be saved to ~/Library/Application Support/EvOSoftware/DSDT/DSDTFiles.

6. After compilation Finder window with that folder will open, two files will be there - DSDT.aml and DSDT.dsl. I suggest you to save this folder location to Places on your left sidebar or make an alias on Desktop (it's a pain locating it every time).

7. Make a copy of DSDT.dsl to have a backup. Simply Alt-drag it somewhere within the same folder.

8. Make a desired patch/fix to DSDT.dsl with your favorite text editor (DSDTSE is not the best option here).

9. Open DSTD.dsl with DSDTSE and click "Compile" again. Proceed if there are no compilation errors.

10. Move resulting DSDT.aml to /Extra. You can place /Extra on your Finder sidebar as well to make this move with a single drag and drop.

11. If you've made ANY changes to kexts in either /S/L/E or /E/E - run pfix!

12. Reboot.

13. If you booted to SnowLeo successfully, go to /Extra and copy DSDT.aml to DSDT_stable.aml. If your further patches raise kernel panic during boot, you can type the following command in Chameleon: DSTD=/Extra/DSDT_stable.aml and it will use that older and stable version of DSDT. Lifesaver!

14. Repeat steps 7-13 as many times as you need to apply all patches.

Before you actually make your own patches I suggest you to study my DSDT. I've commented all my fixes there, just search for "fix " and you will find them.

General DSDT information

DSDT is the part of ACPI which in turn is the essential part of your BIOS. It contains some basic information about devices in your ThinkPad, defines their start-up sequences and provides basic means for their communication between each other. This is very high level of course.

All ACPI tables are written in AML machine language with is decompiled into something that looks very similar to C++. Only very basic and simple commands are supported.

DSDT is the biggest ACPI table and it contains the main devices tree and standard methods. For example, method _PTS (prepare to sleep) is called by the operating system before going to sleep so that proper sleep commands can be issued to all devices, and method _WAK is called upon waking.

The device tree in DSDT can be imagined through the folders analogy. You have a PCI0 bus device which has video, audio and other devices inside. In DSDT they are defined inside PCI0 device scope, the result is folder-like structure (e.g. PCI0->LPC->LDRC).

Some methods in DSTD are global, some methods are defined for particular devices.

Most devices names are only 4 letters and they are not universal (names depend on manufacturer of hardware), but most of them have universal IDs defined inside as a property (Name (_HID, EisaId ("PNP0C0E")), you can google "PNP0C0E" to find out what it is).

We are not patching BIOS itself, but using patched DSDT.aml. Chameleon is feeding this fake DSDT table to OSX on the fly. It's very difficult to harm your hardware with this method, and you are guaranteed that you will be able to boot later no matter what (just need to delete broken DSDT.aml).

Common patches

The following patches are common for everyone and you can safely apply them.

DTGP method. You need to have it in your DSDT for many other fixes that inject some custom parameters for your devices. I put it above _WAK method, but it can defined be anywhere on the highest scope level (not inside any devices).

Many DSDT versions including the one on ThinkPad have different checks in the code for different operating systems. OSX (Darwin) of course is not there, so we need to make sure some advanced ACPI code is enabled for OSX as well.

Insert the following right underneath the block that has all the operating system names checks and above the line If (LGreaterEqual (_REV, 0x02)).

Code:

Store (One, WNTF)Store (One, WXPF)Store (0x02, WSPV)Store (One, WVIS)

Enable brightness slider in Display preferences

The following device needs to be added above LNKA device right after _INI method within Scope (_SB) block.

The following information is outdated. I'm now using brilliant AsereBLN Booter instead of the old Chameleon RC4 which was patched for the restart to work with the below fix.

AsereBLN Booter is based on Chameleon RC code, but it improves it a lot, fixes a number of bugs and introduces some additional automatic fixes, such as this restart fix. You don't have to do anything now, but I leave that part of the guide unchanged for your information. It will help you to better understand what happens behind the scenes when the booter does its trick.

===============

This is a little bit trickier than simple DSDT patching. It is possible that it will be automatically fixed in the next Chameleon, but at the moment you need to use patched Chameleon RC4 that I've provided. I don't remember the source of it, so please point me to the latest version if you know where it is.

Then you need to add the following to your /Extra/com.apple.Boot.plist:

Code:

<key>RestartFix</key><string>yes</string>

And the last part is to patch another ACPI table you extracted before. It is called FADT or FACP. If you open it in DSDTSE you will see something different from DSDT. It will show you the breakdown of all bits in that table and what they mean - it's like a configuration table.

We are interested in "Reset Register Supported (V2)" and for restart to work it needs to be set to 1, but this is a single bit inside a mentioned block. You cannot make this change in DSDTSE, you need to open your favorite Hex editor (I use 0xED) and find that particular bit. So, in my case I had hex code 0000C2AD inside facp.aml and with the needed bit flipped this part changed to 0000C6AD. Saved facp.aml I renamed to fadt.aml and moved it to /Extra. That's it.

SMBIOS fix

Before you had to use patched AppleSMBIOS.kext to see proper CPU/Memory information in System Profiler. Latest Chameleon (and all other bootloaders that are based on Chameleon) can do this on the fly by feeding vanilla AppleSMBIOS.kext with fake information which it either automatically guesses for you or takes from SMBIOS.plist in /Extra. Use mine as the reference and update it to match your config. There's a good guide on SMBIOS.plist creation here.

AsereBLN Booter 1.1.9 does wonderful job of guessing most of the SMBIOS information for you. I've removed SMUUID, SMcputype, SMmemspeed and SMmemtype from my SMBIOS.plist after moving to that bootloader. I believe that SMbusspeed might be removed as well with some later version of it, but for now you need to have it set to 0 to see proper bus speed in your Profiler.

Most important parts in SMBIOS.plist are SMbiosversion and SMproductname which are essential for some other fixes and some software proper functionality (more on that later). Other fields should be populated with the right information for your particular hardware (CPU type and clock, bus speed, memory speed and type, etc.), but those are mostly cosmetic.

UUID fix

This is an interesting one. The fix to have proper UUID and to get rid of UUID-related errors in your log has evolved over time. At first you had to use PlatformUUID.kext, then a couple of patches for Chameleon allowed to set UUID from either com.apple.Boot.plist or SMBIOS.plist.

Now you can forget about all the hassle and simply use AsereBLN Booter 1.1.9 or anything that comes out later. It automatically detects proper UUID for you and injects it into SMBIOS, so that OSX feels "safe". Just kidding here.

You still can set UUID manually, if you need. To do so, put it into your com.apple.Boot.plist in /Extra

To find your UUID open Disk Utility, then right click on the volume you have installed SnowLeo on and choose "Information". Then copy the string named Universal Unique Identifier into your com.apple.Boot.plist as shown above.

Legacy kext

So called "legacy kext" is a great trick to replace any Info.plist in /S/L/E without actually touching /S/L/E. This kext is placed in /E/E and it contains only Info.plist overrides.

Inside legacy kext (in my case it is named LegacyT60p.kext, but you can name it anything you like) there's only single Info.plist. Inside, under IOKitPersonalities sections you can have as many subsections as you like. Let's start with ATIRadeonX1000.kext. As most of you know, to enable proper video we need to patch that kext's Info.plist to inlclude our device id. Here's how it's done via legacy kext.

Then we go to ATIRadeonX1000.kext and copy entire IOKitPersonalities section from Info.plist and place it inside our legacy kext within IOKitPersonalities section. Then you can make any replacements you need, e.g. change IOPCIMatch values.

Now if you regenarate mkext caches with pfix and reboot you will see that ATIRadeonX1000.kext loaded fine even though you haven't changed it's Info.plist directly to include your device id.

Here's the fix for Atheros x64 drivers (they are included only in 10.6.2), it goes right after ATI fix. So, as you can see, we can have as many different overrides as we like inside our single legacy kext.

This is by far the trickiest of all DSDT related fixes. If you are unsure of what you are doing you can use VoodooPowerMini.kext, and it would do the trick for you. But it will not be as effective as vanilla solution, because it doesn't enable C-states.

There are three different CPU states defined in ACPI - P-states, C-states and T-states. We don't care about the latter.

P-states - are actual speed steps, various frequencies/voltages combinations are defined, so that CPU can use less power when it's not under heavy load. You can even adjust those states for undervoltage (Google it) to make your CPU eat less power at the highest frequency.

C-states - are the states of CPU deep sleep, when it almost shuts off its entire core parts when idle. In modern CPUs there are tens of C-states. In Core 2 Duo on mobile platform (different on desktops) four C-states are defined, but only three C-states can work simultaneously (C1, C2, C3 or C1, C2, C4). But it's still more than enough to save a lot of power/temperature. With C-states enabled my CPU core temperature dropped 10-15 degrees Celcius!

SpeedStep functionality in OSX depends on a combination of parameters - DSTD configuration and Mac model. First of all you need to study http://www.everymac.com to find a MacBook or MacBookPro model that is the closest to your ThinkPad in configuration. ThinkPad T60p is using ICH7M platform and with Core 2 Duo 2.33GHz and FireGL V5200 it is almost identical to MacBookPro2,1. If you don't have ATI, and have Intel, your safe choice will be MacBook2,1.

But you cannot use chosen model directly, you need to make your own fake model based on that MacBook family. I've decided that I will use MacBookPro2,3 (there was actual MacBookPro2,2) and I've updated my SMBIOS.plist accordingly:

Next you need to create ACPI configuration for that model allowing OSX to use SpeedStep with that model. In SnowLeo there's /S/L/E/IOPlatformPluginFamily.kext. Inside (Show package contents) in the PlugIns folder there ACPI_SMC_PlatformPlugin.kext.

This is the kext that restricts or allows SpeedStep and C-states for particular Mac models. Before 10.6.2 all models configuration was stored in Info.plist inside that kext. Now in 10.6.2 there's another folder named Resources with separate configuration plists for each Mac that is supported by SnowLeo.

We are not going to change that kext contents, since we need to keep /S/L/E 100% vanilla. But, we are going to use the information that is stored in MacBookPro2_1.plist.

So, again, the path to the plist is:/S/L/E/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/

We now need to put this information into our legacy kext from above and update it to enable SpeedStep for our custom fake Mac model. But first put into legacy kext the following template inside IOKitPersonalities section (check screenshot above):

Inside IOPlatformThermalProfile section you need to copy information from the same section from your chosen Mac model plist. In my case it was MacBookPro2_1.plist. After this I replaced all occurrences of MacBookPro2,1 with MacBookPro2,3.

Next we need to enable P-states and C-states. For P-states, edit copied plist configuration to include the following:

If you have T60 or T60p you can use legacy kext I provide as a part of my /Extra contents below and SMBIOS.plist with only minor changes (CPU info). Once you've made all changes, you can reboot and then use either VoodooMonitor or MSR Tools to see if you have your P-states enabled.

In IORegistryExplorer you will spot the following. With IOService selected when you open info for CPU0@0->AppleACPICPI->ACPI_SMC_PlatformPlugin on right handside you should see that CPUPlimit is 0x0 and PerformanceStateArray contains 5 values. This means you're golden.

Most of vanilla speed step guides tell you that you also need to put P-states definition in your DSDT. On ThinkPads (at least on T60p) you don't need to do that, P-states definition is picked up by OSX automatically from SSDT tables, so you need to put P-states into DSDT only if you want override them to enable undervoltage for example.

With C-states it is a bit different, but I'm not sure why. To enable C-states you need to find in one of previously extracted SSDT tables the following block Name (C1M4, Package (0x04). This block defines three C-states - C1, C2 and C4. You can also use C1M3 or C1M2 or C1M1 (different combinations of C-states) which are defined within the same SSDT. You should then put it into your DSDT like this:

What we do here is that we define/override _CST() method for each of our CPU cores, and this method will return defined package of three C-states we've chosen. You can try to use my C-states, chances are they are the same across all Core Duo / Core 2 Duo family. There's no harm if you have different C-states defined, the section simply won't work and will be ignored by OSX.

The last step for C-states is to add a couple of new sub-sections to legacy kext inside IOPlatformThermalProfile section:

Once you've done all of this and regenerated mkext caches with pfix, reboot and check IORegistryExplorer (see the screenshot above). If you have successfully enabled C-states, you will see CSTInfo parameter. If you don't see it, that means you have no C-states enabled.

That's it, you're done with vanilla speed step. Check CPU temperature (google iStat) and compare it to what you have in Windows or what you've had before your vanilla speed step. You will be surprised.

Clamshell fix

Locate method _LID of the device LID and change it as shown. The idea is to check the Lid register and then if it is closed we notify the Sleep button that it was "pushed".

Then just copy/paste values from Info.plist inside ATIinject.kext that has your EDID and works for you and insert those values into the empty <dict> section about. Then you need download a console tool named gfxutil. Place it into the same folder where you have your new plist and then run the following command from Terminal:

Code:

./gfxutil -i xml -o hex atistrings.plist output.hex

Open the resulting output.kex and copy the long hex EFI string from there to your /Extra/com.apple.Boot.plist:

Code:

<key>device-properties</key> <string>ef1b00.....8c6400</string>

More information about EFI strings is available in this guide. If you have a ThinkPad that is different from T60p, you need to generate the PCI path to your video adapter first (for me it is PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)). This can be done with the following command:

Code:

./gfxutil -f display

You can also inject the same information directly via a patch to DSDT using DTGP method, but it's a bit trickier because of hexadecimal sizes calculations for each parameter, so it's easier to use EFI in com.apple.Boot.plist.

Cosmetic DSDT fixes

Some DSDT fixes are meant to be sort of cosmetic. For example, I've renamed all devices in my DSDT to have the same names that are found in original MacBookPro2,1. Theoretically it might be helpful, but there's no proof that it actually does anything. But anyways, here's the rename map:

Another cosmetic fix - removal of all devices declarations that are not used by OSX - COM and Serial ports, Floppy drive, InfraRed, etc.

Tips and Tricks

The DSDT is a pain to debug. One of the tricks is to make Sleep led blink for a brief moment when a part of code is being executed. You can insert the following piece of code anywhere (or maybe create your own method similar to DTGP) and then whenever that part of code is executed, you will see Sleep led blink.

OSX doesn't have native ways to control fan speed of T60p. When you boot with BIOS settings that I've listed above, the fan will always work at the slowest speed, and will not adjust even if CPU gets very hot. If you go to Sleep and then Wake (if you actually lucky enough to have working Sleep) you will notice that the fan is working at full speed after that.

You can assign some fan speed control commands to some hotkeys, for example brightness control hotkeys. Method _Q14 in DSDT is for brightness up (Fn+Home) and method _Q15 is for brightness down (Fn+End). Just replace the code there (or comment original code out) with any of the following:

Code:

Store (0x80, \_SB.PCI0.LPC.EC.HFSP) - fan set to automatic mode (in OSX it will work at full speed), this is what happens in _WAK method to make fan go full speed after wakingStore (0x00, \_SB.PCI0.LPC.EC.HFSP) - fan is offStore (0x01, \_SB.PCI0.LPC.EC.HFSP) - slowest manual speed....Store (0x05, \_SB.PCI0.LPC.EC.HFSP) - highest manual speed

I'm looking for a method in DSDT that is called automatically on regular basis. If I can find a method like that, than we can have automatic fan control - simple piece of code in DSDT that checks temperature and changes fan speed accordingly.

Questionable fixes

If you go through OSx86 related forums you will find other interesting DSDT fixes, but some of them should not be used with ThinkPad T60p (not sure about other models).

SBUS fix. Very simple and allows OSX to load native SBUS drivers. I've checked original MacBookPro2,1 DSDT and IORegistryExplorer dump, and those drivers are not loaded on that MacBook model. Considering the fact that this Mac is based on the same Intel chipset as our T60p (ICH7M) we don't need this fix.

USB/EHCI fix. Another fix that is related to USB/EHCI and its idea is to inject some "proper" device ids to all USB devices so that OSX recognizes them as vanilla. With T60p we already have proper device ids, they are identical to MacBookPro2,1 USB device ids, so you shouldn't apply this fix, it won't do anything good.

Current location for most essential kexts

It's always better to look for the latest version of a kext before using it. Here are some important kexts' locations:

VoodooHDA.kext. This is your best friend for your audio (works from /E/E only with generated mkext!). The version 0.2.35 allows me to use microphone, but there are newer versions available. So always check this forum thread.

VoodooPowerMini.kext and VoodooBattery.kext. I don't use them, but if you do check Superhai's site for updates: http://www.superhai.com

AsereBLN Booter. I'm using this bootloader instead of Chameleon, because it has a lot of great advantages (restart fix, for example). Until Chameleon moves forward, I suggest you to use AsereBLN's version. Get the latest version and full description here.

Decompiled latest version of my DSDT with comments inside (not the latest version for now).

That's it for now! I welcome any comments and additions to this fix list. I also would be thankful if you put links to this guide on other forums if you talk to someone who has questions. I've spent quite some time working on this guide, and it would be great if more people who want to know more about DSDT and other tricks read it.

i've had a quick scan through and look forward to giving it a proper read - i did crack open my dsdt about 6 months ago with the plan to work it out - but other things constantly got in the way - well done for the effort, must have taken ages

another question - i was trying to figure out if there was a way via dsdt of enabling/disabling the bluetooth (at the acpi level) - as i turned mine off in windows before my osx adventure (been using it for about a year now) but can't be faffed getting windows installed in order to turn it back on.. from what i could see, the acpi codes were in that thinkpad set of linux tools - i just couldn't figure out if i could achieve it via dsdt

another question - i was trying to figure out if there was a way via dsdt of enabling/disabling the bluetooth (at the acpi level) - as i turned mine off in windows before my osx adventure (been using it for about a year now) but can't be faffed getting windows installed in order to turn it back on.. from what i could see, the acpi codes were in that thinkpad set of linux tools - i just couldn't figure out if i could achieve it via dsdt

Well, this shouldn't be the case. Bluetooth is sitting on USB bus and is not controlled from ACPI. You should be able to turn it on in OSX with Fn+F5. Or you should try to turn it on with Fn+F5 before booting to OSX (e.g. on BIOS screen).

also, another question - what part of the video drivers mean no x64? does it mean that if running in x64 then graphics are not accelerated?

i was digging around and found thisLocation: /System/Library/Extensions/ATIRadeonX1000.kext

implying that at least one part are available in x64? i don't think i understand enough about 32/64 in osx!

Well, I'm currently writing from OSX booted to x64 with QE/CI enabled, but this doesn't mean that I have proper graphics support. ATIRadeonX1000.kext works in x64 and it enables acceleration, but it's only a part of the full solution. You also need to have proper ATI framebuffer loaded (for X1600/V5200 it's Wormy). There's SnowLeo kext ATIFramebuffer.kext which has Wormy, but I'm not sure if it even works in x64. Apple is releasing x64 drivers gradually, for example Intel X3100 x64 drivers appeared only in 10.6.2. Besides, original MacBookPro2,x which uses ATI X1600 cannot boot to x64 (EFI on those Macs is only 32-bit), so Apple has no point of releasing x64 framebuffers for X1600. And you need to remember, that vanilla framebuffers cannot be used without patching.

Without proper framebuffer loaded you will not be able to switch resolutions, you will observe mouse tearing (hardware mouse cursor only works with proper framebuffer loaded) and you might get serious artifacts after some OpenGL applications.

The working version of legacy ATI framebuffer is located in ATINDRV.kext which is loaded if you make proper EFI strings injections (via ATIinject.kext or any other way). Of course it is not working in x64, and I haven't seen sources anywhere, so it's a dead end.

There's still hope though. At Insanelymac.com forum there's a new project named RadeonHD and it's a custom ATI framebuffer that is based on Linux drivers. I've tested it and it works, but the current version is only for 32-bit. The sources are available, so someone can make it x64 compatible. But there are other problems with this framebuffer, so I advise against using it for now.

Well, the number of P-states depends on your CPU, in my case it is 5, in yours it might be 3. But CPUPlimit which is anything besides 0 means you don't have SpeedStep enabled. The main reason is that your ACPI_SMC_PlatformPlugin.kext is restricting it.

1. Check what is your Mac model in SMBIOS.plist or simply look into System Profiler.2. Check if you overriding ACPI_SMC_PlatformPlugin.kext restrictions correctly with your legacy kext or directly in /S/L/E for your selected model.3. Try to use MacPro3,1. This is the only model that has CPUPlimit=0 by default.

Sebinouse wrote:

BTW: Rapidshare never allows me to download you files ("ERROR ... Servers overloaded ... blablabla ..."), can you share them with another platform (mediafire, megaupload ?)

1. Check what is your Mac model in SMBIOS.plist or simply look into System Profiler.

Oups, I just forgot to change MacBookPro1,1 into MacBookPro1,3 in smbios.plist like I did in my legacy kext ... Thank you for your expertise !

Now I have CPUPlimit 0x0 and 3 values in PerformanceStateArray ... I had 5 differents P-States with VoodooPower and VoodooMonitor (and therefore DSDT SpeedStep) ... but now my L2400 is 5° to 10° cooler !

Another question: do you think we can add different HDA card in DSDT.aml ? Mine is a "Realtek ALC861"

Now I have CPUPlimit 0x0 and 3 values in PerformanceStateArray ... I had 5 differents P-States with VoodooPower and VoodooMonitor (and therefore DSDT SpeedStep) ... but now my L2400 is 5° to 10° cooler !

Well, VoodooPower always creates P-states automatically, vanilla solution takes P-states from your SSDT or DSDT. You should check your SSDT dumps to see how many P-states you have there. Since you have minimum frequency 1GHz and maximum 1.66GHz, I don't see a point in having more than 3 P-states, which was exactly what Lenovo engineers set

To make sure you are 100% there, check CSTInfo in IORegistryExplorer. If it's set, that means you're done with Vanilla SpeedStep.

Sebinouse wrote:

Another question: do you think we can add different HDA card in DSDT.aml ? Mine is a "Realtek ALC861"

Are you sure you have ALC? I've checked ThinkWiki, and according to this page you have AD1981HD, exactly the same as me. It it is not directly compatible with vanilla AppleHDA, you need to patch it, which goes against my idea of 100% vanilla /S/L/E. I'm afraid, simple DSDT patching will not help you here.

You may be right, I always assumed it was a realtek according to the Vendor/Device ID ... but in fact after further inverst. voodooHDA recognizes it as a AD1981HD ... and this is confirmed by ThinkWiki for X60t !I tried to add a "HDA Driver" in legacy kext, but so far nothing relevant ...

As you said previously, latest version of voodooHDA gives me random KP, so as my old version of AppleACPIBatteryMeter ... I finally manage to get your files from rapidshare and I am testing them right now : no random KP for the time being

One more thing : how did you manage to map your keyboard directly in ApplePS2Controller ? I always used Ukulele to create custom layouts, your solution seems to be better ...

You may be right, I always assumed it was a realtek according to the Vendor/Device ID ... but in fact after further inverst. voodooHDA recognizes it as a AD1981HD ... and this is confirmed by ThinkWiki for X60t !I tried to add a "HDA Driver" in legacy kext, but so far nothing relevant ...

Nah, it's not enough to patch Info.plist, you also need to make binary patches to the AppleHDA itself to make it work with non-standard audio codecs (AD1981HD in our case). There are automatic patchers available, but as I said, it looks to me as a bad solution. Besides, VoodooHDA makes my microphone work, which patched AppleHDA cannot do.

Sebinouse wrote:

As you said previously, latest version of voodooHDA gives me random KP, so as my old version of AppleACPIBatteryMeter ... I finally manage to get your files from rapidshare and I am testing them right now : no random KP for the time being

VoodooHDA.kext and some others are very sensitive to when when they work from /E/E. Whenever you make any changes to /S/L/E, you need to regenerate mkext caches, otherwise VoodooHDA will fail to load. This is due to some weird dependencies, that fail to resolve if /S/L/E is changed. For example, when you install any native OSX software that installs some kexts to /S/L/E (ControllerMate, for example), after you reboot, VoodooHDA will not work. If you then run pfix and reboot again - everything back to normal.

Sebinouse wrote:

One more thing : how did you manage to map your keyboard directly in ApplePS2Controller ? I always used Ukulele to create custom layouts, your solution seems to be better ...

What to you mean "map your keyboard"? I have standard international English keyboard and it works out of the box with PS2 kexts. For Russian input language I use custom PS-style keyboard layout.

I have new development related to VoodooHDA.kext. Didn't check this before, but for the correct functionality we also need to update its Info.plist to include our Pin and Nodes configuration (a rather technical task). Most of us have AD1981HD, so I will share my config when I finish it. Should allow painless microphone and other jacks operation.

I've also found a person in one of the old threads on a Russian forum with X61 mentioning Sleep problem exactly as mine (not able to wake up), and he claims that this Sleep problem is somehow related to audio drivers, and his Sleeps works when he uses Azalia. I will test this and write here about the results.

The same setup as described, vanilla /S/L/E.1) Remove or disable VoodooHDA.kext2) Regenerate caches with pfix3) Remove HDEF fix from DSDT - basically, allow HDEF device to be found by AppleHDA.kext. It won't work, but it will try.4) Reboot

That's it! I've managed to wake up successfully without any problems! I really don't understand how AppleHDA.kext loading affects sleep, but still. Now working on enabling AppleHDA.kext to work with our AD1981HD audio codec (unfortunately, I don't think it will be possible to keep /S/L/E 100% vanilla now).

Prerequisites: You need to be able to go to Sleep properly, and this is ONLY possible (on T60p) using ATINDRV framebuffer. Any other video solution cannot shut the screen off, thus stopping OSX from sleeping.

I don't remember where I've got it, but it works with T60p (and I suppose with almost any 60-series ThinkPad). You need to disable HDEF device in DSDT and then install this kext in /E/E and regenerate caches. Sleep works, sound works, but no microphone. At some point when testing initially I've noticed minor audio glitches, but currently can't hear anything (listening to iTunes).

It's listed as hotkey_radio_sw and from all my reading, the fn+f5 key is only capable of enabling the bluetooth radio via windows, or linux with the thinkpad-acpi tool

I can enable and disable my bluetooth with Fn+F5 no problem in OSX. The quirk is that if you boot into OSX with bluetooth switched off, it will switch on with Fn+F5 (the led will light on), but it won't work. I'm usually enabling it on Chameleon screen with the same key combination before launching OSX.

I still think this ACPI command is controlling USB bus somehow, since Bluetooth appears in IOReg tree under USB after you switch it on.

chris-uk wrote:

Ignoring that, then I'm not sure if there's anything else of use in there with respect to screen brightness, etc?

Brightness depends on the video you have (should work fine with X3100 with a number of DSDT patches) and proper framebuffers. With V5200 brightness works fine with hotkeys without loaded framebuffers, with RadeonHD framebuffer. If you use ATINDRV, than brightness will be very uneven. Settings brightness to Normal in BIOS helps things a little, but not much.

I don't remember where I've got it, but it works with T60p (and I suppose with almost any 60-series ThinkPad). You need to disable HDEF device in DSDT and then install this kext in /E/E and regenerate caches. Sleep works, sound works, but no microphone. At some point when testing initially I've noticed minor audio glitches, but currently can't hear anything (listening to iTunes).

I will continue working on vanilla AppleHDA solution.

Without testing and recall from memory, I believe the Azalia drive wouldn't support sound-in (mic).Could you check to see if sound-in still works?

Another finding regarding sound: Apparently we can have vanilla AppleHDA support with legacy kext in /E/E, but it will be broken in 10.6.3, when Apple again hardcodes codec IDs into binary. So, in 10.6.3 we will need to make a minor patch in the AppleHDA binary, but I think this is acceptable trade off.

BTW, according to ThinkWiki, AD1981HD is found these ThinkPads: R60, R60e, T60, T60p X60, X60s, X60 Tablet, Z60m, Z60t, Z61e, Z61m, Z61t, Z61p. That means that patched Azalia above should work on all of them. I will later post AppleHDA solution, and it will also be functional on those models.

Hey Silencer - what keyboard layout do you have? I'm in the UK so my bottom row of keys (well, not bottom, the one above the spacebar row) has shift, then \|, then Z, then X, etc. In 10.5.6 i had to use a different ps2 controller kext that set the keyboard type to ISO in order for OSX to recognise the key to the left of Z - i think i then used ukelele to create an english keyboard layout to map the key - have you had any such problem or is your keyboard layout different?

Hey Silencer - what keyboard layout do you have? I'm in the UK so my bottom row of keys (well, not bottom, the one above the spacebar row) has shift, then \|, then Z, then X, etc. In 10.5.6 i had to use a different ps2 controller kext that set the keyboard type to ISO in order for OSX to recognise the key to the left of Z - i think i then used ukelele to create an english keyboard layout to map the key - have you had any such problem or is your keyboard layout different?

Now I understand. I have US keyboard, it goes "Shift, Z, X, C...", so no problems in that department, PS2 kext usually work OOB. What you should try is VoodooPS2 kexts. They have been extended to include different keyboards configurations. I had to get rid of them because they were wrong for my keyboard, and I was too lazy figuring out how to configure them (probably Info.plist params changes), but that mean VoodooPS2 might be right for you.

I finally manage to get Sleep working on my X60T with sleepwatcher (method here).And maybe you can use the same method to unload VoodooHDA.kext on sleep and load it on wake ... in that way you may have both sleep and mic.

I finally manage to get Sleep working on my X60T with sleepwatcher (method here).And maybe you can use the same method to unload VoodooHDA.kext on sleep and load it on wake ... in that way you may have both sleep and mic.

Let me know if that works for you ...

Thanks, but as I've mentioned above, Sleep doesn't work with VoodooHDA unloaded. In fact, it's not VoodooHDA fault, it might be just missing some internal functionality that is present in AppleHDA/AppleAzaliaAudio, which allows my T60p to wake up. Currently I'm fine with AppleAzaliaAudio patched for AD1981, the only problem is that after waking up I get some random 'clicks' in Sound. I'm also VERY close to having proper vanilla AppleHDA solution, but it's just too *****Expletives removed by Moderator***** tricky.

If anyone needs it, I have corrected latest VoodooHDA Info.plist which includes proper pin config for all audio nodes, and allows to have fully working microphone (internal and external) almost out of the box. This supposedly will work on all AD1981HD ThinkPad laptops: R60, R60e, T60, T60p, X60, X60s, X60t, Z60m, Z60t, Z61e, Z61t, Z61p.

Thanks, but as I've mentioned above, Sleep doesn't work with VoodooHDA unloaded. In fact, it's not VoodooHDA fault, it might be just missing some internal functionality that is present in AppleHDA/AppleAzaliaAudio, which allows my T60p to wake up.

Actually ... It works for me ... Maybe you should give a try:

I downloaded your info.plist, VoodooHDA(256) from ProjectX and I added a reference to the kext in rc.sleep/rc.wake ... and so far every thing is perfect !