Trying to install Sequoia or Sonoma on a replacement mobo

[Henties]

@All I replaced a faulty Skylake based GA-Z170 UD3 mobo with a GA-Z170X Gaming 7 mobo but cannot get the original EFI, which worked extremely well with the ...UD3 mobo, to also work in combination with the replacement  .....Gaming 7 mobo, no matter what modifications I apply to the original opencore based EFI.

 

The hardware of the faulty board being:

 

Intel® Core™ i7-6700K CPU

AMD Radeon RX 580 8 GB GPU

4 x Kingston RAM KHX2400C12D4/16GX 16GB DIMM DDR4 2400MT/s totalling 64 GIGs

 

was tranfered to the replacement board with all working reliably when under control of Windows 11.

 

I therefore kindly request that somebody have a look at the problem EFI, being attached, and advise what possibly needs to be done to

get it working with the replacement mobo, of which the installed Bios is at version F22m.

 

Greetings Henties

 

Sorry I forgot to mention that the Bios settings, to make the replacement board hackintoshable have indeed all been applied by me.

 

EFI.zip

Edited May 1, 2025 by Henties
Forgotteninfo

[Henties]

@verdazil Oh so true, sorrry, here the details:

 

The booting progress bar, starts incrementing where after the hack either locks up or reboots. This often happens very early during the boot run-up phase but also very long there after. In other words it manifests itself during different stages of the boot process.

 

With a bootable macOS Sonoma or Sequoia USB stick, the progress bar starts advancing for quite some wheno when it finally displays the Apple prohibitive sign, which then ends the boot process.

 

Hoping this helps.

 

Greetings Henties

[Henties]

@verdazil I am trying to boot release 24E263 of Sequoia 15.4.1

I have implemented your recommended changes and also removed all the OLCP kernel entries as well as their kexts.

Booting with -v verbose mode set, now always reboots the run-up process at a line "too many corpses created".

 

The modded EFI attached.

 

Greetings Henties

EFI.zip

[Henties]

@verdaz and @eSaFI have updated OC to the latest release version being 1.0.4 Release 04 March 2025 and it passes ocvalidate for that version.

I have also applied @verdazil's latest Booter and Kernel Quirks. It seems to take longer during the boot process but still reboots with a message that says

"too many corpses created"

 

Thanks for helping me.

 

Modified EFI attached.

EFI.zip

[Anto65]

Try EFI.zip

 

I disabled SSDT-Ports something doesn't convince me
in Delete it should be like this
" Drop OEM SSDT-xh_rvp10 "
Recheck the " tablelenght " (5118) while in the drop it is 10967
Or don't use the length but use OemTableid
Try it in the meantime (if you want it like this) See if it reaches desktop

Edited May 2, 2025 by Anto65

[Henties]

@Anto65Thanks for joining.

I tried your EFI with SSDt-Ports disabled --> still rebooting

Then I tried your EFI with SSDT-Ports enabled and tablelength set to 5118 --> still rebooting

 

Not sure how to use OemTableid or what it actually is, been too long ago that I did all of this. Would be kind if you could

assist on that score.

 

Some other noteworthy discoveries:

 

I removed the SSD from the Skylake hack, with Sonoma installed and plugged it into a Comet Lake hack - GA-7490-Vision G (Bios F 22). When using the Comet Lake EFI the SSD from the Skylake hack boots properly, therefore the SSD as well as the opsys on it - Sonoma - seem OK

 

I did the same test with a bootable USB Sequoia installer:

 

With the Comet Lake EFI and on the Comet Lake platform, I can reach the "installation screen", whereas I get a "NO Entry" sign when using the Skylake EFI on the Skylake platform. This tells me that the bootable USB is intact, from which I conclude that the problem can now only be with the  Skylake EFI or some Bios setting on the Skylake hack.

 

hoping this helps you in evaluationg the possible cause.

 

Greetings Henties

 

 

 

 

[deeveedee]

@Henties Did you extract ACPI for the new board to make sure that the paths in your SSDT ACPI patches are still correct?

[Henties]

@deeveedeenot yet, temporarily disabled the ACPI path and USBPorts.kext using USBInjectAll.kext instead for the time being.

 

The replacement board is now booting after I discovered that the memory originally used in the faulty mobo suffers from compatibility problems when used in the replacement mobo.

 

Luckily I had some spare memory, albeit only 16 GB in total, as opposed to the 64 GB originally used in the old mobo. Will try to get the 4 x 16 GB working at a later stage by tweeking timings in the MIT Memory Bios section. I first need to remap my USB ports to work the way I like best, ie. in the ACPI section.

 

Everything seems to now be under control again, took me quite some hours to discover the root cause of the problem because the replacement board, the GA-Z170X Gaming 7 being 2nd hand from the far east, was initially considered the culprit.

 

Will keep this thread open for a while, at least until I managed to get my USB mapping and the 4 x 16 GB memory timings sorted out properly in order that these sticks will play properly in this mobo.

 

Greetings Henties

 

 

[Henties]

@all I have now completed the USB mapping for this replacement mobo, using my preferred ACPI method. 

 

This method requires NO kexts and only uses  a SSDT...aml  file in the ACPI folder in order to deliver it's  port mapping magic. 

 

Of cause, ignoring the "unwanted" USB declarations in the original SSDT-3-xh_rvp10.aml file, in order to stay within the macOS limit of 15 ports, has also been taken care of. 

 

Evaluation of the attached SSDT-PORTS.aml "Info" entries, within this file, reveals what this is all about.

  

For the NEWLY defined port mapping, to actually be read during the macOC startup phase, the original port declarations, embedded "somewhere" in the system DSDT, must be prevented from being  READ during the startup phase. 

 

This in turn is accomplished by an appropriate entry  in the OC-->ACPI-->Delete section, please consult the relevant section within the 

attached OC EFI folder.

 

I have attached the SSDT-PORTS.aml file, I am now using for this mobo. It works well and as intended, the contents of which also describes the actual locations of the ports I activated for my use situation.

 

For those that are interested, the EFI folder I use for this particular hack, has also been attached, which actually also contains the SSDT-PORTS.aml in the ACPI section, the particular file which I also attached hereto separately.

 

The new mobo is now almost working the way it should. The only aspect remaining is to somehow or other getting the 2 x red USB 3.1 ports working. No matter what I plug into those 2 red ports, they just remain "dead" with no device being plugged in generating any response. 

 

Maybe somebody has any suggestion how to get them working as well.

 

Greetings Henties

 

 

 

EFI.zip SSDT-PORTS.aml.zip NOT WORKING.zip IORegistry Explorer Ports as Mapped on 4 May 2025.zip

[Henties]

@verdazilFor port discovery I have indeed been using the USBMap.command tool, which only shows one controller being XHC@14, the 2 x USB 3.1 red ports are seemingly controlled by an ASmedia PXSX@0 controller, which also shows up as such in Hackintool.

It appears that the ASMedia controller must somehow be activated in Bios or EFI before these 2 ports will also work as required.

 

Your take on this one much appreciated.

 

greetings Henties

pcidevices.txt.zip

[Henties]

31 minutes ago, verdazil said:

The best solution is to configure the USB subsystem using USBMap method, without using DSDT and SSDT patches.

That's indeed what I have done.

 

Excerpts from the handbook confirm that the ASMedia controller is for SATA3 port 6 and 7 on the mobo, whereas the 2 x USB 3.1 ports

seem to depend on the proper functioning of a Thunderbolt 3 Controller, how to get that working is as yet a mystery to me.

 

Maybe you have some ideas.

 

Greetings Henties

 

[Henties]

42 minutes ago, verdazil said:

I also have 4 USB3.2 ports on the board. They work after setting up using USBMap. And without settings for Thunderbolt!

So have I on my other hacks, screenshots refer.

 

Note that the root of the USB tree for the GA-Z490-Vision G mobo is USB 3.1 based and that of the GA-Z790 D is 3.2 based whereas for the GA-Z170X Gaming mobo it is USB 3.0 based. I therefore believe that something software/configuration  wise needs to be done to get these ports to work on the Skylake hack.

 

I also used USBMap for port discovery on the other hacks, actually being quite familiar with it's workings. 

 

A controller for the 2 x USB 3.1 ports is just not discovered on the Skylake hack, with the standard 26 x ports being discovered for controller  XHC@14 and as defined within the original and unmodded SSDT-3-xh_rvp10.aml file. None of the 26 discovered ports show that anything gets connected when probing these ports during the mapping exercise, therefore something seems amiss.

 

Greetings Henties