Liberating you from all restraints, limitations, or regulations otherwise applying to your workstation to run Mac OS X!

DSDT_Featured

Articles > A light & practical introduction to DSDT patching

 


We’ve all heard about it but, for most of us (including myself), DSDT patching remains something rather obscure that is reserved to specialists. True I suppose, but there are some basic modifications that most people can do.

Remember that the DSDT table is part of the computer’s BIOS and all DSDTs used for Mac OS X originate from there. Keep that in mind to understand some of the things you may observe once your computer runs Mac OS X.

This article concentrates on the Dell Latitude D430 notebook to highlight some easy changes that can be made in terms of DSDT patching. It could be the beginning of a series of articles on DSDT patching, we’ll see…

By far and large, D430 notebooks carried the “Centrino” label. This means that they feature an all-Intel combination of processor, chipset & wireless package: U7x00 CPU, 945GMS chipset with GMA950 graphics controller and, most usually, WM3945abg wireless card. We all know that Mac OS X does not support Intel wireles cards, so all D430 Hackintosh normally use a different model (Atheros, Broadcom or otherwise) to enjoy wireless networking.

Having built their D430 Hackintosh with our OSXL bootpack, users may therefore be a little confused when looking up the PCI cards section of their System Report; no matter what wifi card is in place, System Report always shows an Intel 3945 module:
D430 GMA950 with ML 10.8.3

The reason is simple: that information is actually stored in the DSDT table, Centrino labelling oblige. Can it be changed? Of course! With a little DSDT patch… We will take the opportunity of that patch to update the information reported for the Ethernet controller and the video controller too.

In order to patch the DSDT table, we’re going to keep things simple and use 2 little tools/apps readily available:
. Chameleon Wizard v4.2.2 (the latest at time of writing)
. TextEdit (standard Mac OS X app)
D430 GMA950 with ML 10.8.3

To begin with, let’s copy the DSDT table (file DSDT.aml) from /Extra to the desktop. Assuming there is no specific DSDT tool such as DSDT Editor (or other) installed, a simple double-click on the DSDT file will open up Chameleon Wizard and decompile the table. Alternatively: Chameleon Wizard -> DSDT tab -> Compile/Extract secondary tab -> selection of DSDT.aml on the desktop -> Decompile button.

This results in the creation of a DSDT.dsl file on the desktop; this is the source code of the DSDT table. Let’s right click on that .dsl file and open it up with TextEdit. Patching can now begin…
D430 GMA950 with ML 10.8.3 D430 GMA950 with ML 10.8.3

D430 GMA950 with ML 10.8.3 D430 GMA950 with ML 10.8.3 D430 GMA950 with ML 10.8.3

So let’s look at the code… We can press Command-F (or do Edit->Find) to search for character string “3945″ as displayed in system Report. This leads to a small section dedicated to the wireless card. The entry specific to the Intel WM3945abg wireless card can be modified to reflect the true hardware in place. Two parameters are involved:
. the text description
. the string length parameter (Buffer) to reflect new text length (set to number of characters+1, in hexadecimal)

For instance, the code can be changed from:

                                "model",
                                Buffer (0x14)
                                {
                                    "Intel Wireless 3945"
                                },

to:

                                "model",
                                Buffer (0x15)
                                {
                                    "Dell Wireless DW1490"
                                },

That’s it for the wireless reference, nothing else to do. Now let’s look at the graphics controller. It’s basically the same principle. We search for “GMA 950″ as displayed in System Report, then we can change from:

                            "model",
                            Buffer (0x08)
                            {
                                "GMA 950"
                            },

to:

                            "model",
                            Buffer (0x0D)
                            {
                                "Intel GMA950"
                            }, 

Pretty simple, isn’t it? Now, for the Ethernet controller, things get a littler trickier… Searching for “Ethernet” or “Controller” leads to… nothing! What do we do then? Well, looking back at the graphics controller or wireless card, we can see that their individual section of code starts with a:

            Device (xxxx)

For the graphics controller it’s Device (VID), whilst for the wireless card it’s Device (ARPT). A quick browse through all devices in the code reveals a likely entry for the Ethernet board:

                Device (NIC)
                {
                    Name (_ADR, Zero)
                    Name (_SUN, 0x0C)
                    Name (_PRW, Package (0x02)
                    {
                        0x09,
                        0x03
                    })
                    Method (SCMD, 2, NotSerialized)
                    {
                        SX10 ()
                        SX30 (0x10)
                        SX30 (Arg0)
                        SX30 (Arg1)
                        SX11 ()
                        Store (SX42 (), Local0)
                        SX12 ()
                        Return (Local0)
                    }
                    Method (LLTB, 0, NotSerialized)
                    {
                        Store (SCMD (One, Zero), Local0)
                        Store (Local0, Index (SLLP, Zero))
                        Store (SCMD (0x02, Zero), Local0)
                        Store (Local0, Index (SLLP, One))
                        OperationRegion (LOPR, SystemMemory, DerefOf (Index (SLLP, Zero)), DerefOf (Index (SLLP, One)))
                        If (LEqual (LHDL, Zero))
                        {
                            Load (LOPR, LHDL)
                        }
                    }
                    Method (_INI, 0, NotSerialized)
                    {
                        If (LGreaterEqual (OSID (), 0x10))
                        {
                            LLTB ()
                        }
                    }
                }

There’s a good chance that NIC stands for Network Interface Card, however, no text description of any sort to confirm this… Well, let’s have a look at what is coded for the other devices we looked at previously and see what we can do.

For the wireless card, we have:

                Device (ARPT)
                {
                    Name (_ADR, Zero)
                    Name (_SUN, 0x02)
                    Name (_PRW, Package (0x02)
                    {
                        0x09,
                        0x03
                    })
                    Method (_DSM, 4, NotSerialized)
                    {
                        Store (Package (0x06)
                            {
                                "model",
                                Buffer (0x14)
                                {
                                    "Intel Wireless 3945"
                                },
                                "device_type",
                                Buffer (0x08)
                                {
                                    "Airport"
                                },
                                "built-in",
                                Buffer (One)
                                {
                                     0x00
                                }
                            }, Local0)
                        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                    }
                }

and for the graphics controller, we have:

            Device (VID)
            {
                Name (_ADR, 0x00020000)
                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x48)
                        {
                            "device_type",
                            Buffer (0x08)
                            {
                                "display"
                            },
                            "model",
                            Buffer (0x08)
                            {
                                "GMA 950"
                            },
                            "AAPL,slot-name",
                            Buffer (0x09)
                            {
                                "Built in"
                            },
                            ...
                            ...
                            ...
                            ...
                            ...
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }

What do we see? Well, a trend emerges where all device descriptions appear configured under sections starting with:

                Method (_DSM, 4, NotSerialized)

and where the code describing the hardware follows the pattern below:

                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x###)
                        {
                            ...
                            ...
                            ...
                            "model",
                            Buffer (<description length + 1, in hex>)
                            {
                                "<description text>"
                            },
                            ...
                            ...
                            ...
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }

So, let’s try to apply this to the NIC device. But what do we actually specify? Well, a quick look at the PCI database web site reveals that the LAN board of the Latitude D430 (Ven id 0x14e4, Dev id 0×1600) is actually a Broadcom NetXtreme BCM5752 Gigabit controller. Ok, let’s try and specify that in the DSDT table by adding the following _DSM method to the section for NIC device, inserting the code right before the SCMD Method:

                    Method (_DSM, 4, NotSerialized)
                    {
                        Store (Package (0x02)
                            {
                                "model",
                                Buffer (0x23)
                                {
                                    "NetXtreme BCM5752 Gigabit Ethernet"
                                }
                            }, Local0)
                        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                    }

This code is derived from code observed in video controller and graphics controller sections, with DTGP/Return lines simply copied over from other devices code. The number 0×02 specified for Store (Package (###) line was obtained from the observation that every item of a _DSM Method appeared to count as 2. For instance, the ARPT wireless device contains 3 items in its _DSM Method code with a Store (Package (0×06) code line whilst the VID video device contains 36 items it its own _DSM Method with a Store (Package (0×48) (=72) code line.

The file can now be saved and used to recompile a new DSDT table. Again, assuming there is no other specific DSDT tool, Chameleon Wizard can be used to that effect. A double-click on the modified DSDT.dsl file will do that, otherwise the DSDT.dsl file can be manually opened in Chameleon Wizard and the table compiled by clicking on the Compile button. The resulting DSDT.aml file can then be copied to /Extra folder (keeping a backup of the previous table first, renaming it to DSDT_old.aml for instance).
D430 GMA950 with ML 10.8.3 D430 GMA950 with ML 10.8.3

After reboot, System Report reveals that the PCI Cards section has taken the above DSDT patching into account and that the true hardware is now reflected:
D430 GMA950 with ML 10.8.3

So there you are, some basic/simple DSDT patches to reflect true hardware of a system in Mac OS X and an ultralight introduction to DSDT _DSM Methods. This is how we patch D630/D830 DSDT tables so that the reported nVidia video board is changed from GeForce 8400M GS to Quadro NVS 135M or 140M.