MacManx86: Advanced OSx86 Tips, Tricks and Techniques

Customizing SSDT: Power Management Optimization on 10.7.4

2012-05-21T12:10:00.000-04:00

With the release of SSDTs in MultiBeast, I decided to limit the Overclocked SSDT to a maximum clock of 4.2 GHz since that is the maximum that About This Mac can report using auto detection.

Over the past few days, numerous users have been asking how to customize their SSDT to run at a higher clock rate, and how to see more P-states on a non-overclocked system. This post aims to explain the SSDT and how to customize it.

Lets look at the first block of code:

External (\_PR_.CPU7, DeviceObj)
External (\_PR_.CPU6, DeviceObj)
External (\_PR_.CPU5, DeviceObj)
External (\_PR_.CPU4, DeviceObj)
External (\_PR_.CPU3, DeviceObj)
External (\_PR_.CPU2, DeviceObj)
External (\_PR_.CPU1, DeviceObj)
External (\_PR_.CPU0, DeviceObj)

This block defines how many real or hyper-thread CPU's are available. So in this example, we are defining up to 8 CPUs. If your CPU has less (Core i3 or Core i5) it is safe to delete External (\_PR_.CPU4, DeviceObj) thru External (\_PR_.CPU7, DeviceObj). But then you will need to delete the corresponding entries Scope (\_PR.CPU4) thru Scope (\_PR.CPU7) at the end of the SSDT.

Let's look at the next section:

Scope (\_PR.CPU0)
{
Name (APSN, 0x04)
Name (APSS, Package (0x1B)
{

Here we are defining the details for CPU0. The first line is assigning 0x4 to APSN which is an Apple-specific object. The next object APSS is also Apple-specific, but is defined the same as the ACPI object _PSS. The key thing in this line is Package (0x1B) as 0x1B defines in hexadecimal the number of definitions contained within. So 0x1B corresponds to 27 decimal. This means we have 27 states defined.

Next let's look at the top most entry but with comments added based on the ACPI Specification for _PSS:

Package (0x06)
{
0x1068, // CoreFreq
Zero, // Power
0x0A, // TransitionLatency
0x0A, // BusMasterLatency
0x2A00, // Control
0x2A00 // Status
},

From ACPI Specification- Section 8.4.4.2:

• CoreFreq. Indicates the core CPU operating frequency (in MHz).
• Power. Indicates the performance state’s maximum power dissipation (in milliWatts).
• TransitionLatency. Indicates the worst-case latency in microseconds that the CPU is unavailable during a transition from any performance state to this performance state.
• BusMasterLatency. Indicates the worst-case latency in microseconds that Bus Masters are prevented from accessing memory during a transition from any performance state to this performance state.
• Control. Indicates the value to be written to the Performance Control Register (PERF_CTRL) in order to initiate a transition to the performance state.
• Status. Indicates the value that OSPM will compare to a value read from the Performance Status Register (PERF_STATUS) to ensure that the transition to the performance state was successful. OSPM may always place the CPU in the lowest power state, but additional states are only available when indicated by the _PPC method.

So in our example CoreFreq is 0x1068 is 4200 or 4.2 GHz. It seems that Apple is ignoring the value for Power, though you can use the Power values from the motherboard's SSDT extract. I've found that TransitionLatency and BusMasterLatency are always 0x0A. Now for the final two values, 0x2A00 or 4200. In this case we ignore the two zeros and are only concerned with the two numbers. This is the value that will be displayed by MSRDumper. So when the system is running at 4.2 GHz MSRDumper will show the P-state as 42.

Ok now let's look at the next entry.

Package (0x06)
{
0x1004,
Zero,
0x0A,
0x0A,
0x2900,
0x2900
},

So 0x1004 is 4100 or 4.1 GHz and 0x2900 translates to 41. Pretty simple. If you keep following down you will see that CoreFreq decrease by 0x64 or 100 for each state and Control and Status decrease by 1. The last entry will have a CoreFreq of 0x0640 and Control and Status will be 0x1000. This corresponds to 1600 or 1.6 GHz and 16, the minimum clock rate for a desktop Sandy Bridge CPU.

Now that that has been explained lets look at the next Scope.

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

All this is showing is that instead of repeating what we did for the CPU0, we can have the SSDT return what was defined for CPU0. Alternately, you can define individual P-states for each processor, but it is a very time consuming process. The way I've described is much easier and less work.

Finally we can discuss what we need to change when modifying the SSDT. If you remove P-states you must decrease the value in Name (APSS, Package (0x1B) to reflect the number of states deleted. The MultiBeast i7 SSDT has a maximum clock of 3.9 GHz. The means the top entry will look like this:

Name (APSS, Package (0x18)
{
Package (0x06)
{
0x0F3C,
Zero,
0x0A,
0x0A,
0x2700,
0x2700
},

So the Package count went down by 3 from Package (0x1B) to Name (APSS, Package (0x18) and the first package shows the CoreFreq of 0x0F3C is 3900 or 3.9 GHz and Control and Status are now 0x2700 or 39.

Likewise if you want to add states, remember to add 0x64 to each CoreFreq and 1 to Control and Status and make sure that the value in Name (APSS, Package (0x18) corresponds to the total number of P-states defined.

Something everyone should be aware of is that there is a limit to the number of entries that AppleIntelCPUPowerManagement can handle. If you define more P-states then you can use, like using the Overclock SSDT on a non-overclocked system, you will lose P-states at the bottom of the table. When I used the MultiBeast Overclock SSDT which has a maximum clock of 4.2 GHz on a system that can reach a maximum of 3.8 GHz you will see the following from MSRDumper:

MSRDumper PStatesReached: 16 23 24 25 26 27 38

Versus using the MultiBeast i7 SSDT where you will see:

MSRDumper PStatesReached: 16 17 18 19 20 21 35 36 37

You may say what's the big deal? Well it relates to power consumption. The lower the P-state (CPU frequency) the lower the power consumption. So by using the Overclocked SSDT my power consumption will be higher which will cost me money in the long run.

I hope you found this information helpful!

-MacMan

Related Posts:
10.7.4 Power Management and Sandy Bridge CPUs
How To Test for SpeedStep on Sandy Bridge CPUs Using MSRDumper
Mac OS X 10.7.4 Update

UniBeast: Install Mac OS X Lion Using an All-In-One Bootable USB Drive

Building a Sandy Bridge CustoMac: Buyer's Guide

For discussions on this and other topics, register today at tonymacx86.com!

Chimera 1.8.0 Source

2012-02-27T13:13:00.000-05:00

The Chimera 1.8.0 source is now available for downloading. Here is the link to the commit: http://forge.voodooprojects.org/p/chameleon/source/commit/1832/

There is a standalone installer, available at tonymacx86.com/downloads. For bug reporting, feature requests, and general feedback please use the Chimera forum.

-tonymacx86 & MacMan

Related Posts:
Chimera 1.8 Change Log
Chimera 1.8 Update: OS X 10.8 Mountain Lion Support

For discussions on this and other topics, register today at tonymacx86.com!

Chimera 1.8.0 Change Log

2012-02-24T12:32:00.000-05:00

Here are the details on specifically what I changed in Chimera 1.8.0.

• Mountain Lion Boot Support:
Based on cparm's patch.

i386/boot2/boot.c
Changed all (checkOSVersion("10.7") to ((checkOSVersion("10.7")) || (checkOSVersion("10.8")))

i386/libsaio/bootstruct.c
Changed:
&& (gMacOSVersion[2] == '.') && (gMacOSVersion[3] == '7'))

To:
&& (gMacOSVersion[2] == '.') && ((gMacOSVersion[3] == '7') || (gMacOSVersion[3] == '8')))

• Fixed showing boot volume detail:

i386/boot2/gui.c
Changed:
shoWinfo = true

To:
shoWinfo = false

• Trunk Commit: 1827 Xcode 4.3 compile fix:

i386/util/fdisk/misc.c
Changed:
void
putshort(p, l)
void *p;
u_int16_t l;

To:
putshort(
void *p,
u_int16_t l)

• Added addtitional NVIDIA cards and fixed some card definitions using info from latest trunk, ErmaC branch and tonymacx86.com users:

i386/libsaio/nvidia.c
Added:
{ 0x10DE05E7, "Tesla C1060" },
{ 0x10DE061E, "Quadro FX 3700M" },
{ 0x10DE0621, "GeForce GT 230" },
{ 0x10DE062B, "GeForce 9800M GS" },
{ 0x10DE0655, "GeForce GT 120" },
{ 0x10DE06F1, "GeForce G105M" },
{ 0x10DE06FF, "HICx16 + Graphics" },
{ 0x10DE0840, "GeForce 8200M" },
{ 0x10DE0869, "GeForce 9400" },
{ 0x10DE08A0, "GeForce 320M" },
{ 0x10DE08A4, "GeForce 320M" },
{ 0x10DE0A26, "GeForce 405" },
{ 0x10DE0A27, "GeForce 405" },
{ 0x10DE0A38, "Quadro 400" },
{ 0x10DE0A76, "ION" },
{ 0x10DE0A7A, "GeForce 315M" },
{ 0x10DE0CA5, "GeForce GT 220" },
{ 0x10DE0CAC, "GeForce GT 220" },
{ 0x10DE1051, "GeForce GT 520MX" },
{ 0x10DE1084, "GeForce GTX 560" },
{ 0x10DE1087, "GeForce GTX 560 Ti 448 Cores" },
{ 0x10DE1089, "GeForce GTX 580" },
{ 0x10DE108B, "GeForce GTX 590" },
{ 0x10DE1091, "Tesla M2090" },
{ 0x10DE109B, "Quadro 7000" },
{ 0x10DE10C0, "GeForce 9300 GS" },
{ 0x10DE10D8, "NVS 300" },
{ 0x10DE1241, "GeForce GT 545" },
{ 0x10DE1243, "GeForce GT 545" },

Changed:
{ 0x10DE0CAC, "GeForce 315" }, to { 0x10DE0CAC, "GeForce GT 220" },
{ 0x10DE0DF4, "GeForce GT 450M" }, to { 0x10DE0DF4, "GeForce GT 540M" },
{ 0x10DE109A, "N12E-Q5" }, to { 0x10DE109A, "Quadro 5010M" },

• Added additional AMD/ATI Cards:

i386/libsaio/ati.c
Added from trunk, ErmaC and tonymacx86.com users:
{ 0x9440, 0x0851174B, CHIP_FAMILY_RV770, "ATI Radeon HD 4870", kMotmot },
{ 0x68BA, 0x31501682, CHIP_FAMILY_JUNIPER, "AMD Radeon HD 6770", kVervet },
{ 0x68BF, 0x31401682, CHIP_FAMILY_JUNIPER, "AMD Radeon HD 6750", kVervet },
{ 0x68C0, 0x395217AA, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5730", kNull },
{ 0x68C1, 0x02051025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x02961025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x030A1025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x033D1025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x03471025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x03561025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x03581025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x035A1025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x035C1025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x03641025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x03791025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x037E1025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68C1, 0x03821025, CHIP_FAMILY_REDWOOD, "ATI Mobility Radeon HD 5750", kNull },
{ 0x68E4, 0x1426103C, CHIP_FAMILY_CEDAR, "AMD Radeon HD 6370M ", kNull },
{ 0x68E4, 0x397917AA, CHIP_FAMILY_CEDAR, "AMD Radeon HD 6370M ", kNull },
{ 0x6719, 0x21FD1458, CHIP_FAMILY_CAYMAN, "AMD Radeon HD 6950", kGibba },
{ 0x6719, 0x186B174B, CHIP_FAMILY_CAYMAN, "AMD Radeon HD 6950", kNull },
{ 0x6720, 0x04901028, CHIP_FAMILY_BARTS, "AMD Radeon HD 6970M", kElodea },
{ 0x6739, 0x03B41043, CHIP_FAMILY_BARTS, "AMD Radeon HD 6850", kDuckweed },
{ 0x6740, 0x1631103C, CHIP_FAMILY_TURKS, "AMD FirePro M5950", kNull },
{ 0x6740, 0x3388103C, CHIP_FAMILY_TURKS, "AMD Radeon HD 6770M", kNull },
{ 0x6741, 0x1688103C, CHIP_FAMILY_TURKS, "AMD Radeon HD 7690M", kNull },
{ 0x6758, 0x00121028, CHIP_FAMILY_TURKS, "AMD Radeon HD 6670", kBulrushes },
{ 0x6759, 0x20121787, CHIP_FAMILY_TURKS, "AMD Radeon HD 6570", kPithecia },
{ 0x6760, 0x00031179, CHIP_FAMILY_CAICOS, "AMD Radeon HD 6450M", kNull },
{ 0x6779, 0xE180174B, CHIP_FAMILY_CAICOS, "AMD Radeon HD 6450", kPithecia },

• Added the following missing AMD/ATI default card definitions:

i386/libsaio/ati.c
{ 0x944A, 0x00000000, CHIP_FAMILY_RV770, "ATI Radeon HD 4800 Series", kMotmot },
{ 0x9480, 0x00000000, CHIP_FAMILY_RV730, "ATI Mobility Radeon HD 4650 Series", kGliff },
{ 0x9553, 0x00000000, CHIP_FAMILY_RV710, "ATI Radeon HD 4300/4500 Series", kShrike },
{ 0x9581, 0x00000000, CHIP_FAMILY_RV630, "ATI Radeon HD 3600 Series", kNull },
{ 0x9583, 0x00000000, CHIP_FAMILY_RV630, "ATI Radeon HD 3600 Series", kNull },
{ 0x9588, 0x00000000, CHIP_FAMILY_RV630, "ATI Radeon HD 2600 XT Series", kNull },
{ 0x9589, 0x00000000, CHIP_FAMILY_RV630, "ATI Radeon HD 3610 Series", kNull },
{ 0x9591, 0x00000000, CHIP_FAMILY_RV635, "ATI Radeon HD 3600 Series", kNull },
{ 0x68A1, 0x00000000, CHIP_FAMILY_CYPRESS, "ATI Mobility Radeon HD 5800 Series", kNomascus },
{ 0x68A8, 0x00000000, CHIP_FAMILY_CYPRESS, "AMD Radeon HD 6800M Series", kUakari },
{ 0x68BF, 0x00000000, CHIP_FAMILY_JUNIPER, "AMD Radeon HD 6700 Series", kVervet },
{ 0x68C0, 0x00000000, CHIP_FAMILY_REDWOOD, "AMD Radeon HD 6570M/5700 Series", kNull },
{ 0x68C1, 0x00000000, CHIP_FAMILY_REDWOOD, "AMD Radeon HD 6500M/5600/5700 Series", kNull },
{ 0x68E0, 0x00000000, CHIP_FAMILY_CEDAR, "ATI Mobility Radeon HD 5400 Series", kEulemur },
{ 0x68E1, 0x00000000, CHIP_FAMILY_CEDAR, "ATI Mobility Radeon HD 5400 Series", kEulemur },
{ 0x68E4, 0x00000000, CHIP_FAMILY_CEDAR, "ATI Radeon HD 6300M Series", kNull },
{ 0x6750, 0x00000000, CHIP_FAMILY_TURKS, "AMD Radeon HD 6600A Series", kNull },

• Added the following missing AMD/ATI chip family:

i386/libsaio/ati.c
Added CHIP_FAMILY_RV790 to chip_family_t;
Added "RV790" to chip_family_name[]

• Made the following cosmetic changes for AMD/ATI cards:

i386/libsaio/ati.c

Changed all vendor names in radeon_cards to ATI as that would be contrary to what Apple would report.
For any specific card configuration that contained a generic name using something like "ATI Radeon HD 4800 Series" changed it to the specific card name and removed "Series".
Added "Series" to any generic card configuration to signify it's a generic and not card specific.
Corrected a bunch of card names.

There is a standalone installer, available at tonymacx86.com/downloads. For bug reporting, feature requests, and general feedback please use the Chimera forum.

-MacMan & tonymacx86

For discussions on this and other topics, register today at tonymacx86.com!

Chimera 1.7.0 Change Log

2011-12-13T12:16:00.001-05:00

Back ported the following Chameleon commits:

r1671 Updated credits
r1674 Improved Multi-drive boot support from dmazar.
r1710 Fix for kernel flags not being passed to kernel on RAID volumes.

Added the following AMD GPUs:

0x9440, 0x114A174B, CHIP_FAMILY_RV770, "Sapphire Radeon HD4870 Vapor-X", kCardinal
0x954F, 0x20081787, CHIP_FAMILY_RV710, "ATI Radeon HD 4350", kNull
0x6899, 0xE174174B, CHIP_FAMILY_CYPRESS, "ATI Radeon HD 5850", kUakari
0x68A0, 0x043A1028, CHIP_FAMILY_CYPRESS, "ATI Mobility Radeon HD 5870", kNomascus
0x68B8, 0x21F61458, CHIP_FAMILY_JUNIPER, "ATI Radeon HD 5770", kVervet
0x68B8, 0x200A1787, CHIP_FAMILY_JUNIPER, "ATI Radeon HD 5770", kVervet
0x68BE, 0x22881787, CHIP_FAMILY_JUNIPER, "ATI Radeon HD 5750", kVervet
0x68F9, 0x010E1002, CHIP_FAMILY_CEDAR, "ATI Radeon HD 5450", kEulemur
0x68F9, 0x03741043, CHIP_FAMILY_CEDAR, "ATI Radeon HD 5450", kEulemur
0x68F9, 0x23401462, CHIP_FAMILY_CEDAR, "ATI Radeon HD 5450", kEulemur
0x68F9, 0xE145174B, CHIP_FAMILY_CEDAR, "ATI Radeon HD 5450", kEulemur
0x68F9, 0xE153174B, CHIP_FAMILY_CEDAR, "ATI Radeon HD 5450", kEulemur
0x6719, 0x0B001002, CHIP_FAMILY_CAYMAN, "AMD Radeon HD 6950", kGibba
0x6719, 0x20101787, CHIP_FAMILY_CAYMAN, "AMD Radeon HD 6950", kGibba
0x6720, 0x04BA1028, CHIP_FAMILY_BARTS, "AMD Radeon HD 6970M", kElodea
0x6738, 0x31071682, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed
0x6738, 0x31081682, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed
0x6738, 0x174B174B, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kBulrushes
0x6739, 0xAA881002, CHIP_FAMILY_BARTS, "AMD Radeon HD 6850", kDuckweed
0x6740, 0x1D121043, CHIP_FAMILY_TURKS, "AMD Radeon HD 6730M", kNull
0x6760, 0x165A103C, CHIP_FAMILY_CAICOS, "AMD Radeon HD 6470M", kNull
0x6760, 0x167D103C, CHIP_FAMILY_CAICOS, "AMD Radeon HD 6470M", kNull
0x68A0, 0x00000000, CHIP_FAMILY_CYPRESS, "ATI Radeon HD 5800M Series", kNomascus
0x68BA, 0x00000000, CHIP_FAMILY_JUNIPER, "ATI Radeon HD 6770 Series", kVervet
0x6719, 0x00000000, CHIP_FAMILY_CAYMAN, "AMD Radeon HD 6950 Series", kGibbas

Added a change that should hopefully allow the ability to override kNull frame buffer definitions.

Added the following NVIDIA GPUs:

0x10DE06DF, "Tesla M2070-Q"
0x10DE0DCD, "GeForce GT 555M"
0x10DE0DCE, "GeForce GT 555M"
0x10DE0DD6, "GeForce GT 550M"
0x10DE0DDA, "Quadro 2000M"
0x10DE0DEC, "GeForce GT 525M"
0x10DE0DED, "GeForce GT 520M"
0x10DE0DF4, "GeForce GT 450M"
0x10DE0DF5, "GeForce GT 525M"
0x10DE0DF6, "GeForce GT 550M"
0x10DE0DF7, "GeForce GT 520M"
0x10DE0DFA, "Quadro 1000M"
0x10DE0E31, "GeForce GTX 485M"
0x10DE0E3A, "Quadro 3000M"
0x10DE0E3B, "Quadro 4000M"
0x10DE1054, "GeForce GT 410M"
0x10DE1057, "Quadro NVS 4200M"
0x10DE107F, "NVIDIA GF119-ES"
0x10DE10C5, "GeForce 405"
0x10DE1201, "GeForce GTX 560"
0x10DE1251, "GeForce GTX 560M"

Added the following cards to the NVIDIA memory detection bug workaround:

GT 440 Device ID 0x0DE0
GT 525M Device ID 0x0DEC

There is a standalone installer, available at tonymacx86.com/downloads. For bug reporting, feature requests, and general feedback please use the Chimera forum.

-MacMan & tonymacx86

For discussions on this and other topics, register today at tonymacx86.com!

Chimera 1.5.4 Change Log

2011-09-10T14:04:00.000-04:00

It's been a busy couple of weeks since I released Chimera 1.5.0. I delayed this blog post due to the updates I had to make to fix and support additional AMD cards and the Facetime issue. This revision is based on Chameleon 2.0 Revision 1394 which is the code base for the official release of Chameleon 2.0. Since Chimera 1.4 was released the Chameleon team has included some of what I did in Chimera 1.4 to the trunk. I have also have been supplying some fixes and enhancements to the Chameleon trunk to make future updates of Chimera easier.

The main features in this release are:

Support for additional NVIDA and AMD video controllers
Inclusion or correction fo some AMD frame buffer names
Facetime fix from olegpronin at insanelymac (of which I have added a new Boot key to bypass this fix if needed (thanks to Lnx2Mac for the idea.))
Sandy Bridge HD Graphics support based on the work valv started to support the Mobile HD 3000 controller. I've enhanced it to support mobile and desktop controllers.

Here are the specific edits for this version and as a reminder, all lines starting with a dash will be the name of the affected file starting at the branch root.

General fixes and enhancements:
- i386/boot2/boot.h
Added #define kSkipFTFix "SkipFTFix" for disabling the Facetime fix code.
- i386/libsaio/ati.c
Enhanced some of the debug messages for ports and frame buffers.
Added a debug message to display the number of ports the cards VBIOS is reporting.
Changed default frame buffer for the HD 6670 and HD 6450 to Bulrushes
Added the following additional AMD cards:
{ 0x68BF, 0x220E1458, CHIP_FAMILY_JUNIPER, "ATI Radeon HD 6750", kVervet },
{ 0x6738, 0x00D01002, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed },
{ 0x6738, 0x21FA1002, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed },

{ 0x6738, 0x21FA1458, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed },

{ 0x6738, 0x31031682, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed },

{ 0x6738, 0x31041682, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed },

{ 0x6738, 0xE178174B, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed },

{ 0x6738, 0x20101787, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed },

{ 0x6738, 0x23051787, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870", kDuckweed },

{ 0x6739, 0x24411462, CHIP_FAMILY_BARTS, "AMD Radeon HD 6850", kDuckweed },

{ 0x6739, 0xE177174B, CHIP_FAMILY_BARTS, "AMD Radeon HD 6850", kDuckweed },

{ 0x6758, 0x67581002, CHIP_FAMILY_TURKS, "AMD Radeon HD 6670", kBulrushes },

{ 0x6758, 0x22051458, CHIP_FAMILY_TURKS, "AMD Radeon HD 6670", kBulrushes },

{ 0x6758, 0x31811682, CHIP_FAMILY_TURKS, "AMD Radeon HD 6670", kBulrushes },

{ 0x6758, 0x31831682, CHIP_FAMILY_TURKS, "AMD Radeon HD 6670", kBulrushes },

{ 0x6758, 0xE1941746, CHIP_FAMILY_TURKS, "AMD Radeon HD 6670", kBulrushes },

{ 0x6779, 0x64501092, CHIP_FAMILY_CAICOS, "AMD Radeon HD 6450", kBulrushes },

{ 0x6779, 0xE164174B, CHIP_FAMILY_CAICOS, "AMD Radeon HD 6450", kBulrushes },

- i386/libsaio/fake_efi.c

Added olegpronin's Facetime fix
Added the ability to bypass this fix at boot time using the boot key of SkipFTFix=Yes
- i386/libsaio/gma.c
Added valv's code for Mobile HD 3000 Graphics support
Added support for Mobile HD 2000
Added support for desktop HD 2000 and HD 3000
Added specific code for HD 2000 and HD 3000
Added a work around for desktop HD 3000's to work with unpatched kexts or DSDT edits.
- i386/libsaio/nvidia.c
Added the following new device ID:
{ 0x10DE1086, "GeForce GTX 570" },

Chimera Specific Changes:
- i386/boot2/prompt.c
Changed Chameleon to Chimera and hardcoded version information
- i386/libsaio/fake_efi.c
Changed FIRMWARE_VENDOR from Chameleon 2.0 to Chimera 1.5

For bug reporting, feature requests, and general feedback please use the Chimera forum.

-MacMan & tonymacx86

For discussions on this and other topics, register today at tonymacx86.com!

Minimal DSDT Edits for Gigabyte Socket 1155 Motherboards

2011-07-11T00:27:00.000-04:00

I started researching and testing what edits from my New Minimal DSDT Edits for Gigabyte Socket 1156 Motherboards were or weren't needed on the Socket 1155 boards. The good news is that the majority of the edits carry over, but some are not needed. For example, we don't need to inject anything for the USB ports to be fully recognized. But there are a couple of required Socket 1155 specific edits.

The following is a guide for editing the extracted DSDT. The first thing you will need to do is the required edits so that the DSDT will compile. They are:

1) "Reserved method must return a value"

Add to the end of _WAK

Return (Package (0x02)
{
0x00,
0x00
})

2) "Method local variable is not initialized"

In Scope (\_SI)

Change both:

Store (Local0, Local0)

To:

Store (0x00, Local0)

3) "Use of compiler reserved name"

Replace all _T_ with T_

4) "Effective AML package length is zero"

Change:

Name (RPMV, Package (0x00) {})

To:

Name (RPMV, Package (Zero) {})

5) "Result is not used, operator has no effect"

Change:

Or (0x03, PARM)

To:

Or (PARM, 0x03, PARM)

The first required edit is to include Method DTGP for passing configuration parameters to OS X. Next up is renaming device names to follow Apple's conventions. They are renaming all PX40 to LPCB, PX43 to SBUS, all AZAL to HDEF, Device (IDE1) to Device (SATA) and it's sub-device ports from Device (PRIM) to Device (PRT0) and Device (SECD) to Device (PRT1), deleting Device (IDE2) (unused) and finally renaming the USB device names, USBE to EHC1 and USE2 to EHC2

Now that we have all of the correct device names now we need to add some missing information. For the SMBus we need to add the following to Device (SBUS) as a nested sub-device:

Device (BUS0)
{
Name (_CID, "smbus")
Name (_ADR, 0x00)
Device (DVL0)
{
Name (_ADR, 0x57)
Name (_CID, "diagsvault")
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"address",
0x57
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
}

For ALC8xxHDA to work correctly we need to inject into Device (HDEF) codec information. Here is an example of what needs to be added for a board using and an ALC889 codec:

Method (_DSM, 4, NotSerialized)
{
Store (Package (0x04)
{
"layout-id",
Buffer (0x04)
{
0x79, 0x03, 0x00, 0x00 // decimal 889
},
"PinConfigurations",
Buffer (Zero)
{
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}

For other codecs you will need to change the layout-id to match your codec.

There is a problem with Audio break ups that can be corrected in the DSDT. The first is in Device (PIC) remove these two lines:

IRQNoFlags ()
{2}

The other fix for audio break ups is in Device (TMR) where we need to change:

Method (_CRS, 0, NotSerialized)
{
If (LGreaterEqual (OSFX, 0x03))
{
If (HPTF)
{
Return (ATT6)
}
Else
{
Return (ATT5)
}
}
Else
{
Return (ATT5)
}
}

To:
Method (_CRS, 0, NotSerialized)
{
Return (ATT6)
}

The next fix is to prevent kernel panics in AppleIntelCPUPowerManagement at boot time. This fix is easy; just change Method (_STA, 0, NotSerialized) to Return (0x0F) and to change Method (_CRS, 0, NotSerialized) to Return (ATT3).

The final edit is to allow you to use the power button to put the computer to sleep. In Device (PWRB) change Name (_HID, EisaId ("PNP0C0C")) to Name (_CID, EisaId ("PNP0C0C")).

If you don't want to bother with these edits, you can download pre-edited DSDTs from the tonymacx86.com DSDT Database.

For discussions on this and other topics, register today at http://www.tonymacx86.com/

Creating a Bootable “DOS” USB Stick on a Hackintosh Without Windows or MS-DOS

2011-07-05T11:46:00.000-04:00

A lot of manufacturers provide DOS only firmware updaters. If you have a dual boot system with Windows it’s a piece of cake. But the issue is how do you do this on a Hackintosh without Windows installed? Well I have found a solution, FreeDOS, a free DOS-compatible operating system for IBM-PC compatible systems.

What you need:

USB drive greater than 16 MB
FreeDOS Base CD
Blank CD or CD-RW

Installation procedure:

Format the USB drive as a MBR/FAT volume
Burn the FreeDOS Base CD
Shut down OS X and disconnect all disk drives
Boot computer while ensuring that Legacy USB support is enabled in the BIOS and USB drive is connected
Boot from FreeDOS Base CD and follow instructions to install. It will install by default to the 1st drive it finds. In this case it’s the USB drive as it’s the only one connected.
Shutdown and reconnect all disk drives.
You now have a bootable “DOS” drive.

This drive is bootable and can be read and written to in OS X. You can copy any DOS based programs on to it and boot from it to run them.

For discussions on this and other topics, register today at tonymacx86.com!

Chimera v1.4.0 Change Log

2011-05-20T12:23:00.044-04:00

It's good to see that the Chameleon team has started porting some of the changes I made from Chimera to the Chameleon 2.0 RC5 trunk. They recently did a major update and added significant new features in trunk revision 833. Some of the changes were enhanced and fixed Sandy Bridge support amongst others. So I went back and integrated my changes into that trunk version and created Chimera v1.4.0.

Starting with this version I will list in detail all changes I've made. All lines starting with a dash will be the name of the affected file starting at the branch root.

General fixes and enhancements:

Chimera 1.4.0 Installer available
at tonymacx86.com/downloads

- CHANGES
Fixed typos
- doc/BootHelp.txt
  Added UseKernelCache=Yes|No
  Reworded some options
- TODO
  Fixed typos
- i386/boot2/boot.c
  Fixed typos in comments
  Reordered keys according to source file name
- i386/doc/README
  Fixed typos
- i386/libsaio/acpi_patcher.c
  In switch (Platform.CPU.Model)
  Removed nonexistent CPU model case 0x0D: // ?
      Redid comments for all case CPU_MODEL_ to provide actual CPU model names
- i386/libsaio/ati.c
  In static radeon_card_info_t radeon_cards[]
      Removed duplicate blank lines
      Removed duplicate "ATI Radeon HD 5400 Series"
      Added additional AMD cards:
          { 0x6739, 0x21F81458, CHIP_FAMILY_BARTS, "AMD Radeon HD 6850",
kDuckweed },
          { 0x6719, 0x00000000, CHIP_FAMILY_CAYMAN, "AMD Radeon HD 6950
Series", kNull },
{ 0x6738, 0x00000000, CHIP_FAMILY_BARTS, "AMD Radeon HD 6870 Series",
kDuckweed },
          { 0x6739, 0x00000000, CHIP_FAMILY_BARTS, "AMD Radeon HD 6850 Series",
kDuckweed },
          { 0x673E, 0x00000000, CHIP_FAMILY_BARTS, "AMD Radeon HD 6790 Series",
kNull },
      Changed { 0x6718, 0x00000000, CHIP_FAMILY_CAYMAN, "AMD Radeon HD 6900
Series", kNull },
    to { 0x6718, 0x00000000, CHIP_FAMILY_CAYMAN, "AMD Radeon HD 6970 Series",
kNull },
- i386/libsaio/cpu.c
  Updated /* Mobile CPU */ to use MSR_IA32_PLATFORM_ID instead of a hex value
  Rearranged DBG info at end and added additional info
- i386/libsaio/cpu.h
  Added #define MSR_IA32_PLATFORM_ID 0x17
- i386/libsaio/memvendors.h
  Removed extra spaces in fromt of { 0, 0x01, "AMD"},
- i386/libsaio/nvidia.c
  Added comments to add device id blocks like // 0040 - 004F, // 0050 - 005F, etc.

Added workaround code for GT 430 & 9600M GT memory detection from valv

Added GT 420 to GT 430 & 9600M GT memory detection work around
  Added the following new device IDs from valv and Linux driver (some are already in v1.3.0):
      { 0x10DE0410, "GeForce GT 330" },
      { 0x10DE053A, "GeForce 7050 PV / nForce 630a" },
      { 0x10DE053B, "GeForce 7050 PV / nForce 630a" },
      { 0x10DE053E, "GeForce 7025 / nForce 630a" },
      { 0x10DE05ED, "Quadroplex 2200 D2" },
      { 0x10DE05F8, "Quadroplex 2200 S4" },
      { 0x10DE05FF, "Quadro FX 3800" },
      { 0x10DE0601, "GeForce 9800 GT" },
      { 0x10DE0603, "GeForce GT 230" },
      { 0x10DE060F, "GeForce GTX 285M" },
      { 0x10DE0619, "Quadro FX 4700 X2" },
      { 0x10DE061B, "Quadro VX 200" },
      { 0x10DE062D, "GeForce 9600 GT" },
      { 0x10DE062E, "GeForce 9600 GT" },
      { 0x10DE0631, "GeForce GTS 160M" },
      { 0x10DE0632, "GeForce GTS 150M" },
      { 0x10DE0635, "GeForce 9600 GSO" },
      { 0x10DE0637, "GeForce 9600 GT" },
      { 0x10DE0638, "Quadro FX 1800" },
      { 0x10DE063A, "Quadro FX 2700M" },
      { 0x10DE0651, "GeForce G 110M" },
      { 0x10DE0653, "GeForce GT 120M" },
      { 0x10DE0654, "GeForce GT 220M" },
      { 0x10DE0656, "GeForce 9650 S" },
      { 0x10DE065F, "GeForce G210" },
      { 0x10DE06E2, "GeForce 8400" },
      { 0x10DE06E3, "GeForce 8400 SE" },
      { 0x10DE06E6, "GeForce G100" },
      { 0x10DE06E7, "GeForce 9300 SE" },
      { 0x10DE06FB, "Quadro FX 370M" },
      { 0x10DE07E0, "GeForce 7150 / nForce 630i" },
      { 0x10DE07E1, "GeForce 7100 / nForce 630i" },
      { 0x10DE07E2, "GeForce 7050 / nForce 630i" },
      { 0x10DE07E3, "GeForce 7050 / nForce 610i" },
      { 0x10DE07E5, "GeForce 7050 / nForce 620i" },
      { 0x10DE0844, "GeForce 9100M G" },
      { 0x10DE0845, "GeForce 8200M G" },
      { 0x10DE0846, "GeForce 9200" },
      { 0x10DE0847, "GeForce 9100" },
      { 0x10DE0848, "GeForce 8300" },
      { 0x10DE0849, "GeForce 8200" },
      { 0x10DE084A, "nForce 730a" },
      { 0x10DE084B, "GeForce 9200" },
      { 0x10DE084C, "nForce 980a/780a SLI" },
      { 0x10DE084D, "nForce 750a SLI" },
      { 0x10DE084F, "GeForce 8100 / nForce 720a" },
      { 0x10DE0860, "GeForce 9400" },
      { 0x10DE0861, "GeForce 9400" },
      { 0x10DE0862, "GeForce 9400M G" },
      { 0x10DE0863, "GeForce 9400M" },
      { 0x10DE0864, "GeForce 9300" },
      { 0x10DE0865, "ION" },
      { 0x10DE0866, "GeForce 9400M G" },
      { 0x10DE0867, "GeForce 9400" },
      { 0x10DE0868, "nForce 760i SLI" },
      { 0x10DE086D, "GeForce 9200" },
      { 0x10DE086E, "GeForce 9100M G" },
      { 0x10DE086F, "GeForce 8200M G" },
      { 0x10DE087A, "GeForce 9400" },
      { 0x10DE0A22, "GeForce 315" },
      { 0x10DE0A2B, "GeForce GT 330M" },
      { 0x10DE0A2C, "NVS 5100M" },
      { 0x10DE0A2D, "GeForce GT 320M" },
      { 0x10DE0A35, "GeForce GT 325M" },
      { 0x10DE0A3C, "Quadro FX 880M" },
      { 0x10DE0A64, "ION" },
      { 0x10DE0A67, "GeForce 315" },
      { 0x10DE0A68, "GeForce G105M" },
      { 0x10DE0A69, "GeForce G105M" },
      { 0x10DE0A6A, "NVS 2100M" },
      { 0x10DE0A6C, "NVS 3100M" },
      { 0x10DE0A6E, "GeForce 305M" },
      { 0x10DE0A6F, "ION" },
      { 0x10DE0A70, "GeForce 310M" },
      { 0x10DE0A71, "GeForce 305M" },
      { 0x10DE0A72, "GeForce 310M" },
      { 0x10DE0A73, "GeForce 305M" },
      { 0x10DE0CA0, "GeForce GT 330 " },
      { 0x10DE0CA2, "GeForce GT 320" },
      { 0x10DE0CA4, "GeForce GT 340" },
      { 0x10DE0CA7, "GeForce GT 330" },
      { 0x10DE0CAC, "GeForce 315" },
      { 0x10DE0CAF, "GeForce GT 335M" },
      { 0x10DE0CB0, "GeForce GTS 350M" },
      { 0x10DE0CBC, "Quadro FX 1800M" },
      { 0x10DE0DE0, "GeForce GT 440" },
      { 0x10DE0DE5, "GeForce GT 530" },
      { 0x10DE1040, "GeForce GT 520" },
      { 0x10DE1050, "GeForce GT 520M" },
      { 0x10DE1081, "GeForce GTX 570" },   Updated with model name
      { 0x10DE1082, "GeForce GTX 560 Ti" }, Updated with model name
      { 0x10DE1088, "GeForce GTX 590" },
      { 0x10DE10C3, "GeForce 8400 GS" },
      { 0x10DE1200, "GeForce GTX 560 Ti" },
      { 0x10DE1244, "GeForce GTX 550 Ti" },
      { 0x10DE1245, "GeForce GTS 450" },
- i386/libsaio/platform.h
  Added additional info to comments for #define CPU_MODEL_
- i386/libsaio/smbios.c
  Updated comments on all case CPU_MODEL_ to provide actual CPU model names
- i386/libsaio/smbios_getters.c
  Updated comments on all case CPU_MODEL_ to provide actual CPU model names
  Removed all references to nonexistent CPU models:
      case 0x0D: // ?
      case 0x19: // Intel Core i5 650 @3.20 Ghz
  Added workaround to not calculate qpibusspeed for LGA 1155 and LGA 1156 CPUs
and report a sane value
  Added Xeon model detection and reporting to CPU_MODEL_FIELDS:
  Broke out case CPU_MODEL_SANDY_XEON: to report Xeon CPU

Chimera Specific Changes:

- i386/boot2/Makefile
  git revision workaround
- i386/boot2/prompt.c
  Changed Chameleon to Chimera
- i386/libsaio/fake_efi.c
  Changed FIRMWARE_VENDOR from Chameleon 2.0.0 to Chimera 1.4.0

For bug reporting, feature requests, and general feedback please use the Chimera forum.

-MacMan & tonymacx86

For discussions on this and other topics, register today at tonymacx86.com!

Chimera v1.1.0 Source Pedigree and Enhancements

2011-05-11T12:54:00.000-04:00

Most of you know about Chimera based on the announcement we made on the tonymacx86 Blog. A few of you are interested in what I did and what is different in Chimera compared to the Chameleon trunk. Without getting too deep into the code, I will attempt to explain in general terms these differences. I will be explaining the changes based on v1.1.0 r753 as this was the first source version released.

I wanted to start with the trunk version as I know that code is clean and stable. The first few things I did was fix a few spelling errors in TODO and i386/doc/README. No big deal, but I think something that was overdue. Next, I went through all of the source files. I cleaned up the comments for readability to make sure they all lined up properly. Here are the list of files that I did this to:

i386/boot2/boot.h
i386/libsa/memory.h
i386/libsaio/bootstruct.h
i386/libsaio/cpu.h
i386/libsaio/fdisk.h
i386/libsaio/memvendors.h
i386/libsaio/nvidia.c
i386/libsaio/smbio_patcher.c
i386/libsaio/smbio_patcher.h
i386/libsaio/spd.c

Again, not a big deal, but to make it easier for me to read the code.

So now it was time to start merging features. I decided to start with Kabyl's ATI support. For this I had to update doc/BootHelp.txt to include his 2 new boot keys. I also added the two actual boot keys to i386/boot2/boot.h. Then in i386/libsaio/, I replaced the trunk ati.c with Kabyl's. Added his ati_reg.h and removed ati.h. Then I added Kabyl's changes to pci.c, pci.h and pci_setup.c.

Next was merging valv's NVIDIA changes. For that I added 2 new NVIDIA keys to i386/boot2/boot.h. Then in i386/libsaio/nvidia.c I used a combination of trunk, valv and new device ID's I could find to support as many cards as possible in NVKnownChipsets. I then used valv's #define NVIDIA_ROM_SIZE 0x20000 and static uint8_t default_dcfg_0[], static uint8_t default_dcfg_1[], and static uint8_t default_NVPM[]. I also used his improved video RAM detect code, workaround code for gt 430 & 9600M GT and support for user supplied @0,display-cfg and @1,display-cfg keys.

The final changes were in adding Sandy Bridge support. For this I used some of valv's code but added a bunch of my own. From valv I used his setup features which required using his CPU Features in platform.h. Where I also took his #define bit definitions. Then in cpu.h I used his additional MSR defines and static inline __attribute__((always_inline)) void wrmsr(unsigned val, msr_t msr), typedef struct msr_struct and static inline __attribute__((always_inline)) msr_t rdmsr(unsigned val). And finally some of his CPU debug messages and formatting at the end of cpu.c.

So as documented above, I've reused a bunch of code from Kabyl and valv. Now let's discuss the changes I did. The first thing is in platform.h where I added #define CPU_MODEL_DUNNINGTON 0x1D and #define CPU_MODEL_SANDY_BRIDGE 0x2A. Then in cpu.c I changed all p->CPU.Model from using hex values to defined values from platform.h. I did this to make troubleshooting easier- as I don't know all of the CPUs model codes by heart. I then removed p->CPU.Model == 0x1f as I can find no reference anywhere of this CPU model. I then went and redid if ((p->CPU.Vendor == 0x756E6547 /* Intel */) && ((p->CPU.Family == 0x06) || (p->CPU.Family == 0x0f))) to add Sandy Bridge support.

When testing the code I found that cpu.c was reporting 8 cores and 16 threads for Core i and Sandy Bridge CPUs. It took a bit of digging but I found that in the original code the value for them was being extracted from a Machine Specific Register (MSR) that was returning the Maximum # of addressable IDs for logical processors in this physical package and Maximum # of addressable IDs for processors cores in this physical package. So I did a bunch of testing and research and found that there is an undocumented MSR, MSR_CORE_THREAD_COUNT that will return the correct values. I used that in Chimera v1.0.0 r750 but we soon learned that that isn't a valid MSR on Penryn or earlier CPU models. So in v1.1.0 I added the following code to set the number of cores and threads correctly:

if ((p->CPU.Vendor == 0x756E6547 /* Intel */) &&
(p->CPU.Family == 0x06) && (p->CPU.Model >= 0x1a)){

msr = rdmsr64(MSR_CORE_THREAD_COUNT); // Undocumented MSR

p->CPU.NoCores = bitfield((uint32_t)msr, 31, 16); // Get actual values

p->CPU.NoThreads = bitfield((uint32_t)msr, 15, 0); // Get actual values

} else { // Use previous method for Cores and Threads

p->CPU.NoThreads = bitfield(p->CPU.CPUID[CPUID_1][1], 23, 16);

p->CPU.NoCores = bitfield(p->CPU.CPUID[CPUID_4][0], 31, 26) + 1;

}

I also changed the Mobile CPU test from using a hex value to the MSR name MSR_IA32_Platform_ID.

Next up was i386/libsaio/acpi_patcher.c. Here I removed the case 0x0D: statement as this CPU model family Dothan, pre-dates the Core family. I also added a case CPU_MODEL_SANDY_BRIDGE: and added comments for what each CPU model covers. So for example:

case CPU_MODEL_FIELDS:// Intel Core i5, i7, Xeon X34xx LGA1156 (45nm).

In i386/libsaio/spd.c I changed smbus_controllers[] to report "5 Series" instead of "P55" and added {0x8086, 0x1C22, "6 Series",read_smb_intel }.

The final source file to modify was i386/libsaio/smbios_patcher.c. Here I also added better CPU comments like in acpi_patcher.c. I also changed all reference of "Apple Computer, Inc." to "Apple Inc.", fixed MacPro3,1 "SMboardproduct" and MacPro4,1 "SMboardproduct" to use the correct board numbers and finally reorganized the system order to MacBook, MacBook Pro, mini, iMac8,1, iMac11,1 MacPro3,1 and MacPro4,1. The I removed all instances of case 0x19: // Intel Core i5 650 @3.20 Ghz as I couldn't find any references to this CPU model and the description didn't match the model value. I also removed case 0x0D: and added case CPU_MODEL_SANDY_BRIDGE:. Other changes were adding DBG("FSBFrequency %d\n", Platform.CPU.FSBFrequency); and changing DBG("qpimult %x\n", qpimult); to display in hex instead of decimal. The final changes were hard coding the Processor Interconnect speed for Sandy Bridge CPUs to 4.8 GT/s instead of the incorrect calculated value. Finally I redid sm_get_cputype to correctly handle all possible CPU types, including Xeons.

In addition, I took from tonymacx86.com forum user AndyStubbs his code additions to support the AMD Radeon HD 6000 cards and his fix to i386/libsaio/smbios_patcher.c for DMI table overflow on Sandy Bridge systems. Thanks Andy.

Going forward the plan is to keep Chimera updated with trunk revisions in addition to adding new features and bug fixes.

I will post further code changes when I release new versions. So stay tuned for updates.

Further Reading:
Chimera Source
Chimera: Unified Chameleon Bootloader
Chimera Now An Official Chameleon Branch
Chimera 1.1 Update
Chimera 1.3 Update
Chimera at tonymacx86 Wiki

My 5,000th Post on tonymacx86 Forum

2011-02-28T22:25:00.000-05:00

I've just posted my 5,000th post on the tonymacx86 Forum, In this post I've recapped my Hackintosh and tonymacx86 experience. If you've wondered how I got started and what all I've done, check it out.

Chameleon's GraphicsEnabler vs. Enabler Kexts

2011-02-02T16:03:00.001-05:00

Not too long ago, one of the only ways to enable certain graphics cards was using enabler kexts such as NVEnabler.kext and ATY_init.kext. These standalone enablers do an adequate job in identifying cards and enabling full graphics acceleration, however there are numerous issues.

For example, when using the latest ATY_init.kext, you are stuck with running the kernel in 32-bit mode. If you need to change the default frame buffer for your card, you need to manually edit the kext. Finally, this enabler only supports a limited number of HD 5700 and HD 5800 cards.

With NVEnabler, you are limited to only 9xxx cards and earlier. Of the more recent cards, it only supports the GTX 260 and GTX 280. It will not recognize nor properly identify any other newer cards. In that case, you're stuck with Unknown Graphics Controller in System Profiler or a barely functional card. Finally, there has been no further development since the last release in October 2009.

While the benchmarks are the same, it's more advantageous to use Chameleon's GraphicsEnabler instead of these kexts. The Chameleon team as of Chameleon 2.0 RC5, has been advancing GraphicsEnabler development. For instance, there are 89 more supported cards in Chameleon 2.0 RC5 r699 GraphicsEnabler than in NVEnabler. While in Kabyl's branch of Chameleon 2.0 RC5 r700, there is now support for the HD 5400, HD 5500 and HD 5600. With his branch, you can also configure the frame buffer at boot time or in com.apple.boot.plist. Kabyl has stated that his branch will get merged into the main Chameleon trunk as soon as testing has completed.

So it makes sense to switch from these enablers to GraphicsEnabler. For NVIDIA cards, use the main trunk version, 2.0 RC5 r699 or newer. For ATI/AMD cards, use Kabyl's branch, 2.0 RC5 r700 or newer until his code get merged into the trunk. As always you can find the latest version of both in MultiBeast.

How to Use Chameleon's GraphicsEnabler:

If using a DSDT, simply make sure that your com.apple.Boot.plist includes:

If you are not using a DSDT, Chameleon will most likely not identify which slot your graphics card is in. In this case, make sure that your com.apple.Boot.plist includes:

Good luck- and use GraphicsEnabler!

-MacMan & tonymacx86

New Unified Realtek Onboard Audio Solution: ALC8xxHDA

2010-12-28T23:00:00.003-05:00

Introducing ALC8xxHDA.kext, a single combined LegacyHDA replacement for Realtek ALC888, ALC887/888b, ALC889, ALC885/889a, and ALC892 high-definition audio codecs. In order to initiate audio, this driver must be combined with a DSDT from the DSDT Database or HDAEnabler. For any codecs other than the native ALC885/889a, AppleHDA Rollback must also be used. All options now available in the latest MultiBeast.

To update from an existing MultiBeast LegacyHDA + AppleHDA rollback:

Delete LegacyHDA from /Extra/Extenisons
Open MultiBeast
Select ALC8xxHDA + AppleHDA Rollback + System Utilities
Reboot

To update from an existing MultiBeast VoodooHDA:

Delete VoodooHDA from System/Library/Extensions.
Open MultiBeast
Select ALC8xxHDA + AppleHDA Rollback + System Utilities
Reboot

Realtek ALC888, ALC887/888b, ALC889, ALC885/889a support:

OUTPUTS: Analog Front Headphone/Green Line-out, Orange Line-out, Grey Line-out, Digital SPDIF-OUT
INPUTS: Analog Pink Microphone, Blue Line-in, Digital SPDIF-IN

Realtek ALC892 support:
OUTPUTS: Analog Front Headphone/Green Line-out, Digital SPDIF-OUT

INPUTS: Analog Pink Microphone, Blue Line-in, Digital SPDIF-IN

Please report your results with this new method in the forum. Special thanks to complx for the ALC8xxHDA logo. Enjoy!

For discussions on this and other topics, register today at tonymacx86.com!

Graphics Card Support and Mac OS X

2010-12-06T16:32:00.000-05:00

The issue with graphics cards in OS X is that there are what is called a "Reference Design" which is based on what ATI/AMD or NVIDIA provides to manufactures for a baseline hardware design. Then there is what cards manufacturers ship, either a "Reference Design" or their own unique spin on that hardware. They do this unique spin to set their card part from the "Reference Design" cards. That is fine in Windows, but can create problems in OS X. Apple typically uses a "Reference Design" or very close to one in their graphics cards.

So where am I going with this. Apple ships and supports a limited set of ATI/AMD "Reference Design" cards in OS X, they do not provide support for all models or any major variations from the "Reference Design". The reason being that the ATI/AMD architecture requires specific model driver support. For example in 10.6 Apple only supports some 46xx and 48xx cards, there is no OOB support for the 45xx cards. So that is why you see patches and/or modifications for Apple's drivers to support some of these other cards.

The ATI/AMD 5xxx cards are finally easier to install. This has more to do with the GraphicsEnabler technology used within Hackintoshing, Kabyl's boot loader and ATY_Init. Even then you are limited to what cards are supported Out Of BOX (OOB) by Apple. For example the following are the only desktop ATI 5xxx cards Apple supports OOB:

ATI Radeon HD 5800 Series: Device ID 0x6898
ATI Radeon HD 5800 Series: Device ID 0x6899
ATI Radeon HD 5700 Series: Device ID 0x68B8
ATI Radeon HD 5600 Series: Device ID 0x68D8
ATI Radeon HD 5500 Series: Device ID 0x68D9

If your card's device id is not in this list, then you need to add your device ID to ATI5000Controller.kext and possibly ATIRadeonX3000.kext. This is great workaround but will be needed to be done after each and any Apple software update that touches the ATI drivers. Ouch.

NVIDIA cards use a different architecture and allows for a more generic driver than can support more models and variations. The new 4xx cards are based on a new architecture nicknamed "Fermi" and require new drivers. Check out this article on Tony's blog for our solutions for NVIDIA 4xx cards.

So until Apple ships support for more cards or allows AMD and NVIDIA to ship generic drivers, graphics card support is a challenge.

Minimal DSDT Edits for Gigabyte Socket 1366 Motherboards

2010-11-17T14:30:00.002-05:00

Since I posted Minimal DSDT Edits for Gigabyte Socket 1156 Motherboards I picked up a Gigabyte X58A-UD3R Rev 2.0 motherboard as part of the post tonymacx86 and I did for the CustoMac Pro 2010 project on his blog.

I started researching and testing what edits from my Socket 1156 post were or weren't needed on this board. The good news is that the majority of the edits carry over, but some are not needed. For example, we don't need to inject anything for the USB ports to be fully recognized. But there are a couple of required Socket 1366 specific edits.

The following is a guide for editing the extracted DSDT from the new Hackintosh-friendly BIOSes only. If you don't have a new Hackintosh-friendly BIOS, as I described in a previous post, you will have to have to manually edit the DSDT for the CMOS reset issue. You will also need to do the three required edits needed regardless of BIOS version. They are to include Method DTGP, add Return Package at the end of _WAK and fix the "Method local variable is not initialized (Local0)" error.

Now let’s review the common edits that are valid for the Socket 1356 and Socket 1156 motherboards.

First up are the cosmetic changes. Gigabyte uses generic device names in its DSDT instead of descriptive names like Apple does. One example is Gigabyte uses PX40 instead of LPCB for the LPC Interface Bridge. So the first thing we can do is to search for PX40 and do a global replace with LPCB. The next is to rename the System Management Bus (SMBus) device PX43 to SBUS. Next would be to rename Device (IDE1) to Device (SATA) and then within it rename Device (PRIM) to Device (PRT0) and Device (SECD) to Device (PRT1). The final cosmetic edits deal with USB. You can rename the devices to more appropriate ones as shown within this list:

Rename USB0 to UHC1
Rename USB1 to UHC2
Rename USB2 to UHC3
Rename USB3 to UHC4
Rename USB4 to UHC5
Rename USB5 to UHC6
Rename USBE to EHC1
Rename USE2 to EHC2

Next we need to add to Device (SBUS) a sub-device named Device (BUS0) as seen here:

   Device (BUS0)
   {
   Name (_CID, "smbus")
   Name (_ADR, 0x00)
   Device (DVL0)
   {
   Name (_ADR, 0x57)
   Name (_CID, "diagsvault")
   Method (_DSM, 4, NotSerialized)
   {
   Store (Package (0x02)
   {
   "address",
   0x57
   }, Local0)
   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
   Return (Local0)
   }
   }
   }

The next edit is for audio. Gigabyte uses a device name of AZAL, so we need to do a global replace with HDEF. Then we need to add codec information to Device (HDEF). All that is required is to inject layout-id and PinConfigurations.

Here is an example of what needs to be added for a board using an ALC889 codec and using our Legacy889HDA.kext:

   Method (_DSM, 4, NotSerialized)
   {
   Store (Package (0x04)
   {
   "layout-id",
   Buffer (0x04)
   {
   0x79, 0x03, 0x00, 0x00
   },
   "PinConfigurations",
   Buffer (Zero)
   {
   }
   }, Local0)
   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
   Return (Local0)
   }

There is a problem with Audio break ups in 10.6.3 and later that can be corrected in the DSDT. The first is in Device (PIC) remove these two lines:

   IRQNoFlags ()
   {2}

The other fix for audio break ups is in Device (TMR) where Gigabyte has not yet added Hackintosh logic. We need to change:

   Method (_CRS, 0, NotSerialized)
   {
   If (LGreaterEqual (OSFX, 0x03))
   {
   If (HPTF)
   {
   Return (ATT6)
   }
   Else
   {
   Return (ATT5)
   }
   }
   Else
   {
   Return (ATT5)
   }
   }

To:
   Method (_CRS, 0, NotSerialized)
   {
   Return (ATT6)
   }

Gigabyte has not yet added Hackintosh logic to Device (HPET), so you will get kernel panics in AppleIntelCPUPowerManagement. The fix is easy; just change Method (_STA, 0, NotSerialized) to Return (0x0F) and to change Method (_CRS, 0, NotSerialized) to Return (ATT3).

The next edit allows use of the power button to put the computer to sleep. In Device (PWRB) change Name (_HID, EisaId ("PNP0C0C")) to Name (_CID, EisaId ("PNP0C0C")).

One fix we can do in a Socket 1366 DSDT that I haven't been able to figure out how to do in a Socket 1156 DSDT, is cure the orange external drive icon issue. In Device (SATA) you need to add the following code:

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

For the final edits, we can thank insanelymac user mm67. His modification enables shutdown without a kernel panic (KP). This is a two part edit, of which for the first part after:

   OperationRegion (APMP, SystemIO, 0xB2, 0x02)
   Field (APMP, ByteAcc, NoLock, Preserve)
   {
   APMC, 8,
   APMD, 8
   }

Insert:

   OperationRegion (PMRS, SystemIO, 0x0430, 0x01)
   Field (PMRS, ByteAcc, NoLock, Preserve)
   {
   , 4,
   SLPE, 1
   }

For the second part change:

   Method (\_PTS, 1, NotSerialized)
   {
   Or (Arg0, 0xF0, Local0)
   Store (Local0, DBG1)
   OSTP ()
   If (LEqual (Arg0, 0x01)) {}
   If (LEqual (Arg0, 0x03)) {}
   If (LEqual (Arg0, 0x05))
   {
   Store (0x99, SMIP)
   }

To:

   Method (\_PTS, 1, NotSerialized)
   {
   Or (Arg0, 0xF0, Local0)
   Store (Local0, DBG1)
   OSTP ()
   If (LEqual (Arg0, 0x01)) {}
   If (LEqual (Arg0, 0x03)) {}
   If (LEqual (Arg0, 0x05))
   {
   Store (0x99, SMIP)
   Store (0x00, SLPE)
   Sleep (0x10)
   }

So with these edits you'll have a fully functional Socket 1366 DSDT for Gigabyte motherboards. If you don't want to tackle these edits yourself, we maintain a database at tonymacx86 with all of these edits already applied. You will always find the latest versions listed here and can access the complete database here.

If you don't see your Gigabyte Socket 1156 or Socket 1366 motherboard or version listed. You can submit it on the tonymacx86 Forum by clicking here. The instructions are at the top of the topic. After we receive it and verify that it is vanilla, we will do the edits and upload it to the database.

For discussions on this and other topics, register today at the tonymacx86 Forum!

Update in New Minimal DSDT Edits for Gigabyte Socket 1156 Motherboards

2010-10-01T17:17:00.001-04:00

I have updated the New Minimal DSDT Edits for Gigabyte Socket 1156 Motherboards post to reflect that these edits are for Socket 1156 motherboards and to include some information I found while working on edits for Gigabyte Socket 1366 boards.

The change is in the Device (SBUS) section. I have added the injection of "address" with a value of 0x57 as shown here:

   Method (_DSM, 4, NotSerialized)
   {
   Store (Package (0x02)
   {
   "address",
   0x57
   }, Local0)
   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
   Return (Local0)
   }

You can find the complete and updated Device (SBUS) in the original post.

Typo in New Minimal DSDT Edits for Gigabyte Socket 1156 Motherboards

2010-07-18T19:14:00.007-04:00

I was notified that there is a typo in the USBE/EHCI and USE2/EHC2 device edits section of my article New Minimal DSDT Edits for Gigabyte Socket 1156 Motherboards.

In that section:
   "AAPL,current-extra",
   0x04C,
Should be:
   "AAPL,current-extra",
   0x044C,

So that it matches what an iMac with a Core i5/i7 reports.

I have corrected the original article and I would suggest using this correction in your edits.

Many thanks to rekursor for finding this.

New Minimal DSDT Edits for Gigabyte Socket 1156 Motherboards

2010-06-09T11:18:00.034-04:00

We know that using a DSDT is the best way to create a vanilla Hackintosh build. The problem is that there have been numerous articles and forum posts on editing that are based on old versions of Gigabyte BIOS extracts. Many of them are retreads of the same information and are more complex than necessary. Since I am now doing the DSDT edits for the tonymacx86.com DSDT Database, I wanted to figure out what was the least amount of edits I can do, while trying to make the edits match a real Mac as much as possible.

Gigabyte's latest release cycle of P55/H55 BIOS updates in May 2010 includes a few Hackintosh-friendly enhancements. They've included the CMOS reset fix and some other changes. However, these modifications are not complete and some edits still need to be made. The way to tell if you have the Hackintosh-friendly BIOS is to search the decompiled DSDT for AMAC. If you find "Name (AMAC, 0x00)" then you have the new BIOS.

The following is a guide for editing the extracted DSDT from the new Hackintosh-friendly BIOSes only. Some of these edits can be used with the older BIOS extracts, but has not been tested or is the complete list for those versions.

First here are some cosmetic changes that will make your system look more Mac like. Gigabyte uses generic device names in it's DSDT instead of descriptive names like Apple does. One example is Gigabyte use PX40 instead of LPCB for the LPC Interface Bridge. So the first thing we can do is to search for PX40 and do a global replace with LPCB. The next is to rename the System Management Bus (SMBus) device PX43 to SBUS. Next would be to rename Device (IDE1) to Device (SATA) and then within it rename Device (PRIM) to Device (PRT0) and Device (SECD) to Device (PRT1). The final cosmetic edits deal with USB. You can rename the devices to more appropriate ones as shown within this table:

Rename USB0 to UHC1

Rename USB1 to UHC2

Rename USB2 to UHC3

Rename USB3 to UHC4

Rename USB4 to UHC5

Rename USB5 to UHC6

Rename USB6 to UHC7

Rename USBE to EHC1

Rename USE2 to EHC2

There are three required edits needed regardless of BIOS version. They are to include Method DTGP, add Return Package at the end of _WAK and fix the "Method local variable is not initialized (Local0)" error.

Now let’s review the new edits. One of the common edits has been to add a Device (BUS0). The problem I found is that sometimes it was added to the incorrect place or was coded incorrectly. The proper place for this device is as a sub-device within Device (SBUS). Here is what the correct device code should look like:

Device (BUS0)

{

Name (_CID, "smbus")

Name (_ADR, 0x00)

Device (DVL0)

{

Name (_ADR, 0x57)

Name (_CID, "diagsvault")

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x02)

{

"address",

0x57

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

The next edit is for audio. Gigabyte uses a device name of AZAL, so we need to do a global replace with HDEF. Then we need to add codec information to Device (HDEF). Here I found that a lot of edits were injecting a lot of information that wasn't need. All that is required is to inject layout-id and PinConfigurations. Here is an example of what needs to be added for a board using and an ALC889 codec and using our Legacy889HDA.kext:

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x04)

{

"layout-id",

Buffer (0x04)

{

0x79, 0x03, 0x00, 0x00 // decimal 889

"PinConfigurations",

Buffer (Zero)

{

}

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

There is a problem with Audio break ups in 10.6.3 that can be corrected in the DSDT. The first is in Device (PIC) remove these two lines:

IRQNoFlags ()

{2}

The other fix for audio break ups is in Device (TMR) where Gigabyte has not yet added Hackintosh logic. We need to change:

Method (_CRS, 0, NotSerialized)

{

If (LGreaterEqual (OSFX, 0x03))

{

If (HPTF)

{

Return (ATT6)

}

Else

{

Return (ATT5)

}

Else

{

Return (ATT5)

}

To:

Method (_CRS, 0, NotSerialized)

{

Return (ATT6)

}

Gigabyte has not yet added Hackintosh logic to Device (HPET), so you will get kernel panics in AppleIntelCPUPowerManagement. The fix is easy; just change Method (_STA, 0, NotSerialized) to Return (0x0F) and to change Method (_CRS, 0, NotSerialized) to Return (ATT3).

tonymacx86.com forum user Lnx2Mac brought this next edit to my attention. This edit allows use of the power button to put the computer to sleep. In Device (PWRB) change Name (_HID, EisaId ("PNP0C0C")) to Name (_CID, EisaId ("PNP0C0C")).

It seems that if the USB devices have no device-id or it's incorrect you won't have any USB 1.1 devices. So you have to add the following code to each USBx/UHCx device to enable it in Snow Leopard.

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x02)

{

"device-id",

Buffer (0x04)

{

0x34, 0x3A, 0x00, 0x00

}

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

I have found that the same device-id can be used for each USBx/UHCx device. They don't have to be unique, just valid.

Likewise for the USBE/EHC1 and USE2/EHC2 devices we need to add the following code:

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x08)

{

"AAPL,current-available",

0x05DC,

"AAPL,current-extra",

0x044C,

"AAPL,current-in-sleep",

0x09C4,

"device-id",

Buffer (0x04)

{

0x3A, 0x3A, 0x00, 0x00

}

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

The "AAPL, ..." insertion is for compatibility and for native USB power savings. Again, it is safe to use duplicate device-ids.

If you have a Gigabyte P55/H55 motherboard whose current DSDT is not in the tonymacx86.com DSDT Database, you can submit it on the tonymacx86.com forum by clicking here. The instructions are at the top of the topic. After we receive it and verify that it is vanilla, we will do the edits and upload it to the database.

For discussions on this and other topics, register today at tonymacx86.com!

JMicron SATA Support

2010-06-06T20:49:00.003-04:00

Are you tired of seeing this in System Profiler?

I was, so that’s why I created JMicron36xeSATA.kext and JMicron36xSATA.kext.

Now in System Profiler you will see this if you use JMicron36xeSATA.kext:

Or this if you use JMicron36xSATA.kext:

So what’s the difference other than the name display? When using JMicron36xSATA.kext all drives connected to the JMicron controllers will be displayed on the desktop as internal disks, just like the Intel connected drives. But if you use the JMicron36xeSATA.kext, then they show up on the desktop as external (orange) disks and can be hot swapped.

They are available in iBoot 2.0 and in MultiBeast and are installed in /Extra/Extensions.

For discussions on this and other topics, register today at tonymacx86.com!

JMicron ATA Support

2010-06-06T20:44:00.004-04:00

Are you trying to build a Hackintosh on the cheap? Do you have an old IDE CD/DVD drive or hard drive from your Pentium II rig collecting dust in the closet? Does your motherboard use the JMicron or GSATA IDE controller? Have I got the answer for you.

JMicron36xATA.kext is a 32/64-bit driver for the JMicron 361, 363, 365, 366, 368 and Gigabyte GSATA IDE controllers for supporting that old drive in your shiny new Hackintosh.

It is available in iBoot 2.0 so you can install from an IDE DVD Drive or to an IDE Hard Drive and in MultiBeast for installation to running systems.

For discussions on this and other topics, register today at tonymacx86.com!

Welcome to MacManx86: Advanced Hackintosh Tips, Tricks & Techniques

2010-06-06T16:54:00.013-04:00

Let me introduced myself, I am known as MacMan on the tonymacx86 forum and blog. I had to use an different name for my blog, so I decided to go with MacManx86 here as an homage to
tonymacx86. It also makes sense as this is a sister site to tonymacx86.blogspot.com.

On this blog I will be posting more advanced topics than what has typically been posted on tonymacx86.blogspot.com. So if things like DSDT, kexts, and Terminal don't scare you. Or, you want to learn more, stay tuned.