Clover Problems and Solutions

[Andrey1970]

This fix causes a bug, in not dependences on existence of bad tables.

[gujiangjiang]

Why Clover cant boot on Intel Atom Cherry Trail Z8300 or Z8350.

It always shows black screen.

 

I have tried rEFInd and boot well but clover always shows black.

 

I want to know what was happend so i edit the config andd only reserve boot/rebug=ture like this:

<?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>Boot</key>
	<dict>
		<key>Debug</key>
		<true/>
	</dict>
</dict>
</plist>

And i tried to delete all the Drive64UEFI and it still in black and have nothing in CLOVER/misc,no debug.log files.

 

So i want to know how to make Clover work on this Atom platform and i only want to test and use Clover fo multilos change.

 

Thanks.

 

 

 

[cecekpawon]

This fix causes a bug, in not dependences on existence of bad tables.

Unless by not to dropping your MATS & applying this fixes still cannot help you.. I have no other words to say. Same as Slice, I dont have bad table (plus 10.13 installed) to reproduce this issues. Sorry.

During my experiment, by doing this I no longer boot with BGRT table, so it might help people with BGRT panic. Maybe by dynamically load this table by firmware it produced bad table (printing bad ascii, checksum, etc)? I really dont know..

[Slice]

ok add fix header = true  to config. now after selecting HS it is just black screen where usually optiofix driver loads. waited a bit but nothing happened.

 

This fix does not work. Black screen too.

Thanks for the reports.

I confirmed the bug and corrected it in 4128. 

Test, please!

[bronxteck]

2128 corrected the issue, slice and cecekpawon. thank you.

preboot.log.zip

[Andrey1970]

Thanks for the reports.

I confirmed the bug and corrected it in 4128. 

Test, please!

All OK! 

Thank you.

[apianti]

Why Clover cant boot on Intel Atom Cherry Trail Z8300 or Z8350.

It always shows black screen.

 

I have tried rEFInd and boot well but clover always shows black.

 

I want to know what was happend so i edit the config andd only reserve boot/rebug=ture like this:

<?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>Boot</key>
	<dict>
		<key>Debug</key>
		<true/>
	</dict>
</dict>
</plist>

And i tried to delete all the Drive64UEFI and it still in black and have nothing in CLOVER/misc,no debug.log files.

 

So i want to know how to make Clover work on this Atom platform and i only want to test and use Clover fo multilos change.

 

Thanks.

 

I have come to the conclusion that this is probably related to timing the TSC calibration. It's the first thing that happens when the log is initialized, can you build clover? Cause if you go into RefitMain() (while also tracing into other calls) and add some debug output prints to console you can determine where exactly it's getting stuck before the debug.log starts outputting. Since I see that your device is a tablet, I could see that maybe it doesn't have the timer devices that are being looked for by calibration. I had three atom devices (only down to one now) but they are all perfectly fine, one was a x5-z8300. So it must be something else to do with the specific device. I know that the CPU is not actually detected correctly but this comes after and has a pretty simple fix.

[gujiangjiang]

I have come to the conclusion that this is probably related to timing the TSC calibration. It's the first thing that happens when the log is initialized, can you build clover? Cause if you go into RefitMain() (while also tracing into other calls) and add some debug output prints to console you can determine where exactly it's getting stuck before the debug.log starts outputting. Since I see that your device is a tablet, I could see that maybe it doesn't have the timer devices that are being looked for by calibration. I had three atom devices (only down to one now) but they are all perfectly fine, one was a x5-z8300. So it must be something else to do with the specific device. I know that the CPU is not actually detected correctly but this comes after and has a pretty simple fix.

Hello,Here are my system devices.

 

Why my rEFIt can but Clover shows black screen.

 

I didnt build clover yet so how to test how cause this stuck.

 

And very thanks to your help.

 

 

从我的 iPhone 发送，使用 Tapatalk

[apianti]

Ok... Don't see how that's helpful in anyway. You need to debug clover and find out where it's hanging. The only way you can do that is by putting console print statements in the code and wherever the last that prints is where it's hanging. I don't have the ability to code/build right now...

[Slice]

Why Clover cant boot on Intel Atom Cherry Trail Z8300 or Z8350.

It always shows black screen.

 

I have tried rEFInd and boot well but clover always shows black.

84ECA9928BACF951497A9B403E569F33.jpg

 

I want to know what was happend so i edit the config andd only reserve boot/rebug=ture like this:

<?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>Boot</key>
	<dict>
		<key>Debug</key>
		<true/>
	</dict>
</dict>
</plist>

And i tried to delete all the Drive64UEFI and it still in black and have nothing in CLOVER/misc,no debug.log files.

 

So i want to know how to make Clover work on this Atom platform and i only want to test and use Clover fo multilos change.

 

Thanks.

Explain, please, again.

Where did you start your rEFIt/rEFInd? They can't be use on Hackintosh because they are not intended to boot Hackintosh.

When you started Clover how do you do this? By legacy boot or by UEFI boot choosing some option in BIOS Boot Menu? How?

Did the Clover legacy or UEFI make an attempt to start? Or you just can't choose the boot option?

After what action do you see "black screen"?

As far as I understand you can't get debug.log doing Boot->Debug=true?

[gujiangjiang]

Explain, please, again.

Where did you start your rEFIt/rEFInd? They can't be use on Hackintosh because they are not intended to boot Hackintosh.

When you started Clover how do you do this? By legacy boot or by UEFI boot choosing some option in BIOS Boot Menu? How?

Did the Clover legacy or UEFI make an attempt to start? Or you just can't choose the boot option?

After what action do you see "black screen"?

As far as I understand you can't get debug.log doing Boot->Debug=true?

Thanks slice for your reply.

 

I always use Clover on my all laptop.

These days i brought one tab use X5-Z8350 so i want to use Clover to change OS not want to install osx.

 

And the tab is only UEFI64 with no Legacy support.

 

I use rEFInd because i want to know if clover shows blackscreen what does eEFInd shows?but i test the rEFInd works well but Clover still in blackscreen.

 

I use bootx64.efi to boot into Clover or rEFInd and when i start bootx64.efi for Clover they suddenly show blackscreen with nothing show on screen.

 

So i want to debug what to cause this,so i add boot/debug=true but still in blackscreen and have no log files in misc.

 

I also tried remove some and all drive64UEFI and only use bootx64.efi but still in blackscreen.

 

So i had to ask for some help.

 

 

从我的 iPhone 发送，使用 Tapatalk

[Slice]

Exclude all drivers64UEFI. The most dangerous is CsmVideoDxe.

If you choose bootx64.efi to start it must start and the Clover (if it is) first of all created debug.log. If it placed on EFI partition formatted to FAT32.

I see no reason the Clover can't start.

[gujiangjiang]

Exclude all drivers64UEFI. The most dangerous is CsmVideoDxe.

If you choose bootx64.efi to start it must start and the Clover (if it is) first of all created debug.log. If it placed on EFI partition formatted to FAT32.

I see no reason the Clover can't start.

Yes so i want to find the reason.

The log files cant be created when the blackscreen.

 

i try to delete csm driver or the other driver64uefi but still inblackscreen.

 

Can it be stuck before the Clover application load because they have no log files.

 

Does we have any other way to find the reason?

 

My friend with Z8300 have same this blackscreen with Clover.

 

 

从我的 iPhone 发送，使用 Tapatalk

[cecekpawon]

Hey Slice, thanks for the fixes.. Do you think PatchTableHeader() in PatchAllSSDT() are still necessary, while we already have PatchAllTablesHeaders() as a final fixes for all xsdt entries?

[Wppley2]

Yes so i want to find the reason.

The log files cant be created when the blackscreen.

 

i try to delete csm driver or the other driver64uefi but still inblackscreen.

 

Can it be stuck before the Clover application load because they have no log files.

 

Does we have any other way to find the reason?

 

My friend with Z8300 have same this blackscreen with Clover.

 

 

从我的 iPhone 发送，使用 Tapatalk

I just had a similar problem a few minutes ago. After attempting to boot from the recovery HD (no success due to memory allocation problems), the two systems (S / HS) could not load anymore, not even the pen drive. I went to my other computer and removed and reloaded the OsxAptiofixdrv.efi in my pen drive and the system reloaded. I did the same with the EFI partition of the HDD, and fortunately everything went back to normal.

[Slice]

Hey Slice, thanks for the fixes.. Do you think PatchTableHeader() in PatchAllSSDT() are still necessary, while we already have PatchAllTablesHeaders() as a final fixes for all xsdt entries?

I wanted to avoid double memory reallocation.

[Zenith432]

I made bootable USB installation stick with 10.12.6.

In config.plist, KernelAndKextPatches->KextsToPatch

I have 3 custom patches

2 custom patches in AppleIntelKBLGraphicsFramebuffer (one for DP->HDMI, one for ComputeLaneCount)

1 custom patch in AppleUSBXHCIPCI to increase max port count from 15 to 26.

I know all patches are needed, because I've tested without them and things break.

So here is the thing...

All 3 patches work on regular system.

However, on bootable USB installation stick - the 2 patches to AppleIntelKBLGraphicsFramebuffer do not work (the kext does not get patched).

But the patch to AppleUSBXHCIPCI does get done!!

I checked this because

- the ComputeLaneCount doesn't work and hangs so I need IntelGraphicsFixup instead.  I checked from IntelGraphicsFixup debug prints this is the problem.

- I checked with ioreg that DP->HDMI patch does not get done (connector-type 4 instead of 8)

- However, all USB3 ports are there so the USB patch does get done.

 

Any idea what could be causing this?

The Installation stick does not have

/System/Library/Caches

but only

/System/Library/PrelinkedKernel/prelinkedkernel

 

Could this have something to do with it?  I started looking into it, but not too many regular debug prints in Clover code about what's going on.

Thanks.

[Slice]

Installer works in VESA mode. May be the kext AppleIntelKBLGraphicsFramebuffer is not used. Or somehow used with reduced functionality.

[Zenith432]

Of course it's loaded, I see it in ioreg.  I also see in ioreg that connector-type is 4 (DP), not 8 (HDMI) - so it's not getting patched.

Installer does not use IOAccelerator, but uses whatever available IOFramebuffer class works.

If I remove KBLFramebuffer from /S/L/E, installer boots ok, graphics slow and lower-resolution.  It's using some VESA IOFramebuffer (Boot/NDRV).

If KBLFramebuffer is in /S/L/E, it's being used.  graphics is full resolution and faster.  Not QE, but good framebuffer driver with hardware mouse cursor.

Also, with ioreg I see all USB ports are available, so XHCIPCI is getting patched.

I need to add debug prints to Clover custom kext patch code to see what's going on.

[Slice]

KernelAndKextPatches->Debug=YES

[cecekpawon]

Zenith432: Please double check if your "com.apple.driver.AppleIntelKBLGraphicsFramebuffer" does exists on your installer prelinked. My best guess is No, seems Apple never prelinked it (including AppleHDA and some more) in installer / recovery. Yes, I can confirm "com.apple.driver.usb.AppleUSBXHCIPCI" exists on my prelinked installer. To be sure, please compare both (prelinked on installer & installed system) with lzvn decompressor  (I have extended it to support LZSS just in case if you have this compression type): "./lzvn -d prelinkedkernel dictionary". Lilu beat Clover in this case with his "trampoline" to get survived in installer / recovery mode. I have tried this method with Clover (with helps of UEFI-Bootkit) & cc to @bs0d (of course he didnt read it) and just failed.

 

** Slice, have you read this complain about blocking kexts? In case you are interested, I have amateur poc to blocking kext cache here. Existing Clover block kext need FSInject to be installed, and no prelinked to get works.

[Zenith432]

Sorry, but where is the "installer prelinked" you are talking about? I explicitly rebuild

/System/Library/PrelinkedKernels/prelinkedkernel

on the USB stick by deleting it, and running 'kextcache -u' from regular system on the USB stick - after every change to /S/L/E on the stick.

It is the only prelinked with FakeSMC embedded, and since the USB stick boots (as long as IntelGraphicsFixup is also included) - I believe it is the correct prelinked.

I have tired this with

putting KBLFramebuffer in this prelinked and leaving it out.

putting IntelGraphicsFixup+Lilu in this prelinked and leaving it out.

So I have no reason to suspect that KBLFramebuffer is being "singled out" and being left out of the prelinked when I build it explicitly (or that I have the wrong prelinked).

However, I'll try lzvn to see what's in the prelinked later when I have time.

 

Thanks.

 

Zenith432: Please double check if your "com.apple.driver.AppleIntelKBLGraphicsFramebuffer" does exists on your installer prelinked. My best guess is No, seems Apple never prelinked it (including AppleHDA and some more) in installer / recovery. Yes, I can confirm "com.apple.driver.usb.AppleUSBXHCIPCI" exists on my prelinked installer. To be sure, please compare both (prelinked on installer & installed system) with lzvn decompressor  (I have extended it to support LZSS just in case if you have this compression type): "./lzvn -d prelinkedkernel dictionary". Lilu beat Clover in this case with his "trampoline" to get survived in installer / recovery mode. I have tried this method with Clover (with helps of UEFI-Bootkit) & cc to @bs0d (of course he didnt read it) and just failed.

[mhaeuser]

Would deffo do as cece said... unpack the prelinkedkernel and check whether the exact identifier you used is present (it probably is)... if so, only a dump of all identifiers Clover detects could be helpful (idk if that's what "KernelAndKextPatches->Debug=YES" does, I don't use Clover).

[Zenith432]

Done!

• First, I turned on KernelAndKextPatches->Debug.  In the regular system, the AppleIntelKBL... kexts get patched as expected.  In the USB stick system, only XHCIPCI gets patched.
• Then, I did as cecekpawon suggested and ran 'lzvn -d ... list' on prelinkedkernel from USB stick and... AppleIntelKBLGraphicsFramebuffer is not there   Like cecekpawon said.
• For some reason, KBLFramebuffer still gets loaded by the USB stick even though it's not in its prelinkedkernel.
• Next, I tried various options to 'kextcache -u' run offline from a regular system in order to get the USB stick prelinkedkernel to include KBLFramebuffer.  None of them worked.  I also noticed it's possible to give '-v 5' option to kextcache and it will list all kext bundles it's including in the prelinkedkernel (so spares the need to use lzvn.)
• Next, I tried another method - I booted the USB Installer stick.  Then ran 'mount -uw /' to make its root filesystem writable.  Then deleted prelinkedkernel on it, and ran 'kextcache -system-prelinked-kernel'.  I checked with lzvn that this time it includes AppleIntelKBLGraphicsFramebuffer.  Success!
• Finally, I removed IntelGraphicsFixup, Lilu, rebuilt prelinkedkernel locally on booted USB stick.  Checked it has KBLFramebuffer, but not IntelGraphicsFixup/Lilu.  Then I rebooted USB stick with patches in Clover config.plist... and all works

So that problem solved

 

In the process I discovered another bug in Clover...

See the Clover kext patch log in the photo...

 

The Clover kext patcher applies the patch meant for

AppleIntelKBLGraphics

to

AppleIntelKBLGraphicsFramebuffer

and it finds 4 instances of the hex string and patches them!  Even though patch is not meant for this kext!

Fortunately this does not cause crash that I ran into.

But it's still wrong to do.

[PMheart]

I think you may use the complete signature like com.apple.driver.AppleIntelKBLGraphics instead of simple AppleIntelKBLGraphics.

I guess, AppleIntelKBLGraphicsFramebuffer also contains "AppleIntelKBLGraphics" and thus Clover also applies relevant patches to it...