[Guide] Using DSDT with the Gigabyte GA-EP45-DS3L

[blackosx]

Doing a quickly search, i found that your GA-EP45-DS3L are modded too using DELL Slic 2.1..

If you want to see more...Give a try..

Thanks for the link. I will have a look in to this maybe when I get some time

 

I got everythiing working :-), I also added the GFX String in the DSDT.aml

Except for the gfx actually... GraphicsEnabler doesn't work with GTS 250 lol...

 

But yea, I'm going to post a thread with your DSDT.aml that's edited to work with EP43-DS3LR if you don't mind?

I'll wait for your permission.

 

I have a question about the EP45-DS3L...

In my board, I had to choose PCI0, PEGX Graphics option in the ACPI Patcher in Windows.

Is it same here? PCI0, PEGX? or is it PCI1, PEGX (or etc etc)

 

Thanks

I see kdawg has answered your questions (Thanks kdawg).

With regard to the permission to use the DSDT if you're asking about kdawgs then he's answered your question, but if you are asking about the amended version of mm67's that I am using here, then go ahead, just make sure you have made the correct revisions to match your original DSDT.

 

And yes, for the EP45-DS3L, I chose PCI0 as I showed in the DSDT PDF guide posted at the start of the thread.

[LOLmoe]

kDawg,

 

I am using Targus ACB10US Bluetooth Adapter.

It's very cheap, $11 Shipped in Amazon.com :-)

 

I will start the thread soon...

 

Here's my DSDT.AML though

http://s000.tinyupload.com/?file_id=71675319764678661976

 

it's same as BlackOSX, but it has the SATA Fix that's not recommended lol, LPCB Fix for ICH10R, and a injection for NVIDIA GTS 250 (EVGA) with Dual DVI NVCAPs. (dual dvi tested).

[LOLmoe]

Blackosx, can you please post your com.apple.boot.plist?

 

I'm confused for GraphicsEnabler.

 

is it

 

<key>GraphicsEnabler</key>

<string>Yes</key>

 

and i think i have to put PCROOT=0 or something... since the gfx is in PCI0/PEG

[Johnny V]

......

and i think i have to put PCROOT=0 or something... since the gfx is in PCI0/PEG

 

 

<key>GraphicsEnabler</key>

<string>Yes</string>

<key>PciRoot</key>

 <string>0</string>

 

If "0" doesn't work try "1"

[LOLmoe]

<key>GraphicsEnabler</key>

<string>Yes</string>

<key>PciRoot</key>

 <string>0</string>

 

If "0" doesn't work try "1"

 

Thanks man.

I still dont know why though for shutdown restart, why people don't use openhaltrestart.kext. does the new methods work in a different way?

 

i don't notice any speed differences (im using the osxrestart.kext not openhaltrestart.kext)

[blackosx]

Thanks man.

I still dont know why though for shutdown restart, why people don't use openhaltrestart.kext. does the new methods work in a different way?

 

i don't notice any speed differences (im using the osxrestart.kext not openhaltrestart.kext)

It's all about being able to run OS X on a regular PC with the least kexts as possible. Now restart & shutdown (thanks to mm67 & Duvel300) have been figured out with DSDT and the modified Chameleon RC4 boot file, we no longer need a kext to achieve those functions.

[thiagomorales]

Hi friends, i only can test new boot and restart solution from FACP(FADT) table at moment..Here dont works..When i do a restart, system do not restart and fans and leds go on running...(screen totally black)..

 

I will try using original boot posted from Duvel300, and the PC_EFI10.5 compiled by cparm, then i will post results.

 

Regards.

 

It's all about being able to run OS X on a regular PC with the least kexts as possible. Now restart & shutdown (thanks to mm67 & Duvel300) have been figured out with DSDT and the modified Chameleon RC4 boot file, we no longer need a kext to achieve those functions.

 

EDIT: Using Duvel300 original boot file, restart works without any kext, but using your 'mix' on Rekursor and Duvel300 patches, restart don´t works here..

 

EDIT2: I have back to F9E BIOS version, and my ethernet back to work on OSX. Funny that on F9F, my ethernet don´t works on OSX but on Win7 it works 100%..(even QuickBoot on or off)

On new BIOS, my Ethernet recognizes MAC address correctly but it not get IP.. Tomorrow i will flash BIOS with F9F again and make some tests.

 

Regards.

 

Merry Christmas for all!

[blackosx]

Hi friends, i only can test new boot and restart solution from FACP(FADT) table at moment..Here dont works..When i do a restart, system do not restart and fans and leds go on running...(screen totally black)..

 

I will try using original boot posted from Duvel300, and the PC_EFI10.5 compiled by cparm, then i will post results.

 

Regards.

 

 

 

EDIT: Using Duvel300 original boot file, restart works without any kext, but using your 'mix' on Rekursor and Duvel300 patches, restart don´t works here..

 

EDIT2: I have back to F9E BIOS version, and my ethernet back to work on OSX. Funny that on F9F, my ethernet don´t works on OSX but on Win7 it works 100%..(even QuickBoot on or off)

On new BIOS, my Ethernet recognizes MAC address correctly but it not get IP.. Tomorrow i will flash BIOS with F9F again and make some tests.

 

Regards.

 

Merry Christmas for all!

Hi thiago.

 

When Duvel300 released his original restartfix, it needed a change for the FADT for it to work with P35 boards. His revised v2.1 file worked around that and all that you need is the kext.

 

The revised boot file I supplied should not affect anything else on your system. But if it does, then revert back to using a different method like you have done.

 

The Quick Boot feature on BIOS F11c for my mobo works great, as does the ethernet. No problems here.

 

Hope you get your's sorted.

 

Merry Christmas to everyone too.

[LOLmoe]

something weird.

 

The ACB10US is officialy supported by Apple for waking Bluetooth devices.

However, unless I have a USB mouse plugged in (Dont know about keyboards), the "Allow Bluetooth devices to wake this computer" is grayed out..

 

Weirdly enough, the bluetooth keyb + mouse still wakes up the keyboard even if its grayed out.

 

So here's the scenarios.

 

1. USB Mouse plugged in.

- "allow bluetooth devices to wake this computer" - avialble to check or not check

- bluetooth keyboard/mouse wakes the computer.

 

2. USB Mouse NOT plugged in.

- "allow bluetooht devices to wake this computer" - grayed out.

- bluetooth keyboard/mouse wakes the computer.

 

I'm going to see if this is a DSDT.aml issue by loading up my old dsdt.aml. ill report back

[thiagomorales]

Hi again Nick, i recently made some tests..

Well, with boot file that you have supplied RestartFix nor SystemID feature works for me...(You have mixed rekursor patch with Duvel300 fix for Restart)

 

So, i´ve decided to use Duvel300 original boot..Result of test: restart works like a charm.

It sounds very strange, so i decided to make another test with original rekursor boot file..Result of text: SystemID option works correctly..

It sounds for me a bit strange...So, i decided to recompile Chameleon source with these patches(rekursor, and Duvel300)..

 

I downloaded Chameleon2RC4 sources, downloaded rekursor and Duvel300 patches, and with help of DiffMerge i revised all needed files for compile..

 

I compiled the Chameleon2RC4 source, and made some tests with new boot that has compiled from me..

Results of tests..: Worked like a charm. either RestartFix and SystemID features worked for me.

 

i´ve made a diff from your boot compiled that you have supplied, with boot file compiled by me. Diff alerts that have some differences on file..

So, i´m attaching my boot compiled based on Chameleon2 RC4 with RestartFix and SystemID patches from Duvel300 and rekursor. Double check your boot file and make some test with mine.

 

Luck.

Regards.

 

Hi thiago.

 

When Duvel300 released his original restartfix, it needed a change for the FADT for it to work with P35 boards. His revised v2.1 file worked around that and all that you need is the kext.

 

The revised boot file I supplied should not affect anything else on your system. But if it does, then revert back to using a different method like you have done.

 

The Quick Boot feature on BIOS F11c for my mobo works great, as does the ethernet. No problems here.

 

Hope you get your's sorted.

 

Merry Christmas to everyone too.

boot_recompiled_by_thiagom.zip

[bean3669]

Thanks so much for guides! Followed as precisely as i could being fairly new at this. But with 3 days at it still am getting kernel panic when booting up. Am using Chameleon 2.0 RC2 r640 and made my dsdt.alm file and all that but i think the problem might be with the Rc3 boot file you mention in the guide. I am trying to boot into safe mode but am not able to, only way I have be able to get back into Snow leopard was to completely reinstall. Any help would be fantastic!! Thanks again

[blackosx]

Hi again Nick, i recently made some tests..

Well, with boot file that you have supplied RestartFix nor SystemID feature works for me...(You have mixed rekursor patch with Duvel300 fix for Restart)

 

So, i´ve decided to use Duvel300 original boot..Result of test: restart works like a charm.

It sounds very strange, so i decided to make another test with original rekursor boot file..Result of text: SystemID option works correctly..

It sounds for me a bit strange...So, i decided to recompile Chameleon source with these patches(rekursor, and Duvel300)..

 

I downloaded Chameleon2RC4 sources, downloaded rekursor and Duvel300 patches, and with help of DiffMerge i revised all needed files for compile..

 

I compiled the Chameleon2RC4 source, and made some tests with new boot that has compiled from me..

Results of tests..: Worked like a charm. either RestartFix and SystemID features worked for me.

 

i´ve made a diff from your boot compiled that you have supplied, with boot file compiled by me. Diff alerts that have some differences on file..

So, i´m attaching my boot compiled based on Chameleon2 RC4 with RestartFix and SystemID patches from Duvel300 and rekursor. Double check your boot file and make some test with mine.

 

Luck.

Regards.

I have tried your recompiled RC4 boot file and it works the same as the one I did. I wonder what you would have done differently to me?

 

As Rekursor and Duvel300 both used Chameleon RC4 as the base for their fixes, all I did was take the Chameleon RC4 source files and replaced 3 files which I included in my download on the Gigabyte DSDT Fix Thread. They were acpi.h, dsdt_Patcher.c and fake_efi.c, then used make embedtheme to recompile..

 

The ACB10US is officialy supported by Apple for waking Bluetooth devices.

However, unless I have a USB mouse plugged in (Dont know about keyboards), the "Allow Bluetooth devices to wake this computer" is grayed out..

 

Weirdly enough, the bluetooth keyb + mouse still wakes up the keyboard even if its grayed out.

........

I'm going to see if this is a DSDT.aml issue by loading up my old dsdt.aml. ill report back

I am not using either a bluetooth keyboard or mouse so I can't do any testing for you. But your idea of rebooting with an older DSDT is the best way to identify if it's the DSDT causing your issue.

[thiagomorales]

I have tried your recompiled RC4 boot file and it works the same as the one I did. I wonder what you would have done differently to me?

 

As Rekursor and Duvel300 both used Chameleon RC4 as the base for their fixes, all I did was take the Chameleon RC4 source files and replaced 3 files which I included in my download on the Gigabyte DSDT Fix Thread. They were acpi.h, dsdt_Patcher.c and fake_efi.c, then used make embedtheme to recompile..

 

 

I am not using either a bluetooth keyboard or mouse so I can't do any testing for you. But your idea of rebooting with an older DSDT is the best way to identify if it's the DSDT causing your issue.

 

Yes, but rekursor fix has included an patch for PCI Root option too. For that is need to include a "pci_root.c" where Chameleon2 RC4 don´t have this file. Have you noted that 'Makefile' changed too ?

The difference of Makefile patched by rekursor is that he included an reference for "pci_root.o".

If you tried to compile with new Makefile, it will stop with error asking for "pci_root.c" file..

I guess that you have using original 'Makefile' so it dont ask for 'pci_root.c' when compiling sources..

 

Double check this.

Regards.

[blackosx]

Thanks so much for guides! Followed as precisely as i could being fairly new at this. But with 3 days at it still am getting kernel panic when booting up. Am using Chameleon 2.0 RC2 r640 and made my dsdt.alm file and all that but i think the problem might be with the Rc3 boot file you mention in the guide. I am trying to boot into safe mode but am not able to, only way I have be able to get back into Snow leopard was to completely reinstall. Any help would be fantastic!! Thanks again

Hi bean3669

 

I had a conversation with polluxx2008 the other week and helped him get his system running. See if any of that conversation can help you

 

Hi thiago.

Yes, but rekursor fix has included an patch for PCI Root option too. For that is need to include a "pci_root.c" where Chameleon2 RC4 don´t have this files

I didn't know that.

Now I have just read the CHANGES.txt file in Rekursor's original file, I see it. Thanks for pointing it out.

 

Have you noted that 'Makefile' changed too ?

No, but I have now

 

The difference of Makefile patched by rekursor is that he included an reference for "pci_root.o".

If you tried to compile with new Makefile, it will stop with error asking for "pci_root.c" file..

I guess that you have using original 'Makefile' so it dont ask for 'pci_root.c' when compiling boot..

I see now, and yes I had been using the original Makefile. Well spotted thiago .

 

In that case would it be a good idea for you to post your new boot file to the Gigabyte DSDT Fix thread and I will then put a note on my uploaded boot files to point to yours. What do you think?

 

Regards

[thiagomorales]

Hi bean3669

 

I had a conversation with polluxx2008 the other week and helped him get his system running. See if any of that conversation can help you

 

Hi thiago.

 

I didn't know that.

Now I have just read the CHANGES.txt file in Rekursor's original file, I see it. Thanks for pointing it out.

 

 

No, but I have now

 

 

I see now, and yes I had been using the original Makefile. Well spotted thiago .

 

In that case would it be a good idea for you to post your new boot file to the Gigabyte DSDT Fix thread and I will then put a note on my uploaded boot files to point to yours. What do you think?

 

Regards

Right nick. Good idea.

I have posted them on Gigabyte DSDT Fix thread.

 

Thanks and regards.

Thiago

[blackosx]

Right nick. Good idea.

I have posted them on Gigabyte DSDT Fix thread.

 

Thanks and regards.

Thiago

Good job.

[jamonda]

Hi, Blackosx.

Can bios upgrade be done without changes in DSDT.aml?

[blackosx]

Hi, Blackosx.

Can bios upgrade be done without changes in DSDT.aml?

I flashed my BIOS with the latest version (F11c) then went in to Linux, did a new acpidump and DIFF'd the DSDT against the one from my previous acpidump with BIOS version (F11b). There were only a couple of differences and that code had already been stripped out of our DSDT (which was revised from mm67's).

 

For reference, the difference between the DSDT for F11c and F11b BIOS is the following code had been removed in F11c.

    OperationRegion (\GBLE, SystemIO, 0x0421, 0x01)
   Field (\GBLE, ByteAcc, NoLock, Preserve)
   {
       ESMI,   8
   }

and the part in red below.

Method (\_PTS, 1, NotSerialized)
   {
       Or (Arg0, 0xF0, Local0)
       Store (Local0, DBG1)
       OSTP ()
       If (LEqual (Arg0, 0x01)) {}
       If (LEqual (Arg0, 0x03)) {}
       If (LEqual (Arg0, 0x05))
       {
[color="#FF0000"]            Store (ESMI, Local0)
           And (Local0, 0xFB, Local0)
           Store (Local0, ESMI)[/color]
           Store (0x99, SMIP)
       }

       If (LEqual (Arg0, 0x04))
       {
           If (LNot (PICF))
           {
               Sleep (0x64)
           }
       }
   }

So to answer your question I can definitely say yes for my board and that will most probably mean yes for yours too (But to be absolutely sure, you will need to check your new against old).

[jamonda]

I flashed my BIOS with the latest version (F11c) then went in to Linux, did a new acpidump and DIFF'd the DSDT against the one from my previous acpidump with BIOS version (F11b). There were only a couple of differences and that code had already been stripped out of our DSDT (which was revised from mm67's).

 

For reference, the difference between the DSDT for F11c and F11b BIOS is the following code had been removed in F11c.

    OperationRegion (\GBLE, SystemIO, 0x0421, 0x01)
   Field (\GBLE, ByteAcc, NoLock, Preserve)
   {
       ESMI,   8
   }

and the part in red below.

Method (\_PTS, 1, NotSerialized)
   {
       Or (Arg0, 0xF0, Local0)
       Store (Local0, DBG1)
       OSTP ()
       If (LEqual (Arg0, 0x01)) {}
       If (LEqual (Arg0, 0x03)) {}
       If (LEqual (Arg0, 0x05))
       {
[color="#ff0000"]            Store (ESMI, Local0)
           And (Local0, 0xFB, Local0)
           Store (Local0, ESMI)[/color]
           Store (0x99, SMIP)
       }

       If (LEqual (Arg0, 0x04))
       {
           If (LNot (PICF))
           {
               Sleep (0x64)
           }
       }
   }

So to answer your question I can definitely say yes for my board and that will most probably mean yes for yours too (But to be absolutely sure, you will need to check your new against old).

 

Yes, you're right. I compared the linux ACPI dumps for GA-EP45-UD3L with bios F7 and F8 (the last version, with the quick boot option) and found the exact same differences. The diff file is attached.

This proofs the compatibility of your DSDT with the UD3L new bios.

diff_F7_F8.txt

[blackosx]

Yes, you're right. I compared the linux ACPI dumps for GA-EP45-UD3L with bios F7 and F8 (the last version, with the quick boot option) and found the exact same differences. The diff file is attached.

This proofs the compatibility of your DSDT with the UD3L new bios.

Hi jamonda

 

Yep, exactly the same. We both guessed it would be, but it's always good to have actual confirmation. Well done

[jamonda]

Hi, Blackosx.

I'm trying to obtain ACPI tables again, under Ubuntu Linux. I followed the instructions I found in the link of post #404 (http://www.projectosx.com/forum/index.php?showtopic=359) but when I try to run that long command I always get the message 'No match at -e line 1, <> line 883". Do you know what I'm doing wrong?

Thanks.

[thiagomorales]

Hi, Blackosx.

I'm trying to obtain ACPI tables again, under Ubuntu Linux. I followed the instructions I found in the link of post #404 (http://www.projectosx.com/forum/index.php?showtopic=359) but when I try to run that long command I always get the message 'No match at -e line 1, <> line 883". Do you know what I'm doing wrong?

Thanks.

 

Well, you can try using this command, or try to use simple script by zhell on same link..

mkdir ACPI && dmesg | perl  -we '$n=0; while (<>) { if (($t,$a,$l,$o) = (/^[^a-zA-Z]*ACPI: ([-._A-Z0-9]{4,4}) +([0-9A-F]{8,8}), ([0-9A-F]{4,4})+(?:\s*\(([^)]+))?/)) { $o && $o=~s/[^-._a-zA-Z0-9]+/-/g; ($cmd="acpidump -a $a -l $l > \"ACPI/${t}".($o?"_$o":"").".aml\""); print  "Running command: \"$cmd\"\n"; system($cmd); ++$n; } } die("No match") unless $n;' && zip -r ACPI-Tables.zip ACPI

But one more thing...Did you installed acpidump / iasl compiler packages first?

Please make sure that either programs have been installed correctly..

 

On ubuntu you can get these on http://packages.ubuntu.com or try enable all repositories then run "apt-get install acpidump iasl"..

Good luck.

Regards,

Thiago

[waldo_pepperjack]

blackosx, a request/suggestion ... could you mention/add in your next revision of the guide/lead-post that a virtualized Windows setup is good enough for this? I was under the impression that Windows also needed to read the BIOS from CMOS (directly from the board), not just from a stock BIOS file. Doing this with VirtualBox+XP is fine, for instance.

 

I followed your pdf guide, and then MasterChief's/UnsubcribeMe's directions for the USB tweaks to enable Sleep properly.

 

The result is a perfectly working vanilla install (after some tweaks to /Extra : dstd.aml, smbios.plist, com.apple.Boot.plist, /E/E/ contains 7 kexts [no RealTekR1000.kext needed] ).

 

I was hesitant to move from 10.5.8 to SnowLeopard, and at first I was disappointed/uncomfortable w/ the amount of fidgeting that I thought I'd have to do, but now I'm seeing the wisdom of the dsdt efforts. I have better (slightly) function in 10.6.2 than I had in 10.5.8.

 

...so, thanks!

[blackosx]

blackosx, a request/suggestion ... could you mention/add in your next revision of the guide/lead-post that a virtualized Windows setup is good enough for this? I was under the impression that Windows also needed to read the BIOS from CMOS (directly from the board), not just from a stock BIOS file. Doing this with VirtualBox+XP is fine, for instance.

I have mentioned it here on the front page.....

What is needed to complete this guide?

 

• A currently running OS X retail install.

• IORegistryExplorer to find where your hardware is and to get the necessary info.

• You'll need a copy of the BIOS file which you are currently using. See Gigabyte.

• Access to any Windows install, it doesn't have to be on the hardware your hack is running on. A VM will work.

• Koalala's ACPIpatcher. I used Patcher02Beta5.

……..

I followed your pdf guide, and then MasterChief's/UnsubcribeMe's directions for the USB tweaks to enable Sleep properly.

You should be able to use the same DSDT as I use which a tweaked version of mm67's (who uses a GA-EP45-UD3). Jamonda here uses the same board as you and has confirmed the original Gigabyte DSDT for the UD3L is identical to the one for my DS3L.

[Ashe]

EDIT2: I have back to F9E BIOS version, and my ethernet back to work on OSX. Funny that on F9F, my ethernet don´t works on OSX but on Win7 it works 100%..(even QuickBoot on or off)

On new BIOS, my Ethernet recognizes MAC address correctly but it not get IP.. Tomorrow i will flash BIOS with F9F again and make some tests.

Just wondering, did you test F9F again? I'm on F9e without Quick Boot, wondering if it's worth another BIOS update or not - thanks