Guide for Hacking AMI BIOS DSDTs for OSx86 using DSDTSE

[toleda]

I have successfully modified my ASRock Vision 3D (HM55/GT425M/i3-370M) DSDT with all the credit to you. Regarding SATA, I did a copy/paste of your solution and it works great. Audio (on board and HDMI), graphics, network, USB3.0; all working. Haven't looked at the card reader and IR yet. As well, still need to check the USB problem with 10.6.5 and Safari (5.0.3).

Two issues remain: HDMI boot and wake from sleep. My work around on the the HDMI boot problem is to use the DVI port with a DVI to HDMI adapter. Surprisingly, I'm getting HDMI audio out of the DVI port.

The HM55 both shuts down and goes to sleep properly (with power button and Finder). Unfortunately, when the system wakes up, it reboots. Do you have any ideas that might solve the wake problem?

Thanks again for your support.

 

[peterhaas]

The HM55 both shuts down and goes to sleep properly (with power button and Finder). Unfortunately, when the system wakes up, it reboots. Do you have any ideas that might solve the wake problem?

Alas, no.

I don't use sleep, and I have not tested it.

That is to say: I set the processor to sleep: never and the display to sleep: 10 minutes, in System Preferences... --> Energy Saver.

Return from display sleep works perfectly.

Processor sleep is not used and has not been tested.

 

[peterhaas]

Adding HDEF and SBUS devices to AMI BIOS DSDTs ...

1) Locate method _L0D in DSDT,

2) add notify HDEF at the end; the result will look something like this:

Method (_L0D, 0, NotSerialized)
{
If (LEqual (\_SB.PCI0.UHC1.UIFT, Zero))
{
Notify (\_SB.PCI0.EHC1, 0x02)
Notify (\_SB.PCI0.EHC2, 0x02)
}
Else
{
Notify (\_SB.PCI0.UHC1, 0x02)
Notify (\_SB.PCI0.UHC5, 0x02)
}

Notify (\_SB.PWRB, 0x02)
Notify (\_SB.PCI0.HDEF, 0x02)
}

3) locate device BR20,

4) add device HDEF immediately before it (the device SBUS should go there, too, after device HDEF):

Device (HDEF)
{
Name (_ADR, 0x001B0000)
Method (_PRW, 0, NotSerialized)
{
Return (Package (0x02)
{
0x0D,
0x05
})
}

Method (_DSM, 4, NotSerialized)
{
Store (Package (0x04)
{
"layout-id",
Buffer (0x04)
{
0x75, 0x03, 0x00, 0x00 /* ALC890/ALC889a/ALC885 */
},

"PinConfigurations",
Buffer (Zero) {}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}

5) layout ID is 0x78, 0x03, 0x00, 0x00 for ALC888; 0x79, 0x03, 0x00, 0x00 for ALC889; 0x77, 0x03, 0x00, 0x00 for ALC888b,

6) add device SBUS after device HDEF:

Device (SBUS)
{
Name (_ADR, 0x001F0003)
OperationRegion (PBAS, PCI_Config, 0x20, 0x02)
Field (PBAS, ByteAcc, NoLock, Preserve)
{
BAS0, 16
}

Method (SMBB, 0, NotSerialized)
{
And (BAS0, 0xFFFE, Local0)
Return (Local0)
}

Device (BUS0)
{
Name (_CID, "smbus")
Name (_ADR, Zero)
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)
}
}
}

 

[peterhaas]

In the meantime, please confirm your Device (SATA) described in your most recent post replaces the original Device (SATA) and Device (SAT1).

The true SATA device is usually named SATA. Occasionally, it will be named something else, possibly SAT0. However, the supplied SATA device is usually intended for IDE compatibility, so it usually only has CHN0, DEV0 and DEV1 and CHN1, DEV0 and DEV1. Which is why I replace the entire device with a true SATA device tree, having four drives for pre-ICH10 (six drives for pre-ICH10-R), or six drives for ICH10/ICH10-R.

The true IDE device is usually named SAT1. This device really is an IDE device, also having CHN0, DEV0 and DEV1 and CHN1, DEV0 and DEV1. I usually place comments, /* ... */ , around the entire device, thereby maintaining it in the dsl, but deleting it in the aml.

So, technically, I an not replacing SATA AND SAT1 with the true SATA device tree, rather I am replacing the IDE compatibility SATA device tree with a true SATA device tree and I am commenting-out the true IDE device tree.

 

[toleda]

Processor sleep is not used and has not been tested.

I am interested in getting processor sleep to work. Currently, the system goes to sleep properly (the power button flashes). However, pushing the power button to wake from sleep results in a reboot. I recognize you don't use this feature, however, I'm interested in any ideas you may have to fix this problem. Thanks for your support.

 

[peterhaas]

Processor sleep is not used and has not been tested.

I am interested in getting processor sleep to work. Currently, the system goes to sleep properly (the power button flashes). However, pushing the power button to wake from sleep results in a reboot. I recognize you don't use this feature, however, I'm interested in any ideas you may have to fix this problem. Thanks for your support.

I have read that there is a requirement for certain BIOS options, which appear to be missing from some of ASRock's BIOSes.

My several ASRocks behave differently.

My sole ASRock P55 Pro will power-off with the default options (AHCI, etcetera).

However, my ASRock P55DE3 (DeLuxe 3?) will NOT POWER-OFF with the same options; I have to wait until the monitor screen goes to black, and THEN I have to manually power-off the machine.

I guess this is where Hacking is bound to produce some anomalies.

However ...

I paid $71.99 retail full-price (with "free" three-day shipping) for each of my two ASRock P55DE3 mobos, and I paid $70.99 retail "open box" price (with $7.99 three-day shipping) for my sole ASRock P55 Pro, and those prices are VERY CHEAP for very good P55 mobos.

Heck, those mobos each cost less than the 2 x 2 GB = 4 GB Corsair XMS3 RAM which are in these.

CHEAP (low-priced) doesn't have to mean SECOND RATE (poor-quality).

However, I DID take a substantial intellectual risk on these, but my ASRock DSDTs proved to be as solid as my Gigabyte DSDTs, insofar as MacOS X compatibility is concerned, so I am quite a few dollars ahead on this issue alone, plus I got to (read: HAD TO) develop my own ASRock OSx86 hacking Guide for these.

It was fun for me.

Well, not all fun as there were quite a few head-scratchers.

Concurrently with the very successful conclusion of my ASRock P55 Pro project, my sole remaining Macintosh, a Quicksilver 2002 dual 1.0 GHz PPC, failed, so I was, thereby, FORCED to go to an all-Hackintosh system. And, as it would turn out to be, an all-ASRock system.

Rather amazing, as, before, my shop was a mostly all-Gigabyte PLUS a one Macintosh shop, and before that my shop was a mostly all-Shuttle P35 PLUS a one Macintosh shop.

Hmmm ... now it appears to be an all-ASRock P55 (P55DE3, two systems, and P55 Pro, one system) shop.

My, how the MIGHTY have FALLEN!

All hail the MIGHTY MACK (and the MIGHTY HACK).

 

[peterhaas]

The HM55 both shuts down and goes to sleep properly (with power button and Finder). Unfortunately, when the system wakes up, it reboots. Do you have any ideas that might solve the wake problem?

Alas, no.

I don't use sleep, and I have not tested it.

That is to say: I set the processor to sleep: never and the display to sleep: 10 minutes, in System Preferences... --> Energy Saver.

Return from display sleep works perfectly.

Processor sleep is not used and has not been tested.

I have tested the following on my ASRock P55 Pro, but not my ASRock P55DE3 or other AMI BIOSed machines.

Depressing the POWER button the first time does indeed put the machine to sleep, as one expects and requires.

Depressing the POWER button a second time will not necessarily cause the machine to come back from sleep. In fact, the LCD display may say something like "No Input".

However, depressing the POWER button a second time AND immediately thereafter depressing the USB keyboard SHIFT key and/or moving the USB MOUSE will cause the "No Input" message to be dismissed and the machine to return to its active state, where it was before the POWER button was depressed the first time.

Warning: depressing the POWER button a third time, without the machine first having been returned to its active state, may result in the USB system being permanently deactivated until the RESET button is depressed.

This somewhat unusual USB behavior, and its interaction with the POWER and RESET buttons, may be unique to AMI BIOSed machines.

Also, these effects may be exacerbated by operating the machine through a USB KVM switch, or through a particular manufacturer's USB KVM switch.

In this respect, an AWARD BIOSed machine may be a little more tolerant of that which goes on with its USB system than an AMI BIOSed machine.

Once these idiosyncrasies are understood, the problem may become more manageable.

At least there is an apparently reliable work-around.

 

[peterhaas]

At least for the ASRock P55 Pro (which has a JMB383 controller) the hard drive options are ...

SATAII-1
SATAII-2
SATAII-3
SATAII-4
eSATAII-5
eSATAII-6

... all of which are controlled by the ICH10-R chip and ...

7th IDE Master
7th IDE Slave
8th IDE Master
8th IDE Slave

... all of which are controlled by the JMB363 chip (and for which the JMB363ATA kext is appropriate).

However, for the ASRock P55DE3 (which does not have a JMB363 chip) the hard drive options are ...

SATAII-1
SATAII-2
SATAII-3
SATAII-4
eSATAII-5
eSATAII-6

... all of which are controlled by the ICH10-R chip.

Those are the names they are given on the BIOS setup screen.

The first group (the only group for P55DE3) is controlled by the DSDT's SATA device.

The second group is controlled by the DSDT's SAT1 device (and the P55DE3's DSDT does indeed have this device, although there is no corresponding JMB363 chip, and which is but one reason why I usually delete the SAT1 device).

 

[toleda]

peterhaas
Post subject: Re: Guide for Hacking AMI BIOS DSDTs for OSx86 using DSDTSE
peterhaas wrote:

.........


Also, these effects may be exacerbated by operating the machine through a USB KVM switch, or through a particular manufacturer's USB KVM switch.

In this respect, an AWARD BIOSed machine may be a little more tolerant of that which goes on with its USB system than an AMI BIOSed machine.

Once these idiosyncrasies are understood, the problem may become more manageable.

At least there is an apparently reliable work-around.

Thanks for your response.

I'm playing with the ASRock Vision 3D system. Holding the power button has no effect. As soon you move the mouse or touch the keyboard, it reboots. Currently, I have not found a way to get my system to wake up. I'll keep looking for a solution.

 

[Shuriken]

Started working on a DSDT for a Asrock H67M-GE (1.40). Your topic was very helpful.

Had to add the smbus, hdef and the dgst method. The renaming of the _T_0 and _T_1 still necessary.
Changed MUTE, 0xFFF to MUTE, 0xFFFF. Renamed EUSB and USBE, the ports are called PRT10 and so on.Changed SRBG to LPCB.

As the board has a ALC892 i used HDEF:

    Device (HDEF)
            {
                Name (_ADR, 0x001B0000)
                Method (_PRW, 0, NotSerialized)
                {
                    Return (Package (0x02)
                    {
                        0x0D,
                        0x05
                    })
                }

                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x0A)
                        {
                            "built-in",
                            Buffer (One)
                            {
                                0x00
                            },

                            "codec-id",
                            Buffer (0x04)
                            {
                                0x88, 0x08, 0xEC, 0x10
                            },

                            "layout-id",
                            Buffer (0x04)
                            {
                                0x0C, 0x00, 0x00, 0x00
                            },

                            "device-type",
                            Buffer (0x10)
                            {
                                "Realtek ALC888b"
                            },

                            "PinConfigurations",
                            Buffer (0x28)
                            {
                                /* 0000 */    0x10, 0x90, 0xA1, 0x01, 0x20, 0x90, 0xA1, 0x02,
                                /* 0008 */    0x80, 0x30, 0x81, 0x01, 0x90, 0x40, 0x21, 0x02,
                                /* 0010 */    0x30, 0x40, 0x11, 0x01, 0x40, 0x40, 0x01, 0x01,
                                /* 0018 */    0x50, 0x60, 0x01, 0x01, 0x60, 0x20, 0x01, 0x01,
                                /* 0020 */    0x70, 0x61, 0x4B, 0x01, 0xA0, 0x01, 0xCB, 0x01
                            }
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }
            }