Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
I tried the script to no avail. I then put my old bootx64.efi file in place and used the old command I had. That worked, but of course OpenCore no longer works. Any ideas on how to use both OpenCore and enable booting into Windows?
Can you boot back to OS X from Windows? If yes mount that EFI and bless:
Code:
sudo bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/OC/OpenCore.efi  --verbose
 
To reboot back into macOS I had to first boot into recovery and set the -no_compat_check boot-arg.
I usually patch my Catalina with dosdude's USB so I can boot without OC, but it is a personal preference. If you are in recovery you should be able to bless the EFI as well.
 
Just ran Linux UEFI validation distro:
Below are all MSR registers
Code:
;HED msr: MSR register tests.
;SEP ------------------------------------------------------------
;INF Test 1 of 5: Test CPU generic MSRs.
;PAS PASSED: Test 1, MSR 0x00000001 P5_MC_TYPE is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000006 MONITOR_FILTER_SIZE is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000017 PLATFORM_ID is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000002a EBL_CR_POWERON is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000001b APIC_BASE is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000003a FEATURE_CONTROL is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000008b BIOS_SIGN_ID is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x000000fe MTRRCAP is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000179 MCG_CAP is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000017a MCG_STATUS is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000019a CLOCK_MODULATION is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000019b THERM_INTERRUPT is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x000001a0 MISC_ENABLE is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x000001f2 SMRR_PHYSBASE is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x000001f3 SMRR_PHYSMASK is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x000001f8 PLATFORM_DCA_CAP is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x000001f9 CPU_DCA_CAP is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x000001fa DCA_O_CAP is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000200 MTRR_PHYSBASE0 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000201 MTRR_PHYSMASK0 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000202 MTRR_PHYSBASE1 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000203 MTRR_PHYSMASK1 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000204 MTRR_PHYSBASE2 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000205 MTRR_PHYSMASK2 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000206 MTRR_PHYSBASE3 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000207 MTRR_PHYSMASK3 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000208 MTRR_PHYSBASE4 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000209 MTRR_PHYSMASK4 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000020a MTRR_PHYSBASE5 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000020b MTRR_PHYSMASK5 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000020c MTRR_PHYSBASE6 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000020d MTRR_PHYSMASK6 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000020e MTRR_PHYSBASE7 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000020f MTRR_PHYSMASK7 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000210 MTRR_PHYSBASE8 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000211 MTRR_PHYSMASK8 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000212 MTRR_PHYSBASE9 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000213 MTRR_PHYSMASK9 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000250 MTRR_FIX64K_000 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000258 MTRR_FIX16K_800 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000259 MTRR_FIX16K_a00 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000268 MTRR_FIX4K_C000 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000269 MTRR_FIX4K_C800 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000026a MTRR_FIX4K_D000 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000026b MTRR_FIX4K_D800 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000026c MTRR_FIX4K_E000 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000026d MTRR_FIX4K_E800 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000026e MTRR_FIX4K_F000 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000026f MTRR_FIX4K_F800 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000277 PAT is consistent across 24
;PAS CPUs.
;PAS PASSED: Test 1, MSR 0x00000280 MC0_CTL2 is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000281 MC1_CTL2 is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000282 MC2_CTL2 is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000283 MC3_CTL2 is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000284 MC4_CTL2 is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000285 MC5_CTL2 is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000286 MC6_CTL2 is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000287 MC7_CTL2 is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000288 MC8_CTL2 is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x000002ff MTRR_DEF_TYPE is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x000003f1 PEBS_ENABLE is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000480 VMX_BASIC is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000481 VMX_PINPASED_CTLS is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000482 VMX_PROCBASED_CTLS is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000483 VMX_EXIT_CTLS is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000484 VMX_ENTRY_CTLS is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000485 VMX_MISC is consistent across
;PAS 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000486 VMX_CR0_FIXED0 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000487 VMX_CR0_FIXED1 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000488 VMX_CR4_FIXED0 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000489 VMX_CR4_FIXED1 is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000048a VMX_VMX_VMCS_ENUM is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000048b VMX_PROCBASED_CTLS2 is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000048c VMX_EPT_VPID_CAP is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000048d VMX_TRUE_PINBASED_CTLS is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000048e VMX_TRUE_PROCBASED_CTLS is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x0000048f VMX_TRUE_EXIT_CTLS is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0x00000490 VMX_TRUE_ENTRY_CTLS is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 1, MSR 0xc0000080 EFER is consistent across 24
;PAS CPUs.
;PAS PASSED: Test 1, MSR 0xc0000102 KERNEL_GS_BASE is consistent
;PAS across 24 CPUs.
;NLN
;INF Test 2 of 5: Test CPU specific model MSRs.
;INF CPU family: 0x6, model: 0x2c (Westmere)
;PAS PASSED: Test 2, MSR 0x000000ce MSR_PLATFORM_INFO is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 2, MSR 0x000000e2 MSR_PKG_CST_CONFIG_CONTROL is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 2, MSR 0x000000e4 MSR_PMG_IO_CAPTURE_BASE is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 2, MSR 0x000001a2 MSR_TEMPERATURE_TARGET is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 2, MSR 0x000001a6 MSR_OFFCORE_RSP_0 is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 2, MSR 0x000001aa MSR_MISC_PWR_MGMT is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 2, MSR 0x000001ac MSR_TURBO_POWER_CURRENT_LIMIT
;PAS is consistent across 24 CPUs.
;PAS PASSED: Test 2, MSR 0x000001ad MSR_TURBO_RATIO_LIMIT is
;PAS consistent across 24 CPUs.
;PAS PASSED: Test 2, MSR 0x000001fc MSR_POWER_CTL is consistent
;PAS across 24 CPUs.
;NLN
;INF Test 3 of 5: Test all P State Ratios.
;PAS PASSED: Test 3, MSR 0x000000ce Minimum P-State is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 3, MSR 0x000000ce Maximum P-State is consistent
;PAS across 24 CPUs.
;NLN
;INF Test 4 of 5: Test C1 and C3 autodemotion.
;PAS PASSED: Test 4, MSR 0x000000e2 C1 and C3 Autodemotion is
;PAS consistent across 24 CPUs.
;INF C1 and C3 Autodemotion disabled.
;NLN
;INF Test 5 of 5: Test SMRR MSR registers.
;PAS PASSED: Test 5, MSR 0x000001f2 SMRR_PHYSBASE is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 5, MSR 0x000001f2 SMRR_TYPE is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 5, MSR 0x000001f3 SMRR_PHYSMASK is consistent
;PAS across 24 CPUs.
;PAS PASSED: Test 5, MSR 0x000001f3 SMRR_VALID is consistent
;PAS across 24 CPUs.
;NLN
;SEP ============================================================
;SUM 96 passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info
;SUM only.
;SEP ============================================================
 
So I made that program work by loading the kext and rebooting.
Unfortunately the microcode revision is not in :
Cpu->MicrocodeRevision = AsmReadMsr32 (MSR_IA32_BIOS_SIGN_ID)
because when I query that register I get 0 with or without OC boot:
Code:
AnVMSR_10.6 and + % /Users/g5/Downloads/AnVMSR/AnVMSR_10.6\ and\ +/anvmsr  read 8b
RDMSR 8b returns value 0x0
According to this article the microcode revision is actually in IA32_UCODE_REV,
but it is unknown which MSR register is that. Does somebody know?
 
Nevertheless if the code:
Code:
 if (Cpu->Vendor[0] == CPUID_VENDOR_INTEL) {
      Cpu->MicrocodeRevision = AsmReadMsr32 (MSR_IA32_BIOS_SIGN_ID);
is changed to :
Code:
 if (Cpu->Vendor[0] == CPUID_VENDOR_INTEL) {
      Cpu->MicrocodeRevision = AsmReadMsr32 (MSR_IA32_UCODE_REV);
Then the microcode should show up properly. I just don't have any means of proving it without reading the actual register.
 
Upon further reading :
Code:
Microcode update signature. This field contains the
    /// signature of the currently loaded microcode update when read following
    /// the execution of the CPUID instruction, function 1. It is required
    /// that this register field be pre-loaded with zero prior to executing
    /// the CPUID, function 1. If the field remains equal to zero, then there
    /// is no microcode update loaded. Another nonzero value will be the
    /// signature.
Looking at the coreboot microcode update code:
Code:
#if CONFIG_CPU_MICROCODE_IN_CBFS
#define MICROCODE_CBFS_FILE "cpu_microcode_blob.bin"
void intel_microcode_load_unlocked(const void *microcode_patch)
{
    u32 current_rev;
    msr_t msr;
    const struct microcode *m = microcode_patch;
    if (!m)
        return;
    current_rev = read_microcode_rev();
So for the actual microcode it is looking at "cpu_microcode_blob.bin" not directly at the registers
So we know 8b returns 0 if there is no microcode update scheduled and 79 brings a kernel panic when I try to read it.
 
Now this is really strange. I booted from Ubuntu USB :
Code:
root@ubuntu:/home/ubuntu# rdmsr  0x8b
1f00000000
So why in Ubuntu MSR 8b returns 1f (31)? And from OSX it returns 0?
Here is some freebsd documentation on the issue of reading incorrect value of the microcode. Apparently the edk2 procedure on which OC is based is not correct.
Intel SDM manual:
Code:
9.11.7.1      Determining the Signature
An update that is successfully loaded into the processor provides a signature that matches the update revision of the currently functioning revision. This signature is available any time after the actual update has been loaded. Requesting the signature does not have a negative impact upon a loaded update.  The procedure for determining this signature shown in Example 9-9.Example 9-9.
Assembly Code to Retrieve the Update Revision
MOV   ECX, 08BH                    ;IA32_BIOS_SIGN_ID
XOR   EAX, EAX                     ;clear EAX
XOR   EDX, EDX                     ;clear EDX   
WRMSR                              ;Load 0 to MSR at 8BH
MOV   EAX, 1
cpuid
MOV   ECX, 08BH                    ;IA32_BIOS_SIGN_ID
rdmsr                              ;Read Model Specific Register
 
Last edited:
Now this is really strange. I booted from Ubuntu USB :
Code:
root@ubuntu:/home/ubuntu# rdmsr  0x8b
1f00000000
So why in Ubuntu MSR 8b returns 1f (31)? And from OSX it returns 0?
Here is some freebsd documentation on the issue of reading incorrect value of the microcode. Apparently the edk2 procedure on which OC is based is not correct.
Intel SDM manual:
Code:
9.11.7.1      Determining the Signature
An update that is successfully loaded into the processor provides a signature that matches the update revision of the currently functioning revision. This signature is available any time after the actual update has been loaded. Requesting the signature does not have a negative impact upon a loaded update.  The procedure for determining this signature shown in Example 9-9.Example 9-9.
Assembly Code to Retrieve the Update Revision
MOV   ECX, 08BH                    ;IA32_BIOS_SIGN_ID
XOR   EAX, EAX                     ;clear EAX
XOR   EDX, EDX                     ;clear EDX  
WRMSR                              ;Load 0 to MSR at 8BH
MOV   EAX, 1
cpuid
MOV   ECX, 08BH                    ;IA32_BIOS_SIGN_ID
rdmsr                              ;Read Model Specific Register


If you have time for these. Would you consider to create a jump patch installer for all of us?
 
Proper detection of CPU frequency and microcode revision would be great for us!
 
  • Like
Reactions: h9826790
@startergo, regarding your report of the frequency issue on the bug tracker: I fear that it will be overlooked because it appears with a low-priority AMD issue. Perhaps you should create a separate report emphasizing that the issue is about Intel. I think that the issue should be taken just as seriously as the microcode issue, which was quickly acknowledged by the developers.
 
@startergo, regarding your report of the frequency issue on the bug tracker: I fear that it will be overlooked because it appears with a low-priority AMD issue. Perhaps you should create a separate report emphasizing that the issue is about Intel. I think that the issue should be taken just as seriously as the microcode issue, which was quickly acknowledged by the developers.
Yes I was thinking about that. But I would like to find out what is wrong there as during boot it seems to properly detect the frequency. The only thing there is missing package count detection. I wish there was more debugging info. How the frequency from DMidecode changes from 133 to 25? It should be 26 not 25. And 26 and 133 are correct variables in the actual frequency calculation.
 
  • Like
Reactions: h9826790
All right guys I think I found what should be changed for Westmere for proper frequency calculation. Lets discuss it and open an issue in the bug tracker. Westmere is formerly Nehalem-C. So by reading the Intel ADM :
"18.18.3.2 For Intel® Processors Based on Microarchitecture Code Name Nehalem
The scalable bus frequency is encoded in the bit field MSR_PLATFORM_INFO[15:8] and the nominal TSC frequency can be determined by multiplying this number by a bus speed of 133.33 MHz."
I bet you the MSR_PLATFORM_INFO[15:8] is 26 or 25.95064876621916‬ (to give you 3460 for x5690).
What do you think?
 
  • Like
Reactions: h9826790
All right guys I think I found what should be changed for Westmere for proper frequency calculation. Lets discuss it and open an issue in the bug tracker. Westmere is formerly Nehalem-C. So by reading the Intel ADM :
"18.18.3.2 For Intel® Processors Based on Microarchitecture Code Name Nehalem
The scalable bus frequency is encoded in the bit field MSR_PLATFORM_INFO[15:8] and the nominal TSC frequency can be determined by multiplying this number by a bus speed of 133.33 MHz."
I bet you the MSR_PLATFORM_INFO[15:8] is 26 or 25.95064876621916‬ (to give you 3460 for x5690).
What do you think?

Good find. For x5680 it would be 25... But is the problem reading the scalable bus frequency? And why would it (supposedly) work for newer microarchitectures? Or is the problem with the bus speed of 133.33 vs 100 MHz?
 
Or is the problem with the bus speed of 133.33 vs 100 MHz?
I believe so. Judging by the dmidecode readings. I believe it is looking at the incorrect register for Nehalem CPU's. For it should see 133 (unmodified bootloader) and not 25.
 
I believe so. Judging by the dmidecode readings. I believe it is looking at the incorrect register for Nehalem CPU's. For it should see 133 (unmodified bootloader) and not 25.

Maybe for the external frequency. But why 3500 instead of 3460 MHz (lower) for x5690, and 3300 instead of 3330 MHz (higher) for x5680? Perhaps there is some rounding in the calculation...
 
Maybe for the external frequency. But why 3500 instead of 3460 MHz (lower) for x5690, and 3300 instead of 3330 MHz (higher) for x5680?
I wish I knew how is that calculated? I don't see a hint in the code of OcCpuLib file. Plus how is it determining it in the boot log properly and later sets up this incorrect value?
 
Hi, first off all thanks for the great work providing this functionality to cMP users.

I followed the first post and am able to install Catalina and run it on my MVC GTX980. (obviously without acceleration but this has boot screen support)

When I install my MSI RX580 card I don't get a boot screen but also it will not load Catalina. After a while the system just shuts down. It used to work just fine in Mojave.

Where am I going wrong here?
 
After a while the system just shuts down.

This sounds like the machine is trying to boot into Catalina without OC (or without -no_compat_check).

You'll have to get back into the Mojave recovery to set OC again. It's a good idea to have Mojave installed on a SATA disk in bay 1 so that after resetting the NVRAM, the machine boots into that installation by default (I will add this recommendation to the guide), otherwise you may need to remove the Catalina drive.
 
This sounds like the machine is trying to boot into Catalina without OC (or without -no_compat_check).

You'll have to get back into the Mojave recovery to set OC again. It's a good idea to have Mojave installed on a SATA disk in bay 1 so that after resetting the NVRAM, the machine boots into that installation by default (I will add this recommendation to the guide), otherwise you may need to remove the Catalina drive.

Thanks for your reply, the thing is, if I put the GTX980 back it just boots fine into Catalina. Can the change in GFX card mess with boot order??? I think it must be something different.

Catalina is on the 970 EVO NVMe, I even added -no_compat_check to NVRAM in recovery but still no boot on RX580.
 
Thanks for your reply, the thing is, if I put the GTX980 back it just boots fine into Catalina. Can the change in GFX card mess with boot order??? I think it must be something different.

Catalina is on the 970 EVO NVMe, I even added -no_compat_check to NVRAM in recovery but still no boot on RX580.

I’m not sure if a change in graphics card can cause the issue, but if an SMC reset doesn’t help with detecting the disks, I would pull out the Catalina drive, reset the NVRAM, and make sure that the computer can boot into Mojave with the RX 580.
 
  • Like
Reactions: h9826790
Here are some readings from the IoRegistry unmodified boot:
Code:
"processor-lapic" = 0x0
    | | |   "clock-frequency" = <00693bce>=3460000000
    | | |   "processor-number" = 0x0
    | | |   "timebase-frequency" = <00ca9a3b>=1000000000
    | | |   "processor-id" = 0x0
    | | |   "bus-frequency" = <ffffffff>=4294967295   ?????? Weird?
    | | |   "cpu-type" = <0105>
    | | |   "device_type" = <70726f636573736f7200>
    | | |   "name" = <4350553000>
    | | |   "processor-index" = 0x0
OC boot:
Code:
"processor-lapic" = 0x0
    | | |   "clock-frequency" = <00c39dd0> =3500000000 
    | | |   "processor-number" = 0x0
    | | |   "timebase-frequency" = <00ca9a3b>=1000000000 
    | | |   "processor-id" = 0x0
    | | |   "bus-frequency" = <00e1f505> =1000000000 
    | | |   "cpu-type" = <0105>
    | | |   "device_type" = <70726f636573736f7200>
    | | |   "name" = <4350553000>
    | | |   "processor-index" = 0x0
Seems like the clock-frequency and the bus-frequency are different. But why the bus-frequency=4294967295 in the original I/O?
 
I’m not sure if a change in graphics card can cause the issue, but if an SMC reset doesn’t help with detecting the disks, I would pull out the Catalina drive, reset the NVRAM, and make sure that the computer can boot into Mojave with the RX 580.

I'm puzzled, added a Mojave disk in slot 1 as you recommended (but my Mojave backup on one of the Samsung 850 500GB mSata (Addonics PCIe) still is preferred after PRAM reset) anyhow, it boots fine to Mojave with RX580 on slot 1.
I then booted to recovery and added -no_compat_check, booted back to slot 1 Mojave and I see the -no_compat_check. I then hooked up my initial Catalina USB drive on front USB. Set it as startup disk and after quite a while I'm now in Catalina on USB front running my RX 580. o_O

I'm right now cloning the external USB Catalina (which also has the EFI OC) to my internal NVMe drive, wondering if it will boot after cloning. After that I will try to get OC running again...
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.