Contribute
Register

[Guide] Lenovo Z50-70/Z40-70/G50-70/G40-70 using Clover UEFI

I made two PRs for two different codecs discovered (so far) with the Probook guide.
I gave up waiting for a build and just included my fixed build in the repo.
When a new build appears with the fixes, I'll remove my build and download theirs.
I made my own build too and I've been testing it. But I prefer to wait for an official release so that I can avoid uploading pre-built binaries to the repo when it is supposed to contain pure code.

BTW, you might want to take a look at some of the recent additions to my hack-tools github project.
I added a LiluFriend generator (and a second technique of my own, LiluFriendLite).
Although I'm not 100% convinced LiluFriend is required, vit9696 recommends it when you install Lilu kexts to /L/E or /S/L/E.
The script automatically scans for Lilu-based kexts that are installed and sets up the OSBundleLibraries dependencies that match.

LiluFriend.kext has always confused me. I've never encountered any problems with Lilu and its plugin kexts installed to /L/E so I've never really felt I needed LiluFriend.kext.

However, I can see that your LiluFriendLite.kext is a codeless kext (Info.plist only), and my understanding is that it has to be regenerated every time we want to install a new Lilu plugin, right?

Also, do you still think it's a bad idea to have the required kexts injected by Clover instead of installing them to system locations?
 
Your ioreg still shows alc-layout-id=2 for HDEF.
Are you sure you attached a new ioreg?
I think I did. Just in case I rebooted the computer. I am sending you the ioreg again and also the only SSDT file in the patched folder. Thanks again
 

Attachments

  • Javier’s MacBook Pro.zip
    508 KB · Views: 68
  • SSDT-G50.aml.zip
    4.4 KB · Views: 78
LiluFriend.kext has always confused me. I've never encountered any problems with Lilu and its plugin kexts installed to /L/E so I've never really felt I needed LiluFriend.kext.

Yeah, same here, but I had some suspicious stuff happening with one user with a NUC8, and even myself had a KP that magically cleared up after a boot with -liluoff and rebuild cache/reboot, that made me think that LiluFriend might be needed.

However, I can see that your LiluFriendLite.kext is a codeless kext (Info.plist only),

Yes. It seems like the effect should be equivalent, since the LiluFriend class does nothing more than IOService. Similar to the Disabler kext code where it wasn't really necessary (a codeless kext works for disablers too).

and my understanding is that it has to be regenerated every time we want to install a new Lilu plugin, right?

It has to contain references to each Lilu plugin (and Lilu itself) in its OSBundleLibraries dictionary, so yes, any change to the set of Lilu kexts installed results in a change to the LiluFriend (or LiluFriendLite) Info.plist. This is why I install all kexts first (with a cache rebuild), then generate LiluFriendLite, then install it, then rebuild cache again. It is quick and easy with the create_lilufriend.sh script.

Also, do you still think it's a bad idea to have the required kexts injected by Clover instead of installing them to system locations?

Yes. Some kexts don't work well when injected (some don't work at all).
It is also next to impossible to verify that the set of kexts a user has in EFI are compatible with each other. The output of kextcache provides excellent diagnostics of user mistakes/mismatches.

I tend to use injection early in the development process especially if I'm testing across multiple versions (recently tested the NUC8 with 4 different macOS versions, tweaking things here and there, and it was handy to have everything on USB, and injecting kexts from there as I was updating them, and testing with each of the 4 versions of macOS).

Then when I finalize, I install everything to /L/E.
 
I think I did. Just in case I rebooted the computer. I am sending you the ioreg again and also the only SSDT file in the patched folder. Thanks again

IOACPIPlane HDEF clearly shows layout-id 2. So does IOService:HDEF:alc-layout-id.
Make sure you're generating a new ioreg, not opening an existing one you already saved.

Check for any HDA "enabler" kexts you may have installed.
 
Last edited:
Yeah, same here, but I had some suspicious stuff happening with one user with a NUC8, and even myself had a KP that magically cleared up after a boot with -liluoff and rebuild cache/reboot, that made me think that LiluFriend might be needed.



Yes. It seems like the effect should be equivalent, since the LiluFriend class does nothing more than IOService. Similar to the Disabler kext code where it wasn't really necessary (a codeless kext works for disablers too).



It has to contain references to each Lilu plugin (and Lilu itself) in its OSBundleLibraries dictionary, so yes, any change to the set of Lilu kexts installed results in a change to the LiluFriend (or LiluFriendLite) Info.plist. This is why I install all kexts first (with a cache rebuild), then generate LiluFriendLite, then install it, then rebuild cache again. It is quick and easy with the create_lilufriend.sh script.



Yes. Some kexts don't work well when injected (some don't work at all).
It is also next to impossible to verify that the set of kexts a user has in EFI are compatible with each other. The output of kextcache provides excellent diagnostics of user mistakes/mismatches.

I tend to use injection early in the development process especially if I'm testing across multiple versions (recently tested the NUC8 with 4 different macOS versions, tweaking things here and there, and it was handy to have everything on USB, and injecting kexts from there as I was updating them, and testing with each of the 4 versions of macOS).

Then when I finalize, I install everything to /L/E.
I see. I think I will use your technique (LiluFriendLite.kext). I ask for your permission to borrow some ideas from your create_lilufriend.sh script to add to my macos-tools project.
 
I see. I think I will use your technique (LiluFriendLite.kext). I ask for your permission to borrow some ideas from your create_lilufriend.sh script to add to my macos-tools project.

Sure, as long as you show credit to original source.
 
IOACPIPlane HDEF clearly shows layout-id 2. So does IOService:HDEF:alc-layout-id.
Make sure you're generating a new ioreg, not opening an existing one you already saved.

Check for any HDA "enabler" kexts you may have installed.
I think this is a new ioreg.
 

Attachments

  • Javier’s MacBook Pro.zip
    510.7 KB · Views: 65
RehabMan, I found AppleHDA.kext in SLE. Should I erase it?
 
Back
Top