- Joined
- Oct 23, 2011
- Messages
- 12
- Motherboard
- Asus Maximus-IV Extreme-Z
- CPU
- i7-2600K
- Graphics
- Radeon 6870
- Mac
- Classic Mac
- Mobile Phone
Hi nemeckay1,
I have a P87ZZ-I Deluxe/WD, 3770K, GTX680 and it works great. (pmpatched BIOS
0702, flashed with FTK, custom DSDT extracted and patched from PJALM's repo...)
You are going down the right path, don't give up.
To answer some of your questions:
Patched BIOS
---------------
Here is the what and why of patching the BIOS... OSX writes to an Intel MSR (model
specific register) in the CPU to change SpeedStep clock ratios for power management.
This register can be "locked" to prevent buggy SW from accidentally changing it. For
some reason Asus decided to lock the SpeedStep MSRs in their BIOS where other
vendors (e.g. Gigabyte, MSI) leave them unlocked.
Windows knows how to unlock these registers, but OSX assumes they are unlocked
when the OS boots. And the native OSX power management driver crashes when the
MSR is locked.
The pmpatch BIOS patch utility changes literally just a few bytes in the BIOS to jump
around the "lock MSR" instruction in the ASUS BIOS. That's it, nothing else. Every
other function in the BIOS is left alone. So there is practically no difference from a
SW point of view, nothing in the BIOS UI changes, etc.
NullCPUPowerManagement
------------------------------
The NullCPUPowerManagement driver replaces the native OSX driver. It does not
attempt to do SpeedStep power management but it can "halt" the CPU, go to sleep,
etc. The idle power is somewhat higher than with native power management.
(For a desktop you might not even care, but for a notebook it is a big deal...)
ASUS unpatched BIOS, native OSX power management driver => kernel panic
ASUS patched BIOS, native OSX power management driver => works great!
ASUS patched *OR* unpatched BIOS, NullCPUPowerManagement => mostly works
Because NullCPU is almost always "safe" as a workaround for BIOS and DSDT issues
when you are setting up a system you often want to install NullCPU even if you don't
think you need it, until you have a DSDT working, etc. Then you can just remove it.
DSDT
------
The DSDT is a table in the BIOS that tells an OS (OSX or Windows or Linux) how to
find and configure devices in the system. The DSDT also tells an OS how to setup
power management and enter low-power states like sleep or hibernate.
The DSDT in the BIOS is board-specific *and* BIOS revision specific. So any time
you need a DSDT for your system you need to track down the exact board and BIOS
revisions.
The contents of the DSDT are complicated and obscure... The best way to deal with
creating one is to either find a pre-made one for your system/BIOS or carefully
follow one of the many guides with patches, etc.
Sorry, nothing I wrote above is actually very helpful regarding DSDTs.
But here are a few specific things I think will help you:
- The pmpatch patching process does *not* change the DSDT. So if you use the
MaciASL editor to extract your DSDT you will get exactly the same results from
the patched or unpatched BIOS.
- Once you create a DSDT, the Chimera/Chameleon boot loader reads the file you
store in /Extra/DSDT.aml and uses it to completely replace the BIOS DSDT in
system memory. (MaciASL extracts the DSDT in system memory, hence why you
need to boot with "DSDT=No" the first time you try to extract it...)
- For the most part, PJALM's Asus DSDT patches worked just fine for me. Even
though the "P8Z77-I Deluxe" and "P8Z77-I Deluxe/WD" are slightly different
boards with different BIOS revisions -- the P8Z77-I patches just work. With
just one small caveat -- see below...
P8Z77-I WIFI / Bluetooth / Sleep
-------------------------------------
I found that with the original P8Z77-I Wifi card, my system would *not* sleep
even with a patched DSDT. The system would go to sleep, but wake up right
away after just 2-3 seconds.
I tracked the problem down to the USB Bluetooth controller on the Wifi card
forcing the system to wake up via USB wakeup requests.
In theory the P8Z77-I BIOS lets you disable the Bluetooth module. However
this had no effect -- I have read this is a known ASUS BIOS bug.
If your system won't stay asleep, the simplest way to test this is just take out
the Wifi card. If sleep just starts working without it, this is the same problem.
Now, the P87ZZ-I Wifi card is not supported by OSX. So if you're planning to
order a replacement, e.g. an AR9280 card for about $15, then once you swap
the card it should work great (no USB bluetooth on the AR9280...)
If you want to leave the original card in place, you can make sleep work by
patching the DSDT to disable USB power management wakeup events. But
that is messy.
I would offer to send you my DSDT but it has a lot of other broken stuff in it
at the moment. I need to go back and cleanly repatch the original 0702 BIOS
DSDT with PJALMs patches and then retest it.
Other BIOS / CMOS funkyness
----------------------------------
After you patch the BIOS or after you add or remove a video card from the
system -- I recommend you pull all the power from the board and physically
add/remove the clear CMOS jumper.
I had a variety of odd boot crashes whenever I switched from testing with
an add-on video card (e.g. a GTX 680 or Radeon 6870) to the internal
HD4000 graphics. Clearing the CMOS and resetting all of the BIOS settings
cleared these problems up.
Sorry, no good explanation for this. But you can try it as a last resort.
Boot Loader / Boot Args / Panics
------------------------------------
I think at this point, most of your problems are just confusion about which
set of boot args and Chimera settings are being used where.
I recommend you go through the /Extra folder and org.chameleon.Boot.plist
on your hard disk carefully and compare them against the /Extra on the USB
stick you're booting from.
I think when you get all of the right pieces set up on the hard disk it should
all work.
One trick you can try -- copy or rename your /Extra folder on the hard drive
e.g. to /Extra-backup and copy the /Extra from your working USB stick to
the hard drive.
If that gets the hard drive booting OK -- you just need to start working
through the differences one step at a time. First copy over your correct
boot args (dart=0), next copy over your DSDT and check the Chimera
messages to see that it is actually being loaded, then delete NullCPU, and
so on...
Good luck!
I have a P87ZZ-I Deluxe/WD, 3770K, GTX680 and it works great. (pmpatched BIOS
0702, flashed with FTK, custom DSDT extracted and patched from PJALM's repo...)
You are going down the right path, don't give up.
To answer some of your questions:
Patched BIOS
---------------
Here is the what and why of patching the BIOS... OSX writes to an Intel MSR (model
specific register) in the CPU to change SpeedStep clock ratios for power management.
This register can be "locked" to prevent buggy SW from accidentally changing it. For
some reason Asus decided to lock the SpeedStep MSRs in their BIOS where other
vendors (e.g. Gigabyte, MSI) leave them unlocked.
Windows knows how to unlock these registers, but OSX assumes they are unlocked
when the OS boots. And the native OSX power management driver crashes when the
MSR is locked.
The pmpatch BIOS patch utility changes literally just a few bytes in the BIOS to jump
around the "lock MSR" instruction in the ASUS BIOS. That's it, nothing else. Every
other function in the BIOS is left alone. So there is practically no difference from a
SW point of view, nothing in the BIOS UI changes, etc.
NullCPUPowerManagement
------------------------------
The NullCPUPowerManagement driver replaces the native OSX driver. It does not
attempt to do SpeedStep power management but it can "halt" the CPU, go to sleep,
etc. The idle power is somewhat higher than with native power management.
(For a desktop you might not even care, but for a notebook it is a big deal...)
ASUS unpatched BIOS, native OSX power management driver => kernel panic
ASUS patched BIOS, native OSX power management driver => works great!
ASUS patched *OR* unpatched BIOS, NullCPUPowerManagement => mostly works
Because NullCPU is almost always "safe" as a workaround for BIOS and DSDT issues
when you are setting up a system you often want to install NullCPU even if you don't
think you need it, until you have a DSDT working, etc. Then you can just remove it.
DSDT
------
The DSDT is a table in the BIOS that tells an OS (OSX or Windows or Linux) how to
find and configure devices in the system. The DSDT also tells an OS how to setup
power management and enter low-power states like sleep or hibernate.
The DSDT in the BIOS is board-specific *and* BIOS revision specific. So any time
you need a DSDT for your system you need to track down the exact board and BIOS
revisions.
The contents of the DSDT are complicated and obscure... The best way to deal with
creating one is to either find a pre-made one for your system/BIOS or carefully
follow one of the many guides with patches, etc.
Sorry, nothing I wrote above is actually very helpful regarding DSDTs.
But here are a few specific things I think will help you:
- The pmpatch patching process does *not* change the DSDT. So if you use the
MaciASL editor to extract your DSDT you will get exactly the same results from
the patched or unpatched BIOS.
- Once you create a DSDT, the Chimera/Chameleon boot loader reads the file you
store in /Extra/DSDT.aml and uses it to completely replace the BIOS DSDT in
system memory. (MaciASL extracts the DSDT in system memory, hence why you
need to boot with "DSDT=No" the first time you try to extract it...)
- For the most part, PJALM's Asus DSDT patches worked just fine for me. Even
though the "P8Z77-I Deluxe" and "P8Z77-I Deluxe/WD" are slightly different
boards with different BIOS revisions -- the P8Z77-I patches just work. With
just one small caveat -- see below...
P8Z77-I WIFI / Bluetooth / Sleep
-------------------------------------
I found that with the original P8Z77-I Wifi card, my system would *not* sleep
even with a patched DSDT. The system would go to sleep, but wake up right
away after just 2-3 seconds.
I tracked the problem down to the USB Bluetooth controller on the Wifi card
forcing the system to wake up via USB wakeup requests.
In theory the P8Z77-I BIOS lets you disable the Bluetooth module. However
this had no effect -- I have read this is a known ASUS BIOS bug.
If your system won't stay asleep, the simplest way to test this is just take out
the Wifi card. If sleep just starts working without it, this is the same problem.
Now, the P87ZZ-I Wifi card is not supported by OSX. So if you're planning to
order a replacement, e.g. an AR9280 card for about $15, then once you swap
the card it should work great (no USB bluetooth on the AR9280...)
If you want to leave the original card in place, you can make sleep work by
patching the DSDT to disable USB power management wakeup events. But
that is messy.
I would offer to send you my DSDT but it has a lot of other broken stuff in it
at the moment. I need to go back and cleanly repatch the original 0702 BIOS
DSDT with PJALMs patches and then retest it.
Other BIOS / CMOS funkyness
----------------------------------
After you patch the BIOS or after you add or remove a video card from the
system -- I recommend you pull all the power from the board and physically
add/remove the clear CMOS jumper.
I had a variety of odd boot crashes whenever I switched from testing with
an add-on video card (e.g. a GTX 680 or Radeon 6870) to the internal
HD4000 graphics. Clearing the CMOS and resetting all of the BIOS settings
cleared these problems up.
Sorry, no good explanation for this. But you can try it as a last resort.
Boot Loader / Boot Args / Panics
------------------------------------
I think at this point, most of your problems are just confusion about which
set of boot args and Chimera settings are being used where.
I recommend you go through the /Extra folder and org.chameleon.Boot.plist
on your hard disk carefully and compare them against the /Extra on the USB
stick you're booting from.
I think when you get all of the right pieces set up on the hard disk it should
all work.
One trick you can try -- copy or rename your /Extra folder on the hard drive
e.g. to /Extra-backup and copy the /Extra from your working USB stick to
the hard drive.
If that gets the hard drive booting OK -- you just need to start working
through the differences one step at a time. First copy over your correct
boot args (dart=0), next copy over your DSDT and check the Chimera
messages to see that it is actually being loaded, then delete NullCPU, and
so on...
Good luck!
