Contribute
Register

SUCCESS: Asus prime Z370-A MK II + i5-9600K + Sapphire Pulse RX 580

Status
Not open for further replies.
Totally unrelated topic, but how do you feel the build will work with VR headsets, such as the Oculus Rift? Is the rx580 powerful enough to handle it? Thanks as always.
 
Build 1
PRIME Z370-A |  i5 9600K |  RX 580 Pulse 8GB
@Aldaro,
I’m VERY HAPPY to report that your EFI folder works with the ASUS TUF Gaming Z370-Plus board with only slight modifications. In the ACPI folder, in addition to SSDT-PLUG, I added two custom SSDTs from my Clover ACPI folder: one to rename the ASM 1142 hub, ...RP03.PXSX, to XHC2, and one to define the XHC2 ports. I created a separate SSDT to rename my embedded controller, H_EC, to EC. Note: renaming H_EC was a mistake; I have switched to using a virtual EC as @Aldaro suggested two posts below. The kexts folder has a modified USBPorts.kext to inject the two XHCI hubs. I used ProperTree to redo the those two sections, changed the three values in the Platforminfo section using genSMBIOS and that’s about it.

The first time I copied the EFI folder to the USB and fired it up, it actually worked! Really liked that on reboot the BIOS chose the right device to boot from and OC chose the right option to continue the installation. So the install is now a —noInteraction event, just like creating the flash drive!

I thank you for documenting your work and supplying you EFI folder. I had multiple flash drives in play, some USB3 and some USB2, three identified as install Catalina. With Hackintool and CMD-I, it was possible to keep track of which one was which was which, but moving the OC boot to its own flash drive, as you strongly suggested, is high on my todo list.

Thank you again for your excellent post. I cannot thank you enough. Wished you lived closer: I’d take you out for dinner.
 

Attachments

  • EFI-6.3.zip
    1.8 MB · Views: 65
Last edited:
Previous system
GA-Z97X-UD3H |  i5 4690 |  GeForce GTX 650 Ti
Current system
TUF Z370-PLUS GAMING |  i5 8400 |  RX 570 Pulse 8GB
Aldaro said:
Yeah I was referring to UEFI, and it looks like you have that set up correctly.

I have to be honest, I'm not too familiar with setting up an iGPU only config on this board, as I've always had a dGPU to go with it, but based on info for the PRIME Z390-A (which is similar of course) hackintool has this prebuilt patch. It'll need to be modified to fit this board, but I think this should get you closer. I know there's a lot of needless values thrown in here, but I wanted to leave everything as is.

Code: 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
    <dict>
        <key>AAPL,ig-platform-id</key>
        <data>BwCbPg==</data>
        <key>AAPL,slot-name</key>
        <string>Internal@0,2,0</string>
        <key>device-id</key>
        <data>mz4AAA==</data>
        <key>device_type</key>
        <string>VGA compatible controller</string>
        <key>enable-hdmi20</key>
        <data>AQAAAA==</data>
        <key>framebuffer-con0-busid</key>
        <data>AgAAAA==</data>
        <key>framebuffer-con0-enable</key>
        <data>AQAAAA==</data>
        <key>framebuffer-con0-index</key>
        <data>AgAAAA==</data>
        <key>framebuffer-con0-pipe</key>
        <data>CgAAAA==</data>
        <key>framebuffer-con0-type</key>
        <data>AAgAAA==</data>
        <key>framebuffer-con1-enable</key>
        <data>AQAAAA==</data>
        <key>framebuffer-con1-index</key>
        <data>AwAAAA==</data>
        <key>framebuffer-con1-pipe</key>
        <data>CAAAAA==</data>
        <key>framebuffer-con1-type</key>
        <data>AAgAAA==</data>
        <key>framebuffer-con2-busid</key>
        <data>AQAAAA==</data>
        <key>framebuffer-con2-enable</key>
        <data>AQAAAA==</data>
        <key>framebuffer-con2-index</key>
        <data>AQAAAA==</data>
        <key>framebuffer-con2-pipe</key>
        <data>CQAAAA==</data>
        <key>framebuffer-patch-enable</key>
        <data>AQAAAA==</data>
        <key>hda-gfx</key>
        <string>onboard-1</string>
        <key>model</key>
        <string>Intel UHD Graphics 630 (Desktop 9 Series)</string>
    </dict>
</dict>
</plist>

If possible, I'd try to grab a dGPU, as it'll make your life a lot easier. If you don't need much in the way of GPU performance, something like the RX 570 is more than enough, and will definitely be a huge upgrade over the IGPU. I'd stick with the Sapphire pulse variant of this card, as it seems Apple model'd their polaris drivers after the VBIOS found on the Pulse lineup of cards for the Radeon RX 4xx/5xx series.
Click to expand...
Hi @Aldaro,
Unfortunately, that way I've already tried before. But I have an update. I posted it in my own thread: https://www.tonymacx86.com/threads/...-os-graphic-doesnt-smooth.307403/post-2208715
Since you have the same CPU, could you please share your ioreg version? Thanks in advance.
 
@Starry48
Thank you so much, and I'm glad things are working! When it comes to your SSDTs, SSDT-UIAC is specific to USBInjectall.kext as per the name; UIAC = USBInjectAll configuration. At a quick glance through the SSDT, it seems like a standard configuration SSDT for USBInjectAll; so, it wouldn't be doing anything on your system, as I don't see that kext being loaded.

Correct me if I'm wrong, as I may very well be looking at the wrong ACPI tables, but I still have your origin folder on my system, and when looking through the DSDT, I saw the following for H_EC
Code: 
        Device (H_EC)
        {
            Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */)  // _HID: Hardware ID
            Name (_UID, One)  // _UID: Unique ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                ^^^GFX0.CLID = 0x03
                Return (Zero)
            }
As per one of RehabMan's old posts, in this example, you don't want to rename H_EC to EC, as the device was left inactive by the OEM for a reason. The best course of action would be to use a simple fake EC SSDT
Code: 
DefinitionBlock ("", "SSDT", 2, "hack", "_EC", 0x00000000)
{
    Device (_SB.EC)
    {
        Name (_HID, "EC000000")  // _HID: Hardware ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (_OSI ("Darwin"))
            {
                Return (0x0F)
            }
            Else
            {
                Return (Zero)
            }
        }
    }
}
I also updated to OC 0.6.4 recently and will attach the new EFI to the thread. I keep backups of all previous versions on my HDD; so, if anyone notices regression, I can always repost the old folder.
 
@Aldaro

Many thanks for figuring our that the H_EC device wasn't what I thought it was. I saw the ^^^GFX0, but had no clue what it meant. I'm using the igp in headless mode, so using it maybe OK, but I'll change it anyway. I can simply use the code you provided. What does ^^^GFX0 mean?

Today I started trying to migrate from 0.6.3 to 0.6.4. If you post your config.plist That would be appreciated. I'm still in catchup mode. Of course, today I found the guide for migration from Clover to OC. With all my installs I pretty much cleaned out my /etc hacks.
 
Previous system
GA-Z97X-UD3H |  i5 4690 |  GeForce GTX 650 Ti
Current system
TUF Z370-PLUS GAMING |  i5 8400 |  RX 570 Pulse 8GB
@Starry48
What does ^^^GFX0 mean?
Click to expand...
Ignoring the "^^^", GFX0 refers to your IGPU. By sharp contrast, Apple uses GFX0 to represent a PCIe GPU, and IGPU to represent the IGPU in their ACPI tables. In the past, we'd use patches like "Rename GFX0 to IGPU" and "Rename PEGP to GFX0" in order to work around this problem, but said patches are no longer relevant since WhateverGreen already takes care of this.

I just posted my 0.6.4 folder as well and in the process, I realized a massive oversight on my 0.6.3 folder I'd previously uploaded in November. I left drop xh_rvp08 enabled in the OC config; so, things probably did not work out too well for many people.

I always use my current EFI folder as the base for what gets uploaded here; only changing the SMBIOS info, re enabling USBInjectAll + port limit patch, and disabling SSDTTime patches.
 
@GoodBoris
Sorry it took me so long to reply to your comment. Given the different configurations (i.e headless vs primary) I do not think this'll be helpful, but here's an example from my IOReg.
Screen Shot 2020-12-23 at 8.18.58 PM.png
 
Aldaro said:
@Starry48
Thank you so much, and I'm glad things are working! When it comes to your SSDTs, SSDT-UIAC is specific to USBInjectall.kext as per the name; UIAC = USBInjectAll configuration. At a quick glance through the SSDT, it seems like a standard configuration SSDT for USBInjectAll; so, it wouldn't be doing anything on your system, as I don't see that kext being loaded.
Click to expand...
This morning I decided to see if not loading the SSDT-UIAC.aml was actually necessary, and it turns out it isn't needed at all. So I guess I didn't understand things as well as I thought I did. So, now I have just a rename pf the PXSX device to XHC2, not required but simple to do. And yes, once you've finish port mapping, both setting up the used ports in the ACPI section and the USBInjectAll.kext are superfluous.

I do have a question for which I've found no answer: when ports are dropped, I still assign the used ports the actual port number which the have in the schematic. On your board and mine the first port used is HS03 which is at address 0x03, and the SS03 is at physical port 0x13. Looking at the IOReg map, HS03 shows up at 0x14100000, not 0x14300000! It's working, but I'm scratching my head as to how it's possible. Do you have an explanation?

Thank you!
 
Previous system
GA-Z97X-UD3H |  i5 4690 |  GeForce GTX 650 Ti
Current system
TUF Z370-PLUS GAMING |  i5 8400 |  RX 570 Pulse 8GB
Spent a while trying to figure out the easiest way to setup the XHC and XHC2 devices. While they both were working, all approaches to actually define the XHC2 device failed: I still saw the device as defined by the ACPIExpert in IORegistryExplorer. Today, I gave the approach advocated by OpenCore Group in Dortania's Post-Install guide. The key thing I learned is that the code to disable macOS from trying to autodetect my hubs was that the blocking needed to happen at the RHUB device just below XHC and XHC2. The process works like this: (1) rename any hubs that have funky names (Mine was named _SB.PCI0.RP03.PXSX. There were approximately 20 RP devices, each of which had a child called PXSX). The tool will tell you which hubs need renaming. (2) block macOS from doing its auto detection on the associated RHUBs, and (3) inject the right values for port number, name and usbConnector using a custom plist in USBMap.kext. There is a Python script that will generate the SSDT-RHUB-Reset.{dsl,asl} files, and the USBMap.kext. The Info.plist in the kext needed some TLC to get the pins properly defined, but the end result was that now the hub attached to RP03 shows up in IOReg looking just like XHC. Not only that, but both hubs are now listed in Hackintool.

@Aldaro, I got your method for defining XHC working, but to eliminate unused ports, I had to also change the location to Nil. This was also done with the USR ports. I left it in the zip in case you wanted to see it.
 

Attachments

  • EFI-6.4-1229.zip
    1.9 MB · Views: 62
  • XHC2 defined via USBMap.kext.png
    XHC2 defined via USBMap.kext.png
    227.1 KB · Views: 75
  • Hackintool USB Hub display.png
    Hackintool USB Hub display.png
    171.9 KB · Views: 63
Previous system
GA-Z97X-UD3H |  i5 4690 |  GeForce GTX 650 Ti
Current system
TUF Z370-PLUS GAMING |  i5 8400 |  RX 570 Pulse 8GB
Spent a while trying to figure out the easiest way to setup the XHC and XHC2 devices. While they both were working, all approaches to actually define the XHC2 device failed: I still saw the device as defined by the ACPIExpert in IORegistryExplorer. Today, I gave the approach advocated by OpenCore Group in Dortania's Post-Install guide. The key thing I learned is that the code to disable macOS from trying to autodetect my hubs was that the blocking needed to happen at the RHUB device just below XHC and XHC2. The process works like this: (1) rename any hubs that have funky names (Mine was named _SB.PCI0.RP03.PXSX. There were approximately 20 RP devices, each of which had a child called PXSX). The tool will tell you which hubs need renaming. (2) block macOS from doing its auto detection on the associated RHUBs, and (3) inject the right values for port number, name and usbConnector using a custom plist in USBMap.kext. There is a Python script that will generate the SSDT-RHUB-Reset.{dsl,asl} files, and the USBMap.kext. The Info.plist in the kext needed some TLC to get the pins properly defined, but the end result was that now the hub attached to RP03 shows up in IOReg looking just like XHC. Not only that, but both hubs are now listed in Hackintool.
Click to expand...

Hmm, okay; I know the RHUB reset method is pretty much mandatory for 10th gen systems, but I've never faced this issue myself, or at least to a degree in which going through this process was required. Thank you for posting your solution, it's greatly appreciated!

I've also finally upgraded to Big Sur as my daily driver since the bugs I was experiencing, even on real Macs, were resolved with the 11.1 update.

Lastly, with the release of Apple's M1 Macs, I recently put together what'll be my hackintosh swan song to close the x86 era with something really powerful. The build is rocking an i9 9900k, 32 GB 3200 MHz RAM, and a 5700 XT. Cooling the i9 has proven to be quite the challenge though, and until I get temps that I'm comfortable with, I'm not going to do a build thread for it yet. For this new build, I went with the mATX form factor, because I wanted something a little different.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top