Thunderbolt native support for Lenovo W540

[RehabMan]

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.

Check system.log to check for clues as to why FakePCIID is not attaching to the device. Also, make sure you rebuild cache *and* check for errors during the cache rebuild.

 

[LeonTravowski]

I can see FakePCIID attaching to the graphics card on boot, but not the thunderbolt device. Attaching the system.log & ioreg. This reflects booting without dropping the OEM SSDT tables & with the update kext darkvoid provided.

Thanks@!

 

[RehabMan]

I can see FakePCIID attaching to the graphics card on boot, but not the thunderbolt device. Attaching the system.log & ioreg. This reflects booting without dropping the OEM SSDT tables & with the update kext darkvoid provided.

Thanks@!

There is at least some progress in this one... FakePCIID is attached to pci8086,1566@0.

But there is no alternate device-id injected there, so its effect is nil. The AppleUSBMergeNub personality doesn't appear to be working.

 

[the-darkvoid]

Since he doesn't have an ACPI node for the device, what is easiest?

Hardcoded FakePCIID? Or create an ACPI node?

 

[RehabMan]

Since he doesn't have an ACPI node for the device, what is easiest?

Hardcoded FakePCIID? Or create an ACPI node?

I'm working on a new version of FakePCIID that is able to gather the RM,device-id/etc from the FakePCIID node. This will allow the injections to happen directly in the IOPersonality for the FakePCIID instance itself without the use of AppleUSBMergeNub.

All it does is search the children of the hooked PCI (during the calls to configread32/16) for the first FakePCIID node. It then can retrieve the properties from that entry.

I'll keep you posted... (code is written... need to test...)

 

[RehabMan]

I'm working on a new version of FakePCIID that is able to gather the RM,device-id/etc from the FakePCIID node. This will allow the injections to happen directly in the IOPersonality for the FakePCIID instance itself without the use of AppleUSBMergeNub.

All it does is search the children of the hooked PCI (during the calls to configread32/16) for the first FakePCIID node. It then can retrieve the properties from that entry.

I'll keep you posted... (code is written... need to test...)

Actually, this is not going to work. Because of the way FakePCIID is attached/detached/re-attached during the initialization process, when configread32/16 is called, the FakePCIID entry is not attached and therefore cannot be found... (thought that might happen...)

We should try using the "FakeProperties" merge code. It is under #ifdef DEBUG, but DEBUG is not being defined (even by the debug build...). I've attached a set to try.

 

[LeonTravowski]

Hey, I appreciate you taking the time to look into this. I think the Lenovo W540 & Dell M3800 workstations are the only two PC laptops atm equipped with Thunderbolt 2, they may use the same chipset.

Anyways, I see more action when booting up with FakePCIID but it looks like the Kext is detaching right after it attaches. *see attachments (no pun) for the newest system.log & ioreg.

Thank you again/

 

[RehabMan]

Hey, I appreciate you taking the time to look into this. I think the Lenovo W540 & Dell M3800 workstations are the only two PC laptops atm equipped with Thunderbolt 2, they may use the same chipset.

Anyways, I see more action when booting up with FakePCIID but it looks like the Kext is detaching right after it attaches. *see attachments (no pun) for the newest system.log & ioreg.

Thank you again/

It is normal for it to attach/detach/attach during startup. Looking at ioreg, it is attached and doing what I expected (note RM,device-id and RM,subsystem-id injected on the parent node).

But there are no requests for the IDs for your TB device as seen from FakePCIID. I suspect that the kext is not dependent on the IDs and something else is wrong/missing. You should probably do some more research. I don't have much experience on TB, but I seem to recall reading that hotplug doesn't work for some reason. Maybe try plugging your TB device in prior to booting.

 

[LeonTravowski]

Hi. Yes it definitely doesn't work when hotplugged, but I've had the Apple Thunderbolt -> Firewire 800 dongle installed/inserted throughout the whole testing process.

One thing that is slightly glaring is under IOThunderboltController in ioreg for the MacbookPro 11,2, there is a node called IOThunderboltport@5 (8086:156d). This is missing from my ioreg. In my system I believe this device ID is 8086:1567 (6 of them show up in DPCI manager).

Perhaps also have a swap for device ID 1567 to 156d is necessary in order for Thunderbolt to work? Attaching latest system.log, ioreg + macbookpro11,2's ioreg.

Cheers

 

[RehabMan]

Hi. Yes it definitely doesn't work when hotplugged, but I've had the Apple Thunderbolt -> Firewire 800 dongle installed/inserted throughout the whole testing process.

One thing that is slightly glaring is under IOThunderboltController in ioreg for the MacbookPro 11,2, there is a node called IOThunderboltport@5 (8086:156d). This is missing from my ioreg. In my system I believe this device ID is 8086:1567 (6 of them show up in DPCI manager).

Perhaps also have a swap for device ID 1567 to 156d is necessary in order for Thunderbolt to work? Attaching latest system.log, ioreg + macbookpro11,2's ioreg.

Cheers

It is not possible to accomplish with FakePCIID... Those IOThunderboltPort entries are not matched/loaded by iokit, but probably loaded by the IOThunderboltController class itself. They are not devices on the PCI bus... it is something internal to TB.