dsdt patch request: ga-g41mt-s2pt rev. 2.1

[Namidar]

Hello,

I was wondering (hoping) that someone could help me patch a dsdt for a gigabyte ga-g41mt-s2pt rev. 2.1 motherboard. I have found a patch for the s2p model but not the s2pt model that I have.

Unless the s2p model patch would work for the s2pt board as well?

Any and all help is appreciated.

Thanks very much,

Namidar

[artur-pt]

hello

u can try it

or

http://Olarila.com/forum/viewtopic.php?f=19&t=634

good hack

[Namidar]

Thanks for your help.

I had a look at the link you provided and found it quite confusing.

I found a dsdt for an earlier revision of this board. I understand that the difference between them is the audio chipset. Would it be hard to patch this dsdt so that it would work with my chipset?

Also... How does the patching process work? If I patch the audio, does the new patch overwrite the old configuration?

Thanks again for any help.

Namidar

[artur-pt]

hello

dsdt is not the salvation, not GOD...

if u patch for u audio, must find the right kext for it

the hacks use a patch kext for the alc

the audio is not native.

good hack

[analogg]

I was wondering (hoping) that someone could help me patch a dsdt for a gigabyte ga-g41mt-s2pt rev. 2.1 motherboard. I have found a patch for the s2p model but not the s2pt model that I have.

I just got my GA-G41MT-S2PT rev 2.1 working fairly well. The hardware monitoring is not working, and I haven't confirmed speed stepping. Audio and network are working, and both continue to work after sleep, which is itself working. Geekbench scores are what I would expect.

I started by extracting the BIOS's DSDT using Ubuntu 12 LTS. I applied to that the patch for the GA-G41M-Combo board. After applying the patch, the system booted, and sleep worked. Audio didn't work, but I'm using the "Optimized Realtek AppleHDA", mentioned here: http://www.tonycrapx86.com/audio/67763-ml-optimized-realtek-applehda-preview-alpha.html. I further added the patches found here: http://www.tonycrapx86.com/audio/67710-ml-how-add-edit-dsdt-hdef.html in the attachment ML_hdef_audio_ids_v1.zip. Specifically, I applied add_hdef.txt, followed by hdef_audio_id_1.txt.

In my efforts to determine if the hardware monitoring problem is DSDT related, I've compared 4 of the 9 patches for various Gigabyte G41 series boards. They are all the same. I was hoping to find a different patch for the IT8720 used on the -S2PT, but it looks like it is not different enough from the IT8718 used on the -Combo to warrant a different patch.

If you are using the now old-style audio drivers, you can probably just apply the GA-G41M-Combo patch, and call it a day. Even though the audio is different, I don't think it will matter. The patch files I compared were for boards with differing audio, but the patches were all the same.

Good luck!

[Namidar]

Thank you! Thank you! Thank you!

I'm soooooo excited to have a glimmer of hope at the end of this tunnel!

I will try this later tonight or tomorrow and post results.

Namidar

[analogg]

Thank you! Thank you! Thank you!

You're welcome! You're welcome! You're welcome!

I've been using the "multishit" post install tool. I had used MB 5.1.2, with it's updated features. I just tried a clean install, using MB 5.0.2 with the older hardware monitoring, and audio drivers.

I created a DSDT with only the GA-G41M-Combo patch, and ran post-install with MB 5.0.2. The older hardware monitoring works, and with that I can tell that speed stepping works. Uh-oh, audio didn't work.

To fix that, I manually changed the audio "layout-id" in the DSDT from "0x0C, 0x00, 0x00, 0x00" to "0x77, 0x03, 0x00, 0x00". You can find that in Device HDEF, which is within Device PCI0. Find them in the tree view on the left side of "DSDT Editor". Click "Device HDEF" in the tree view, and it will appear in the edit window.

I'm going to keep this configuration for now, as "everything" seems to work. I just need to find who's working on the hardware monitoring stuff, and mention that there might be an issue.

What the heck - I needed to create a new patch file anyway. Attached is the complete patch. Apply that to your "raw" DSDT, and you should be good to go.

GA-G41MT-S2PT_DSDT_PATCH.zip

[Namidar]

I was in the process of typing this when you made your last post. Please disregard anything that you've already addressed. BTW... What multishit settings did you use?

================================================================

Ok,

Me again. I forgot to ask a few basic and non-basic questions:

Do I install the kexts to s/l/e or extra? Do you recommend chameleon wizard for this?

Did you do a unishit/multishit install or a myhack install, or perhaps another?

I did a unishit install and have been trying a multishit install with the following results:

[i've copied and pasted this from a post I made on tonycrapx86.com]

================================================================

MY RIG:

- Gigabyte ga-g41mt-s2pt, rev. 2.1 (which is supposed to make it a bit of a pain).

- Intel core 2 duo e2180 (old and simple chip)

- EVGA NVIDIA 9800gtx 512mb, and 8 gigs of ddr3 ram on the motherboard

- 2 x Corsair Force 3 SSD drives, one of which I am trying to install OS X 10.8.2 on

- 1 x Seagate 500gb HD

- pcie sata 3 2-plug expansion card (cannot remember brand but recognized out of the box)

I can install 10.8 fine with unishit. After install I have no ethernet. Then I install 10.8.2 update and then afterwards the 10.8.2 supplemental. After this the network is fine.

The system seems to work well except for 4 things:

1. sleep

2. sound

3. hardware monitoring

4. the fact that I cannot boot after a multishit installation

In regards to not booting after multishit installation (of various configurations - easybeast included and at one point easybeast alone): The system seems to boot. Using the -v flag, I can see what looks like everything booting, and then the screen goes black and everything shuts down. I have used -v, -x, -f, PCIRootID=0/1, and GraphicsEnabler=Yes/No. All in various combinations. No luck.

*** EDIT: Is it perhaps problematic to install OS X on a SSD drive? Just wondering.

If I boot from the unishit stick, all seems ok (except sleep and sound).

Also, Im not sure how to check to see if QE/CI is enabled, but I assume it is because of the fact that the 9800gtx is natively supported in ML.

================================================================

Got any ideas or advice for me?

Either way, I appreciate your help! Thanks.

[Namidar]

BTW... Thanks very much for the file!

[analogg]

My setup has a 9800 GT, and some old Seagate rotating storage.

At some point, I downloaded the Mountain Lion installer again, to get 10.8.2 on the install stick. It's made life a little easier.

The install stick was created with unishit.

I had three partitions: one clean 10.8.2, one with Easybeast, one DSDT-free. Neither the Easybeast or the DSDT-free would even boot (black screen).

I used the install stick to boot into the clean partition, and delete the /Extra folder from the DSDT-free partition, then booted into it from the install stick. I created the DSDT from there. Oh, at some point, I booted Ubuntu to get the "raw" DSDT. Nice OS. USB 3.0 just works.

For the final installation, I cloned the clean install onto the Easybeast partition (only took a few minutes, as all of the files were already there.) I created the DSDT, and left it on the desktop. I ran multishit 5.0.2 and selected...

UserDSDT or DSDT-Free Installation

Audio.Realtek.WithDSDT.ALC888b/887.v100302

Miscellaneous.FakeSMC Plugins.Motherboard Plugins

Miscellaneous.FakeSMC Plugins.HWMonitor Application

Network.maolj's AtherosL1cEthernet

System.AppleRTC Patch for CMOS Reset

Boot Options.Verbose Boot

I rebooted, and found I hadn't deleted OemSMBIOS.kext. Grrrr. Fix, reboot, and most things worked. Audio didn't work, but fortunately, my first guess was the layout-id. (I had done lots of reading at this point.)

If you are using MB 5.0.2 and OS X 10.8.2, you'll have to delete OemSMBIOS.kext, and then rebuild the kext cache. I've taken to just deleting the kext cache, and letting it get rebuilt on the next boot. (sudo rm /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache)

If you use MB 5.1.2 (maybe 5.1.1 or later) you don't need to delete OemSMBIOS.kext, but you will have to change the audio layout-id to 1, and the HWMonitor won't work.

If you use an SSD, I believe you should also select TRIM Enabler. I don't have any experience with this myself.

The easiest way I know of to check for QE/CI is to have a close look at the menu bar. If it's a solid color, no QE/CI. If you can see the background through it, (blurred - basically, any variations in color/brightness) you're good. Just use a background that has some detail at the top of the screen.

Again, good luck!

[Namidar]

Not sure why, but the board is telling me that I am not authorized to download the patch... hmmmm... will try again, I guess.

Thanks.

[Namidar]

ok,

now it is letting me click on the patch, but instead of allowing me to save it, it is opening it in a text window with a lot of text in it... what extension should I save this with in order to be able to use it?

Thanks again.

[artur-pt]

hello

man , have u reading the guide

http://Olarila.com/forum/viewtopic.php?f=19&t=634

i think u don't read, if u don't read how u gonna apply the patches and create dsdt

good hack

[analogg]

Hmm, I tried clicking on the patch file, and it downloaded as a .zip, as it should. Inside the zip is a .txt file. I wonder if your browser is automatically opening the file?

Anyway, the .txt file is what you will apply as a patch.

Regarding the black screen on boot, the PNY 9800GT that I'm using will always give a black screen if I try to use HDMI. I've tried with several systems, and it's the same. I don't know if it's unique to this particular board, or 9800x's in general. So if, after you have a DSDT, you still get black and you are using HDMI, this might be a problem.

Here's yet another how-to on patching, this one is pictorial, instead of video.

http://www.tonycrapx86.com/dsdt/31716-guide-creating-your-own-dsdt-most-boards.html

It's really straightforward, once you get into it.

[Namidar]

I appreciate your help.

I am running an EVGA 9800gtx... Problem is that the card has ONLY got 2 hdmi ports... Hmmm. Hope you are wrong on that count.

EDIT: In theory the card should be able to be made to work as it works just peachy when I boot the system from unishit. At least this makes sense to me.

I have built 3 other hackintoshes, but this is the first time I've really had to deal with dsdt files.

In response to artur-pt: I just want to say that I have looked at / skimmed /perused over a few guides and sites, but I just don't have a whole lot of time these days. My old Asrock Conroe 1333-d667 went for a crap and I'm trying to get this one functional ASAP as I have progress reports due in like a week. I just don't have the time that I used to have prior to having young children, marriage, demands of work, etc. I'm trying, though. I love hackintoshing and I learn what I can when I can. Priorities, right?

Anyways, analogg, thanks for all of your help. I will try to implement your knowledge as soon as I'm able. I will report back.

Thanks,

Namidar

[Namidar]

Analogg (or artur-pt, should you feel so inclined to assist),

I've tried to compile the DSDT, but get the following warning:

2138 Warning ResourceTag larger than Field (Tag: 16 bits, Field: 8 bits)

In searching the forum I've found a suggested and supposedly working fix for the following warning:

2138 Warning ResourceTag larger than Field (Tag: 64 bits, Field: 32 bits)

In my reading I understand that it would seem that there is a difference between the fix for these two different errors, but for the life of me I cannot seem to find out what that would be. I've googled quite a bit regarding this.

I've made a post (on this board) asking for help, but I am wondering if you encountered the same problem, and if so, how did you go about fixing it?

Can I continue on with the process of compiling and using the DSDT without fixing these warnings for now?

As always,

Thanks muchly.

[analogg]

how did you go about fixing it?

Can I continue on with the process of compiling and using the DSDT without fixing these warnings for now?

Originally, I cavalierly ignored them. I did indeed get the same warnings. Three errors, two warnings. I hit the "fix errors" button, and was left with the warnings.

After reading your post, I spent some time looking at the warnings. I will now respectfully ignore them.

The "raw" DSDT, if re-compiled, yields 3 errors, and 12 warnings. After seeing that, I thought I'd just give it a try. And, it worked.

The warnings are about byte fields being created for a buffer at a location where there is a 16-bit value. Intentionally, as far as I can tell. They are taking a 16 bit IO address, and creating byte fields "LO" and "HI". Seems reasonable.

The warning occurs for the "LO" part, because the byte offset used evaluates to an entry in the symbol table, and that symbol (the buffer field name) is used. For the "HI" part, the offset+1 does not match a symbol table entry, and the offset (a number) is used instead. The symbol is tagged as a 16 bit value, and the warning is generated.

This may have been compiled with warnings. Or, perhaps, a different symbol was used originally, some kind of cast operator was used, or perhaps a pragma was used to suppress warnings. If there was something like that, it was lost in the compile - decompile process.

A dirty "fix" would be to change the symbol names used to offsets - (0x02, and 0x04, respectively). This works, generates the same code, with no warnings, but is bad programming practice.

I may have over-thought this one.

Cheers, Analogg

[artur-pt]

hello

try to use

CreateWord

good hack

[analogg]

hello

try to use

CreateWord

good hack

Artur-pt, I think that is not what is wanted here. Yes, it would eliminate the warning, but would change what the code is doing. The intent is to access the hi and lo bytes separately in a 16 bit value. Using CreateWord would change the access from 8 to 16 bits. Writing the lo byte would change the whole word, and writing the hi byte would change the high byte, plus the byte that follows it. That can't be good.

This code appears in the ACPI Implementers' Guide. In the guide, they just use the byte offset, instead of the symbolic value. So, whether it seems like bad practice or not, that's what they recommend.

Cheers, Analogg

[Namidar]

Analogg,

Thanks for the reply. I did in fact go ahead and ignore it. Seems to boot well ... Up to the blank/black screen.

That one is driving me nuts because as I mentioned before, the card works great when booting from the USB key. I wonder if deleting all video kexts on the 10.8.2 install and replacing them with the ones crom the USB key would be a cheap work around.

As for those errors go... I'm sure glad you know what you are talking about. I've been hacking around on computers for about 30 years now, but that coding is way beyond me.

Thanks for the help

Namidar

[analogg]

30 years... That puts you up there with me. Started with an 8080 at 2MHz, 256 bytes ROM, 8K RAM. Wooo!

I've been able to figure some of this stuff out. Really _understanding_ ACPI? No, but the way the code is written makes a bit of sense.

I can think of two ways to cause the black screen: A problem with the DSDT - It should end up in /Extra, and be the one you patched. It should be compiled, and have a .aml extension. DSDT.aml is common.

The other is the HDMI / 9800GT problem I would have, if I tried to use HDMI. However, in my case, the screen is black even if I use the install stick.

I don't think that the installer kexts are any different than those that do get installed.

Cheers, Analogg

[Namidar]

I'm not sure what I was thinking, but I have mistakenly given you the wrong information. The card is dual dvi not hdmi. Not sure how I even got confused about that one.

I'm gonna keep looking around.

Yeah, I'm up there a bit.

When I was ten my parents sent me for a one week computer course at the radio shack plant that used to be here in my city. The first computer that I really hacked on was a Tandy, 1000 model if I remember correctly. (if there was such a model, it's been so long...). The first computer my family owned was a brand spanking new Apple ][e. Many/most of my friends were c64 fans. My firt pc was based on an 8086 architecture. (Again, am I remembering that correctly?)

It's the grey hair coming in, I tell you. It makes you forget things. I turn 42 at the end of this month.

Thanks again,

Namidar

[Namidar]

OK,

so after taking another look I realized that multishit had not moved the DSDT.aml file into the /extra directory.

I also recompiled the DSDT.aml file using chameleon wizard.

Next thing I did was boot using the flags GraphicsEnabler=Yes and PCIRootID=1.

So now she boots fine!

I'm not exactly sure what combination of the above did the trick (probably all?), but now I have a functional system. I'm gonna clone it before anything else is installed.

Again, I will report back.

Namidar

[Namidar]

analogg,

You absolutely rock and are without a doubt my savior.

Everything works great... qe/ci, sleep, app store, sound, graphics card, etc.

The only thing left to test (most likely tomorrow at work) is if dual monitor support is in place and if it isn't I suspect that I can activate onboard video and use it for my second monitor.

I've unplugged my OS X install drive and my Seagate 500gb data/time machine drive and am now installing Windows 7 on a second SSD drive. Man am I glad that I got a great deal on these SSD (refurbished) drives. I mean a great deal (for around here anyways)!

From what I understand a dual boot os x / windows system is pretty straight forward if installing on two physically separate drives. If you have any advice or cautions regarding this please let me know. This will be the first time I've had a Windows install in like 4 or 5 (maybe 6?) years.

I couldn't be more pleased! Thanks.

I cannot remember the last time I had such a tight build... Probably since my first hackintosh some years back after following the original lifehacker guide.

Next I have to update my other home hackintoshes. I'm not nearly as worried about doing them as I've seen install guides and pre-edited DSDT files for them. My main system will also get two SSD drives and dual boot while my other system (kids system) will dual boot also, but off of two physically separate hard drives.

I even bought a fifth of these Corsair Force 3 120gb SSD drives and put it in an esata / USB enclosure that I got for a steal ($10, I think). It seems to be of impressive quality. It is only USB 2.0 but that makes no difference to me as I don't have USB 3.0 on any of my systems. Each one has esata, though. All three are socket 775, and at this point I have no need to upgrade. I'm not a gamer, really, aside from a bit of WOW, and my kids are still young.

After I get everything stabilized I am going to try to overclock my simple e2180 2.0ghz CPU. I've read online that it is very overclockable. I've seen a few reports of guys successfully running them as high as 3.4ghz without any stability issues, or even cooling issues to speak of. I don't mind trying to overclock it as I have a spare e2180, and I've seen them as low as $10 on eBay.

Thanks again.

Let's keep in touch,

A very excited and grateful Namidar.

[analogg]

Hey, no problem. I'm glad you got it working. This seems like a nice little board.

Tomorrow at work... Saturday? Awww.

I had the same problem with multishit not moving the DSDT. I wonder if there is a new naming convention, or there's just a bug.

Windows... I've got one machine that runs both OS X and Windows 7. I just installed to another HD, like you are doing, and boot from the OS X drive.

I'll send you a PM.

Cheers, Analogg