Hackintosh Journey on a Lenovo Yoga 720

This is a record of my effort to convert a Lenovo Yoga 720 15IKB into a hackintosh (10.15.6) in the hope to find some feedbacks if you happened to have a similar setup as I ran into several problems (poor NVME performance from the original Intel 600p SSD, and fail to make ELAN 0651 touchpad work).

My model: Yoga 720, 15ikb, Intel Core i7–7700HQ, SSD: INTEL SSDPEKKW256G7 (Intel 600p). 8Gb ram. $300 from craigslist, touch screen not working under Windows 10. Bluetooth/wifi bcm94360 ($43 from eBay).

Lenovo Yoga 720 running Hackintosh

It took a lot of work in making things work, I would probably skip this deal if I know that in advance. Part of it is the learning curve of OpenCore, which is the new bootloader for Hackintosh.

I started by following the OpenCore installation guide. Highly recommended to read carefully the guide several times. Currently, the Hackintosh is semi-working, with Bluetooth mouse and keyboard and good HD screen except for the NVME issue and trackpad.

Update (25/9/2020): NVME issue solved by switching to a Western Digit SN750, touchpad fixed partially with an SSDT patch disabling an I2C device causing the boot problem.

Update (11/7/2020): This has become one of my daily work-from-home computer for quite a while, most of the time works perfectly with a magic mouse. Trackpad usually works after a reboot but could lose response if not using(yes, the trick is to keep using it), the click does not have the same behavior as a native MacBook pro trackpad. Overall it is fast, cool, draining about 10 watts with half brightness. (VoltageShift helps, I was able to use a setup voltageshift offset -150 -150 -150). Easily get 4–5 hours of screen life from the original battery.

Update (1/22/2021): Upgraded this to a Big Sur. First upgraded Opencore to 0.6.5, updated the lilu, then disable the VoodooInput from VoodooPS2 package (to avoid kernel panic as VoodooI2C and VoodooPS2 both provide the VoodooInput). Then use the Software Update to upgrade. The computer rebooted a couple of times and Big Sur is up.

Update (5/1/2021): Upgraded this to Big Sur 11.3. USB port, Bluetooth, and camera stop working. Find a solution in this post. Change this in the config.plist to the devices works again:

<key>XhciPortLimit</key>
<true/>

To:

<key>XhciPortLimit</key>
<false/>

Bios Setting:

Unlike more professional models like Thinkpad, Yoga 720 has surprising fewer options to play within the Bios. Main configurations are:

1. SATA Controller mode: AHCI (Default is RAID)
2. Intel Virtual Technology: Enabled (DisableIoMapper = Yes in config.plist)
3. Thunderbolt Device Boot Support: Disabled
4. Intel Platform Trust Technology: Disabled
5. Intel SGX: Disabled
6. Secure Boot: Disabled
7. Boot Mode: UEFI

Audio: ACL236 (alcid=16, however, the sound is having glitching issues, could not be fixed by changing layout id, and related to the NVME SSD see below).

Bootup Troubleshooting: (covered by the OpenCore troubleshooting)

1. Stuck on no vault provided!Security->Vault to Optional in the config.plist

2. Stuck on [EB|#LOG:EXITBS:START]: The motherboard does not have MATs, checked the OpenCore log:OCABC: MAT support is 0. So need this setting in the config.plist:

• Disable both RebuildAppleMemoryMap and SyncRuntimePermissions then enable EnableWriteUnprotector.

Main issues:

Touchpad not working

The research point to VoodooI2C, however, following the troubleshooting from OpenCore document is not enough to solve this problem.

1. VoodooI2C + VoodooI2CHID cause kernel panic at boot time
2. VoodooI2C + VoodooI2CELAN report: invalid report error.

It may require additional hacking on DSDT suggested in the VoodooI2C.

Random Boot failure (mainly associated with some slide values)

In the beginning, the system only occasionally boot. Often stuck and output “Image failure”. This is annoying as it could take several reboots to finally able to boot up correctly.

It turns out to be the bad slide values, removing nonessentials kexts and turning off never used functions in Bios did help a lot (successful booting rate from 20% to 90%). Fixed the slide value (slide=0) in the boot arguments will do the job.

Poor NVME performance

I got a very poor performance from the original intel NVME SSD and kernel panic when turning off the computer which is also related to the NVME. Below are two DiskMark results. After a fresh boot, the sequential read seems reasonable, random 4k read is already bad. After some light usage, the reads drop dramatically. Please let me know if you have any suggestions to fix this.

DiskMark after a fresh boot

DiskMark after some usage

Another related issue is sound glitching, which happens when there are some disk IOs working in the background. Below is the kernal panic when reboot or shut down the computer. I also tried the NVMEFix.kext but enable the kext will cause the laptop to freeze shortly after bootup.

Updates on the NVME issue (9/25/2020)

I swapped the original intel 600p NVME with a WD SN750, which was recommended here and the kernel panic never show up.

Random 4k IO not at the expected level with WD SN750.

Main Hacks:

CFG unlock

Follow the instruction of https://dortania.github.io/OpenCore-Post-Install/misc/msr-lock.html. I know that my computer has LOCKED MSR E2. Then I need to download the Bios Firmware from the Lenovo website, however, it is .exe file. This post suggests using 7-zip or Universal Extractor. I was able to extract the .ROM file with Universal Extractor.

UEFITool is not able to read .ROM file, using another tool suggested https://github.com/LongSoft/InsydeImageExtractor/releases/tag/v0.2, I converted the .ROM file into .bin file that can be recognized by UEFITool, then find the “offset” to be 0x3C. However, using the modified Grub Shell can not unlock the MSR, as point out in the last paragraph of the instruction. This computer falls into the category that ‘Some OEMs like Lenovo may have the variable set but cannot unlock it without physically modding the BIOS’. And the solution is a tool called RU, with instruction here. My offset is exactly the same as used in the instruction. Be very careful if you are going to do this. There is a risk to brick the laptop. At some moment I thought the laptop is dead, after just booting RU without any modification. Fortunately, I opened the back cover and disconnected and reconnected the battery, the laptop was able to boot up again.

Updated: Fixed with RU can not survive after a Bios reset to default operation. So better keep the USB drive ready somewhere in case you need it. (or have a bootable USB disk with OpenCore settings that are functional when the CFG is locked, i.e. AppleCpuPmCfgLock and AppleXcpmCfgLock set to Enabled).

Touchpad

I was able to have the touchpad working (One time only) with VoodooI2C and VoodooI2CHID after the CFG unluck. Then it stops working after I reboot, reporting a kernel panic when setting up Accelerometer from VoodooI2CHID. So VoodooI2c + VoodooI2CHID seems the way to go. (at lease one success that never reproduced again). Again, kindly give me a feedback if you have experience with it. Thanks.

Progress update on the Touchpad (9/23/2020)

I was reasoning why the only one success boot with VoodooI2CHID fail to reproduce. The only success happened before I fixed the boot-arg slide=0. The kernel panic was related to

__ZN28VoodooI2CAccelerometerSensor13setPowerStateEmP9IOService

However, after I switched to slide=0, it starts with a different kernel panic, related to

__ZN10VoodooGPIO23intel_gpio_irq_set_typeEjj + 0x71
__ZN10VoodooGPIO15enableInterruptEi + 0x49

So it is possible that before I fixed slide=0, when slide value was randomly chosen at bootup, some slide value actually allows either a success boot or reproduce the kernel panic with AccelerometerSensor. To test this hypothesis, I edited the config.plist and change the slide=1. Boom! it worked, I was able to get the Touchpad working again.

So the recipe seems to be VoodooI2C + VoodooI2CHID + slide=1

But wait a second, does this survive a reboot? Sadly, No. Reboot, and Boom, kernel panic with AccelerometerSensor. Maybe I can change the slide again said slide=2, no luck, same kernel panic.

Let’s take a step back, it seems that when we have slide=0, the I2C device somehow not like the setup (maybe a memory map issue), but with slide=1, we was able to avoid that region and get AccelerometerSensor kernel panic or a successful boot.

Then it is puzzling that the successful boot followed with bad boot, it seems that there is a state of the I2C device that got toggled. Let’s call this state S. Since now I have a second success boot, it means that between these two success boot, the state was toggled into a state that when I switched from slide=0 to slide=1, it allowed a success boot (let’s say when S=1 it allowed a success boot with usable Trackpad, S=0 triggers AccelerometerSensor kernel panic). However, a success boot will toggle the state back to 0.

Again, to test this hypothesis, we need to reproduce such kind of behaviours, meaning we need to reset the S = 1, but how?

One possibility is that if I boot up with ubuntu or windows, the I2C device state maybe reset, so I can reproduce the success boot. So I booted into a Ubuntu USB disk, then restart, clean NVRAM, boot with slide=1. No luck, so booting into Ubuntu does not help. Another candidate operation is boot with VoodooI2c + VoodooI2CHID + slide=0, we know it leads to kernel panic, but it may reset the state. So let’s try this.

I was able to do this in a few times:

1. VoodooI2c + VoodooI2CHID + slide = 0 , kernel panic
2. slide = 0 (without VoodooI2c) success boot, no trackpad.
3. clean NVRAM
4. VoodooI2c + VoodooI2CHID + slide = 1, success boot, with trackpad.
5. VoodooI2c + VoodooI2CHID + slide = 1, AccelerometerSensor kernel panic

6. Back to 1.

This protocol seems quite promising, until I leave the computer for idle for some time after a success boot (step 4), and the trackpad was not responsive after the idle (no sleep actually). And I have trouble reproducing it.

So here is the current status: trying to reproducing the booting circle which should be useful for future hacking. There seems a hidden state maybe save in the I2C device that interfere with the loading of VoodooI2C kexts.

After a few circles trying, I tried several times in step 4 and get some lucks. And it seems that several tries on step 4 will actually toggle the state, and it was clear now that the kernel panic happened when initializing the I2C sensor hub(NPCE0388). This give me some hints that if I can disable this device somehow, I maybe able to have it boot correctly.

SSDT to disable the I2C0

I have very limited knowledge of DSDT and SSDT, only experiences come mostly from reading OpenCore documents. I took the example SSDT file which disable the EC as the template and modified it to disable the I2C0 device (using the original DSDT file as reference to make sure the naming are correct). The resulting file looks like this:

Compile and add it to EFI/ACPI and updated the config.plist. Now I boot with VoodooI2C + VoodooI2CHID + slide = 1 successfully without going through the circles.

That is a good step forward. Except for one new problem, the trackpad will stop working randomly (maybe similar to this).

Finally, the OpenCore EFI to boot or install is available here.