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

[CaseySJ]

MISSION UPDATE #1:

This will be today's mission!

Step 1:
Attempt the 10K pull-up resistor method to read Flash ROM. Fortunately I have an Arduino kit that includes many resistors of various Ohms, including 10K. If this method can reliably read W25Q80DV in-circuit, then it's on to next step.

• With a 10 kOhm resistor between CS and Vcc (Pins 1 and 8), unfortunately neither Option 1 nor Option 2 resulted in reliable in-circuit reading.
• Will try again with a different resistor.

...
Step 3:
Use the TbtOnPch method to modify 10 bytes. Use a script registered with Launch Daemon to run automatically on startup with root privileges.

• Created the necessary shell scripts to run tbpatch automatically with root privileges. It works.
• More details coming in subsequent post.

 

[NorthAmTransAm]

@CaseySJ I cannot wait to see where you get with tbpatch. So cool to watch all of this further develop into what I imagine is a method that is simplified for most people.

When you bricked your Titan Ridge, did the flasher only show one quick blip of green light (go) then nothing else? I cannot tell if my spare card is dead from something previous or bricked and am unsure of the solution.

No pressure to respond to this right now. Onward!

 

[Elias64Fr]

@Elias64Fr

Because I'm currently running your modified firmware, tbpatch is fully working. Do you think it can be used to completely re-flash the entire W25Q80DV? Even the TI Power Delivery section? Alternatively, I can flash only the Thunderbolt section.
View attachment 454625
Because tbpatch seems to work on our TPS65983, why does this warning appear on Osy86's GitHub page?
View attachment 454623

@CaseySJ

I don't think that it will be possible for now because of tbpatch code that use only plist file as input data. But If someone has little time to make another version that use an HEX (or BIN) format as input by extracting 2x8byte per 2x8bytes, it should possible
Unfortunately you can't use plist file for all 1Mbytes except if you have longest week to make all splitted plist files .. but it would be a miracle if it work at first time !

About warning message, only god know .. and for sure Osy86 coder. On my case it work like a charm, probably due to similar command/register for both model TPS65982/TPS65983. No more questioning, it work or not
If we use tbpatch list result command and GitHub description, we can see that 2 kind of access are possible :

1. By I2C interface if wired on motherboard (not the case on Designare but ready on my laptop .. unfortunately its TPS65988)
2. By AppleHPMIECS interface that appear only on full thunderbolt tree, that's the reason that we should have an unoperational SSDT specifically for full tree by removing all unrequired method (I think about RTPCs especially that could cause access lost , all _PSx and XHC2 configuration). Like said on my previous post, we can have an access on SSDT aml code (via CIOR/CIOW) to the flash ROM. I have successfully read DROM offset data from VSEC register, but, for now I don't know how I can read/write by using bit banging method. I think that patching could be done with only an SSDT with long work a research.. to much for me

UPDATE:
On Github Osy86 code, we have some informations about TI PD used and It seem to be compatible with all family TP6598x (command and register location to be verified on other than TPS65982) :

 

[z4k]

I can't seem to get FaceTime and Messages working on my Hackintosh. OpenCore 0.5.5 with @CaseySJ Guide and SSDTs. Tried Resetting NVRAM (I think it worked since once I booted in MacOS it required me to allow certain extensions to startup with the os again) Always getting a You cannot sign in to FaceTime on this Mac at this time. (Same for Messages)

Info:
-BIOS F7
-I have working NVRAM, confirmed with [TestVar Hello] after restart.
-I haven't touched MSR 0xE2 at all. This system is brand new everything built for running this Hackintosh, no other OS. -Logged out and back in to iCloud, also cleaned up every device associated with this iCloud account from iCloud devices.
-Verifying MSR 0xE2 lock (selecting the option from OC boot picker) returned this:
This firmware has LOCKED MSR 0xE2 register!
-Selected "Clear NVRAM" from Picker, waited till I got inside white MacOS recovery screen and just booted to my Mojave drive from there.

Problem persists...

Questions:
-Is selecting the "Clear NVRAM" option from Picker dangerous to my system since 0xE2 is locked?
-I'm using i219V7 (BSD name: en0). There is NO wifi/BT card on my system at all.
-Should I try to unlock MSR 0xE2 or is it still considered a dangerous procedure for someone with basic Hackintosh knowledge? If yes, can someone point me to a specific guide to us or should I just follow the guide from OpenCore release?

Thanks in advance!!

 

[Elias64Fr]

@CaseySJ I cannot wait to see where you get with tbpatch. So cool to watch all of this further develop into what I imagine is a method that is simplified for most people.

When you bricked your Titan Ridge, did the flasher only show one quick blip of green light (go) then nothing else? I cannot tell if my spare card is dead from something previous or bricked and am unsure of the solution.

No pressure to respond to this right now. Onward!

Hi @NorthAmTransAm
for a quick answer, if you have a programmer that can read/write your SPI Flash ROM, you can easily unbrick your board .. but only if previously bricked due to bad file/data flashing... not burned component

 

[CaseySJ]

** Mini-Guide: Running Osy86's "tbpatch" Automatically on System Startup **
Please do not quote this mini-guide in its entirely. Post a link instead.​

This mini-guide works only with a custom Thunderbolt SSDT that enables Thunderbolt Bus without a firmware patch. This mini-guide is still a work in progress...

First we copy Osy86's tbpatch to /Users/Shared folder. Then we do the following:

Script #1: This is used to determine the UUID of the AppleHPM device.

• We run this first.
• It outputs the result into /Users/Shared/patchlist.txt
• We save this script in the /Users/Shared folder as filename tbpatch_list.sh
• Then we provide file-execute permission by typing chmod +x /Users/Shared/tbPatch_list.sh

#!/bin/bash -xe
sudo /Users/Shared/tbpatch list 2> /Users/Shared/patchlist.txt

• Now we register /Users/Shared/tbpatch_list.sh with Launch Daemons so it will run automatically on boot.
• First we copy the file below to /Library/LaunchDaemons as filename local.tbpatch.plist.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/Shared/tbpatch_list.sh</string>
    </array>
    <key>Label</key>
    <string>local.tbpatch</string>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <false/>
</dict>
</plist>

• Then we register it with Launch Daemons as follows:

launchctl load /Library/LaunchDaemons/local.tbpatch.plist

• Now we reboot. When the computer restarts, we login, open Terminal and type cd /Users/Shared.
• When we examine the newly created file patchlist.txt, we see something like this:

% cd /Users/Shared
% cat patchlist.txt
/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP05@1C,4/IOPP/UPSB@0/IOPP/DSB0@0/IOPP/NHI0@0/AppleThunderboltHAL/AppleThunderboltNHIType3/IOThunderboltController/IOThunderboltPort@7/IOThunderboltSwitchType3/IOThunderboltIECSNub/AppleHPMIECS/AppleHPMDevice@0
  Address : 0x00000000
  PID     : 0x2831454341
  UID     : 1A43A00E-39A4-68AD-804C-12C1EF39A6F5
  Version : 8
  Build   : a0566aa071c0a0cabf803a9532caee53ddd2ced5_03012018
  Device  : TPS65983 HW0030 FW0001.38.04 ZTBT1

/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP05@1C,4/IOPP/UPSB@0/IOPP/DSB0@0/IOPP/NHI0@0/AppleThunderboltHAL/AppleThunderboltNHIType3/IOThunderboltController/IOThunderboltPort@7/IOThunderboltSwitchType3/IOThunderboltIECSNub/AppleHPMIECS/AppleHPMDevice@1
  Address : 0x00000001
  PID     : 0x2831454341
  UID     : 2D53A00E-3A34-BD84-6B49-81C21C68F450
  Version : 8
  Build   : a0566aa071c0a0cabf803a9532caee53ddd2ced5_03012018
  Device  : TPS65983 HW0030 FW0001.38.04 ZTBT1

• The UUID we need is the first one next to UID, namely: 1A43A00E-39A4-68AD-804C-12C1EF39A6F5.
• Your system may have a different UID so do not just copy-and-paste this one!

Script #2: Now we modify the /Users/Shared/tbpatch_list.sh script to this (after copying/pasting UUID from /Users/Shared/patchlist.txt):

#!/bin/bash -xe
sudo /Users/Shared/tbpatch dump -p RP05 -u 1A43A00E-39A4-68AD-804C-12C1EF39A6F5 -o 0x4000 -s 0x1000 -f /Users/Shared/First4KBytes.bin 2> patch_output.txt

• This will read the first 4096 bytes of the active partition into the file /Users/Shared/First4KBytes.bin.
• We save the changes and reboot.
• When the computer restarts, we login, open Terminal and type cat /Users/Shared/patch_output.txt.
  • If there are any errors, they will be in this file.
• Now we run Hex Fiendor any binary file viewer.
  • We open /Users/Shared/First4KBytes.bin and we get:

---

We can simplify the procedure by using only a single script as follows:

#!/bin/bash -xe
sudo /Users/Shared/tbpatch dump -p RP05 -o 0x4000 -s 0x1000 -f /Users/Shared/First4KBytes.bin 2> patch_output.txt

• By omitting the UID field (-u) and using only -p RP05, the script will use the first UID for RP05.
• On Designare Z390, this method will work.

 

[NorthAmTransAm]

Hi @NorthAmTransAm
for a quick answer, if you have a programmer that can read/write your SPI Flash ROM, you can easily unbrick your board .. but only if previously bricked due to bad file/data flashing... not burned component

I was suspicious of this card about 6 months ago. I thought the power was off when I plugged it in. It uh, wasn't. I think it's very dead. It was inexpensive and I have a second one so no big deal. I thought it was reading the other day but I might have had it confused with my other card. Too bad this one is the exact wrong nvm. Cant find my firmware to save my life.

 

[S1lla]

@Elias64Fr

Because I'm currently running your modified firmware, tbpatch is fully working. Do you think it can be used to completely re-flash the entire W25Q80DV? Even the TI Power Delivery section? Alternatively, I can flash only the Thunderbolt section.
View attachment 454625
Because tbpatch seems to work on our TPS65983, why does this warning appear on Osy86's GitHub page?
View attachment 454623

Save the modified firmware via SPI, I can write an tool for patching via macos without the risk to brick the chip if you are not in time.

 

[Ploddles]

-Should I try to unlock MSR 0xE2 or is it still considered a dangerous procedure for someone with basic Hackintosh knowledge? If yes, can someone point me to a specific guide to us or should I just follow the guide from OpenCore release?

Thanks in advance!!

Just follow the steps in the mini guide HERE

 

[CaseySJ]

@CaseySJ

I don't think that it will be possible for now because of tbpatch code that use only plist file as input data. But If someone has little time to make another version that use an HEX (or BIN) format as input by extracting 2x8byte per 2x8bytes, it should possible
Unfortunately you can't use plist file for all 1Mbytes except if you have longest week to make all splitted plist files .. but it would be a miracle if it work at first time !

About warning message, only god say .. and for sure Osy86 coder. On my case it work like a charm, probably due to similar command/register for both model TPS65982/TPS65983. No more questioning, it work or not
If we use tbpatch list result command and GitHub description, we can see that 2 kind of access are possible :

1. By I2C interface if wired on motherboard (not the case on Designare but ready on my laptop .. unfortunately its TPS65988)
2. By AppleHPMIECS interface that appear only on full thunderbolt tree, that's the reason that we should have an unoperational SSDT specifically for full tree by disabling all unrequired method (I think about RTPCs especially that could cause access lost , all _PSx and XHC2 configuration). Like said on my previous post, we can have an access on SSDT aml code (via CIOR/CIOW) to the flash ROM. I have successfully read DROM offset data from VSEC register, but, for now I don't know how I can read/write by using bit banging method. I think that patching could be done with only an SSDT with long work a research.. to much for me

• No problem -- I will use external flasher to restore the original Thunderbolt firmware.
• I have also tested the automatic boot-time script to run tbpatch. This option may be viable with the "unoperational" SSDT to enable Thunderbolt Bus for 20 seconds!