Graphics corruption @ 60hz on DP

[RDPRDP]

I woke up this morning and on a COLD BOOT thought that the USB didn't die (power LED on my mouse was active) on the first boot using OC USB tester. However, the input devices were still unresponsive. I haven't been able replicate that COLD BOOT scenario since, so for now its an anomaly.

One thing I did see a pattern to this morning, is that either on COLD BOOT or a successful reboot after booting with CLOVER into my installation (not sure which is the trigger), is that the OC boot will properly load the NVIDA drivers, and the correct screen resolution, until I reset the NVRAM (using the OC USB tester). Once the NVRAM has been reset the drivers use the built-in functionality, and the resolution is back at a lower number.


thanks,
RDP

 

[Edhawk]

What resolution are you using?

We can set a specific resolution instead of the 'Max' entry in the /OC/config.plist - UEFI > Output > Resolution, if you know the resolution you want to use.

Regarding the USB devices not working but working under Clover.

1. It won't be a BIOS issue, if it were it would effect both setups.
2. I just realised that you are using a SMBIOS for an iMac 13,2 but the USBPorts.kext is set for an iMac 13,1. This may be why the OC setup fails.
3. I just checked the CLOVER folder I downloaded previously for your setup, it doesn't contain a USBPorts.kext whereas your /OC/Kexts folder does.
4. Can you remove the USBPorts.kext and config.plist entry from the OC setup and see what happens. The XhciPortLimit entry needs to be enabled when the USBPorts.kext is removed.
5. You probably need to recreate your USBPorts.kext for the iMac13,2 system.
6. It may be as simple as changing the Mac model number in the USBPorts.kext, it occurs in multiple locations. As I don't suppose there will be much different between the iMac13,1 and iMac13,2 with regards USB ports. Other than the name!

 

[RDPRDP]

I'm fine with the resolution for now, as just getting into the system remains my priority!

So, quick update: No change.

Try 1. I changed the keys and the strings in the USBPorts.kext to 13,2 with XhciPortLimit disabled. No change.
Try 2. I removed the USBPort.kext, and enabled XhciPortLimit. No change.

I absolutely agree with you that my issue is not my BIOS as Clover USB works just by booting from Clover.

I'd also point out that back when I first went about creating my USBPorts.kext (https://www.tonymacx86.com/threads/...ort-configuration.286553/page-82#post-2140878 ), for years up until that point I hadn't used anything special for USB, and the system USB just kind of worked, but was a bit wonky (devices not being able to be hot-plugged, needing a reboot to discover). So unless OC is radically different for USB support than Clover I would expect some basic USB functionality, but as I said, the moment the Apple Logo and progress bar appears the screen, the devices turn off. I'm almost of the feeling that its an issue unrelated to USBPorts.kext and/or the port limit patch, something on a higher level. Feel free to ignore my rambling......

Regarding one of my old folders not having USBPorts.kext (your #3), that makes sense as I was using L/E and S/L/E folders for things until that point, which you corrected me on proper usage.


thanks,
RDP

 

[Edhawk]

OK, that's a shame.

I'm a bit stumped and not sure what to suggest next.

 

[RDPRDP]

Oh no! That leave me with trying to claw back to Clover then. I do have a bootable backup of the boot clover drive, however will need to carefully go back to your instructions/links to see what I wiped on the main installation drive as prep to migrate. Which funnily, even after wiping continues to work...... However, I've come so far. I'll keep my other thread open in the Hardware Troubleshooting sub-forum and see if anyone bites. However, you seem to be the top dog, so I'm not hopeful at all!!!!

For an internal sanity check I've uploaded the EFI OC folder I'm currently using. This you should be able to confirm that I hopefully didn't mess up:

1. Even though both are listed on the Sanity Check document you provided I did as you instructed and removed (you said either were ok to remove, just pick one) SSDT-SB-OC.aml from the ACPI folder, and from config.plist. Hope I did that right.

2. I updated the USBPorts.kext manually to iMac13,2 using search and replace with ProperTree. Hope I did that right.


I'm always concerned I haven't done something against your instructions and wasted your time; the most embarrassing scenario.....

OC EFI attached with MLB and Serial redacted.

I'm going to try logging now: https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/debug.html#file-swaps

UPDATE: I couldn't get the OC USB to boot after I made the changes according to the instructions above, I notice in the file I downloaded the Bootstrap folder and file were missing, which doesn't match the instructions. I've given up for now. File was DEBUG from: https://github.com/acidanthera/OpenCorePkg/releases/tag/0.6.6 , with the config.plist changes made. Maybe not the same version as what I have or, the lack of the Debug specific Bootstrap is the culprit.

thanks,
RDP

 

[RDPRDP]

Two updates:

1. Trawling though OC USB docs I found a pattern, that seems to call the mapping kext now USBMap.kext instead of Clover using USBPorts.kext. I thought this was it! I changed config.plist, and then changed the kext name, then went into the kext and replaced all the strings. It didn't work, but maybe I missed an edit somewhere, or maybe it really doesn't matter. Maybe its a hint. I attached my modified config.plist and USBMap.kext for review.

2. I notice when comparing my Clover patches that the OC config no longer patches H_EC to EC. Is that ok?


thanks,
RDP

 

[Edhawk]

I'll have a look and get back to you, if I see anything.

 

[Edhawk]

Couple of things:

USBMap.kext.
I really don't like the way your system records the USB ports. The port numbering just looks wrong.

Too many ports are identified as port <01000000>, <03000000> and similar for the EH01, EH02 and XHC sections.

The EH01 sections port-count is <01000000> (PR11) & <08000000> (EH01) when there are only 3 ports in total.
The EH02 sections port-count is <01000000> (PR21) <06000000> (EH02) when there are only 5 ports in total.
The XHC sections port-count is <08000000> when there are only 6 ports in total.

Also you are using the SSDT-EHCx-off.aml table, the same as I am in my iMac1 system. So I would expect all the EHCx devices to be shunted to the XHC controller, I would also expect all the ports to appear as either HSxx (USB2) or SSxx (USB3) numbered ports.

I am wondering if we disabled the EHC1 to EH01 and EHC2 to EH02 rename patches in the config.plist, would the SSDT do its job and move all the USB2 ports to the XHC controller? Would your USB ports then look more like mine does in Hackintool's USB tab.


Hackintool > USB tab, for my iMac1 system, with all ports on the XHC controller.

Config.plist:
You have the Kernel > Quirks > AppleXcpmCfgLock = False, the guide recommends this be set to True. If you can't disable the CFG Lock I the bios.

screenshot from config - Kernel > Quirks section.

You have the Quirk above enabled, when it is not specifically called in the guide. It is shown as being enabled in the screenshot, but not in the list of quirks to edit. The Quirk is - AppleCpuPmCfgLock=True.

Setting these two quirks incorrectly could result in a Kernel Panic.

The rest of it looks fine.

 

[RDPRDP]

Quirks:

AppleXcpmCfgLock - Tried on and off (as was set previously), and have gone back to leaving it off as I remember that I've patched my BIOS to remove CfgLock. Seems I can do some things right.....

AppleCpuPmCfgLock -I've changed it to False, with no perceived difference in operations.


USB Ports:

I tried disabling/false the patches for EHC1 and EHC2, didn't notice any change.

Find attached a grab what my ports looked like last year (Post_Install.png) once processed by Hackintool, "approved" by moderator Utter Disbelief. The conversation sort of ended up here: https://www.tonymacx86.com/threads/...to-usb-port-configuration.286553/post-2145201 . Note I have one USB2/3 port pair disabled as the physical port is damaged. PR11 and PR21 are my root ports.

NOTE: Currently when booting via Clover into my installation I also have a EHC2 listed in Hackintool (screen shot with todays date), but I'm assuming that because I've removed some files as prep for move to OC as per migration instructions. Or, it means I have another issue....., I don't see the mapping in my kext, so assume its Clover related.

 

[RDPRDP]

Success!!!! I've got my USB back, and am writing you this from the OC tester booting into my main installation.

AMAZING!

I still have a slow boot, and another few smaller issues which I will get to later in an update, but I wanted to get you this news ASAP. What a huge, massive breakthrough. Literally been at this for months, and so have you, take a bow!

What I did: Disabled SSDT_EHCx_OFF

What lead me to that: On another forum a Z79 and Z77 focused troubleshooting thread had comment from a high-level user noting "You are using SSDT-EHCx_OFF.aml which is only really needed if your UEFI BIOS cannot Enable XHC handoff". I thought to myself, wait, I think I have the hand-off enabled in my BIOS, I should put this to false. It worked! I wasn't expecting that it would outright address the problem, and made the change as more of a housekeeping effort to try and align the config, but oh my, oh my.

I'll report more soon on my continuing slow boot, and provide updated files, but for now I can advise that on first boot into the desktop I was on the built-in graphics, but easily (much more than before!) was able to use the NVIDIA driver picker and restarted into the NVIDA drivers perfectly.

wow wow wow.


thanks,
RDP