Thunderbolt native support for Lenovo W540

[LeonTravowski]

K, does that mean changing the chipset devID from 1566 to 156c in this system isn't possible through fakepciid or dsdt?

i know some bluetooth devices beed a kext to correctly load firmware on every boot, wonder if thunderbolt behaves in the same way...

 

[RehabMan]

K, does that mean changing the chipset devID from 1566 to 156c in this system isn't possible through fakepciid or dsdt?

According to your ioreg, that is already being done by FakePCIID.kext. But as I've noted previously, the kext does not seem to query the ID (at least as to what you've provided in system.log).

You were asking about a non-PCI device id.

i know some bluetooth devices beed a kext to correctly load firmware on every boot, wonder if thunderbolt behaves in the same way...

Or something else...

 

[RehabMan]

K, does that mean changing the chipset devID from 1566 to 156c in this system isn't possible through fakepciid or dsdt?

According to your ioreg, that is already being done by FakePCIID.kext. But as I've noted previously, the kext does not seem to query the ID (at least as to what you've provided in system.log).

You were asking about a non-PCI device id.

i know some bluetooth devices beed a kext to correctly load firmware on every boot, wonder if thunderbolt behaves in the same way...

Or something else... Note "NVM Loaded" property in the Mac under ThunderboltHAL... and other missing properties further down the hierarchy.

 

[LeonTravowski]

Wouldn't the device show up as 8086:156c in DPCIManager though? The PCI id still is showing 8086:1566. My HD4600, which uses your fakepciid, shows in DPCIManager as 8086:0412 (originally 0416). Maybe I'm misunderstanding.

thanks again

 

[RehabMan]

Wouldn't the device show up as 8086:156c in DPCIManager though? The PCI id still is showing 8086:1566. My HD4600, which uses your fakepciid, shows in DPCIManager as 8086:0412 (originally 0416). Maybe I'm misunderstanding.

thanks again

DPCIManager shows the injected device-id from ioreg.

Although it is possible the kext is looking at the values in ioreg, it is unlikely. The FakePCIID spoofing is hidden from view and in particular hidden from DPCIManager (it doesn't query the device-id through IOPCIDevice, but rather just reads the values from ioreg).

In the HD4600 case, you're both injecting device-id=0x0412 *and* using FakePCIID...

 

[LeonTravowski]

Gottcha. Would it be of any use to provide the system.log & ioreg of a thunderbolt equipped mac-mini booting with the thunderbolt-firewire dongle attached?

 

[RehabMan]

Gottcha. Would it be of any use to provide the system.log & ioreg of a thunderbolt equipped mac-mini booting with the thunderbolt-firewire dongle attached?

Would it show anything different than the MacBookPro11,x? Seems unlikely...

 

[LeonTravowski]

Probably not the ioreg, was thinking maybe the system log revealed some process that was happening in a real thunderbolt equipped mac that didn't with this system.

Thanks again for your patience and time trying to solve this.

 

[RehabMan]

Probably not the ioreg, was thinking maybe the system log revealed some process that was happening in a real thunderbolt equipped mac that didn't with this system.

Thanks again for your patience and time trying to solve this.

I think you should do some searching/google... I know that tb works on certain desktops (but hotplug is an issue). Perhaps you can learn about it from desktop experiences.

I don't have any tb hardware, so there isn't much motivation here.

 

[LeonTravowski]

It seems like he Gigabyte boards use the same 156c TB as the Macbook Pro 11,2. Is it possible that a ID change at the DSDT or Clover level would be applied earlier in the boot process than fakepciid?