Thunderbolt native support for Lenovo W540

[LeonTravowski]

I was hoping the thunderbolt 2 port on this Lenovo W540 would work out of the box, but that doesn't seem to be the case.

I bought an Apple Thunderbolt to Firewire 800 adapter, when this is inserted two of the Apple Thunderbolt kext's load (see attachment) & "ExpressCard" appears under PCI in System Information. Unfortunately, neither a Firewire Audiocard or Hard-drive was recognized using the apple thunderbolt to firewire dongle.

It occurred to me if I was able to do a DSDT patch so that the Device ID of my Intel Thunderbolt appeared as the version found in the Macbook Pro 11,2 that might be a solution. I'm not a programmer however and my skills are limited to basic plist patches.

I'm attaching a screenshot of my system (left) Vs. Macbook Pro 11,2 (right) using ioreg, specifically dealing with thunderbolt. You can see my Intel Thunderbolt 2 deviceID is 8086:1566. In the Macbook Pro 11,2 (NHI0@0), the deviceID is 8086:156c (very close to my model name).

Attaching my system dsdt & ssdt, any help with deriving a patch would be really appreciated.

 

[RehabMan]

I was hoping the thunderbolt 2 port on this Lenovo W540 would work out of the box, but that doesn't seem to be the case.

I bought an Apple Thunderbolt to Firewire 800 adapter, when this is inserted two of the Apple Thunderbolt kext's load (see attachment) & "ExpressCard" appears under PCI in System Information. Unfortunately, neither a Firewire Audiocard or Hard-drive was recognized using the apple thunderbolt to firewire dongle.

It occurred to me if I was able to do a DSDT patch so that the Device ID of my Intel Thunderbolt appeared as the version found in the Macbook Pro 11,2 that might be a solution. I'm not a programmer however and my skills are limited to basic plist patches.

I'm attaching a screenshot of my system (left) Vs. Macbook Pro 11,2 (right) using ioreg, specifically dealing with thunderbolt. You can see my Intel Thunderbolt 2 deviceID is 8086:1566. In the Macbook Pro 11,2 (NHI0@0), the deviceID is 8086:156c (very close to my model name).

Attaching my system dsdt & ssdt, any help with deriving a patch would be really appreciated.

Maybe AppleThunderboltNHI.kext is whitelisting the PCI IDs (it matches on class).

I wonder if FakePCIID could help here: https://github.com/RehabMan/OS-X-Fake-PCI-ID

 

[LeonTravowski]

I've actually got that kext installed, i think i had followed a guide of yours involving using it to enable the hd4600 under yosemite. I re-read the description for FakePCIID but it's a little over my head. If it can change the device 8086:1566 to appear as 8086:156c (MBP 11,2), then hopefully Yosemite will see the thunderbolt as internal and gain full native functionality.

 

[the-darkvoid]

Give this attachment a try.
Place it in the same directory as FakePCIID and the Intel HD4600 injector.

No idea as to what might happen, because Thunderbolt IOReg seems quite involved.
Don't blame me if it starts smoking

After loading kext re-verify your IOreg, FakePCIID should be attached.
If its not intercepting properly you might have to use DSDT for the device-id injection instead of AppleMergeUsbNub (we required this for Intel HDMI audio also)

 

[LeonTravowski]

Thanks for your help. Installed using kextwiazrd and fixed permissions + rebuilt cache, but nothing seems to have changed PCI device is still showing up as 8086:1566 (see *attachment).

Don't suppose anyone would be willing to give a DSDT re-injection patch a shot? My ACPI tables were attached in the first post.

Thanks again!

 

[the-darkvoid]

I do not see FakePCIID attaching to your device, thats not a good thing.

For DSDT try this patch:

into method label _DSM parent_label EXP5 remove_entry;
into device label EXP5 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }\n
    Return (Package()\n
    {\n
        "device-id", Buffer() { 0x6c, 0x15, 0x00, 0x00 },\n
    })\n
}\n
end;

I am not a DSDT master, so maybe Rehabman can look at it, but I think this should work.
Also see updated kext to match against the native Apple ID.

 

[RehabMan]

I do not see FakePCIID attaching to your device, thats not a good thing.

Yes, it points to some other fundamental problem with FakePCIID and FakePCIID_thunderbolt injector. Likely an installation issue. The OP should check system.log for clues.

For DSDT try this patch:

into method label _DSM parent_label EXP5 remove_entry;
into device label EXP5 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }\n
    Return (Package()\n
    {\n
        "device-id", Buffer() { 0x6c, 0x15, 0x00, 0x00 },\n
    })\n
}\n
end;

Not recommended and will not work. According to the ioreg screen shot, there is no ACPI node for the device... (probably due to dropping a needed OEM SSDT).

And EXP5 is not the correct node.

 

[the-darkvoid]

He has the SLOT device under EXP5 in his DSDT ACPI, but nothing under that.
Nothing in SSDT's.

 

[RehabMan]

He has the SLOT device under EXP5 in his DSDT ACPI, but nothing under that.
Nothing in SSDT's.

A DSDT patch would need to add a node that will match up against the pci8086,1566@0 node, giving it an ACPI identity. If that doesn't exist in the OEM SSDTs, it would need to be added (as a device under the associated/nearest IOPP node).

At this point, there is a problem getting FakePCIID attached, which is unrelated to ACPI... That problem should be solved first.

 

[LeonTravowski]

Thanks for your help in looking into this. I was pretty sure FakePCIID was installed correctly cause i was using it to get hardware acceleration in my HD4600 working.

Clover is set up to drop the ssdt as I used maciASL to create a speedstep profile. Should i undo this and use the native SSDT?

let me know if i can provide anything more, i'll upload the ioreg dump when i get off work this evening.