Contribute
Register

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

Everything looks fine in the May EFI folder. Please try this:
  • Boot using OpenCore 0.6.9 (May EFI)
  • At the OpenCanopy GUI press and release CMD-V to enable Verbose
  • Then boot macOS
  • When the boot process hangs grab a photo and then:
    • Remove EXIF location info from the photo
    • Resize it so that file is no larger than about 512KB to 768KB
    • Post the photo
Thanks Casey,

So the first time it booted in ok. I restarted and got stuck 3 times with different errors (attached photos). The fifth time it booted again ok. I am hesitant to copy the EFI to SSD till I''m sure it works. Thanks again for your help
 

Attachments

  • IMG_3721.png
    IMG_3721.png
    19.7 MB · Views: 72
  • IMG_3722.png
    IMG_3722.png
    18.4 MB · Views: 73
  • IMG_3723.png
    IMG_3723.png
    18.6 MB · Views: 73
Thanks Casey,

So the first time it booted in ok. I restarted and got stuck 3 times with different errors (attached photos). The fifth time it booted again ok. I am hesitant to copy the EFI to SSD till I''m sure it works. Thanks again for your help
That's very peculiar. Some questions:
  • What is the make/model of your NVMe SSD?
  • What is the total capacity of the NVMe SSD?
  • How much space is left?
 
From the Apple open source page for Big Sur 11.2 (file csr.h), the bit flags for SIP are as follows:
C:
/* CSR configuration flags */
#define CSR_ALLOW_UNTRUSTED_KEXTS               (1 << 0)
#define CSR_ALLOW_UNRESTRICTED_FS               (1 << 1)
#define CSR_ALLOW_TASK_FOR_PID                  (1 << 2)
#define CSR_ALLOW_KERNEL_DEBUGGER               (1 << 3)
#define CSR_ALLOW_APPLE_INTERNAL                (1 << 4)
#define CSR_ALLOW_DESTRUCTIVE_DTRACE                    (1 << 5) /* name deprecated */
#define CSR_ALLOW_UNRESTRICTED_DTRACE                   (1 << 5)
#define CSR_ALLOW_UNRESTRICTED_NVRAM                    (1 << 6)
#define CSR_ALLOW_DEVICE_CONFIGURATION                  (1 << 7)
#define CSR_ALLOW_ANY_RECOVERY_OS                       (1 << 8)
#define CSR_ALLOW_UNAPPROVED_KEXTS                      (1 << 9)
#define CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE    (1 << 10)
#define CSR_ALLOW_UNAUTHENTICATED_ROOT                  (1 << 11)

The command csrutil disable properly disables SIP. It does so by setting the following flags:
C:
/* Flags set by `csrutil disable`. */
#define CSR_DISABLE_FLAGS (CSR_ALLOW_UNTRUSTED_KEXTS | \
                       CSR_ALLOW_UNRESTRICTED_FS | \
                       CSR_ALLOW_TASK_FOR_PID | \
                       CSR_ALLOW_KERNEL_DEBUGGER | \
                       CSR_ALLOW_APPLE_INTERNAL | \
                       CSR_ALLOW_UNRESTRICTED_DTRACE | \
                       CSR_ALLOW_UNRESTRICTED_NVRAM)

This equates to binary 0000 0000 0111 1111 or hex 0x007F. In reverse byte order (needed for OpenCore) this is 7F00. But two additional flags are always enforced:
C:
#define CSR_ALWAYS_ENFORCED_FLAGS (CSR_ALLOW_DEVICE_CONFIGURATION | CSR_ALLOW_ANY_RECOVERY_OS)

If we add the bit flags for these, the SIP value becomes binary 0000 0001 1111 1111 or hex 0x01FF. In reverse byte order this is FF01.

But if we want to go beyond Apple's csrutil disable and disable everything, then we can specify binary 0000 1111 1111 1111 or hex 0x0FFF. In reverse byte order this is FF0F.

Now let's look at 67000000. We ignore the last 4 bytes and examine only 6700, which we know is in reverse byte order because we're getting this value from OpenCore config.plist. Switching the bytes we get 0x0067 or binary 0000 0000 0110 0111. We can decode this as follows:
C:
#define CSR_ALLOW_UNTRUSTED_KEXTS               (1 << 0)
#define CSR_ALLOW_UNRESTRICTED_FS               (1 << 1)
#define CSR_ALLOW_TASK_FOR_PID                  (1 << 2)
...
#define CSR_ALLOW_UNRESTRICTED_DTRACE                   (1 << 5)
#define CSR_ALLOW_UNRESTRICTED_NVRAM                    (1 << 6)
Happy now? :) Bottom line: Do not worry about it. We've been running with SIP completely disabled for years.
I tell you what that’s a pretty clear explanation considering! thanks again
 
That's very peculiar. Some questions:
  • What is the make/model of your NVMe SSD?
  • What is the total capacity of the NVMe SSD?
  • How much space is left?
I have two 1TB WD-Black SN750 NVMe. One has Windows 10 (closer to the CPU), the other is Mac. I have 840GB free space in Mac and similar in Windows. I tried restarting again and get different errors in Verbose.
 

Attachments

  • IMG_3726.png
    IMG_3726.png
    18.8 MB · Views: 57
  • IMG_3727.png
    IMG_3727.png
    18.2 MB · Views: 59
  • IMG_3728.png
    IMG_3728.png
    16.4 MB · Views: 66
I have two 1TB WD-Black SN750 NVMe. One has Windows 10 (closer to the CPU), the other is Mac. I have 840GB free space in Mac and similar in Windows. I tried restarting again and get different errors in Verbose.
Suggestion 1:
Try disabling NVMeFix.kext from the Kernel section of config.plist and rebooting. Alternatively, we can copy this file from the OC 0.6.8 folder to the OC 0.6.9 folder.

The WD Black SN750 should, however, work just fine.

Suggestion 2:
Perform CMOS Reset and configure BIOS parameters again, starting with F7 (Load Optimized Defaults). BIOS --> CFG-Lock must also be Disabled. We should not use BIOS F9j. Instead, F9g and F9i are okay.
 
Suggestion 1:
Try disabling NVMeFix.kext from the Kernel section of config.plist and rebooting. Alternatively, we can copy this file from the OC 0.6.8 folder to the OC 0.6.9 folder.

The WD Black SN750 should, however, work just fine.

Suggestion 2:
Perform CMOS Reset and configure BIOS parameters again, starting with F7 (Load Optimized Defaults). BIOS --> CFG-Lock must also be Disabled. We should not use BIOS F9j. Instead, F9g and F9i are okay.
Thank You Casey, you rock man. Copying the old NVMeFix.kext worked.
So should I wait for the next kext update or is there a way to fix the current one?
 
Thank You Casey, you rock man. Copying the old NVMeFix.kext worked.
So should I wait for the next kext update or is there a way to fix the current one?
It may be necessary to report this bug to the Acidanthera developers. Or we can hope that someone has already done so and a fix will appear in the next release. Meanwhile there’s no downside to running the old version.
 
It may be necessary to report this bug to the Acidanthera developers. Or we can hope that someone has already done so and a fix will appear in the next release. Meanwhile there’s no downside to running the old version.
Thank you, I will let them know. Have a great weekend
 
One more question. I was thinking about getting the Raspberry Pi 4 to flash the onboard Thunderbolt chip. I mainly want to do it so I can access the full capability of my QNAP through Thunderbolt.
Is it worth it and what is the success rate?
 
One more question. I was thinking about getting the Raspberry Pi 4 to flash the onboard Thunderbolt chip. I mainly want to do it so I can access the full capability of my QNAP through Thunderbolt.
Is it worth it and what is the success rate?
This is a legitimate reason for flashing the on-board controller! The process can be straightforward if we follow all of the precautions such as removing corrective lenses if we are near sighted (i.e. use natural near sightedness for close up work), attaching and detaching the SOIC clip gently every time without touching any nearby surface mount devices, wiring the SOIC clip properly and double-checking all connections, etc.
 
Back
Top