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

[blackosx]

I updated the 'DSM Package Store' in attachment. Thanks.

I´m trying to fix UUID errors through DSDT..I believe that UUID errors is caused because system can not find the built-in ethernet..The Device LAN0 works with old DSDT in same place, and i did get any UUID errors.

 

When i´m at home i´ll try to look on my old DSDT..

Regards.

Okay. See what happens when you get home on your system.

[jamonda]

Okay.

 

So you are running the EP45-UD3L? I thought you were running this motherboard? It would help if you add a signature so we can all see what hardware you're running.

 

Have you started using the DSDT I posted? as mm67's original DSDT is for the EP45-UD3 and I amended it for the EP45-DS3L by removing some PCI Routing Table data. If you are using the one I posted then you are missing that code for your board. You must have been reading the last couple of pages as you were posting in them? Go back to this post and read onwards to see what we did. Especially this bit...

Your system might run as it is, but it makes sense to have the DSDT contain the original code for your motherboard.

 

I know you are right. I thougt I had said before that my board is EP45-UD3L.

 

I will try to make my DSDT, but so far I don't have the knowledge to do that. I wonder if you could point me the way, show me the apps to create a diff file like the one you showed us a few posts ago and tell me how to discover what to put and what not to put in my DSDT.

 

Thanks.

[blackosx]

I know you are right. I thougt I had said before that my board is EP45-UD3L.

 

I will try to make my DSDT, but so far I don't have the knowledge to do that. I wonder if you could point me the way, show me the apps to create a diff file like the one you showed us a few posts ago and tell me how to discover what to put and what not to put in my DSDT.

 

Thanks.

You did say you had a EP45-UD3L before, but you have to remember that I can't remember everybody's setups. That's why having a signature is very helpful. If you don't know how to do it, here's how. Click on the Cog icon at the top right corner of the blue bar above your login name, then down the left side of the next page, click on 'Edit Signature'.

 

Don't worry about not knowing that much about DSDT yet as it complicated and I am still trying to learn it myself

 

For adding relevant code back in for your board, you need to do the following. Note: this is providing that the information for your motherboard will be identical to mm67's? (to be sure you will want to get yourself an acpidump from linux and then compare the original DSDT with mm67's).

 

Load up the DSDT.dsl you got from this thread (with your replaced CPU information in) search for 0x001E0000 and it will take you to inside the Device (PCIB), then replace this part from...

            Name (_ADR, 0x001E0000)
               Name (_STA, 0x0F)
               Method (_PRT, 0, NotSerialized)
               {
                   Return (Package (0x08) // Blackosx - Removed superfluous code relevant to mm67's GA-EP45-UD3
                   {
                       Package (0x04){0xFFFF,Zero,Zero,0x14}, 
                       Package (0x04){0xFFFF,One,Zero,0x13}, 
                       Package (0x04){0xFFFF,0x02,Zero,0x12},
                       Package (0x04){0xFFFF,0x03,Zero,0x10},
                       Package (0x04){0x1FFFF,Zero,Zero,0x13},
                       Package (0x04){0x1FFFF,One,Zero,0x12},
                       Package (0x04){0x1FFFF,0x02,Zero,0x10},
                       Package (0x04){0x1FFFF,0x03,Zero,0x14},
                   })

 

to read (as mm67's original DSDT)

            Name (_ADR, 0x001E0000)
               Name (_STA, 0x0F)
               Method (_PRT, 0, NotSerialized)
               {
                   Return (Package (0x10)
                   {
                       Package (0x04){0xFFFF,Zero,Zero,0x14}, 
                       Package (0x04){0xFFFF,One,Zero,0x13}, 
                       Package (0x04){0xFFFF,0x02,Zero,0x12},
                       Package (0x04){0xFFFF,0x03,Zero,0x10},
                       Package (0x04){0x1FFFF,Zero,Zero,0x13},
                       Package (0x04){0x1FFFF,One,Zero,0x12},
                       Package (0x04){0x1FFFF,0x02,Zero,0x10},
                       Package (0x04){0x1FFFF,0x03,Zero,0x14},
                       Package (0x04){0x2FFFF,Zero,Zero,0x12},
                       Package (0x04){0x2FFFF,One,Zero,0x10},
                       Package (0x04){0x2FFFF,0x02,Zero,0x14},
                       Package (0x04){0x2FFFF,0x03,Zero,0x13},
                       Package (0x04){0x7FFFF,Zero,Zero,0x17},
                       Package (0x04){0x7FFFF,One,Zero,0x17},
                       Package (0x04){0x7FFFF,0x02,Zero,0x17},
                       Package (0x04){0x7FFFF,0x03,Zero,0x17}
                   })

 

Save it and recompile it.

That should do it for your EP45-UD3L, and hopefully mm67 can confirm this. But note my main interest is in the EP45-DS3L and any DSDT stuff I post here is normally targeted for that.

[blackosx]

I updated the 'DSM Package Store' in attachment. Thanks.

I´m trying to fix UUID errors through DSDT..I believe that UUID errors is caused because system can not find the built-in ethernet..The Device LAN0 works with old DSDT in same place, and i did get any UUID errors.

 

When i´m at home i´ll try to look on my old DSDT..

Regards.

Here's my latest dsdt.dsl that I am using.

The things I have changed are...

 

• Removed the extra comma at the end of PCI Routing Table in the Return Package in Device (PCIB).

• Managed to get rid of the 'Remark' that appeared when compiling, caused in the _DSM for Device (HDEF).

• Commented out Device (PCI0.EXPL) - running a trial to see if this is necessary

• Commented out Device (PMIO) - running a trial to see if this is necessary

• Commented out Device (LAN0) - this is just for me as my Ethernet works even if this is out.

dsdt.dsl.zip

[thiagomorales]

Here's my latest dsdt.dsl that I am using.

The things I have changed are...

 

• Removed the extra comma at the end of PCI Routing Table in the Return Package in Device (PCIB).

• Managed to get rid of the 'Remark' that appeared when compiling, caused in the _DSM for Device (HDEF).

• Commented out Device (PCI0.EXPL) - running a trial to see if this is necessary

• Commented out Device (PMIO) - running a trial to see if this is necessary

• Commented out Device (LAN0) - this is just for me as my Ethernet works even if this is out.

 

Hi Nick. I managed to fix UUID errors on console with DSDT..So, i have added LAN0 Device(now on right place), and using these DSDT UUID errors are gone (without use any UUID keys, or modified boot - i´m using original Netkas PC_EFI 10.5).

On IORegistryExplorer we can see "LAN0@0" now.

 

I updated your last DSDT with LAN Device fix(Fixing UUID errors and Time Machine en0 errors). Try it.

Regards.

DSDT_BlackOSX101209_rev_thiagom.dsl.zip

[jamonda]

You did say you had a EP45-UD3L before, but you have to remember that I can't remember everybody's setups. That's why having a signature is very helpful. If you don't know how to do it, here's how. Click on the Cog icon at the top right corner of the blue bar above your login name, then down the left side of the next page, click on 'Edit Signature'.

 

Don't worry about not knowing that much about DSDT yet as it complicated and I am still trying to learn it myself

 

For adding relevant code back in for your board, you need to do the following. Note: this is providing that the information for your motherboard will be identical to mm67's? (to be sure you will want to get yourself an acpidump from linux and then compare the original DSDT with mm67's).

 

...

 

Blackosx, I want to thank you again for your patience. You'll go to heaven, I'm sure! Maybe you won't believe, but I studied law. What I know about OS X is what I've learnt since last march, when I came across an OS X distro DVD for MSI Wind. I only knew Windows before.

My ACPI/DSDT linux dump is attached to this post. Two hours in front of the computer to get the file. I'll try to compare it to mm67's DSDT dump to discover what I have to change in your DSDT to get my system running well.

Thanks again.

dsdt__EP45_UD3L__linux_dump_.dsl.zip

[blackosx]

Hi Nick. I managed to fix UUID errors on console with DSDT..So, i have added LAN0 Device(now on right place), and using these DSDT UUID errors are gone (without use any UUID keys, or modified boot - i´m using original Netkas PC_EFI 10.5).

On IORegistryExplorer we can see "LAN0@0" now.

 

I updated your last DSDT with LAN Device fix(Fixing UUID errors and Time Machine en0 errors). Try it.

Regards.

Thanks Thiago. I have tried the DSDT with the Device (LAN0) as you supplied. I did these tests using the original PC-EFI v10.5 and removed PlatformUUID.kext from /E/E and removed the SMUUID key/string from SMBIOS.plist.

 

I can confirm it removes lot of errors but not all of them on my system, and yes, LAN0@0 now appears in IORegistryExplorer rather than ethernet@0. I have attached some screengrabs....

 

First, IORegistryExplorer with and without the LAN0 device in DSDT.

 

Second, the result of grep UUID /var/log/system.log in Terminal with and without the LAN0 device in DSDT.

[mm67]

Thanks Thiago. I have tried the DSDT with the Device (LAN0) as you supplied. I did these tests using the original PC-EFI v10.5 and removed PlatformUUID.kext from /E/E and removed the SMUUID key/string from SMBIOS.plist.

 

I can confirm it removes lot of errors but not all of them on my system, and yes, LAN0@0 now appears in IORegistryExplorer rather than ethernet@0. I have attached some screengrabs....

 

First, IORegistryExplorer with and without the LAN0 device in DSDT.

 

Second, the result of grep UUID /var/log/system.log in Terminal with and without the LAN0 device in DSDT.

 

New Chameleon rc4 seems to have same UUID patch as that modified PC EFI version, no need to use UUID strings anywhere.

My list of UUID errors, which is kind of short

[blackosx]

New Chameleon rc4 seems to have same UUID patch as that modified PC EFI version, no need to use UUID strings anywhere.

My list of UUID errors, which is kind of short

It's been released? Thanks for the confirmation mm67.

Thanks to Zef, I had been running a pre-release version for a while now, but I had to keep quiet about it's features.

Hibernation works great for me now as does using the PciRoot key/string for device injection.

[blackosx]

Blackosx, I want to thank you again for your patience. You'll go to heaven, I'm sure!

Thanks, you're too kind.

 

Maybe you won't believe, but I studied law.

Wow!.. respect.

 

What I know about OS X is what I've learnt since last march, when I came across an OS X distro DVD for MSI Wind. I only knew Windows before.

Windows to OS X is one thing, OSX86 is another thing. We all had to learn from some point so well done, you are doing well.

 

My ACPI/DSDT linux dump is attached to this post. Two hours in front of the computer to get the file. I'll try to compare it to mm67's DSDT dump to discover what I have to change in your DSDT to get my system running well.

Thanks again.

Well done for extracting your DSDT from the acpidump

To compare it with mm67's original one, find his file (he posted it to the Gigabyte DSDT Fix thread) and in Terminal type the following.....

 

diff -uw fileA fileB > result.txt

 

Of course, replacing fileA and fileB with the actual DSDT.dsl filesnames you want to compare.

You will find the result.txt file in your ~/ folder. (That's the root of your user folder).

[thiagomorales]

Thanks Thiago. I have tried the DSDT with the Device (LAN0) as you supplied. I did these tests using the original PC-EFI v10.5 and removed PlatformUUID.kext from /E/E and removed the SMUUID key/string from SMBIOS.plist.

 

I can confirm it removes lot of errors but not all of them on my system, and yes, LAN0@0 now appears in IORegistryExplorer rather than ethernet@0. I have attached some screengrabs....

 

First, IORegistryExplorer with and without the LAN0 device in DSDT.

 

Second, the result of grep UUID /var/log/system.log in Terminal with and without the LAN0 device in DSDT.

 

Very strange...Here, using no any keys and PC_EFI 10.5 i get rid all of these messages.. Can you confirm that with old DSDT (and no any UUID keys nor UUID kexts) these errors not appear in log ?

If yes, please upload your old DSDT to look..

 

Regards.

[blackosx]

Very strange...Here, using no any keys and PC_EFI 10.5 i get rid all of these messages.. Can you confirm that with old DSDT (and no any UUID keys nor UUID kexts) these errors not appear in log ?

If yes, please upload your old DSDT to look..

Hi mate

 

I have always had these errors in 10.6 when I don't use PlatformUUID.kext / SMUUID key in SMBIOS. And that's using either the original PC-EFI 10.5 or Chameleon RC3 . I used to always get them in 10.5 too unless I used UUID.kext.

 

With old DSDT, I believe I still had errors, but to be honest I never checked for them.

Here is what I was running with before mm67 shared his revelation.

Previous_dsdt.dsl.zip

 

As mm67 pointed out, it's all fixed now with Chameleon RC4.

[jamonda]

Thanks, you're too kind.

 

 

Wow!.. respect.

 

 

Windows to OS X is one thing, OSX86 is another thing. We all had to learn from some point so well done, you are doing well.

 

 

Well done for extracting your DSDT from the acpidump

To compare it with mm67's original one, find his file (he posted it to the Gigabyte DSDT Fix thread) and in Terminal type the following.....

 

diff -uw fileA fileB > result.txt

 

Of course, replacing fileA and fileB with the actual DSDT.dsl filesnames you want to compare.

You will find the result.txt file in your ~/ folder. (That's the root of your user folder).

 

Hi, master.

The diff file is attached to this post.

What's next?

diff_UD3P_UD3L.txt

[blackosx]

Hi, master.

LOL.... I wouldn't go that far

 

The diff file is attached to this post.

Have you attached the file, as the link goes to an error?

[jamonda]

LOL.... I wouldn't go that far

 

 

Have you attached the file, as the link goes to an error?

 

Sorry, my mistake.

Here is the file. I compared it to the one you attached in post #376, which I also attached below.

I may be wrong, but they seem to be almost the same.

diff_UD3P_UD3L.txt

ACPIdump_DSDT_Differences.txt

[blackosx]

Sorry, my mistake.

Here is the file. I compared it to the one you attached in post #376, which I also attached below.

I may be wrong, but they seem to be almost the same.

Good work jamonda. You have learned quickly

They do look identical in which case you can carry on using the DSDT file we have been working on here.

I am surprised by that, as I thought yours would be similar to mm67's. (Shows how much I know? )

Maybe the PCI Routing Table I stripped out of mm67's for our DSDT is common only to the 'P' designated board and not the 'L' designated board that both you and I have.

 

PS. Thanks for creating a signature

[jamonda]

Good work jamonda. You have learned quickly

They do look identical in which case you can carry on using the DSDT file we have been working on here.

I am surprised by that, as I thought yours would be similar to mm67's. (Shows how much I know? )

Maybe the PCI Routing Table I stripped out of mm67's for our DSDT is common only to the 'P' designated board and not the 'L' designated board that both you and I have.

 

PS. Thanks for creating a signature

 

I'm very happy to know! This means that if I follow your steps I'll always be safe!

I suspected there would be no great differences between UD3L and DS3L because their technical specifications are virtually the same. The UD series motherboards differ from the DS ones in the 'ultra durable' components and in the 2oz copper inner layer. Thank God!

And yes, I created a signature. I don't know why mine and yours are pretty identical ... (mere coincidence, I think! )

[blackosx]

I'm very happy to know! This means that if I follow your steps I'll always be safe!

I suspected there would be no great differences between UD3L and DS3L because their technical specifications are virtually the same. The UD series motherboards differ from the DS ones in the 'ultra durable' components and in the 2oz copper inner layer. Thank God!

And yes, I created a signature. I don't know why mine and yours are pretty identical ... (mere coincidence, I think! )

Hopefully you don't think it was a waste of time doing all that, but if you hadn't done it then we wouldn't have known. At least you now know more than you did before, and you will also have other tables from your acpidump like the FACP which you can use to learn from.

[jamonda]

Hopefully you don't think it was a waste of time doing all that, but if you hadn't done it then we wouldn't have known. At least you now know more than you did before, and you will also have other tables from your acpidump like the FACP which you can use to learn from.

 

 

Experiences are never waste of time. And the more I learn the more I want to learn: I'm already reading the other tables you mentioned!

 

Thank you very much for the lesson.

[jamonda]

For me Chameleon RC4 kills sleep and QE/CI

[kantok]

For me Chameleon RC4 kills sleep and QE/CI

 

For me, fan is working in full speed.

Any conflict between DSDT and boot?

[jamonda]

Hi, fellows.

I solved the graphics detection and sleep issues doing this:

- decompile dsdt.aml

- edit dsdt.dsl and look for Device (PCI0)

- change Name (_UID, One) for Name (_UID, Zero)

- recompile dsdt.dsl and use the resulting dsdt.aml

Found this fix in http://forum.hmbt.org/viewtopic.php?f=135&t=3763

It's used to solve problems with GraphicsEnabler with Chameleon RC2/RC3.

I didn't have this issue with RC2/RC3, but I can see that the fix solved the issue I had with RC4.

Can anybody explain why changing One to Zero fixes the GFX detection?

Thanks.

[kantok]

- change Name (_UID, One) for Name (_UID, Zero)

 

 

Yeah! everything has come back!!!

Thanks a lot!

 

[edit] Now I put PciRoot=1.

[9z9]

For adding relevant code back in for your board, you need to do the following. Note: this is providing that the information for your motherboard will be identical to mm67's?

...

That should do it for your EP45-UD3L, and hopefully mm67 can confirm this. But note my main interest is in the EP45-DS3L and any DSDT stuff I post here is normally targeted for that.

Thank's You both (blackosx and mm67). Speed step still working only half (frequency switching from 2,8 to 1,5GHz, but voltage is still 1.2V). BUT!! Resume from sleep with my Apple wired keyboard fully working in this time. Before, I must resume from sleep only with mouse.

 

PS: I use this kext files: fakesmc.kext, LegacyHDA.kext, NullCPUPowerManagement.kext, OpenHaltRestart.kext, OrangeIconFix.kext, PlatformUUID.kext and SleepEnabler.kext. It's ok ?

 

Sorry for my english

[Aargh-a-Knot]

Thank's You both (blackosx and mm67). Speed step still working only half (frequency switching from 2,8 to 1,5GHz, but voltage is still 1.2V). BUT!! Resume from sleep with my Apple wired keyboard fully working in this time. Before, I must resume from sleep only with mouse.

 

PS: I use this kext files: fakesmc.kext, LegacyHDA.kext, NullCPUPowerManagement.kext, OpenHaltRestart.kext, OrangeIconFix.kext, PlatformUUID.kext and SleepEnabler.kext. It's ok ?

 

Sorry for my english

 

To have fully functioning speedstepping, you need to get rid of NullCPUPowerManagement.kext. And, if you are using the newest Chameleon, you do not need PlatformUUID.kext. I'm not sure about with your setup, but I do not need SleepEnabler.kext. And I use MC's OSXRestart instead of OpenHaltRestart.kext. Shutdown works fine. My dsdt is based on mm67's.