Contribute
Register

[Guide] Lenovo Yoga 3 14 [Broadwell, HD5500]

Status
Not open for further replies.
S

sheg0

Guest
Hey folks,


heres my first guide for the Lenovo Yoga 3-14.
It has:

  • Core i5-5200U Processor
  • 8 Gb RAM
  • Intel HD5500 and Nvidia 940m
  • FHD Touchscreen (works oob)
  • Intel Wireless AC-3160
  • 250 Gb Samsung SSD
Like most of you will know, the Intel Wireless Card won´t work on OS X at least for wifi. So far i added a TP-LINK TL-WN725N USB-Dongle which works fine for me.

After this guide you have a working El Capitan with:
Backlight control including keys, keyboard, touchpad with multitouch, sound, wifi, usb, CPU power management, battery status, sleep, touchscreen and almost 4 hours battery time.


First thing to start is the BIOS settings:
This guide is for BIOS Version BACN95WW. I don't know what will be changed in future updates. So if you experience problems with this guide flash back to this version (Allow flashback option must be enabled).
Related settings for this guide:


  • Graphics Mode -> UMA only
  • Intel DTPF -> enabled
  • Boot options -> Legacy but UEFI first
  • USB Boot -> on
  • Load optimized OS settings -> disabled
All other settings are left untouched from the original configuration (and i think they don't matter that much).

Second step: Get the installer working.
Strictly follow RehabMans guide on [Guide] Booting OS X installer on LAPTOPS with Clover.
In my configuration i used FakeSMC, VoodooPS2Controller and GenericUSBXHCI kexts on the USB-Stick.
Take the config_USB-INSTALL.plist as your config.plist on the usb stick.
Install OS X and make sure you have the Clover Install Package somewhere on an USB Dongle.
After the installation install clover to your harddrive and take note on the advanced settings (Install RC-Scripts on so on) from RehabMans Guide. Replace the default config.list with the one from the install stick.
First kext you want to do is to install
FakeSMC using Kext Wizard.
After this install
VoodooPS2Controller according to the manual on GitHub.
Then install USB-Inject-All and the kexts from AppleHDA.zip

You should now be able to boot from your hard drive.

Third step: Post-Installation
To get the WLAN working install the driver from TP-Link.zip in the attachment and reboot. You should then see the wireless configuration in the status bar.
To get the HD5500 working change the config.plist in your EFI-Partition to
config_POST-INSTALL_FIRST.plist and boot on time without caches by pressing space bar in clover.
At this point following things should work:
Graphics, WLAN, Booting from SSD, Sound including buttons and USB.

Fourth step: Patching your ACPI implementation.
Carefully read the [Guide] Patching LAPTOP DSDT/SSDTs to understand what each step in the next section does and may be able to resolve errors yourself.
After this extract your ACPI tables using a Linux distribution. I used Xubuntu 14.04. Extract DSDT, and SSDTs 1 - 11.
After this create two folders. In one folder you place all extracted files except SSDT-4 and in the other folder all extracted files except SSDT-5. After this you disassemble both folders using the provided refs.txt.
Copy all the DSL-files to one folder (and just replace duplicates) and we can begin with the patching process. Next section describes all patches applied to the files.
First of all set your compiling ACPI level to 5.0 and then add PJALM-, and RehabMan-repositories.
Apply the patches in following order:
DSDT:
from RehabMan:
ADGB Error
Remove _DSM
Fix _WAK Arg0 v2
HPET
SMBUS
RTC
IRQ
OS Windows 8
Shutdown v2
Mutex non zero
PNOT/PPNT
_WAK IAOE
usb3_pwr 0x0D
from SourceForge:
InsertDTGP
from PJALM:
Generic fixes -> after this compile and fix the error by renaming _SB.PCI0.SAT0 to _SB.PCI0.SATA
LPC
USB Power
SSDT1:
should compile without patches.
SSDT2:
from PJALM:
Generic fixes
SSDT3:
from PJALM:
Generic fixes
SSDT4:
By first compiling you´ll get a scope-error for _SB_.PCI0.XHC_.
Fix this by moving the first line containing _SB_.PCI0.XHC_.DUAM from the top under the first line with _SB_.PCI0.XHC_.
from PJALM:
Generic fixes -> and SAT0 to SATA like in DSDT.
SSDT5:
Same procedure as SSDT4.
SSDT6:

from PJALM:
Generic fixes
SSDT7:
from RehabMan:
remove _DSS Placeholders
SSDT8:
should compile without patches.
SSDT9:
You´ll get some scope errors regarding PCI0 fix them by moving the declarations from refs.txt on top in under the first PCI0 scope like you did with XHC_ in SSDT4.
SSDT10 and SSDT11:
should compile without patches.

Lets get to some device specific patches now:
Battery:
Patch your compiling DSDT with the attached
Yoga3-14_BatteryStatus.txt. After this install RehabMans ACPI-Battery-Driver kext from here.
Backlight Brightness:
Patch the DSDT with RehabMans Brightness-fix for Haswell and Broadwell.
Uncomment the line above the error line when compiling.
After this apply GFX0 to IGPU patch to your DSDT and SSDT9.
Last of all patch DSDT with the provided
Yoga3-14_BacklightKeys.txt and install the Intel-Backlight kext from here.

After all this patching, place the compiled ASL-files to CLOVER/ACPI/patched in your EFI partition and change the config.plist to the provided config_FULL.plist. After this add the SSDT from the attachment into the ACPI folder for working CPU-PM.

If everything is correct you should now have a working El Capitan, congrats.
Please answer to this thread if i forgot something. ;D




 

Attachments

  • config_USB-INSTALL.plist
    7.9 KB · Views: 741
  • AppleHDA.zip
    1.7 MB · Views: 549
  • TP-Link.zip
    10.4 MB · Views: 695
  • config_POST-INSTALL_FIRST.plist
    8.2 KB · Views: 651
  • refs.txt
    774 bytes · Views: 554
  • Yoga3-14_BatteryStatus.txt
    4.9 KB · Views: 599
  • Yoga3-14_BacklightKeys.txt
    258 bytes · Views: 497
  • config_FULL.plist
    8.7 KB · Views: 658
  • SSDT.aml
    1.6 KB · Views: 516
Last edited by a moderator:
Advanced topics:

Here is a great easy to use keyboard layout file which provides the command key on windows key and so called umlaute for german keyboards.

coming up:
fan control and OpenWRT Time Capsule
 
I was kinda lazy when I was doing X1 Carbon and Asus UX305FA. I wanted to just copy as many binary SSDTs over as I could without editing them.

Pjalm's "Generic fixes" messes with SATA. I found that wasn't necessary for me in the DSDT, which meant I didn't need to patch a couple SSDTs either.

Clover can drop _DSMs for you, I think.

If you can get it down to zero edited SSDTs, you can switch to DropOem false and remove all the SSDTs from patched.
 
Clover can drop _DSMs for you, I think.

Don't bother with DropOEM_DSM. It doesn't work like you think it should.

Rename _DSM to XDSM with binpatch instead.
 
Don't bother with DropOEM_DSM. It doesn't work like you think it should.

Rename _DSM to XDSM with binpatch instead.

What do you mean here? Should i rename them in the original SSDTs instead of removing them?
 
What do you mean here? Should i rename them in the original SSDTs instead of removing them?

Removing them is fine. You don't have to change anything.

(The more often I write this message, the better I understand it. You can skip it if you are happy with your DSDT/SSDTs.)

There are basically 3.5 ways of patching DSDT/SSDT:

1) Use text patches on all DSDT/SSDT, and recompile. This is the traditional way.

1.5) Use text patches on only the SSDTs that need them. Any SSDT you don't modify can be copied directly from origin/ to patched/ without recompilation--and without patches just to get it to compile.

2) Use text patches *only* on DSDT. Then you can set DropOem=false, which is equivalent to copying all SSDTs from origin/ to patched/. (Don't set DropOem until you've actually deleted the SSDTs. :)

There is a bonus: if you set DropOem to false, Clover binary patches will work on the BIOS SSDT tables. If the only patch you need to make to SSDTs is a simple rename, you can use a binary patch like "change GFX0 to IGPU".

3) Get rid of all DSDT patches too. Move functionality to new SSDT files like SSDT-HACK.aml.

This is harder, and requires some knowledge of ACPI, and playing with Hex Fiend to try out changes. It is also very likely to work across BIOS revisions, and sometimes across similar machines.

If there is already a "GPRW" method in the BIOS DSDT, you can't have one in SSDT-HACK.aml. In other words, you can't overwrite methods.

However, you can use Clover binary patches to change the BIOS DSDT definition "Method(GPRW,2)" to something unused like "Method(XPRW,2)". Then your SSDT-HACK can define its own GPRW (since binary patches do not apply to loaded SSDT files.) Your new GPRW can even call the original BIOS version as XPRW. But you have to come up with a search/replace pair that makes only the change you want.

So, getting back to _DSM...

You can delete all _DSM methods *not in loaded SSDTs* with a binary patch to rename "_DSM" to something unused like "XDSM". But binary patches still apply to any DSDT, so you will need to supply any replacement _DSM methods in loaded SSDTs like SSDT-HACK.

Sorry that was so complicated. I need to write this up with better examples. I went through all of these methods with the UX305FA, and I have the GitHub commit history to prove it. :)
 
What do you mean here? Should i rename them in the original SSDTs instead of removing them?

My reply was to gfoury, not you.
 
2) Use text patches *only* on DSDT. Then you can set DropOem=false, which is equivalent to copying all SSDTs from origin/ to patched/. (Don't set DropOem until you've actually deleted the SSDTs. :)

Keep in mind it is very rare that you can get away with this (mostly only with older computers).

The reason is that renames must be balanced. Given that most modern computers have GFX0 references in DSDT and SSDTs, and GFX0 is renamed to IGPU for IGPU PM, for modern computers you end up patching the SSDTs as well.

You can delete all _DSM methods *not in loaded SSDTs* with a binary patch to rename "_DSM" to something unused like "XDSM". But binary patches still apply to any DSDT, so you will need to supply any replacement _DSM methods in loaded SSDTs like SSDT-HACK.

This gets pretty confusing for most people, but here is a simple set of rules to keep in mind...

- Clover ACPI binpatches apply to all OEM DSDT+SSDTs.
- Clover ACPI binpatches apply to ACPI/patched/DSDT.aml
- Clover ACPI binpatches DO NOT apply to ACPI/patched/SSDT*.aml

As long as you understand the ramifications of that, you'll be ok.

Because it is confusing, it is probably best to stick to one method or another. In other words, if you don't understand it clearly, don't try to mix hotpatch with static patching.
 
@sheg0: You still don't need to do anything. :)

Because it is confusing, it is probably best to stick to one method or another. In other words, if you don't understand it clearly, don't try to mix hotpatch with static patching.

That makes more sense than what I wrote, thank you.

While we're on confusing, could you quickly eyeball what http://pjalm.com/repos/intel9/Generic_Fixes.txt is doing? I don't understand it. It's used in this guide, and in the 10.10 UX303 guide. I don't use it.

Generic_Fixes renames SAT0 to SATA, causing a bunch of balancing renames. (The rename doesn't touch Scopes, so there's still "Scope (_SB.PCI0.SAT0)", causing compilation errors...) Is the SAT0->SATA rename useful these days for laptops? I don't see it in your laptop-dsdt-patches repository.

The Generic_Fixes looks like it is adding "Return(Zero)" a bunch of places, probably to quiet "method does not return value" warnings. But it also can drop Return(Zero) out of control paths, so you get this diff on UX305FA:
Code:
             {
                 If (LEqual (DVID, 0xFFFF))
                 {
-                    Return (Zero)
+
                 }
That seems wrong.

From a legal point of view, the license has about three "compiler warnings". Ignoring the problems, the license means that I can't fix Generic_Fixes, so I just took it out of the UX305FA patch set, with no apparent problems....
 
While we're on confusing, could you quickly eyeball what http://pjalm.com/repos/intel9/Generic_Fixes.txt is doing? I don't understand it. It's used in this guide, and in the 10.10 UX303 guide. I don't use it.

Looks like a batch of uncommented patches.

Note: the AAPL,slot-name injection is cosmetic only (for System Information -> PCI List).

Many of the patches there are not needed (warnings), or are fixing things that would have never been a problem with correct disassembly.

Generic_Fixes renames SAT0 to SATA, causing a bunch of balancing renames.

SAT0 -> SATA is a rename that is not needed...

The Generic_Fixes looks like it is adding "Return(Zero)" a bunch of places, probably to quiet "method does not return value" warnings.

Warnings don't need to be fixed. Default return value from a code path without return is already zero.
 
Status
Not open for further replies.
Back
Top