Graphics corruption @ 60hz on DP

[RDPRDP]

I'm back with good news, the culprit preventing booting from the USB stick has been found.

Originally you mentioned I should move FakeSMC and associated kexts to the USB drive, which I did. You then recommended VirtualSMC, and were so kind to include it your Clover folder you made for me. This is what I tried booting with until recently.

Today, I re-read your messages, looking for any clues, and this jumped out at me:

"However, I would suggest you move from FakeSMC.kext to VirtualSMC.kext. FakeSMC.kext has not been updated for sometime. While VirtualSMC.kext and its associated sensor kext and efi driver are being actively developed and updated."

You suggested "move", and I wondered if perhaps there was a conflict. Deleting FakeSMC and associated kets now permits me to boot. Great!


Questions (always questions....):

"Here is a revised CLOVER folder with a few kexts removed, including USBInjectAll.kext and the Broadcom Bluetooth kexts. Hopefully these were the ones that prevented you booting with the initial revised CLOVER folder. Plus the config.plist has been edited, so the USB port limit patch is disabled."

As removal of USBInjectAll.kext and the port limit patch are good things, if I simply put back the kexts you removed between the first and second version, would that bring me back to your baseline at which point I will upload my clover folder again (to make sure I didn't goof up things too much)?


thanks,
RDP

 

[Edhawk]

You have a USBPorts.kext configured for your system, which you should have moved to the USB's /CLOVER/kexts/Other folder.

That being the case then you don't need and shouldn't use USBIjectAll.kext, as it doesn't work with a USBPorts.kext.

There are two occasions when you should use USBInjectAll.kext.

1. When you are installing macOS and using the Raise USB port Limit patches to discover your USB ports, and
2. When you have completed the USB port discovery, and choose to use an SSDT-UIAC.aml for your USB configuration settings, instead of a USBPorts.kext.

You had a number of kexts that to me seemed to be unnecessary. I would temper any want/impulse to reinstall the kexts I removed.

I would recommend you get your system up and running from your macOS Drive. Then look at which if any devices are not functioning. Then and only then do you look to add any kexts to the /CLOVER/kexts/Other folder on your macOS Drive.

Keep the booting USB drive safe for future assistance, like booting the system after an issue that locks you out of macOS.

 

[RDPRDP]

I have my main drive now booting the Clover r5119 with your folder/config. As I might have goofed something I am providing an updated zip.

Note: Before copying the Clover folder over from the USB drive I tried to install Clover r5119 on my main drive in order to downgrade as I was on r5126, and while I am now certinally booting of your config files on main main drive (as confirmed by the was APFS now loads, and that verbose is on) I still get the Clover bootloader graphics on the first screen showing me as r5126, and once OSX loads, Clover (via the menu) believes I am on r5126 as well. I'm not sure if this is an issue or not.

In regards to backup boot options, I am probably ok after being burned before as I now have:

1. Carbon Copy Cloner drive with bootable EFI partition.
2. Duplicate USB Stick with copy of same EFI partition.
3. The stick we just made now.

I can provide the L/E and S/L/E folders again if you would like, just please let me know.

In an interesting development I'd like to note that I have (by a small miracle) found a way to 100% percent of the time get my monitor to work at 60hz. I believe this verifies it is a config (vs. a cable or otherwise) issue?

To obtain success:

Monitors:
Problem monitor: LG Ultrawide 3440x1440
Working monitor: Benq 1920x1200

1. Connect both monitors.
2. Boot or Reboot.
3. When the OSX login screen comes up my LG will be garbage (as shown in my first post). My Benq will be fine (before logging a solid screen showing if set as the 2nd display, or with the login prompt if set as the primary display).
4. Turn off the power to the LG display. The Benq will flash once, but the screen basically is unchanged.
5. Turn on the LG display. It's working in 60hz.

The above process works every time.

NOTE: Next reboot requires that I perform the same power cycling to fix things; it needs the power cycle.

This means something, I'm just now sure what. Now the I can repeatably get it to work (with effort) is pleasing, as it is at least a consistent fix, rather than just sometimes.

UPDATE: After further testing it seems the power cycling at the login screen works equally to fix the issue as well with the 2nd monitor fully disconnected. I don't believe it exhibited this previously.

thanks,
RDP

 

[Edhawk]

Glad to see you have a solution for the display issue, although the power cycle trick will become a pain if you need to do that every time you boot or reboot your system. I am sure that was a 'fix' used for some systems that suffered with the black screen issue, back when we were running Mountain Lion, Mavericks and Yosemite.

Not sure what the power cycle is doing but it must be clearing/changing something relevant for your LG display.

Regarding Clover version, if it says r5126 then that is what is running not r5119. However, I would say if it works OK with the Clover folder contents you are now using then leave it be.

I don't need to see the /L/E or /S/L/E folders. I assume you have removed all the third-party kexts from these folders, and now have these kexts injected from your /CLOVER/kexts/Other folder.

What might good to see is a copy of your current Bootlog, so I can see if anything needs tweaking in your CLOVER folder and config.plist, i.e. remove any unused patches, fixes etc. The Bootlog can be obtained from the Logs tab in Hackintool. Copy and paste the log to a TextEdit document so you can compress it and attach it to a post here.

From a quick review fo your current CLOVER folder these issues need to be resolved:

1. you have SMCHelper.efi and VirtualSMC.efi present in your /CLOVER/drivers/UEFI folder. SMCHelper needs to be removed, this driver works with FakeSMC.kext so it is no longer required as you have moved to VirtualSMC.kext.
2. You can remove the verbose boot argument -v from the config.plist.
3. You need to populate the MLB option in the Rt Variables section with the Board Serial Number from the SMBIOS section.

Revised CLOVER folder and config, with the changes listed above included. Rename the CLOVER-working folder to CLOVER before use.

 

[RDPRDP]

Thanks very much. I've attached the log.

A few points on my current submission.

I used Clover Configurator to try and find where to remove "-v" to get rid of the verbose boot. I couldn't find it, so instead removed "debug=0x100", which seems to provide the desired result. Please confirm thats one and the same thing.

I copied the Board Serial Number to the MLB, no problem. I did however reinstate my original Serial Number from when we first started this process. Bad move, or ok?

Finally, I'm going to have to read up on Clover Configurator as I don't understand the way it populates checkboxes. For instance USB Inject is currently set to - , instead of being empty, or with a checkmark. I don't understand what a populated checkbox with - stands for. Off to search......

thanks,
RDP

 

[Edhawk]

"debug=0x100" is not the same as verbose mode "-v". But if your system stopped showing the Verbose text that is all that really matters.

I have never seen a Bootlog like yours before. I read about the Clover developers incorporated parts of the OpenCore system in their newest releases, but I am shocked to see such a mis-match and duplication of entries in the log. IT appears as if Clover runs and then OpenCore runs, bizarre!

• It starts of fine as a Clover compatible log, with a few minor issues.
  • Such as boot screen resolution only being 1280 x 1024.​
  • To fix this you need to add EmuVariableUefi.efi back to your /CLOVER/drivers/UEFI folder to improve the boot screen resolution.​
• It then transfers to a hybrid Clover/OC log, duplicating entries that have already been logged.
  • Changing how some entries are displayed, so you are not clear about what has been patched and what hasn't. This was specifically related to the config.plist rename patches.​

Bottom end of the thing is it takes too long to process the boot items, should be under 9 seconds probably less, it is currently running at around 15.4 seconds. You are definitely running Clover_r5126.

You would not have this mis-match if you were running Clover_r5119, as that is a pure Clover installer, which runs very stable. The Clover version you are running is a mess. No wonder so many people have jumped ship for OpenCore.

The kexts, drivers and SSDT's in your system's CLOVER folder are all loading successfully. Same goes for the ACPI rename patches. Your Over-clock SSDT gets a section all of its own, which I haven't seen before, probably because this is a hybrid log and I don't normally see OC logs of this nature.

Now do you:

1. Revert to Clover_r5119 or
2. Jump ship and switch to OpenCore.

Let me know what you want to do.

I can create an OpenCore EFI folder for your system with the information I currently hold, if that is what you want to do.

 

[Edhawk]

I have created an Ivy Bridge OpenCore EFI folder for your system, see the attached folder. With this you can choose to move to OpenCore.

If you do use the OC EFI folder I would point out the following:

1. You need to remove your current Clover EFI folder completely.
2. You need to check this Clover Conversion page and delete any items in your system, as instructed - https://github.com/dortania/OpenCore-Install-Guide/tree/master/clover-conversion
3. You may choose to use a different SMBIOS, the one in the config.plist is one I generated for you, it is new and not used by a real Mac. SMBIOS iMac 13.2, as recommended for an Ivy Bridge Hack running with a discrete graphics card.
4. If you want to run Big Sur with this folder you would need to change the SMBIOS data to a late Haswell system, iMac 15.1.
5. When you boot with this folder you will be greeted by the OC GUI not the picker list, as I have included the settings and files for the GUI in the folder. On this boot screen you will see an icon for ResetNvram.efi, you need to use this before you boot your macOS drive. To clear any left overs from the Clover boot loader installation.

I would recommend you use a spare USB to test the folder. You do not have to install anything, this is a simple copy and paste, or drag and drop scenario. Where you copy the attached EFI folder to the EFI folder on your USB.

DO NOT select MERGE if it is offered when dragging and dropping the folder to the USB drive.

I have used the SSDT's and kexts from your CLOVER folder.

Here is a link to the Sanity Check for the attached OC config.plist - https://opencore.slowgeek.com/?file=ivybridge063GJ8LbE&rs=ivybridge063

The only thing of note is the two drop table entries are set to NO/false when the checker says they should be Yes/true. The reason I set them as No/false is you have an Over-clock SSDT, which negates the need for these two entries. Yours is a mature system with a USB configuration and CPU power management, which most people don't have when starting a Hackintosh with OpenCore.

See if it works, how it works and if you have a smoother boot and running system using this process.

 

[RDPRDP]

Hello again,

I see a pattern emerging where you provide me with guidance, then go ahead and do all the hard work for me; I can't thank you enough. Given that you went ahead and prepared an OC folder for me it would be rude for me not to try to migrate.

I believe I followed your instructions (using a spare USB) including the cleanup instructions on github, and did the Nvram reset. On the github instructions some files to cleanup are on the main drive (not the EFI), so my original config no longer boots from its original state (as expected), but thats fine, I have a Carbon Copy backup I'm using now to type this.

Did it work? Yes and no:

• Used spare USB to install the EFI folder. It was a clean install.
• Booted from the spare USB, and did the NVRam reset first.
• Next boot from the spare USB took I pointed to my main drive, and it eventually did boot to the login screen. I did notice that while usually the progress bar will finish up around when it hits the mid point of the apple logo, it did take extra time to reach the far right of the progress bar.
• This is where testing ended, as none of my USB keyboards or mice work. I'm stuck. But, at least I got that far!

According to the github page, I VIEW the offending kexts:

sudo kextcache -i /

Then they are REMOVED:

sudo -s
touch /Library/Extensions /System/Library/Extensions
kextcache -i /

I don't need to do anything else for KEXTS, correct?


RDP

 

[Edhawk]

Ok, that probably means your USB config has been borked and we may need to enable the XhciPortLimit option in OpenCore, so you have working USB ports. Revised configv1.plist attached, rename it to config.plist before using. The only change between this and the first config.plist is I have enabled the XhciPortLimit option.

Not sure why your USB ports don't work as your USBPorts.kext is present in the /OC/Kexts folder and the kext is enabled in the config.plist. There are no other USB related SSDT's or helper kexts (USBInjectAll.kext) present in the OC folder.

The slow down in the boot time may be my fault, as I have included both Power Management SSDT's, Doh!

To fix this you need to remove one of these SSDT's from the /EFI/OC/ACPI folder:

• SSDT-PM.aml, or
• SSDT-SB-OC.aml

Plus the corresponding entry in the config.plist, for whichever SSDT you remove.

 

[RDPRDP]

Thanks for getting back to me. I tried your new config.plist

1. Changing the Power Management SSDT's (removing the file from the folder, and editing the plist) didn't seem to change the moving bar speed. Its not terribly slow, just a bit more than when on clover. For now, input devices continue to be the priority.

2. When the OSX login appears (I noted this in an earlier message I think), I'm at default rez, and I think due to the way the screen refreshes its using the built in graphics drivers, not the NVIDIA. Maybe I can address that once I can get logged in.

3. USB still doesn't work at all. I did verify in the config.plist than in Kernel/Quirks you turned the limit on.

Observations: USB dies as soon as the OSX boot progress bar appears. I can tell as the light on my mouse goes out. It's like the USB is completely turned off, power and everything, not just configured wrong.

And now, I'm back writing this to you booting off my backup clover boot to my main SSD installation. USB works as expected.

I wish I had better news after all your effort. Does OC have a log option we can use to watch the boot and see what might be skipped/broken, but not causing it to totally fail?


thanks so very much,
RDP