Contribute
Register

GC-ALPINE RIDGE in hands

Status
Not open for further replies.
From your pci.txt file and what I know about Thunderbolt PCIe layout, I think your Thunderbolt devices are like this:
Code:
00:06:00.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
    00:07:00.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
    00:07:01.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
    00:07:02.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
        00:0A:00.00 8086:15B6 Serial Bus Controllers - USB : DSL6540 USB 3.1 Controller [Alpine Ridge]
    00:07:04.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]

00:0C:00.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
    00:0D:00.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
        00:0E:00.00 8086:1577 Base System Peripherals - Other system peripheral : DSL6540 Thunderbolt 3 NHI [Alpine Ridge 4C 2015]
    00:0D:01.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
    00:0D:02.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
        00:29:00.00 8086:15B6 Serial Bus Controllers - USB : DSL6540 USB 3.1 Controller [Alpine Ridge]
    00:0D:04.00 8086:1578 Bridge Device - PCI/PCI bridge : DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
        00:2A:00.00 8086:1549 Bridge Device - PCI/PCI bridge : DSL2210 Thunderbolt Controller [Port Ridge 1C 2011]
            00:2B:00.00 8086:1549 Bridge Device - PCI/PCI bridge : DSL2210 Thunderbolt Controller [Port Ridge 1C 2011]
                00:2C:00.00 1B4B:9230 Mass Storage Controller - Serial ATA controller : 88SE9230 PCIe SATA 6Gb/s Controller
The devtree file should be able to verify the hierarchy. You can check the vendor and device ids of each device at http://pci-ids.ucw.cz

This shows two Thunderbolt 3 controllers.

The first one is used by the motherboard to support USB 3.1 gen 2 only, so there is no NHI device. This is as expected. Have you verified USB 3.1 gen 2 capability from this port?

A Thunderbolt 1 device containing a SATA controller is connected to port 2 of the second Thunderbolt 3 controller which must be the GC-ALPINE RIDGE card. So it seems you should be able to see that SATA drive in macOS. There appears to be nothing connected to port 1 of the GC-ALPINE RIDGE.

Are you expecting any other devices to appear in the pci.txt file? What is your Thunderbolt chain like? Make sure Thunderbolt 1 devices come after Thunderbolt 2 devices and Thunderbolt 2 devices come after Thunderbolt 3 devices. Maybe try each device by itself before chaining them together. Use port 1 for one device, and port 2 for another (you may want a second Thunderbolt 3 to Thunderbolt 2 adapter - one for each Thunderbolt 3 port).

You should try the lspci command in macOS.

Download the zip from https://github.com/pciutils/pciutils
Add /usr/local/sbin to the end of the file /etc/paths and save it.
Open Terminal.app, go to the location of the unzipped folder(pciutils-master), make and install it.
Code:
cd ~/Downloads/pciutils-master
make install
update-pciids
update-pciids downloads the latest pci vendor and device IDs (same list as at pci-ids.ucw.cz).
Now you can use the lspci command to get pci information. The following command gets a hierarchy of the pci devices:
Code:
sudo lspci -nnvt > lspcinnvt.txt

The following command gets all the information for all the pci devices:
Code:
sudo lspci -nnvvvxxxx > lspcinnvvvxxxx.txt

pciutils also includes a setpci command that will let you read or set individual registers (for example, you could check the current link width and link speed, or change them).

If you have lspci V1.1.pkg installed, you should uninstall those files before installing the version from GitHub because the GitHub version is the latest.

We have similar boards, GA-Z170X Ultra Gaming... On board thunderbolt works great but trying to add on the Alpine Ridge card would never mount drives in OSX. Windows worked fine but OSX just wouldn't see them, ended up returning them. Very interested to see this figured out!
 
@archalys you cant have two alpine ridge cards in one system. thats the reason only the onboard one is working for you.

I have two x99 asus mainboards with thunderboltex pcie running with 10.12.6. but on one everything is working ok (no sleep <- not possible with tb now) on the other have random crashs etc. try to find out whats wrong with them.. tb with osx on a hack is pain in the ass. hope somebody find the right way out.
 
@archalys you cant have two alpine ridge cards in one system. thats the reason only the onboard one is working for you.

I have two x99 asus mainboards with thunderboltex pcie running with 10.12.6. but on one everything is working ok (no sleep <- not possible with tb now) on the other have random crashs etc. try to find out whats wrong with them.. tb with osx on a hack is pain in the ass. hope somebody find the right way out.
Some of the supported motherboards listed at https://www.gigabyte.com/Motherboard/GC-ALPINE-RIDGE-rev-10#ov also have an onboard Thunderbolt controller. I don't think there's any documentation stating that they can't be used simultaneously. Therefore, if it doesn't work in Windows, then you should talk to Gigabyte about it. I haven't checked ASUS motherboards.
 
Hey guys,

I've just put together a build with the ALPINE-RIDGE card, using it to drive two Thunderbolt Displays. My first move was to get it up and running in Windows, which went OK thanks to the advice here. (Particularly thanks to @joevt and @Numb3r for alerting to the NVM-e slot issues)

However, when switching over to the Mac side (10.12.6 Sierra, basically a straight-up recommended install), I encountered an oddity -- the Thunderbolt connections appear to be working, as evidenced by the fact that the display Ethernet and FireWire ports work -- however, the USB hubs in the monitors are totally dead, which means no sound or display brightness controls.

IORegistryExplorer shows the display's internal USB tree being successfully enumerated:
Screen Shot 2017-11-03 at 10.50.56 PM.png
But none of the ports are active.

I'm guessing this is somehow related to USB injection, port limits, and that sort of thing. I'm unfamiliar with the details, so other than installing the basic MultiBeast patch to raise the port limit, I'm not sure what else to do.

Anyone have any advice? Thanks.
 
I'm guessing this is somehow related to USB injection, port limits, and that sort of thing. I'm unfamiliar with the details, so other than installing the basic MultiBeast patch to raise the port limit, I'm not sure what else to do.
Anyone have any advice? Thanks.

Is this the Apple Thunderbolt display?

These USB controllers (OHCI, EHCI) only have 2 ports, so a port limit patch does not need to be applied.

Only the USB controller in the PCH (XHCI) has a port limit problem (more than 15 ports). You should remove the port limit patch anyway, after deciding which ports of the PCH are
useable and removing the rest. Follow the USB port guide to properly remove unusable ports.
https://www.tonymacx86.com/threads/guide-10-11-usb-changes-and-solutions.173616/

The USB fixes you make for the PCH should not affect the usb controllers of the Thunderbolt displays. Maybe remove all such fixes so that you can test the Thunderbolt display's USB ports without the fixes. Make sure the Clover config file doesn't have any USB fixes.

Did you try connecting USB devices to the USB ports of the display then examine the system logs while doing that?
 
Is this the Apple Thunderbolt display?
Yes, to be specific, two Apple Thunderbolt Displays, connected to two Apple TB3 to TB2 Adapters, connected to the two TB3 ports on the ALPINE-RIDGE board. The TB3 video is being driven by two DP cables hooked up to my GeForce 1060.

The USB fixes you make for the PCH should not affect the usb controllers of the Thunderbolt displays. Maybe remove all such fixes so that you can test the Thunderbolt display's USB ports without the fixes. Make sure the Clover config file doesn't have any USB fixes.
I don't think I need the USB patches for onboard ports, or at the very least, I've encountered no problems using my mobo's onboard USB thus far. Putting them in was a desperation move in order to try to get my displays working.

In the interest of establishing a minimum reproducible case, I removed all those USB patches. I also unplugged all peripherals except keyboard, mouse, and a single Thunderbolt Display.

After a bit of fiddling with cold reboots, lo and behold, it worked -- camera, brightness, sound, and USB ports all fine! Also apparently stable through several warm reboots with just one plugged in.

I then shut down and plugged in the second display. This shut down USB on the first display, but the USB on the newly-added display began to work.

I got this desktop notification at boot:

Screen Shot 2017-11-05 at 5.23.30 PM.png

A text excerpt from the Console with some USB failure messages (halt/restart):

default 17:29:14.792938 -0500 kernel 000090.065930 AppleUSBEHCIPI7C9X440SL@41000000: AppleUSBEHCI::RestartUSBBus: USBSTS.HCHalted did not set as expected: USBCMD 0x00010330 USBSTS 0x0000e004
default 17:29:14.792960 -0500 kernel 000090.065982 AppleUSBEHCIPI7C9X440SL@41000000: AppleUSBEHCIPCI::hardwareException: could not halt controller in 100 ms
default 17:29:15.075779 -0500 kernel 000090.348797 AppleUSBEHCIPI7C9X440SL@41000000: AppleUSBEHCI::StopUSBBus: USBSTS.HCHalted did not set as expected: USBCMD 0x00010330 USBSTS 0x0000e004
default 17:29:15.075788 -0500 kernel 000090.348815 AppleUSBEHCIPI7C9X440SL@41000000: AppleUSBEHCIPCI::hardwareException: could not halt controller in 100 ms
default 17:29:15.191057 -0500 kernel 000090.464081 AppleUSBEHCIPI7C9X440SL@41000000: AppleUSBEHCIPCI::hardwareException: could not reset controller in 100 ms


@41000000 is the address of one of the Thunderbolt Display internal USB hubs. An IOREG dump is also attached.

EDIT: Some more tinkering: I can plug either display in solo and it works as it should. If I plug both displays in, whichever one gets IOreg address @40000000 works, and whichever one gets IOreg address @41000000 doesn't. (They are consistently assigned one of those two addresses)

So, progress: I can have one working display at a time, and the new status quo is that only one of the two displays is exhibiting the negative symptoms that both were experiencing before. I'm at a loss to explain this, as all I really did was remove that USB hack.
 

Attachments

  • usb kernel exceptions 1.txt
    12.3 KB · Views: 329
  • wcj-mac-2017.ioreg
    18.2 MB · Views: 273
Last edited:
I then shut down and plugged in the second display. This shut down USB on the first display, but the USB on the newly-added display began to work.
Very strange. If you had a MacBook Pro with Thunderbolt 3, then you could test this configuration on that. If that failed, then you could report it to Apple via apple bug reporter. I don't think they'd appreciate a bug report from a Hackintosh though. The MacBook Pro has 4 Thunderbolt ports, so I would try both displays connected to one Thunderbolt chip, and then one Display connected to each Thunderbolt chip.
I got this desktop notification at boot:

The IORegistry doesn't contain information about USB power requirements. System Information.app has that information (Current Available/Current Required). The best way to dump that information is with the command:
Code:
system_profiler SPUSBDataType > usbinfo1.txt
It might be interesting to compare the results of the following (make sure no USB devices are connected to each display):
1) Thunderbolt Display 1 to Thunderbolt port 1
2) Thunderbolt Display 1 to Thunderbolt port 2
3) Thunderbolt Display 2 to Thunderbolt port 1
4) Thunderbolt Display 2 to Thunderbolt port 2
5) Thunderbolt Display 1 to Thunderbolt port 1 and Thunderbolt Display 2 to Thunderbolt port 2
6) Thunderbolt Display 1 to Thunderbolt port 2 and Thunderbolt Display 2 to Thunderbolt port 1

Also, USBProber.app (666.4.0) can get USB information. I don't know if any of that will help.

@41000000 is the address of one of the Thunderbolt Display internal USB hubs. An IOREG dump is also attached.
I don't see anything wrong with the IOREG dump, but it is recommended to use IORegistryExplorer2.1.app instead of version 3.

EDIT: Some more tinkering: I can plug either display in solo and it works as it should. If I plug both displays in, whichever one gets IOreg address @40000000 works, and whichever one gets IOreg address @41000000 doesn't. (They are consistently assigned one of those two addresses)

So, progress: I can have one working display at a time, and the new status quo is that only one of the two displays is exhibiting the negative symptoms that both were experiencing before. I'm at a loss to explain this, as all I really did was remove that USB hack.
What exactly was the USB hack? If it was a DSDT patch, then it would be interesting to get a ACPI dump from Clover (press F4 at the Clover boot screen, you should notice that it hangs for a couple seconds as it saves the files to the EFI partition, meaning you can't move the drive selection left or right for a couple seconds). Then we can see how the Thunderbolt Displays appear in the DSDTs, if at all, and can determine how the patch affects that.
 
Very strange. If you had a MacBook Pro with Thunderbolt 3, then you could test this configuration on that. If that failed, then you could report it to Apple via apple bug reporter. I don't think they'd appreciate a bug report from a Hackintosh though. The MacBook Pro has 4 Thunderbolt ports, so I would try both displays connected to one Thunderbolt chip, and then one Display connected to each Thunderbolt chip.
I don't personally own a TB3 MBP, but I can probably arrange to borrow one for a while. I don't expect it to fail when plugged into an actual Mac, as I've had these two displays plugged into a 2012 Thunderbolt 1 MBP for months with no problems.
It might be interesting to compare the results of the following (make sure no USB devices are connected to each display):
1) Thunderbolt Display 1 to Thunderbolt port 1
2) Thunderbolt Display 1 to Thunderbolt port 2
I have not had time to run all these tests yet, but I have done the first two. Log files from all the tools you've mentioned so far (ioreg, system profiler, and USB Prober) are attached. To possibly save you some download time, I found no significant difference between whether display 1 was plugged in on port 1 or port 2. Sharper eyes than mine may see a difference, but in both cases, generally what happened was the internal USB hub got assigned address 0x40000000 and everything worked.

What was interesting, though, is cold boot (total shutdown + wait 10 sec for TB display to shutdown also) versus warm boot (plain restart). I've attached IOreg from both.

Consistently, after a fully cold boot, not only would the TB Display's internals not work, but the Thunderbolt card itself (the IOThunderboltController node) along with all the PCI bridges would disappear from ioreg. Following this up with a warm boot would restore the Thunderbolt controller as well as the display's internals to working order. I've attached one of each ioreg output from cold versus warm boot.

This may explain why some people earlier observed the need to boot into Windows first -- I think some initialization step is not being done, particularly on cold boot. Possibly related to hot plugging or the System Profiler not recognizing that there is a Thunderbolt controller in place?
What exactly was the USB hack? If it was a DSDT patch, then it would be interesting to get a ACPI dump from Clover (press F4 at the Clover boot screen, you should notice that it hangs for a couple seconds as it saves the files to the EFI partition, meaning you can't move the drive selection left or right for a couple seconds). Then we can see how the Thunderbolt Displays appear in the DSDTs, if at all, and can determine how the patch affects that.
No DSDT patch. The specific USB-related things I installed were both from Multibeast: "Increase Max Port Limit 200 Series" and "3rd Party USB 3.0" -- I've since removed both these things.
 

Attachments

  • ioreg-coldboot_d1p1.ioreg
    5.3 MB · Views: 212
  • ioreg-coldboot_d1p2.ioreg
    5.2 MB · Views: 206
  • ioreg-warmboot_d1p1.ioreg
    5.7 MB · Views: 221
  • ioreg-warmboot_d1p2.ioreg
    5.6 MB · Views: 227
  • USBPortStatus_d1p1.txt
    2.7 KB · Views: 282
  • USB Bus Probe_d1p2.txt
    71.8 KB · Views: 214
  • USB Bus Probe_d1p1.txt
    71.8 KB · Views: 242
  • system_profiler_d1p2.txt
    3.1 KB · Views: 414
  • system_profiler_d1p1.txt
    3.1 KB · Views: 658
  • IORegistry_d1p2.txt
    586 bytes · Views: 228
  • IORegistry_d1p1.txt
    586 bytes · Views: 261
  • USBPortStatus_d1p2.txt
    2.7 KB · Views: 283
@Crashing00
Please: are you able to get SSDTs from that MacBook regarding the Thunderbolt-implementation?
That would be great.
 
I'm trying to get a UAD Apollo unit to work in 10.12.6 Sierra on my Z270X-UD3 motherboard with Alpine Ridge add-in card.

I can get the unit to show up in Windows 10 (I did a firmware update as well) and it communicates with the software in that OS.

I can't get it to display in OS X.

I wonder, my system definition is 14,3 - is that a problem because it pre-dates TB3? I can't for the life of me get my machine to get past a black screen when it's 18,X.

I've read this thread (and it's been super helpful) to try to get my head around what might be wrong.

I've tried unplugging the header cable (didn't do anything).

I've attached the output from my ioreg command.

With the current Clover it appears I can't use pci > pci.txt to output the results.

It's a TB2 device and I'm using the Apple adaptor and Apple TB cable. (Works great in Win 10).

Any isolation tips or procedures would be most appreciated! I've built about 20 Hackintoshes over the years, but this has me stumped.
 

Attachments

  • ioreg-roger-explosion.txt
    93.4 KB · Views: 264
Status
Not open for further replies.
Back
Top