[GUIDE] Snow Leopard with 100% vanilla /S/L/E - Comprehensive DSDT patching guide

[Silencers]

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.

 

• Feb 27, 2010 - Added chapter with some general information on bootloaders, updated Restart and UUID fixes with AsereBLN Booter related information, uploaded fresh version of my /Extra folder.
  
• Apr 05, 2010 - Reuploaded /Extra and DSDT files to MediaFire, removed deprecated links to patched bootloader and PS2 kexts.
  

 

Basic glossary

 

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

• CPU: Intel Core 2 Duo 2.33GHz
  
• RAM: 4GB
  
• Video: ATI Mobility FireGL V5200 256MB, screen resolution is 1400x1050
  
• Wireless: Atheros a/b/g/n
  

 

Result

 

As the result of everything that is described in this guide I have the following:

• /System/Library/Extensions 100% vanilla - no kexts touched, deleted or added.
  
• /Extra/Extensions contains only the following kexts: FakeSMC.kext, AppleACPIPS2Nub.kext, ApplePS2Controller.kext, AppleACPIBatteryManager.kext, VoodooHDA.kext, LegacyT60p.kext, ATINDRV.kext, VoodooTSCSync.kext.
  
• In /Extra I have additional files supporting my fixes: dsdt.aml, fadt.aml, com.apple.Boot.plist, SMBIOS.plist.
  

 

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.
  
• Brightness slider in Display preferences with DSTD patch, but uneven brightness control.
  
• Vanilla SpeedStep works (P-states and C-states) with custom Mac model in SMBIOS.plist, patch to DSDT and LegacyT60p.kext.
  
• Vanilla IOATAFamily.kext - DSDT patch.
  
• Native AHCI driver - DSDT patch.
  
• No need to remove /S/L/E/AppleHDA.kext to allow VoodooHDA.kext to work - DSDT patch.
  
• Restart works with AsereBLN Booter 1.1.9 with embedded restart fix.
  
• UUID fix is applied automatically by AsereBLN Booter 1.1.9.
  
• Going to Sleep on lid close - DSDT patch.
  
• Shutdown works OOB.
  
• Bluetooth works OOB with some minor quirks.
  
• AHCI and ATA injectors not needed on ThinkPads, everything works OOB.
  
• Atheros wireless drivers load automatically in x64 mode with LegacyT60p.kext fix.
  
• 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:

cd /System/Libary/Extensions
mv SomeKextToPatch.kext SomeKextToPatch.kext.original
cp -r /Volumes/YourUSBDrive/SomeKextToPatch.kext /System/Library/Extensions/

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.

/* grant yourself a superuser access for this session */
sudo -s (to gran)
cd /folder_where_you_have_your_bootloader_unpacked/
/* now find out what is the system location for the drive and partition you installed OSX to */
df /
/* let's assume it's /dev/disk1s2 */
/* install boot0 to the MBR */
fdisk -f boot0 -u -y /dev/rdisk1
/* install boot1h to the partition's bootsector */
dd if=boot1h of=/dev/rdisk1s2
/* Install boot to the partition's root directory */
cp boot /

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:

<key>Theme</key>
<string>Bullet</string>

My /Extra archive includes two themes - Default and Bullet (from original Chameleon package).

 

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:

<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.
  
• PlistEdit Pro - essential tool for plist files editing. Download, install and forget about original plist editor. Download it here.
  
• 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.
  

 

Some basic steps to follow for successful DSDT patching

 

• 1. Boot to SnowLeo for the first time.
  
• 2. Copy provided custom Chameleon bootloader to the root of your SnowLeo drive.
  
• 3. Install DSDTSE.
  
• 4. Double click on your previously extracted DSDT.aml (or DSDT.dsl if it's already decompiled). DSDTSE should open.
  
• 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).

Method (DTGP, 5, NotSerialized)
{
If (LEqual (Arg0, Buffer (0x10)
		{
			/* 0000 */	0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44, 
			/* 0008 */	0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B
		}))
{
	If (LEqual (Arg1, One))
	{
		If (LEqual (Arg2, Zero))
		{
			Store (Buffer (One)
				{
					0x03
				}, Arg4)
			Return (One)
		}
		If (LEqual (Arg2, One))
		{
			Return (One)
		}
	}
}
Store (Buffer (One)
	{
		0x00
	}, Arg4)
Return (Zero)
}

RTC fix. It is required for proper power management and latest versions of OSX to work without KP. Simply comment or delete IRQFlags part.

Device (RTC)
{
Name (_HID, EisaId ("PNP0B00"))
Name (_CRS, ResourceTemplate ()
{
	IO (Decode16,
		0x0070,			 // Range Minimum
		0x0070,			 // Range Maximum
		0x01,			   // Alignment
		0x02,			   // Length
		)
	/* Fix - RTC fix 
	IRQNoFlags ()
		{8}
	Fix End */
})
}

HPET fix. This is required for proper SpeedStep functionality and some other things. Just replace your HPET device with this.

Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (_CID, EisaId ("PNP0C01")) 
Name (_STA, 0x0F)
Name (_CRS, ResourceTemplate ()
{
	IRQNoFlags ()
		{0}
	IRQNoFlags ()
		{8}
	Memory32Fixed (ReadOnly,
		0xFED00000,		 // Address Base
		0x00000400,		 // Address Length
		)
})
}

PIC and TIMR devices fix. Required to get rid of audio and video stuttering after SpeedStep with C-states is enabled. Just remove IRQNoFlags () {2} and IRQNoFlags () {0} code from each of them.

 

IOATAFamily.kext kernel panic fix

 

In both your SATA and IDE0 devices insert the following code above GPCT method

Field (IDCS, DWordAcc, NoLock, Preserve)
{
		Offset (0x40), 
PRIT,   16, 
SECT,   16
}
Method (_INI, 0, NotSerialized)
{
Store (0xE307, PRIT)
Store (0xC000, SECT)
}

And then insert the following at the very beginning of _WAK method:

\_SB.PCI0.PATA._INI ()
\_SB.PCI0.SATA._INI ()

 

Native AHCI support

 

Insert the following above GPCT method. Notice how we are using DTGP method defined before.

Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
   "device-id",
   Buffer (0x04)
	 {
		  0xC5, 0x27, 0x00, 0x00
	  }
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}

 

The fix to override operating system checks

 

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

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.

Device (PNLF)
{
Name (_HID, EisaId ("APP0002"))
Name (_CID, "backlight")
Name (_UID, 0x0A)
Name (_STA, 0x0B)
}

 

Enable vanilla AC adpater driver

 

Insert the following code after Name (_UID, Zero) line inside AC device.

Name (_PRW, Package (0x02)
{
0x18,
0x03
})

 

Fix to forget about AppleHDA.kext removal before using VoodooHDA.kext

 

Just comment out or delete your HDEF device:

/* Fix - Disable AppleHDA.kext auto loading to use VoodooHDA.kext 
Device (HDEF)
{
Name (_ADR, 0x001B0000)
Name (_S3D, 0x03)
Name (RID, Zero)
Name (_PRW, Package (0x02)
{
	0x05, 
	0x04
})
Method (_PSW, 1, NotSerialized)
{
	Noop
}
} 
Fix End */

 

Restart fix

 

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:

<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

<key>SystemID</key>
<string>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</string>

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.

 

Empty legacy kext looks like this.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleIdentifier</key>
<string>com.silencer.driver.LegacyT60p</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>Legacy fixes for T60p</string>
<key>CFBundlePackageType</key>
<string>KEXT</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>999.9.9</string>
<key>IOKitPersonalities</key>
<dict>
   [====this is the part we are going to fill with overrides====]
</dict>
<key>OSBundleLibraries</key>
<dict>
	<key>com.apple.iokit.IOGraphicsFamily</key>
	<string>1.1</string>
	<key>com.apple.iokit.IOPCIFamily</key>
	<string>1.0</string>
	<key>com.apple.kpi.iokit</key>
	<string>8.3.1</string>
	<key>com.apple.kpi.libkern</key>
	<string>8.3.1</string>
	<key>com.apple.kpi.mach</key>
	<string>8.3.1</string>
</dict>
<key>OSBundleRequired</key>
<string>Local-Root</string>
</dict>
</plist>

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.

<key>ATIRadeonX1000</key>
<dict>
<key>ATIEnableWideBlitSupport</key>
<true/>
<key>CFBundleIdentifier</key>
<string>com.apple.ATIRadeonX1000</string>
<key>IOPCIMatch</key>
<string>0x71c41002</string>	
[====other fields skipped====]
</dict>

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.

<key>Atheros Wireless LAN PCI</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.driver.AirPort.Atheros21</string>
<key>IOClass</key>
<string>AirPort_AthrFusion21</string>
<key>IOMatchCategory</key>
<string>IODefaultMatchCategory</string>
<key>IONameMatch</key>
<array>
	<string>pci168c,24</string>
</array>
<key>IOProviderClass</key>
<string>IOPCIDevice</string>
</dict>

 

Vanilla Speed Step

 

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:

<key>SMbiosversion</key>
<string>MBP23.88Z.00A5.B01.0611031449</string>
<key>SMproductname</key>
<string>MacBookPro2,3</string>

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

<key>ACPI_SMC_PlatformPlugin</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.driver.ACPI_SMC_PlatformPlugin</string>
<key>IOClass</key>
<string>ACPI_SMC_PlatformPlugin</string>
<key>IOPlatformThermalProfile</key>
<dict>
			[====Here we'll place info from MacBookPro2_1.plist====]
</dict>
<key>IOProbeScore</key>
<integer>1200</integer>
<key>IOPropertyMatch</key>
<dict>
	<key>IOCPUNumber</key>
	<integer>0</integer>
</dict>
<key>IOProviderClass</key>
<string>AppleACPICPU</string>
<key>IOResourceMatch</key>
<string>ACPI</string>
</dict>

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:

...
<key>ConfigArray</key>
<array>
<dict>
	<key>model</key>
	<string>MacBookPro2,3</string>
	<key>restart-actions</key>
	<dict>
		<key>cpu-p-state</key>
		<integer>0</integer>
	</dict>
</dict>
</array>
<key>ControlArray</key>
...
<key>PLimitDict</key>
<dict>
<key>MacBookPro2,3</key>
<integer>0</integer>
</dict>
<key>StepDataDict</key>
....

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:

Scope (_PR)
{
Processor (CPU0, 0x00, 0x00001010, 0x06) {}
Processor (CPU1, 0x01, 0x00001010, 0x06) {}
}
Scope (\_PR.CPU0)
{
Name (C1M4, Package (0x04)
{
	0x03, 
	Package (0x04)
	{
		ResourceTemplate ()
		{
			Register (FFixedHW, 
				0x01,			   // Bit Width
				0x02,			   // Bit Offset
				0x0000000000000000, // Address
				0x01,			   // Access Size
				)
		}, 
		0x01, 0x01, 0x03E8
	}, 
	Package (0x04)
	{
		ResourceTemplate ()
		{
			Register (SystemIO, 
				0x08,			   // Bit Width
				0x00,			   // Bit Offset
				0x0000000000001014, // Address
				,)
		}, 
		0x02, 0x01, 0x01F4
	}, 
	Package (0x04)
	{
		ResourceTemplate ()
		{
			Register (SystemIO, 
				0x08,			   // Bit Width
				0x00,			   // Bit Offset
				0x0000000000001016, // Address
				,)
		}, 
		0x03, 0x39, 0x64
	}
})

Method (_CST, 0, NotSerialized)
{
Return (C1M4)
}
}
Scope (\_PR.CPU1)
{
Method (_CST, 0, NotSerialized)
{
	Return (\_PR.CPU0._CST)
}
}

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:

<string>ACPI_SMC_PlatformPlugin</string>
<key>IOPlatformThermalProfile</key>
<dict>
<key>CStateDemotionDict</key>
<dict>
	[====skipped, check attached Extra.zip for reference====]
</dict>
<key>CStateDict</key>
<dict>
	[====skipped, check attached Extra.zip for reference====]
</dict>
	.....

 

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

			Name (LIDS, One)
		Method (_LID, 0, NotSerialized)
		{
				Store (^^PCI0.LPC.EC.HPLD, LIDS) 
				XOr (LIDS, One, Local0)
				If (Local0)						
				{ 
					Notify (SLPB, 0x80)				
				} 
				Return (LIDS)
		}

 

Video EFI strings injection

 

We don't need ATIinject.kext, it's easier to use EFI strings to inject the same information. First, create a simple plist file using the template below.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)</key>
<dict>
</dict>
</dict>
</plist>

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:

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

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

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

  LID -> LID0
 AGP -> PEGP
 VID -> GFX0
 EXP0 -> RP01
 EXP1 -> RP02
 EXP2 -> RP03
 EXP3 -> RP04
 USB0 -> USB1
 USB1 -> USB2
 USB2 -> USB3
 USB3 -> USB4
 PCI1 -> PCIB
 PIC -> IPIC
 FPU -> MATH
 SIO -> LDRC
 IDE0 -> PATA
 PRIM -> PRID
 MSRT -> P_D0

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.

\_SB.PCI0.LPC.EC.LED (0x07, 0x80)
Sleep(0x64)
\_SB.PCI0.LPC.EC.LED (0x07, 0x00)

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:

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 waking
Store (0x00, \_SB.PCI0.LPC.EC.HFSP) - fan is off
Store (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:

• FakeSMS.kext. Always check netkas' site for the fresh version: http://netkas.org
  
• 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.
  

 

My files

 

Finally, here are all the links to the files I use:

• My full /Extra folder copy.
  
• Decompiled latest version of my DSDT with comments inside.
  

 

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.

[yozloy]

Thanks

That's the most comprehensive guide I've ever seen,

[Fatshenanigans]

WOW! This is the best guide on DSDT that I've seen so far! Well done!

 

GraphicsEnabler=Yes doesn't work for you in conjunction with the AsereBLN 1.9 bootfile? I guess it doesn't matter if your way is working already hehe.

 

I'm going to go play with my old HP for awhile now

[Silencers]

GraphicsEnabler=Yes doesn't work for you in conjunction with the AsereBLN 1.9 bootfile? I guess it doesn't matter if your way is working already hehe.

 

I've only tried PC EFI 10.5 with GraphicsEnabler=Yes, didn't work for me. Unfortunatelly the main problem with my ATI is not actual injection, but poor framebuffers that are available.

[Silencers]

GraphicsEnabler=Yes doesn't work for you in conjunction with the AsereBLN 1.9 bootfile?

 

BTW, thanks for the pointer, I'm will give it a go, it certainly looks promising. Potentially it makes a couple of fixes I've described much easier, so if it does, I will update the guide to include this bootloader.

[Silencers]

Updated the guide with AsereBLN's bootloader information. Thanks Fatshenanigans for the tip.

[Fatshenanigans]

Updated the guide with AsereBLN's bootloader information. Thanks Fatshenanigans for the tip.

 

I thought of something else that I cannot live without when tweaking my DSDT that's a good alternative to Everest

 

EvoToolsX from the EvoSoft developers is a way to get your ACPI info while in OSX. It can show you all of your device ID's in 3 different summary views and also shows you what ports are active in OSX and what is residing there. It's sort of like a summary of what you see in I/O reg but also gives the names of the vendors in addition to their device ID

[Sparcky]

After several installs (leo and snow). This surely the best guide for my T60p (1600x1200 LCD)

 

The only issues I still have are:

Sleep, it goes in a freeze state but does not "power down" (screen still on), but awakes with the powerbutton.

Mouse cursor corrupted after going full screen... I did not have this in 10.5.7.

.. I'll update in a few days

[Silencers]

Sleep, it goes in a freeze state but does not "power down" (screen still on), but awakes with the powerbutton.

Mouse cursor corrupted after going full screen... I did not have this in 10.5.7.

 

Sleep is a pain in SnowLeo. I couldn't get mine working, and it was fine in 10.5.6 for me.

 

The symptom with screen not shutting down is very likely caused by missing framebuffers support for your ATI. The only framebuffer kext that works well with shutting the screen off is ATINDRV.kext, and you need to launch it properly with injecting enough params via EFI, including proper EDID. That should solve the mouse cursor problem as well.

 

1. Get your EDID in Windows, using Phoenix EDID Designer.

2. Create plist with ATI params including the EDID you got on the previous step.

3. Feed this plist to gfxutil to get your hex EFI string.

4. Put that string into com.apple.Boot.plist 'device-properties' param.

5. If ATINDRV.kext is in /Extra/Extensions, generate mkext caches with pfix before rebooting.

6. Reboot.

[Silencers]

Almost randomly stumbled upon Sleep solution! Will post here, it might save someone a lot of time.

 

The same setup as described in the DSDT guide linked above, vanilla /S/L/E.

1) Remove or disable VoodooHDA.kext

2) Regenerate caches with pfix

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

 

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.

 

Intermediate quick and dirty solution to get both Sleep and Sound working - patched AppleAzaliaAudio.kext patched for AD1981HD: http://www.mediafire.com/file/yyz22mlzljz/...a.fixad1981.zip

 

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

[coldequation]

silencers,

 

This is indeed a wonderful DSDT guide. Really the best one out there. It's lacking one thing, however; an explanation of some of the fixes. I've documented some of the fixes elsewhere (don't want to diss insanely by posting where) and I've tried to indicate what the relevant devices, and methods are so that folks who have different hardware can try to create a similar fix.

 

For example, I have a machine that's quite similar to your Tpad, since it uses ICH7 and Core 2 Duo. I'ts also by default very compatible with a MacBook. However, I don't have a GPCT method anywhere, so suggesting pasting the Native ACHI fix above the GPCT method doesn't tell me what context to put it in.

 

I find that if you can possibly correlate things to the ICH7 datasheet, the ACPI 4.0 spec, or implementers guide, then demystifying DSDT becomes easier for all. But please don't take the above as a criticism-- you've done a wonderful job!

[Silencers]

I find that if you can possibly correlate things to the ICH7 datasheet, the ACPI 4.0 spec, or implementers guide, then demystifying DSDT becomes easier for all. But please don't take the above as a criticism-- you've done a wonderful job!

 

No, I don't take it the wrong way, and you are right, the guide needs some generic explanations to help people with different hardware. I'm now working on vanilla AppleHDA solution, so as soon as I have, I will append the guide with the information about it and I will also put more generic comments to most of the fixes. There's no point in writing such a huge guide unless people can actually make use of it Thank you for pointing that out.

[coldequation]

Let me know if there's anyway I can help. Your goal is very noble.

 

BTW, there is one thing in your guide that I disagree with. It's in the section where you discuss the fix to override operating system checks. In many cases, vendors put checks in there to enable specific hacks for a particular OS version. By enabling all, you make it difficult to predict which hacks/fixes/or even enhancements are applied. It may end up depending on the order of if statements that test for a particular OS.

 

So where as you put it as "onsider Darwin to be capable of all Win-specific features," what if the DSDT code is really there to work around differences in how the OS handles certain things-- in other words "consider Darwin to be capable of all Win-specific *defects*??

 

No, I don't take it the wrong way, and you are right, the guide needs some generic explanations to help people with different hardware. I'm now working on vanilla AppleHDA solution, so as soon as I have, I will append the guide with the information about it and I will also put more generic comments to most of the fixes. There's no point in writing such a huge guide unless people can actually make use of it Thank you for pointing that out.

[Fatshenanigans]

Almost randomly stumbled upon Sleep solution! Will post here, it might save someone a lot of time.

 

The same setup as described in the DSDT guide linked above, vanilla /S/L/E.

1) Remove or disable VoodooHDA.kext

2) Regenerate caches with pfix

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

 

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.

 

Intermediate quick and dirty solution to get both Sleep and Sound working - patched AppleAzaliaAudio.kext patched for AD1981HD: http://www.mediafire.com/file/yyz22mlzljz/...a.fixad1981.zip

 

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've noticed this too with voodoo. On the other hand my HP9000 laptop has HDEF in its code and it auto-sleeps. I need to go back and look at the code later when I have some spare time to see what the GPE scope looks like since I think it has a PRWB command. That might be the key. I didn't need many kexts at all for it since everything on it including the 8400 nvidia dedicated graphics is almost identical to a MacBook Pro.

 

To add to what you guys are talking about I think something should be said about wisely choosing what kexts you will use. Voodoo is a perfect example of this. In my case I modified my fakesmc.kext to match my boot plist version as well as the smc that is run by current iMac. I just taught myself, today actually thanks to some guides here hehe, how to create my own audio kexts so I don't lose my personal sleep if I lose auto-sleep on my 1156 systems

 

But it seems that I come across so many guides where I'll see a folder full of something like 10-12 kexts when all they need is 2-4.

 

One big blunder I've been observing is people who are trying to model their 1156 DSDT after the 1366 ICH10 when Lynnfield and the ICH10 are two totally different chipsets. At the same time I'm not sure even the motherboard manufacturers, especially ASUS, know how to code their boards for Lynnfield. Look at how many revisions to the bios have been made already. I think my board has been out for 3 months and already it's on version 7 I think. Several of the devices that are declared in the DSDT do not match how the OS sees them in either Windows or OSX when they are active. This probably accounts for most of the problems in my current chipset. I wish I could be sure about what is indeed correct but I'm still in the testing phase myself even if everything is running better than I imagined it ever would.

[Silencers]

In my case I modified my fakesmc.kext to match my boot plist version as well as the smc that is run by current iMac.

What exactly did you change in fakesmc.kext? I didn't touch it at all, so I'm now wondering if I actually should

 

But it seems that I come across so many guides where I'll see a folder full of something like 10-12 kexts when all they need is 2-4.

 

That is very true. I have started with Snow Leo by using another guide, and it had a {censored}load of kexts in both /S/L/E and /E/E, but when I asked about those kexts on forum, no one answered, so I started again from scratch, only adding kexts when I couldn't work without them (fakesmc.kext, PS2 kexts), and the result is this guide.

 

I'm now fighting with sound, but AppleHDA with my audio codec (AD1981HD) is a very tricky thing.

[Fatshenanigans]

Let me know if there's anyway I can help. Your goal is very noble.

 

BTW, there is one thing in your guide that I disagree with. It's in the section where you discuss the fix to override operating system checks. In many cases, vendors put checks in there to enable specific hacks for a particular OS version. By enabling all, you make it difficult to predict which hacks/fixes/or even enhancements are applied. It may end up depending on the order of if statements that test for a particular OS.

 

So where as you put it as "onsider Darwin to be capable of all Win-specific features," what if the DSDT code is really there to work around differences in how the OS handles certain things-- in other words "consider Darwin to be capable of all Win-specific *defects*??

 

Wouldn't this only really apply if someone was to use a SMbiosdefaults=No in their boot.plist? Even then wouldn't the boot file determine what is and is not seen unless you override it in the DSDT? I never really understood this fully since there's something like GraphicsEnabler=Yes that tells the bootloader to inject code that emulates EFI for the graphics card but you can override this with the DSDT. But there are other features like realtime overclocking that requires Windows to trigger the checks coded in the DSDT. Even if you make it so all features are enabled by setting the default OS to Windows 7 or Vista it doesn't seem to make any difference in OSX. But that's just what I've observed in the boards I own or have set up for others. Otherwise that's one thing I don't quite understand.

 

Edit - I forgot to mention that I tend to strip the code of what I'm positive is not used by OSX. I just thought of something else - my benchmarking scores are much lower when I leave in the 19000 lines of ASUS code even with the system checks in place. When I strip the code down to around 7000 lines my scores go up as much as 30% while my operating temperatures stay exactly the same. I don't have any idea what is going on so I'm all ears to any hypothesis you guys might have

[Silencers]

Let me know if there's anyway I can help. Your goal is very noble.

 

BTW, there is one thing in your guide that I disagree with. It's in the section where you discuss the fix to override operating system checks. In many cases, vendors put checks in there to enable specific hacks for a particular OS version. By enabling all, you make it difficult to predict which hacks/fixes/or even enhancements are applied. It may end up depending on the order of if statements that test for a particular OS.

 

So where as you put it as "onsider Darwin to be capable of all Win-specific features," what if the DSDT code is really there to work around differences in how the OS handles certain things-- in other words "consider Darwin to be capable of all Win-specific *defects*??

 

Well, this is an interesting point. I've carefully studied my DSDT and all the places where there are checks for a particular operating system. Most of the time the easiest part of the code is only applied for modern Windows versions - Vista, Vista SP1/SP2. After that it usually falls back to Windows XP/2000, and then in some rare cases to Windows 98. This shows that the most compact and clean DSDT code used only in 'capable' and clean OSes, the ones which know about advanced ACPI registers, etc.

 

Because of the way it works in my DSDT (fall back scenario), I enable all Windows versions flags, but probably it make sense to only enable Vista and/or XP. In that aspect you are right, for older Windows versions there are clear fixes for *defects*, but I never get there, because the code for newer versions is always executed first.

[Fatshenanigans]

What exactly did you change in fakesmc.kext? I didn't touch it at all, so I'm now wondering if I actually should

 

 

 

That is very true. I have started with Snow Leo by using another guide, and it had a {censored}load of kexts in both /S/L/E and /E/E, but when I asked about those kexts on forum, no one answered, so I started again from scratch, only adding kexts when I couldn't work without them (fakesmc.kext, PS2 kexts), and the result is this guide.

 

I'm now fighting with sound, but AppleHDA with my audio codec (AD1981HD) is a very tricky thing.

 

If I was to do the hack for a MacBook Pro with ICH7 chipset like the 2,1 (same as your board?) the name "napa" would stay the same as the normal 2.5 vs a rename to thurley in Mac Pro or Piketon in the iMac but the revision would change in all cases. I figured this out by seeing what the was being done for the 1366 chipset so I spent the next four hours figuring out what is being used for the current iMacs after seeing how Mac Pro wasn't using "napa". For those two you'd have to also change the smbios revision to match the respective models in the kext so two net changes rather than one net change for the MacBook Pro. Here's the MacBook Pro2,1 change of the stock:

<key>REV </key>
			<data>
			ATAPAAAD
			</data>
		</dict>
		<key>debug</key>
		<true/>
		<key>smc-compatible</key>
		<string>smc-napa</string>
		<key>tjmax</key>
		<integer>100</integer>
	</dict>
</dict>
<key>OSBundleLibraries</key>
<dict>
	<key>com.apple.iokit.IOACPIFamily</key>
	<string>1.0.0d1</string>
	<key>com.apple.kpi.iokit</key>
	<string>7.0</string>
	<key>com.apple.kpi.libkern</key>
	<string>8.0.0d0</string>
	<key>com.apple.kpi.unsupported</key>
	<string>8.0.0b1</string>
</dict>
<key>OSBundleRequired</key>
<string>Root</string>
</dict>
</plist>

 

 

Hacked to match the current 1.14f5 (change to this in your boot file) while changing the following in the fakesmc2.5:

 

		<key>REV </key>
			<data>
			ARQPAAAF
			</data>
		</dict>
		<key>debug</key>
		<true/>
		<key>smc-compatible</key>
		<string>smc-napa</string>
		<key>tjmax</key>
		<integer>100</integer>
	</dict>
</dict>
<key>OSBundleLibraries</key>
<dict>
	<key>com.apple.iokit.IOACPIFamily</key>
	<string>1.0.0d1</string>
	<key>com.apple.kpi.iokit</key>
	<string>7.0</string>
	<key>com.apple.kpi.libkern</key>
	<string>8.0.0d0</string>
	<key>com.apple.kpi.unsupported</key>
	<string>8.0.0b1</string>
</dict>
<key>OSBundleRequired</key>
<string>Root</string>
</dict>
</plist>

 

 

So you should see the revision in your System Profiler as well as I/O reg under SMC

 

This is what I'm working on right now to make HD pins for my ASUS:

http://www.insanelymac.com/forum/index.php?showtopic=149128

[Silencers]

So you should see the revision in your System Profiler as well as I/O reg under SMC

 

This is what I'm working on right now to make HD pins for my ASUS:

http://www.insanelymac.com/forum/index.php?showtopic=149128

 

Thanks, I will look into it later. If you say it might be related to HDA, I need to try it. Currently I'm struggling to make AppleHDA work, although I have prepared proper pin config and nodes chains.

[Fatshenanigans]

Thanks, I will look into it later. If you say it might be related to HDA, I need to try it. Currently I'm struggling to make AppleHDA work, although I have prepared proper pin config and nodes chains.

 

 

If you want to leave HDEF out give the EFI method a try. You'll need to download Mozilla browser since Safari still doesn't support the map you'll need to create.

[coldequation]

Well, this is an interesting point. I've carefully studied my DSDT and all the places where there are checks for a particular operating system. Most of the time the easiest part of the code is only applied for modern Windows versions - Vista, Vista SP1/SP2. After that it usually falls back to Windows XP/2000, and then in some rare cases to Windows 98. This shows that the most compact and clean DSDT code used only in 'capable' and clean OSes, the ones which know about advanced ACPI registers, etc.

 

Which means your DSST has stuck to a particular style consistently. I've seen DSDTs that don't, so caution is needed in trying to enable Windows-specific DSDT code.

 

Still, I was wrong about the code being "defect-based", and you were more correct in your thinking. According to the ACPI spec:

 

5.7.2 \_OSI (Operating System Interfaces)

This object provides the platform with the ability to query OSPM to determine the set of ACPI related interfaces, behaviors, or features that the operating system supports.

The _OSI method has one argument and one return value. The argument is an OS vendor defined string representing a set of OS interfaces and behaviors or an ACPI defined string representing an operating system and an ACPI feature group of the form, “OSVendorString-FeatureGroupString”.

Arguments: (1) Arg0 – A String containing the OS interface / behavior compatibility string or the Feature Group

string, as defined in Table 5-70, or the “OS Vendor String Prefix – OS Vendor Specific String”. OS Vendor String Prefixes are defined in Table 5-69

Return Value: An Integer containing a Boolean that indicates whether the requested feature is supported:

0x0 – The interface, behavior, or feature is not supported 0xFFFFFFFF – The interface, behavior, or feature is supported

OSPM may indicate support for multiple OS interface / behavior strings if the operating system supports the behaviors. For example, a newer version of an operating system may indicate support for strings from all or some of the prior versions of that operating system.

_OSI provides the platform with the ability to support new operating system versions and their associated features when they become available. OSPM can choose to expose new functionality based on the _OSI argument string. That is, OSPM can use the strings passed into _OSI to ensure compatibility between older platforms and newer operating systems by maintaining known compatible behavior for a platform. As such, it is recommended that _OSI be evaluated by the \_SB.INI control method so that platform compatible behavior or features are available early in operating system initialization.

 

Still, one woman's feature is another woman's defect. So a DSDT writer will have to do other things if the OS doesn't support the feature-- a classic workaround as the vendors march down the path to the latest hardware and OS.

[coldequation]

Well, this is an interesting point. I've carefully studied my DSDT and all the places where there are checks for a particular operating system. Most of the time the easiest part of the code is only applied for modern Windows versions - Vista, Vista SP1/SP2. After that it usually falls back to Windows XP/2000, and then in some rare cases to Windows 98. This shows that the most compact and clean DSDT code used only in 'capable' and clean OSes, the ones which know about advanced ACPI registers, etc.

 

Because of the way it works in my DSDT (fall back scenario), I enable all Windows versions flags, but probably it make sense to only enable Vista and/or XP. In that aspect you are right, for older Windows versions there are clear fixes for *defects*, but I never get there, because the code for newer versions is always executed first.

 

I had a strange result yesterday while removing older Windows code, and enabling Windows 2006 for Darwin.

 

I was editing my DSDT to take out parts that were specific for older parts of Windows (Win 2001). I also enabled for Darwin, anything that was specific to Windows 2006. When I rebooted, everything seemed pretty much the same, except I no longer had the brightness controls, which are mapped to the Fn-up, and fn-down arrows.

 

So I plan to analyze what changed, and then see if I can make them come back. Might be a clue to that brightness keys issue which bedevils many laptop users: for some it works, others, nothing works.

[Silencers]

So I plan to analyze what changed, and then see if I can make them come back. Might be a clue to that brightness keys issue which bedevils many laptop users: for some it works, others, nothing works.

 

When I was investigating my brightness controls, I've found that methods for brightness hotkeys contain two different sets of registers (or ways accessing them), and only one of them worked in OSX, and it was "the advanced" one.

[juanerson]

Excellent Installation guide, especially Native SpeedStep and DSDT patching, congratulations! Of course, Thank you very much.

[BigBeluga]

Fantastic guide. Very comprehensive! Thank you for being an asset to the OSx86 community.