[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

[bluepr0]

The display takes 10 bpc pixels and uses FRC to simulate 10 bits on an 8 bit panel by changing the color each frame.

Frame rate control - Wikipedia

en.wikipedia.org

You can use SwitchResX to switch between millions (8 bpc) and billions (10 bpc) of colors.

Oh I see. So even if we can confirm that the new LG 5K is using DP1.4, it won’t be using all its potential color wise due to the lack of bandwidth... so I’m off better using an Alpine/Titan ridge card anyway.

Wondering why they even bothered (if confirmed) to update the new LG to a Titan ridge card.

 

[mobi]

VirtualSMC 1.0.7 has been running quite well on my system. If you copied this kext to /Library/Extensions, did you remember to run Kext Utility to rebuild the kernel cache?

Yes, I'm aware, but , just running from EFI folder (like I had previous 1.06 version), not from L/E

 

[CaseySJ]

Oh I see. So even if we can confirm that the new LG 5K is using DP1.4, it won’t be using all its potential color wise due to the lack of bandwidth... so I’m off better using an Alpine/Titan ridge card anyway.

Wondering why they even bothered (if confirmed) to update the new LG to a Titan ridge card.

This excerpt from AnandTech suggests that Titan Ridge enables DisplayPort over a conventional (non-Thunderbolt) USB-C connection -- specifically from the 2018 iPad Pro. Sadly the AnandTech article does not state that the new LG 5K incorporates DisplayPort 1.4. That was our wish!

 

[zipb]

Nice to see the initiative!

I am still a bit skeptical about manually injecting device properties that are supposed to be injected by Apple's EFI driver (ThunderboltNHI.efi). Let's look at this:

We can disassemble the ThunderboltNHI.efi driver using any of several disassemblers such as Hopper. We can see that the binary EFI file is separated into code segments and text segments (just like any other binary executable file). If we look at the text segments (the green section of the horizontal bar along the top) look what we find:
View attachment 421652View attachment 421650

• tbt-scc-offset
• tbt-options
• pathcrumbsv2
• pathcr
• sccOffset
• ThunderboltDROM
• ThunderboltUUID
• TBTDPLowToHigh
• And a few others...

Your plist file is inserting the ones boldfaced above. The disassembler also produces both assembly code and C-like pseudo-code. The pseudo-code is still difficult to read, but better than nothing. Here's an example of the pseudo-code for a subroutine (or function) that injects ThunderboltDROM, ThunderboltUUID, and TBTDPLowToHigh:
View attachment 421651
While some of these properties are simple data types (such as ThunderboltUUID and TBTDPLowToHigh), others are arrays of hex values such as ThunderboltDROM, pathcr, and pathcrumbsv2. The values in these arrays may not be conducive to a simple copy-and-paste.

This is just the EFI side of the equation. The other side consists of the various ACPI methods and objects in the Thunderbolt SSDT that we are unable to duplicate because our DSDT does not contain equivalencies. For example, on a MacBook Air 7,1 with Falcon Ridge Thunderbolt 2 controller, the native Thunderbolt-on-PCI SSDT references a number of GPIO registers that simply don't exist in the DSDT of the Asus X99 Deluxe II. We could try to fake them, but it's not that simple because each GPIO on a real Mac is physically tied to a circuit element, and we would have to determine if those circuit elements also exist on our motherboard and where to find them in the ACPI structure.

All of this might sound discouraging, but it is also a nice challenge. And we can make stepwise progress rather than an all-or-nothing outcome. For example, I've been able to port a subset of the ACPI methods related to Thunderbolt Power Conservation, and the boot log confirms that power conservation is enabled. I've also attempted to port huge chunks of the SSDT, but with very mixed results. A proper solution, I believe, involves both (a) EFI drivers, and (b) ACPI methods/objects.

If we figure out TB on Hacks, that would be like going past the final frontier...

Unfortunately, I'm too tied up with lots of other things to be of much help here.

 

[ubidefeo]

@CaseySJ
Something which could make it into an update to the post:

ABSOLUTELY
DO NOT
USE
USB HUBS

not really sure why but it kept shutting down and rebooting afte the first "Install Mac OS from Mojave" and never continued further.
Unplugged the Hub (Keyboard was going through it) and I'm finally moving forward (now at "graceful restart")

 

[mobi]

@CaseySJ
Something which could make it into an update to the post:

ABSOLUTELY
DO NOT
USE
USB HUBS

Even with real Macs, as a rule of thumb, things like input devices better straight to the computer...

 

[ubidefeo]

Even with real Macs, as a rule of thumb, things like input devices better straight to the computer...

I know, I know...
16 years of Macs and I still do these things

@CaseySJ
Plugging the BlackMagic UltraStudio Mini and seeing it appear as a result of TB hot-plug is priceless.
do you have a kofi account or something? Do you accept donations?
I'd really love to offer you a coffee, beer, cake whatever

 

[Westsurf]

That’s quite possible. On which motherboard is this happening?

On my Asus X99 Deluxe II there is a similar problem with an NVMe SSD mounted to a PCIe Card. Fortunately, though, we have a SSDT that registers it as an Internal drive.

GA-Z77X-UP5-TH as per my build. Probably complicated by the fact that to get NVMe M.2 drives to be recognized on boot took a modified BIOS which was found on Tweaktown.

Moments like this I wish I had more knowledge than I do. I’ve literally only compiled my first SSDT for USB ports, days ago, to utilize.

Would you able to point my to a thread / post to do the same as the X99 for the Z77X?

 

[NorthAmTransAm]

Nice to see the initiative!

I am still a bit skeptical about manually injecting device properties that are supposed to be injected by Apple's EFI driver (ThunderboltNHI.efi). Let's look at this:

We can disassemble the ThunderboltNHI.efi driver using any of several disassemblers such as Hopper. We can see that the binary EFI file is separated into code segments and text segments (just like any other binary executable file). If we look at the text segments (the green section of the horizontal bar along the top) look what we find:
View attachment 421652View attachment 421650

• tbt-scc-offset
• tbt-options
• pathcrumbsv2
• pathcr
• sccOffset
• ThunderboltDROM
• ThunderboltUUID
• TBTDPLowToHigh
• And a few others...

Your plist file is inserting the ones boldfaced above. The disassembler also produces both assembly code and C-like pseudo-code. The pseudo-code is still difficult to read, but better than nothing. Here's an example of the pseudo-code for a subroutine (or function) that injects ThunderboltDROM, ThunderboltUUID, and TBTDPLowToHigh:
View attachment 421651
While some of these properties are simple data types (such as ThunderboltUUID and TBTDPLowToHigh), others are arrays of hex values such as ThunderboltDROM, pathcr, and pathcrumbsv2. The values in these arrays may not be conducive to a simple copy-and-paste.

This is just the EFI side of the equation. The other side consists of the various ACPI methods and objects in the Thunderbolt SSDT that we are unable to duplicate because our DSDT does not contain equivalencies. For example, on a MacBook Air 7,1 with Falcon Ridge Thunderbolt 2 controller, the native Thunderbolt-on-PCI SSDT references a number of GPIO registers that simply don't exist in the DSDT of the Asus X99 Deluxe II. We could try to fake them, but it's not that simple because each GPIO on a real Mac is physically tied to a circuit element, and we would have to determine if those circuit elements also exist on our motherboard and where to find them in the ACPI structure.

All of this might sound discouraging, but it is also a nice challenge. And we can make stepwise progress rather than an all-or-nothing outcome. For example, I've been able to port a subset of the ACPI methods related to Thunderbolt Power Conservation, and the boot log confirms that power conservation is enabled. I've also attempted to port huge chunks of the SSDT, but with very mixed results. A proper solution, I believe, involves both (a) EFI drivers, and (b) ACPI methods/objects.

Wow Im going to have to read over this quite a bit. Thanks for all the detail. Pretty incredible. Let me know if you need a lab rat for anything experimental.

 

[totototo]

Is Apple Watch unlock working right after waking up from sleep? I have to wake first then press ESC and hit keyboard again to unlock with watch. I am using darkwake=0.