Contribute
Register
No luck with the jumper instead of the THB-C header. The card wasn't even recognized in the BIOS anymore. Strange
Here is a picture of my alpine ridge, the wire you can not see is just a loop I have it taped to the card. Honestly it should not matter since the cable only does a few things, the first is to power the card on (that is what the jumper does), second is control sleep that is why you remove it to allow the OS to control sleep. I normally use the alpine in a system that does not have a THB-C header, but my Titan is flashed with nvm33 and uses the jumper wire on 3-5 and the bios still sees the card is there.

IMG_0160.jpg
 
Here is a picture of my alpine ridge, the wire you can not see is just a loop I have it taped to the card. Honestly it should not matter since the cable only does a few things, the first is to power the card on (that is what the jumper does), second is control sleep that is why you remove it to allow the OS to control sleep. I normally use the alpine in a system that does not have a THB-C header, but my Titan is flashed with nvm33 and uses the jumper wire on 3-5 and the bios still sees the card is there.

View attachment 502701
I definitely connected the correct pins. I used one of the elegoo F-F jumper wires. I tried a couple different ones after the first one didn't seem to work. I'll try it again when I feel like messing with it some more.
 
I definitely connected the correct pins. I used one of the elegoo F-F jumper wires. I tried a couple different ones after the first one didn't seem to work. I'll try it again when I feel like messing with it some more.
Guess you do not have the bang your head against it till it works bug! I could not tell you that the jumper works for sure on an unflashed card since both my cards are flashed and I did not use the jumper till after!
 
Guess you do not have the bang your head against it till it works bug! I could not tell you that the jumper works for sure on an unflashed card since both my cards are flashed and I did not use the jumper till after!


I tried to use the THB-C header cable to short pins 5-3, no luck either. Maybe it does need to be flashed or I need to run a separate 3V connection in from the SATA power. Not sure I am ready to try that one yet though.

I think the next thing I am going to try is flashing my TR card again with the firmware you like to see if that works any better than 23.
 
I think the next thing I am going to try is flashing my TR card again with the firmware you like to see if that works any better than 23.
It is not a matter of like it is just a matter of what works and what does not. Early on I found that 33 just worked where the others did not work as well. In the end as far as I can tell it works as well as a real mac. However, I do think there are some issues with cold boot and some devices.
 
It is not a matter of like it is just a matter of what works and what does not. Early on I found that 33 just worked where the others did not work as well. In the end as far as I can tell it works as well as a real mac. However, I do think there are some issues with cold boot and some devices.


I just installed the DESIGNARE-Z390-NVM33-Elias64Fr.bin firmware on my TR card. I'll let you know how it goes. So far working OK, although it woke from sleep unexpectedly. Hopefully not a indicator of a new problem.

When you switch firmware, were you also using the corresponding SSDT generated using HackinDROM?
 
I just installed the DESIGNARE-Z390-NVM33-Elias64Fr.bin firmware on my TR card. I'll let you know how it goes. So far working OK, although it woke from sleep unexpectedly. Hopefully not a indicator of a new problem.

When you switch firmware, were you also using the corresponding SSDT generated using HackinDROM?
I use these files but you should customize it for your system using the following guide:

 

Attachments

  • Archive.zip
    2.7 KB · Views: 75
I use these files but you should customize it for your system using the following guide:

I just kept using my existing SSDT files and they seem to work fine.

This DesignareNVM 33 firmware does work way better than the Titan Ridge NVM23 I had used before. I wish I had tried it 6 months ago. With my Apple TB display I have only had one occurrence of it not waking back up from sleep. It would probably have been 10 times by now with the old firmware. It also stays on during a reboot which it maybe would stay on 50% of the time with the NVM23. Sleep seems to be working fine too. I don't think I would have ever tried it without reading your posts. Thanks @scottkendall !
 
I just kept using my existing SSDT files and they seem to work fine.

This DesignareNVM 33 firmware does work way better than the Titan Ridge NVM23 I had used before. I wish I had tried it 6 months ago. With my Apple TB display I have only had one occurrence of it not waking back up from sleep. It would probably have been 10 times by now with the old firmware. It also stays on during a reboot which it maybe would stay on 50% of the time with the NVM23. Sleep seems to be working fine too. I don't think I would have ever tried it without reading your posts. Thanks @scottkendall !
Great to hear sometimes my third display does not wake up also it is connected from USB-C on the Thunderbolt to an HDMI. However, If I just unplug it and plug it back in it comes right on. I am not really sure what causes it only that it happens from time to time. I am not really sure why the NVM23 and 50 do not work as well as the NVM33 but it does.
 
Hey guys,

I have a specific question about writing a custom Thunderbolt SSDT, I hope that you could help me out please!

I attach my IOReg screenshot. My Thunderbolt paths differ quite a bit from what has been reported in the thread.

I am experiencing an issue with daisy chaining here, so I assume that I need to define all these paths correctly in the SSDT.

Am I right to assume that I should add:

External (_SB_.PCI0.GPP1, DeviceObj) // (from opcode)
External (_SB_.PCI0.GPP1.PT02, DeviceObj) // (from opcode)
External (_SB_.PCI0.GPP1.PT02.PT20, DeviceObj) // (from opcode)
External (_SB_.PCI0.GPP1.PT02.PT20.X162, DeviceObj) // (from opcode)

Is this correct? How would I define each of these objects in this tree?

Also, is pci8086,15d2 a problem, i.e., not properly initialised?

Your help would be so much appreciated.
 

Attachments

  • Screen Shot 2021-01-13 at 8.30.05 pm.png
    Screen Shot 2021-01-13 at 8.30.05 pm.png
    69.7 KB · Views: 100
Back
Top