[GUIDE] Installing Snow Leopard/Leopard retail DVD on the GA-E7AUM-DS2H

[adidasprince]

Link for OrangeHDIcon

 

http://pcwiz computer.com/index.php?option=com_docman&task=doc_details&gid=82&Itemid=74

[brownies]

Yes I should make it clear in my main post that it is the on-board video that causes the memory limitation.

Hi dlach,

Do you mean that adding a gfx card will solve the 2Gb issue ?

[x4nd0r]

Chameleon 2 RC 3 is out. It has some intresting featurs, including:

 

VideoROM

You can pass an alternate video ROM image file to the system.

 

VBIOS

Using this boolean switch, you can control the injection of your video BIOS to device-properties. We got various reports if this switch is really needed to make your graphics device handled correctly by the system.

 

 

 

 

I think one or both of these features can resolve the 2GB issue's. I'm unable to test these features for the next two, so i hope that some one can test it on the e7-aum-ds2h.

 

 

 

 

Other strange thing that i have that i lost my audio after upgrading to 10.5.8. Is some one experiencing the same problems? and is there a FIX?

 

-x

 

 

 

 

 

 

[dlach]

Hi dlach,

Do you mean that adding a gfx card will solve the 2Gb issue ?

 

Yes, I believe that people on the big thread reported that adding a gfx card and disabling the on-board video and avoids the 2GB limitation and KentWAhaha has just confirmed as a couple of posts ago. I don't find this at all surprising because the problem has been reported to be video memory mapping in the SSDT.

 

Chameleon 2 RC 3 is out. It has some intresting featurs, including:

 

VideoROM

You can pass an alternate video ROM image file to the system.

 

VBIOS

Using this boolean switch, you can control the injection of your video BIOS to device-properties. We got various reports if this switch is really needed to make your graphics device handled correctly by the system.

 

 

 

 

I think one or both of these features can resolve the 2GB issue's. I'm unable to test these features for the next two, so i hope that some one can test it on the e7-aum-ds2h.

 

 

 

 

Other strange thing that i have that i lost my audio after upgrading to 10.5.8. Is some one experiencing the same problems? and is there a FIX?

 

-x

 

Did you re-apply the AppleHDA.kext from the first post? I found that my audio worked after updating to 10.5.8 put then I installed iLife and got a kernel panic because 10.5.8 apparently did not completely overwrite the audio kext. Re-applying AppleHDA.kext fixed the problem. Of course I use the USB audio device I point to in the first post because it is cheap, works great and avoids the resume from sleep issue.

 

Chameleon 2 RC 3 is out. It has some intresting featurs, including:

 

VideoROM

You can pass an alternate video ROM image file to the system.

 

VBIOS

Using this boolean switch, you can control the injection of your video BIOS to device-properties. We got various reports if this switch is really needed to make your graphics device handled correctly by the system.

 

 

 

 

I think one or both of these features can resolve the 2GB issue's. I'm unable to test these features for the next two, so i hope that some one can test it on the e7-aum-ds2h.

 

 

 

 

Other strange thing that i have that i lost my audio after upgrading to 10.5.8. Is some one experiencing the same problems? and is there a FIX?

 

-x

 

Did you re-apply the AppleHDA.kext from the first post? I found that my audio worked after updating to 10.5.8 put then I installed iLife and got a kernel panic because 10.5.8 apparently did not completely overwrite the audio kext. Re-applying AppleHDA.kext fixed the problem. Of course I use the USB audio device I point to in the first post because it is cheap, works great and avoids the resume from sleep issue.

[x4nd0r]

Did you re-apply the AppleHDA.kext from the first post? I found that my audio worked after updating to 10.5.8 put then I installed iLife and got a kernel panic because 10.5.8 apparently did not completely overwrite the audio kext. Re-applying AppleHDA.kext fixed the problem. Of course I use the USB audio device I point to in the first post because it is cheap, works great and avoids the resume from sleep issue.

 

Strange, after, again, re-applying AppleHDA.kext it did *not* fix the problem. But after re-seating the audio plug in to it socket, it works. This is realy strange behaviour.

 

dlach, do you have any luck running sl?

 

-x

[dlach]

Strange, after, again, re-applying AppleHDA.kext it did *not* fix the problem. But after re-seating the audio plug in to it socket, it works. This is realy strange behaviour.

 

dlach, do you have any luck running sl?

 

-x

Not yet but I know it can be done. I am mostly focused on getting the boot123 iso ready and being able to document the process.

[tomtefar]

dlach:

 

I read on the first page that you have reported the SSDT / memory mapping issue for the onboard GPU to Gigabyte. It would be interesting if you could post some details on what you actually reported to them. Maybe it could be used for others to form personalized versions of your report (and thus increasing the chance of it being resolved as from Gigabyte's perspective there would seems as more ppl being affected by the bug).

 

Please?

 

Cheers!

/Tom

[dlach]

dlach:

 

I read on the first page that you have reported the SSDT / memory mapping issue for the onboard GPU to Gigabyte. It would be interesting if you could post some details on what you actually reported to them. Maybe it could be used for others to form personalized versions of your report (and thus increasing the chance of it being resolved as from Gigabyte's perspective there would seems as more ppl being affected by the bug).

 

Please?

 

Cheers!

/Tom

 

Glad to. Unfortunately I'm not sure exactly what the problem is. One guy over on the big thread insisted it was SSDT. But then I went through and could only find a reasonable assertion that it was in the DSDT. Here is the text from the post I sent Gigabyte. Note that they haven't responded to me since I sent this. They told me they didn't support OSX and there were no guarantees but then they came back as asked me what version of OSX I had the problem with. I told them I had seen it in 10.5.5, 10.5.6, 10.5.7 10.5.8 and it had been reported in 10.6.

 

Before you bug Gigabyte, please lets just see what they respond to me with.

 

Here is the note from the big thread:

"The test was with a very simple ACPI table called MCFG.CFG which is a "Memory Mapped Configuration table".

 

The Gigabyte one looks like:

CODE

/*

* Intel ACPI Component Architecture

* AML Disassembler version 20061109

*

* Disassembly of MCFG.dat, Thu Nov 27 19:59:58 2008

*

* ACPI Data Table [MCFG]

*

* Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue

*/

 

[000h 000 4] Signature : "MCFG" /* Memory Mapped Configuration table */

[004h 004 4] Table Length : 0000003C

[008h 008 1] Revision : 01

[009h 009 1] Checksum : 14

[00Ah 010 6] Oem ID : "GBT "

[010h 016 8] Oem Table ID : "GBTUACPI"

[018h 024 4] Oem Revision : 42302E31

[01Ch 028 4] Asl Compiler ID : "GBTU"

[020h 032 4] Asl Compiler Revision : 01010101

 

[024h 036 8] Reserved : 0000000000000000

 

[02Ch 044 8] Base Address : 00000000E0000000

[034h 052 2] Segment Group Number : 0000

[036h 054 1] Start Bus Number : 00

[037h 055 1] End Bus Number : 1F

[038h 056 4] Reserved : 00000000

 

Raw Table Data

 

0000: 4D 43 46 47 3C 00 00 00 01 14 47 42 54 20 20 20 MCFG<.....GBT

0010: 47 42 54 55 41 43 50 49 31 2E 30 42 47 42 54 55 GBTUACPI1.0BGBTU

0020: 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 E0 ................

0030: 00 00 00 00 00 00 00 1F 00 00 00 00 ............

 

That table on all of the other 730i boards I have in my sig looks like

CODE

/*

* Intel ACPI Component Architecture

* AML Disassembler version 20080926

*

* Disassembly of acpitbls/MCFG.aml, Wed Jan 28 18:25:06 2009

*

* ACPI Data Table [MCFG]

*

* Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue

*/

 

[000h 000 4] Signature : "MCFG" /* Memory Mapped Configuration table */

[004h 004 4] Table Length : 0000003C

[008h 008 1] Revision : 01

[009h 009 1] Checksum : 38

[00Ah 010 6] Oem ID : "010809"

[010h 016 8] Oem Table ID : "OEMMCFG "

[018h 024 4] Oem Revision : 20090108

[01Ch 028 4] Asl Compiler ID : "MSFT"

[020h 032 4] Asl Compiler Revision : 00000097

 

[024h 036 8] Reserved : 0000000000000000

 

[02Ch 044 8] Base Address : 00000000FC000000

[034h 052 2] Segment Group Number : 0000

[036h 054 1] Start Bus Number : 00

[037h 055 1] End Bus Number : 1F

[038h 056 4] Reserved : 00000000

Invalid zero length subtable

 

Raw Table Data

 

0000: 4D 43 46 47 3C 00 00 00 01 38 30 31 30 38 30 39 MCFG<....8010809

0010: 4F 45 4D 4D 43 46 47 20 08 01 09 20 4D 53 46 54 OEMMCFG ... MSFT

0020: 97 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC ................

0030: 00 00 00 00 00 00 00 1F 00 00 00 00 ............

 

See the difference in address?

 

Anyway I tried a bios with the Gigabyte's addressed changed to FC and I didn't see the video memory range move up in memory like I thought it would. In the end it looks like it just relocated ACPI. Didn't do any further tests as it looked like we were back to needing a vgabios update.

 

So here's the deal with that - the DFI is the only other 9400 board on the market as far as I can tell. I couldn't directly use that vga bios on the Gigabyte as their video out ports are different and has a different nvcap. You basically end up with non-working video on boot because of it.

 

Arti's tool for decoding nvcap (nvcapmaker) for our hackintosh use knows where to locate this information in a nvidia vgabios but damn if I can. It's encoded (as in not the same hex you see generated by nvcap maker) and could possibly be in several locations.

 

I've tried contacting Arti through email to ask him about this but he hasn't responded and doubt he will.

 

Only way to easily compare is to get vgabios's that are identical releases for the same gpu with different ports on each card (i.e. let's say a 7300GT with dual dvi vs. a 7300GT with vga+dvi). That's been a needle in a haystack.

 

Reverse engineering Arti's program (nvcap located in NVCapMaker's resources directory) isn't something easy for me to do either.

 

If anybody finds that info out, let me know.

 

My only other choice is to take one of the 9300 vgabios's and make it think it's a 9400 for a test. Those vgabios's share the same nvcap.

 

Anyway, here's the bios for the Gigabyte with the one byte MCFG.CFG change and nothing else touched. It's based on F3a. I doubt it helps at all but you can give it a shot if you like."

[netcastle]

dlach,

 

Your dedication to this board is becoming legendary. Thanks for all your hard work. I wish there was a way I could throw you some karma.

 

net

[olegischinski]

hallo,

 

my experiences with this board are a little bit different.

I installed 10.5.6 for month using this Guide (Thanks!), only using the patched BIOS and kexts described above (optional only OpenHaltRestart.kext), but there were no problems with this 2GB limitation - here are 2x2GB-Rams in it. I had many problems with the update to 10.5.7, solved it (don't know how) with my MBP and an extern HDD. I tried the update to 10.5.8 via Apple-Software-Update ... and it works. No try with SL.

 

Only for information, no question - sorry ...

[dlach]

hallo,

 

my experiences with this board are a little bit different.

I installed 10.5.6 for month using this Guide (Thanks!), only using the patched BIOS and kexts described above (optional only OpenHaltRestart.kext), but there were no problems with this 2GB limitation - here are 2x2GB-Rams in it. I had many problems with the update to 10.5.7, solved it (don't know how) with my MBP and an extern HDD. I tried the update to 10.5.8 via Apple-Software-Update ... and it works. No try with SL.

 

Only for information, no question - sorry ...

 

 

Anyone who thinks they've got >2GB working should try this memory test:

 

Memory Test

 

Go there and download and run it. Make sure you're ready for a hard stop though. Please report back here if successful.

 

olegischinski, since you've posted that you have no problems please run the test and report back your results. I'd be willing to that just like all of the others who think they've got no problem, you just haven't run into it yet. Sorry if I'm coming off as being a bit peeved but I am getting tired of the parade of people who keep challenging this fact even though I've posted several times that you need to run the memory test (or use a memory intensive application) to see it.

[blueknight]

I try to install SL on GA-E7AUM-DS2H and suppose to success.

I use 2GB memory and Koalala's BIOS -e7aumd2hf3x.

 

What we need;

• modified dsdt.aml (to avoid CMOS restting after reboot SL)
  

• 64bit kexts
  

fakesmc v2

OpenHaltRestart

PlatformUUID

NullCPUPM

SleepEnabler these from InfiniteMac "How to Install SL on a PC" thread.

ALC889a from this form No 140941

 

• Chameleon-2-RC3
  

Making dsdt.aml, I use DSDTSE ( it is very nice !)

We have to modiy two sections, Device(RTC) and NVH7.

Get dsdt.dsl and let's modify.

 

Search this section;

Device (RTC)

{

Name (_HID, EisaId ("PNP0B00"))

Name (ATT0, ResourceTemplate ()

{

IO (Decode16,

0x0070, // Range Minimum

0x0070, // Range Maximum

0x00, // Alignment

0x04, // Length

)

})

Name (ATT1, ResourceTemplate ()

{

IO (Decode16,

0x0070, // Range Minimum

0x0070, // Range Maximum

0x00, // Alignment

0x04, // Length

)

 

Modify Length from "0x04" to "0x02", like this.

 

 

Device (RTC)

{

Name (_HID, EisaId ("PNP0B00"))

Name (ATT0, ResourceTemplate ()

{

IO (Decode16,

0x0070, // Range Minimum

0x0070, // Range Maximum

0x00, // Alignment

0x02, // Length

)

})

Name (ATT1, ResourceTemplate ()

{

IO (Decode16,

0x0070, // Range Minimum

0x0070, // Range Maximum

0x00, // Alignment

0x02, // Length

)

 

 

 

 

 

Next, search "NVH7" and find

 

 

 

If (CondRefOf (NVH7, Local7))

{

Return (NVH7 ())

}

 

Modify to

 

If (CondRefOf (NVH7, Local7))

{

Store (0x966A, ^^^SBUS.SMT2)

}

 

Then you can compile to dsdt.aml

 

[olegischinski]

hi dlach,

 

sorry, I didn't intend to peeve you. Perhaps I should read the whole thread before posting next time. Thanks again for your help in this forum.

 

Well, the memtest fails, as you expected.

I can post details like syslog, if it helps.

[dlach]

I try to install SL on GA-E7AUM-DS2H and suppose to success.

I use 2GB memory and Koalala's BIOS -e7aumd2hf3x.

 

What we need;

• modified dsdt.aml (to avoid CMOS restting after reboot SL)
  

• 64bit kexts
  

fakesmc v2

OpenHaltRestart

PlatformUUID

NullCPUPM

SleepEnabler these from InfiniteMac "How to Install SL on a PC" thread.

ALC889a from this form No 140941

 

• Chameleon-2-RC3
  

Making dsdt.aml, I use DSDTSE ( it is very nice !)

We have to modiy two sections, Device(RTC) and NVH7.

Get dsdt.dsl and let's modify.

 

Search this section;

Device (RTC)

{

Name (_HID, EisaId ("PNP0B00"))

Name (ATT0, ResourceTemplate ()

{

IO (Decode16,

0x0070, // Range Minimum

0x0070, // Range Maximum

0x00, // Alignment

0x04, // Length

)

})

Name (ATT1, ResourceTemplate ()

{

IO (Decode16,

0x0070, // Range Minimum

0x0070, // Range Maximum

0x00, // Alignment

0x04, // Length

)

 

Modify Length from "0x04" to "0x02", like this.

 

 

Device (RTC)

{

Name (_HID, EisaId ("PNP0B00"))

Name (ATT0, ResourceTemplate ()

{

IO (Decode16,

0x0070, // Range Minimum

0x0070, // Range Maximum

0x00, // Alignment

0x02, // Length

)

})

Name (ATT1, ResourceTemplate ()

{

IO (Decode16,

0x0070, // Range Minimum

0x0070, // Range Maximum

0x00, // Alignment

0x02, // Length

)

 

 

 

 

 

Next, search "NVH7" and find

 

 

 

If (CondRefOf (NVH7, Local7))

{

Return (NVH7 ())

}

 

Modify to

 

If (CondRefOf (NVH7, Local7))

{

Store (0x966A, ^^^SBUS.SMT2)

}

 

Then you can compile to dsdt.aml

 

 

Blueknight, did you get SL working? What boot method did you use to get the install working...boot think? I am working on a boot123 disc and getting closer. I am able to boot and install to a SATA drive all the way to the end and then it says "Mac OSX can not be started on Disk".

 

Would you please post your modified DSDT.aml? I want to extract the DSDT from Koalala's bios, patch the DSDT and then patch back to the BIOS. The we should not need the NULLCPUPM kext.

 

dlach,

 

Your dedication to this board is becoming legendary. Thanks for all your hard work. I wish there was a way I could throw you some karma.

 

net

 

Thanks for the good karma wishes Netcastle. The main reason I'm dedicated is I have one ;^)

Seriously, I think this board is very, very close to being able to do the holy grail of vanilla install. So I keep pursuing it. Gigabyte is apparently interested in the >2GB problem (at least we keep exchanging email) and I have some hope for a new BIOS.

[blueknight]

Blueknight, did you get SL working? What boot method did you use to get the install working...boot think? I am working on a boot123 disc and getting closer. I am able to boot and install to a SATA drive all the way to the end and then it says "Mac OSX can not be started on Disk".

 

On 10.5.8, mount SL DVD and go to Terminal and type,

open /Volumes/Mac\ OS\ X\ Install\ DVD/System/Installation/Packages/OSInstall.mpkg

then SL installer starts.

So we need running OSX and anather HDD to install SL.

 

After install SL, do not reboot from SL yet.

 

We need to install Chameleon-2-RC3 manually ( package installer doesn't work well).

 

$ sudo su
# diskutil list

We can find the disk and partition which is SL installed.

In my case /dev/disk2 is the target drive and /dev/disk2s2 has SL.

 

Get Chameleon-2.0-RC3-r658-bin.tar.gz and we have "Chameleon-2.0-RC3-r658-bin" folder.

 

# cd Downloads/Chameleon-2.0-RC3-r658-bin
# cd i386

We are in "i386" folder.

 

# mkdir /Volumes/EFI
# diskutil eraseVolume HFS+ EFI /dev/disk2s1

Make mount point of hidden EFI partition and format it.

 

# fdisk -f boot0 -u -y /dev/rdisk2
# dd if=boot1h of=/dev/rdisk2s1
# cp boot /Volumes/EFI/
# touch /Volumes/EFI/.fseventsd/no_log

Install boot files to MBR and EFI partition.

 

# mkdir /Volumes/EFI/Extra
# mkdir /Volumes/EFI/Extensions

 

We' d better to place kexts and dsdt.aml in the EFI/Extra folder to keep system "Vanilla".

 

Then put the patched dsdt.aml into /Volumes/EFI/Extra and

put essential kexts into /Volumes/EFI/Extra/Extensions.

fakesmc, OpenHaltRestart, PlatformUUID, NullCPUPowerManagement

(We do not need the last one, with proper dsdt.aml ?)

 

My com.apple.Boot.plist is very simple and put it into /Volumes/EFI/Extra.

<plist version="1.0">
<dict>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string></string>
</dict>
</plist>

 

Then we can reboot from SL partition (maybe).

 

 

Would you please post your modified DSDT.aml? I want to extract the DSDT from Koalala's bios, patch the DSDT and then patch back to the BIOS. The we should not need the NULLCPUPM kext.

Here is my current DSDT.aml.

DSDT.aml.zip

[dlach]

WooHoo! Gigabyte has sent us a new bios!

 

They say it should fix the >2GB problem but unfortunately it doesn't have Koalala DSDT patch applied.

 

So someone who has a good DSDT or can extract it from the F3a bios can try this.

 

My plan is to learn how to use Koalala tool to extract from the F3a and apply to this one but don't hold your breath.

 

anyway here it is:

e7aumd2h.f4e.zip

[brownies]

Very good news, thanks dlach

[blueknight]

Thanks dlach. I tried this BIOS with 4GB memory and 10.6.1.

But memtest caused display panic as former BIOS.

[dlach]

Blueknight, thanks for trying it. It is pretty disappointing that it didn't work. I've reported by to Gigabyte perhaps they'll pursue it further. Will keep everyone posted.

 

The good news is that I've got Koalala's ACPI patch working and should be able to create a patched bios for SL soon, hopefully this weekend.

[dlach]

Hold the presses! It looks like Blueknight's test of the new BIOS may not have been valid.

 

The new BIOS has a DSDT in it so when Blueknight used his patched DSDT for SL I zm pretty sure he overwrote the new DSDT that Gigabyte put in. I think you would have to run DSDT patcher on the new BIOS without your own DSDT loaded in order to avoid this.

 

I extracted the DSDT from the new bios and can diff it and see changes in memory layouts.

 

I am going to try to create a new patched bios.

[fraatomo]

Hold the presses! It looks like Blueknight's test of the new BIOS may not have been valid.

 

The new BIOS has a DSDT in it so when Blueknight used his patched DSDT for SL I zm pretty sure he overwrote the new DSDT that Gigabyte put in. I think you would have to run DSDT patcher on the new BIOS without your own DSDT loaded in order to avoid this.

 

I extracted the DSDT from the new bios and can diff it and see changes in memory layouts.

 

I am going to try to create a new patched bios.

 

Thanks dlach

[blueknight]

It is very sad to say that I tried new BIOS without any DSDT.aml with 4GB memory on 10.5.6

but memtest made me crazy.

 

Without DSDT.aml, I can not boot Snow Leopard.

[dlach]

For any interested party with DSDT patching experience. Here are the two dsl files dsdt-new.dsl was extracted from the new Gigabyte bios. dsdt-koalala.dsl was extracted from koalala's bios.

 

I'm having some trouble compiling the new dsl with koalala's tool and will be trying DSDTSE. I had to change the extensions to .txt inorder to get the forum to let me upload them. They are text files but may need to be changed back to .dsl depending on the tool used.

dsdt_koalala.dsl.txt

dsdt_new.dsl.txt

[genzai]

For any interested party with DSDT patching experience. Here are the two dsl files dsdt-new.dsl was extracted from the new Gigabyte bios. dsdt-koalala.dsl was extracted from koalala's bios.

 

I'm having some trouble compiling the new dsl with koalala's tool and will be trying DSDTSE. I had to change the extensions to .txt inorder to get the forum to let me upload them. They are text files but may need to be changed back to .dsl depending on the tool used.

 

I was very excited to see your post and new BIOS. I really hope we can get it to work as i have one system using the DS2H and i had to remove half the memory. I have some experience working on DSDT of other boards so i may give this a try if i have time.

 

Are you still in contact with Gigabyte? If this BIOS does not fix the issue will they continue development?

Let us know if there is an email address or forum you are contacting Gigabyte with if you think we could help by making more requests for this.

g\

[dlach]

It is very sad to say that I tried new BIOS without any DSDT.aml with 4GB memory on 10.5.6

but memtest made me crazy.

 

Without DSDT.aml, I can not boot Snow Leopard.

 

Thanks for testing it Blueknight, and don't worry we both know things will be no different under SL. I was so happy when they sent it too me. Maybe they'll still fix it.

 

So the good news is that Gigabyte still engaged. They are asking if 4GB is detected on POST and/or after the OS boots. I suspect the answer for both is yes but please let me know.