GC-ALPINE RIDGE in hands

[Roger-Explosion]

Ahhhh I sat down to boot the machine up into OS X this morning and the damn thing is working.

So for Googlers - that's a UAD Apollo 16 MKII on Sierra 10.12.6 on a Z270X-UD3. The system definition is actually iMac 14,3.

I have NO idea how that happened, but the last steps I took were re-downloading the latest UAD drivers and unplugging the power cable last night after turning it off. I did actually do this after installing the firmware on Windows.

System profiler has no idea about it in the Thunderbolt area, but in Audio it sees it (notice I also have a PCI-e Raydat in there and a PCI-ie UAD-2 quad card).




But here is a screenshot of it working in OS X



I'm actually pretty determined to figure out how this worked because I have no idea. I did, however, follow a lot of the great information from this thread.

I guess if you buy one of these cards in your Gigabyte board, just know that these UAD interfaces will work - it just is a bit fiddly. No idea how stable it is though!

EDIT / UPDATE

I have come to understand the problem with getting this unit to work is actually related to power state (and possibly that little header cable).

• If the header cable is in, I must power the Apollo on at the BIOS loading screen and NOT power the unit on before boot (which is a lot of advice that I read on this forum).
• If you power it on before turning on the computer, it does not work.
• I must turn the unit on and off whether I use shut down or reboot and power it back up at that screen.
• If the header cable is unplugged, the unit powers up less often, but it works on reboot without powering the it off and on.

So for flawless operation

1. Plug the header cable in.
2. Power on the unit only at the BIOS loading screen at the start of the boot process (and not before you turn on your machine).

This is where it is for now ...

 

[joevt]

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.

Probably won't fail, but wouldn't it be wonderful if it did?

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.

I found no difference either, except in the order that some of the devices were listed. Seems strange that this order is not deterministic. It may be because of the multi-threaded nature of the kernel. The Location ID's are the same, but the index changed.

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.

I have found that this may be true. There might be two different kinds of cold boot. One where you unplug the computer, and the other is where you just shutdown the computer. In the latter case, the motherboard may still be using standby current. This may be related to the Thunderbolt firmware update instruction to unplug the computer for 30 seconds before starting up.

I've attached a script that uses lspci from https://github.com/pciutils/pciutils.

# How to install pciutils:

# Download the zip from https://github.com/pciutils/pciutils
# Open Terminal.app, go to the location of the unzipped folder, type the following:

make install

#add /usr/local/sbin to the end of /etc/paths
#Now you can open a new Terminal window and enter

update-pciids

sudo lspci -nn

You may need to change some permissions.

Execute the pcitree.sh script using sudo "sudo ./pcitree.sh". I've attached some example output. It's basically like the lspci -t -vnn command except it shows information about the upstream and downstream switches and the max and current link speed, link width (g1 = gen 1, etc.). The example output shows a OWC Thunderbolt 2 Dock connected to a OWC Thunderbolt 3 Dock. Sometimes, if they don't appear in macOS (the NHI may not appear either), I boot into Windows, unplug the cable, reconnect it, make sure they appear in Windows Device Manager or Intel Thunderbolt sofware list of devices, and restart into MacOS.

Possibly related to hot plugging or the System Profiler not recognizing that there is a Thunderbolt controller in place?

System Profiler is only part of the problem. I haven't gotten around to looking at this problem. Some people have tried. Maybe they succeeded partly. For example: you can see some Thunderbolt properties being added in the sample Clover config.plist.
https://sourceforge.net/p/cloverefi...ckage/CloverV2/EFI/CLOVER/config-sample.plist
I haven't tried them myself. I don't know if there's a post somewhere that explains them or the effect they have. It may be that Apple's hardware doesn't do hot plug like PC hardware, which could make Apple's drivers not fully compatible with Hackintosh. Some workarounds may be needed. For example, compare Linux Thunderbolt patches for Apple and PC hardware (if you can actually get Thunderbolt working in Linux).

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.

Your ioregistry dumps show that you are still using a port limit patch. That should be removed. You should exclude 11 of the ports that you are not using. This probably won't fix your problems though.

 

[joevt]

I've attached the output from my ioreg command

It would be more useful to include the properties with a command like this:

ioreg -l -w0 > ioreg.txt

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

First you have to find the file system that contains Clover. This is easier if you put a file or folder in the root directory like "ThisIsTheCloverEFIPartition". Use "fs0:" "fs1:" etc to change the file system (this is like "C:" in Windows). Use "ls" to list the files. Once you find the EFI file system, you can pipe the output of commands into a file on that file system "pci > pci.txt".

 

[joevt]

@Crashing00
Please: are you able to get SSDTs from that MacBook regarding the Thunderbolt-implementation?
That would be great.

Use MaciASL.app to get the DSDT/SSDTs from the MacBook Pro. Use the "Export Tableset..." command in the File menu.
https://github.com/RehabMan/OS-X-MaciASL-patchmatic
https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/
The following commands will extract the binaries from the table set, in case you want to disassemble then to text files using the iasl command line.

# assume Tableset.acpi is in ~/Downloads
mkdir ~/Downloads/patched
pushd ~/Downloads/patched
eval $(plutil -p "../Tableset.acpi" | sed -En '/^ *"([^"]+)" => <([^>]+)>/s//echo -n "\2" | xxd -r -p > "\1.aml";/p')
popd

Use the IORegistryExplorer.app (version 2.1) to save the IO Registry (because it uses a UI).

Use the command "ioreg -l -w0 > ioreg.txt" to create a text file version (because text is better for copy/paste and search).

Use "sudo ./pcitree.sh" command to get the device tree listed with bus numbers etc. The pcitree script (see post above) uses pciutils so install that first by using the "sudo make install" command in the pciutils-master directory (with sudo you don't have to worry about permissions). You'll also need to make sure to add /usr/local/sbin to the /etc/paths text file if you haven't already. Don't forget to update the pciid database by executing "update-pciids".

What may also be useful is some logging. Use the following command:

sudo boot-args="debug=0x144 pci=0x45"

"debug=0x144" is required by pciutils (lspci, setpci).

The debug= flags are listed at https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/kern/debug.h.auto.html
and described at https://developer.apple.com/library...Conceptual/KernelProgramming/build/build.html
0x144 is DB_LOG_PI_SCRN + DB_ARP + DB_NMI

There is a version of lspci that uses it's own kernel extension instead of Apple's AppleACPIPlatformExpert so that it doesn't require sudo or the debug flags, but that version is out of date (doesn't show PCI Express 3.0 information).

I don't know exactly which flags pciutils requires because AppleACPIPlatformExpert is not open source, but 0x144 is the sugestion given in the error message if you don't have the flags.

The pci= flags are listed at https://opensource.apple.com/source...0.1.1/IOKit/pci/IOPCIConfigurator.h.auto.html
Use pci= to set flags and npci= to clear flags. I think we only care about kIOPCIConfiguratorIOLog. KPrintf is for serial port or firewire kprintf, but you can set some of the "debug=" flags to make IOLog also go to kprintf (I think one or both of DB_PRT and DB_KPRT).

The io= flags are listed at https://opensource.apple.com/source/xnu/xnu-4570.1.46/iokit/IOKit/IOKitDebug.h.auto.html

You can find more flags by googling

PE_parse_boot_argn site:opensource.apple.com

. You can find usage of flags be googling

"PE_parse_boot_argn pci" site:opensource.apple.com

.

Once you enable kIOPCIConfiguratorIOLog, restart the computer. Open Terminal.app, and start streaming the log using a command like this:

log stream --style syslog --predicate 'not senderImagePath ENDSWITH "/IOUSBHostFamily" and processImagePath ENDSWITH "/kernel"'

Execute that command. press Command-K to clear the Terminal window before you do something that you want to log. Unplug a Thunderbolt device. Copy the contents of the terminal window to a text file. Connect a Thunderbolt device. Copy the contents of the terminal window to another text file.

The results should give a clue how a workaround for hot plug may be created. The IOPCIFamily is open source. Hopefully we don't need to go into the IOThunderboltFamily which is not open source.

I've attached results from a Thunderbolt 2 MacBook Pro which has a Thunderbolt 1 FireWire adapter and a Thunderbolt 1 Ethernet adapter.

About the two Thunderbolt Display problem, a log without the IOUSBHostFamily exclusion filter might be useful (or at least informative). The problem probably occurs during boot when you don't have access to Terminal (it can't occur after boot because hot plug doesn't work for PCI devices over Thunderbolt on Hackintosh yet), so you want to use a variation of the log command that outputs past events after the boot.

log show --last boot --style syslog --predicate 'processImagePath ENDSWITH "/kernel"'

If the error doesn't occur in that log then you may need to add log flags for USB and/or power management. And you may need to exclude the kernel filter from the predicate if the error is reported in user space.

 

[PaulGemini]

Hi everyone,

My starting point: Z370 Aorus Gaming 7 + 8700K + GC TB3 1.0 on HighSierra 10.13.1...

I see that most here have gotten much farther than I

I installed Alpine Ridge TB3 Rev. 1.0 (in the PCI x4 and no M.2 in the lower slot), updated the latest drivers (getting the same "Controller Not Found" message when trying to update the FW and have a ticket pending with Gigabyte).

All works well in Windows 10 Pro, which leads me to believe that the card and the BIOS are ok. However, when trying to boot into Mac OS X 10.13.1, I immediately get the interdiction symbol. I have not installed any patches or kexts for Thunderbolt (yet) as I have read that AML files are extremely hardware-specific and none that I found matched my configuration.

I have tried disabling the various Thunderbolt settings, as suggested in other threads, as well as set Security to None. I also put the CSM to Enabled and Other PCI to the various combinations of Legacy, and such. The only way I can get the Mac to boot is to unplug the header cable, which of course defeats the whole purpose.

Being new to this, I will gladly provide any additional information than "I got the interdiction symbol"; just point me to how to get it; no need to retype everything here. I can also attach the EFI folder if needed (without themes and S/N).

Any ideas appreciated! Thanks. I'm sure it's a trivial bone-headed thing that I missed. Usual is... :,(

 

[joevt]

Hi everyone,

My starting point: Z370 Aorus Gaming 7 + 8700K + GC TB3 1.0 on HighSierra 10.13.1...

I see that most here have gotten much farther than I

I installed Alpine Ridge TB3 Rev. 1.0 (in the PCI x4 and no M.2 in the lower slot), updated the latest drivers (getting the same "Controller Not Found" message when trying to update the FW and have a ticket pending with Gigabyte).

The firmware of the GC-ALPINE RIDGE is probably the latest version already and doesn't need to be updated. Do you have a Thunderbolt device connected to it? Do you have DisplayPorts connected to the GC-ALPINE RIDGE? You may need to connect stuff to update the firmware.

Is your motherboard firmware updated?

All works well in Windows 10 Pro, which leads me to believe that the card and the BIOS are ok. However, when trying to boot into Mac OS X 10.13.1

What Thunderbolt device are you testing? Does it work in Windows?

I have tried disabling the various Thunderbolt settings, as suggested in other threads, as well as set Security to None. I also put the CSM to Enabled and Other PCI to the various combinations of Legacy, and such. The only way I can get the Mac to boot is to unplug the header cable, which of course defeats the whole purpose.

Can you disable Thunderbolt entirely to boot macOS?

I immediately get the interdiction symbol. I have not installed any patches or kexts for Thunderbolt (yet) as I have read that AML files are extremely hardware-specific and none that I found matched my configuration.

Try to boot with the card installed. Write down what time you started booting. Write down what time it crashed. Then unplug the card so you can boot and examine the log.

log show --start "2017-11-26 16:00:00" --end "2017-11-26 17:00:00" --style syslog --predicate 'processImagePath ENDSWITH "/kernel"'

The first thing that should appear in the log is "Derwin Kernel Version".

 

[PaulGemini]

The firmware of the GC-ALPINE RIDGE is probably the latest version already and doesn't need to be updated. Do you have a Thunderbolt device connected to it? Do you have DisplayPorts connected to the GC-ALPINE RIDGE? You may need to connect stuff to update the firmware.

Is your motherboard firmware updated?

I got the controller to show up after connecting an OWC Thunderbolt dock. The FW updater ran and showed that I am indeed up to date. So, I have the later TB drivers and Alpine Ridge FW from Gigabyte. I also connected my GTX 1080 into the card and out via HDMI to a monitor. That works as well on the windows side.

My motherboard is updated to F4a, which is the latest that I can find.

What Thunderbolt device are you testing? Does it work in Windows?

Yes. See above. I also connected a TB2 Drive through the dock and Windows see it (it's a Mac drive, so it can't open it, though, as expected).

The dock is connected to the card via an Apple TB3 to TB2 adapter.

Can you disable Thunderbolt entirely to boot macOS?

I still get the crash if I disable Thunderbolt support in the BIOS. Also, it appears that if I disconnect the TB header, but leave a device connected to the card, it also crashes. To boot in to MacOS, I can leave the card in place, but cannot connect anything to it. I'll keep trying other combinations of USB, monitor, and TB connections and will report again on what works, if any. [I did this; see EDIT just below]. So far, I can only boot with nothing connected to the card.

-----EDIT-----
Tested configurations again, more systemically. Tried connecting the DP in to either the GTX 1080 or the iGPU, then out via HDMI. Connected USB-C hub with USB devices. Connected TB Dock with TB HD. So long as I cold boot, I can boot into MacOS. The issue seem to appear once I connect the header cable.

Of note, when I first connected the TB dock, the boot process started (with the progress bar), then the computer restarted, and I eventually logged in. When I connected the DP in cable, the computer restarted twice, then logged in. These events only happen the first time that I connected the devices.
-----END EDIT-----

Try to boot with the card installed. Write down what time you started booting. Write down what time it crashed. Then unplug the card so you can boot and examine the log.

log show --start "2017-11-26 16:00:00" --end "2017-11-26 17:00:00" --style syslog --predicate 'processImagePath ENDSWITH "/kernel"'

The first thing that should appear in the log is "Derwin Kernel Version".

I don't see that. This is what was returned.

log: warning: The log archive contains partial or missing metadata

Filtering the log data using "processImagePath ENDSWITH "/kernel""

Skipping info and debug messages, pass --info and/or --debug to include.

Timestamp                       (process)[PID]   

2017-11-27 13:28:41.000027-0500  localhost kernel[0]: mem_actual: 0x1000000000

 legacy sane_size: 0xff8000000

Thank you for your help. I hope this helps others too!

 

[joevt]

I don't see that. This is what was returned.

log: warning: The log archive contains partial or missing metadata

Filtering the log data using "processImagePath ENDSWITH "/kernel""

Skipping info and debug messages, pass --info and/or --debug to include.

Timestamp                       (process)[PID]  

2017-11-27 13:28:41.000027-0500  localhost kernel[0]: mem_actual: 0x1000000000

 legacy sane_size: 0xff8000000

Thank you for your help. I hope this helps others too!

What is the output of the following command?

sudo log config --status

I think it should say "System mode = INFO"
If not, then you can add --info or --debug to the log show command line.
Or you can change the default configuration

sudo log config --mode "level:debug"

Even so, I think you should have seen more than one line. Try this:

log show --last boot --style syslog --predicate 'processID = 0'

This should dump the log for the current boot. This needs to work before you can see logging for previous boot times. 'processID = 0' is a more succinct way of saying 'processImagePath ENDSWITH "/kernel"'

The Thunderbolt add-in card is a PCI device which is a switch that connects to other PCI devices, so you may want to add PCI configurator logging to the boot args. In your Clover config.plist file, add "pci=1" to the boot arguments.

If the computer crashes without writing boot log to the log database (I don't know if that's a possible issue) then you may want to consider enabling kprintf from serial port (if your motherboard has a COM port) or Firewire port of an addin card to another computer. The Firewire port of a Thunderbolt dock or adapter should work to, except you're trying to debug the Thunderbolt port...

 

[PaulGemini]

What is the output of the following command?

sudo log config --status

I think it should say "System mode = INFO"
If not, then you can add --info or --debug to the log show command line.
Or you can change the default configuration

sudo log config --mode "level:debug"

Even so, I think you should have seen more than one line. Try this:

log show --last boot --style syslog --predicate 'processID = 0'

This should dump the log for the current boot. This needs to work before you can see logging for previous boot times. 'processID = 0' is a more succinct way of saying 'processImagePath ENDSWITH "/kernel"'

The Thunderbolt add-in card is a PCI device which is a switch that connects to other PCI devices, so you may want to add PCI configurator logging to the boot args. In your Clover config.plist file, add "pci=1" to the boot arguments.

If the computer crashes without writing boot log to the log database (I don't know if that's a possible issue) then you may want to consider enabling kprintf from serial port (if your motherboard has a COM port) or Firewire port of an addin card to another computer. The Firewire port of a Thunderbolt dock or adapter should work to, except you're trying to debug the Thunderbolt port...

Ok, I think we're getting somewhere. The System mode was indeed INFO. Adding debug didn't change anything, neither did adding pci=1, but I did add it to my plist.

The stop sign comes up immediately upon selecting the boot drive in Clover; no progress bar, which makes me suspect that the boot process doesn't even start. It looks like it fails at the hardware check. Booting with verbose flag, I get this (this is the entire output):

(see attached)

So it looks like the device tree is the issue. FWIW, I am using Clover r4259.

Tried substituting OsxAptioFix2Drv-free2000.efi and OsxAptioFixDrv-64.efi for OsxAptioFix2Drv-64.efi, but then I can't boot at all (dark screen).

 

[joevt]

Ok, I think we're getting somewhere. The System mode was indeed INFO. Adding debug didn't change anything, neither did adding pci=1, but I did add it to my plist.

The stop sign comes up immediately upon selecting the boot drive in Clover; no progress bar, which makes me suspect that the boot process doesn't even start. It looks like it fails at the hardware check. Booting with verbose flag, I get this (this is the entire output):

(see attached)

So it looks like the device tree is the issue. FWIW, I am using Clover r4259.

I don't think I've seen the device tree error before. But I have seen the alloc type 2 error. That usually happens for me if I try using Intel Graphics instead of Nvidia, but it may be random - it would successfully boot after a few tries. Maybe you need to use a different aptiofix driver, or some other memory fix driver or option.

The log should work when you have a successful boot. The first line might be "kernel: memory_actual: 0x80000000" but the "Darwin Kernel Version" line should be in the first 10 lines.

Check the pci device list in the Clover boot log. I don't think you'll find anything wrong there. You can check the devtree and pci commands in the EFI Shell. Those should also be reasonable.