Contribute
Register

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

@ CaseySJ,

I have everything running very good at 10.15.2 and try to update the Mac OS to 10.15.3. After pressing the “update now” and the machine need to restart as normal However, it is still 10.15.2 after the machine boot up. Any idea to fix it?

Keith
 
@ CaseySJ,

I have everything running very good at 10.15.2 and try to update the Mac OS to 10.15.3. After pressing the “update now” and the machine need to restart as normal However, it is still 10.15.2 after the machine boot up. Any idea to fix it?

Keith
Please see this post:
 
I'm seeing this exact same behavior. I figured it was due to running Developer BETA code and when the final release comes out it would all be magical and fix the issue. I did a backup and untethered the backup from my Dev upgrades, and was able to restore back to 10.15.2 and then upgrade like normal to 10.15.3.
 
@CaseySJ Once again congrats on the awesome guide on unlocking MSR 0xE2. Everything went absolutely smooth and now it is properly unlocked.

-Made new serials as per OpenCore guide (valid but unused)
-Used my MAC address in config plist, the one from our Intel I219V7
-Ethernet port in use BSD name is en0
-Cleared all caches before retrying
-Made a brand new Apple ID with NO other devices except my new iMac19,1 connected to it.
-Enabled 2 step verification.

(Note I did all that BEFORE trying to login to Messages/Facetime so as not to block my new account from too many attempts)

Sadly even after all this the Messages/Facetime problem persists. The only step forward is the awkward Apple contact?
 
...
-Ethernet port in use BSD name is en0
...
Sadly even after all this the Messages/Facetime problem persists. The only step forward is the awkward Apple contact?
Because en0 exists, have you tried any of the following:
  • Deleting /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist and rebooting?
  • Ensuring that ROM field in OpenCore config.plist uses MAC address of en0?
  • Clearing NVRAM now that NVRAM is working?
 
Last edited:
** Mission Update **

Recap of today's mission statement:

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.

Step 2:
Flash original firmware back and verify.

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.

Step 4:
If I brick the system again with Step 3, I'll modify those 10 bytes directly in original firmware and flash entire thing with external programmer.


MISSION REPORT

Mission 1: Use of Pull-Up Resistors to Facilitate In-Circuit Chip Reading
  • Despite the use of 10K Ohm, 2K Ohm, and 1K Ohm pull-up resistors, the on-board flash chip remained difficult to read. So this does not seem to be viable solution.
  • However, others with more experience in this area might be able to find a way.
Mission 2: Flash Original Firmware Back
  • Using the Raspberry Pi and carefully adjusting the SOIC8 clip over the Winbond chip until the LEDs on motherboard were a faint shade of red, it was possible to flash the original firmware back.
Mission 3: Use Osy86's tbpatch to Modify 7 Bytes in Thunderbolt Firmware
  • This was the most potentially exciting possibility.
  • However, after several hours of attempts, it was not successful.
  • Automatic boot script was created to read 4K bytes of Thunderbolt firmware four times in a row.
    • This was successful.
  • But subsequent attempt to modify 7 bytes in firmware failed.
    • Attempt 1 failed during the first read operation, so firmware was unchanged.
    • Attempt 2 failed during the write operation, so Thunderbolt controller got bricked again.
Mission 4: Manually Change 7 Bytes in Original Firmware and Flash the Whole Thing Back
  • The Thunderbolt controller was bricked anyway, so why not just modify the firmware manually and flash it in?
  • Using the Raspberry Pi, this succeeded. The result of this is very promising just as @Elias64Fr pointed out yesterday.


Result of Flashing Modified Original Firmware (7 Bytes Changed)

Screen Shot 2020-03-15 at 1.06.42 PM.png

Testing is under way, but preliminary result shows:
  • Both DSB1 and DSB4 ports are functional.​
  • Hot plug is functional.​
  • Thunderbolt devices not only connect, they work as well.​
  • Link Speed and Link Status are correct -- including 40 Gbps.​
  • USB controller is still alive and kicking!​
Preliminary Conclusion:
  • With only 7 bytes modified and a simple SSDT added for enabling hot-plug, the results so far are better than anything we've yet seen on this motherboard.
 
Last edited:
More Updates:
  • Apple Ethernet adapter was hot-unplugged, and eGPU was hot-plugged. eGPU attached without any problem.​

Screen Shot 2020-03-15 at 1.42.28 PM.pngScreen Shot 2020-03-15 at 1.43.15 PM.pngScreen Shot 2020-03-15 at 1.42.58 PM.pngScreen Shot 2020-03-15 at 2.21.19 PM.png
Screen Shot 2020-03-15 at 1.44.02 PM.png
 
Last edited:
The Awesomeness Continues:

  • Hot-unplugged the Belkin Thunderbolt 3 Dock Pro.
  • Hot-plugged a USB-C flash drive. It works!
  • On port 2 nevertheless -- DSB4 / SSP2.
Screen Shot 2020-03-15 at 1.49.56 PM.png
 
Last edited:
Quick Thoughts and Firmware Files

  • @Elias64Fr -- you have certainly proved yourself. You tackled some of the most challenging problems we were facing and offered many different options. I gained significantly more knowledge about ACPI than I ever expected I would.
    • On behalf of the entire community, thank you! :clap:
  • The results I'm seeing with the on-board Titan Ridge controller are the best I've ever seen. They're better than using a GC-Titan Ridge with flashed firmware.
  • Although there may be room for improvement (i.e. to somehow make it more Windows compatible), I am surprised it took only 7 bytes! Color me impressed...
  • Update: My goodness, even sleep/wake works!
Now we need to find a way to make this easier for others to adopt...

If you are somehow able to flash your Designare Z390 firmware, the modified firmware file and associated SSDT is attached. If you do this, you incur all risk and responsibility for your actions and the consequences of those actions. If you brick your system, you may not blame anyone but yourself.
 

Attachments

  • designare_z390_tb3_rom_1-Elias64Fr-Mod.bin.zip
    268.7 KB · Views: 432
  • SSDT-TBOLT3-RP05-V3.aml
    2 KB · Views: 368
Last edited:
Back
Top