MP 1,1-5,1 RefindPlus|OpenCore by MyBootMgr

[Dayo]

1: Switch Run Mode has not been working for me in Monterey/BigSur. Works fine in Mojave?

SwitchRunMode is not tied to Mac OS versions but I suppose you mean since additional OC instances where added.
AFAIK, this was fixed a few iterations ago. "Has not been working for me" is a bit too broad. You will need to spell what the issue you have is a bit more clearly.

2: The cpuid flag AAAAAAAAJCAAAAAA crashes my 3,1. I’m assuming this is the SSE4.2 spoof flag? Shame because I want to run latest PShop in Monterey! Is this a known issue with the 3,1? Anyone else have this problem?

For this and @joevt input, SSE4.2 Spoofing was being looked at a while ago in relation to VMWare updates etc. The idea for 3,1 was to use along with AAAMouSSE.

The effort pertered out due to limited feedback and not so promising results. @Syncretic explained back then that spoofing this in this way is indeed likely to cause a KP as the kernel will see this and try to use AVX instructions which are not available.

IIRC though, @startergo found that it did not KP when the AVX bit was disabled. Can't recollect if this was done here. Notwithstanding this, Photoshop/VMWare were not fooled by spoofing XSAVE. They seemed to get the info directly from the CPU instead of the kernel cache

Haven't looked at this for a long time now and will just add to the health warning on the dialogue in ConfigFactory. Alternatively, might just remove it altogether since tested software did not use the spoofed info. Either way, you can forget using Photoshop on Monterey by simply spoofing SSE4.2 in this manner. I believe there are some more involved required steps outlined in some other posts.

Question for you:
The "AAAAAAAAJCAAAAAA==" value is spoofing VMM and SSE4.2 which is only set on one of the OpenCore instances created by ConfigFactory when SSE4.2 Spoofing is indicated. Are you saying it doesn't KP on the other instances? I believe these would have something like "AAAAAAAAJAAAAAAA=="

3: No H264 accel in Monterey, only HevC ? Works in Mojave.

No idea ... Ask on the Monterey thread perhaps?

 

[joevt]

Below is described how to set Cpuid1Data and Cpuid1Mask (this example is for setting sse4.2 and popcnt). I don't know if the example is useful. I don't know if it causes kernel panics. The description may be used to set other bits that are useful.

The settings are described in https://dortania.github.io/docs/latest/Configuration.html
The string is base64. You can translate it to hex like this:
base64 -d <<< AAAAAAAAAAAAAJAAAAAAAA== | xxd -p | sed -E 's/(..)/\1 /g'
which gives:
00 00 00 00 00 00 00 00 00 00 90 00 00 00 00 00

You can translate hex to base64 like this:
xxd -p -r <<< "00 00 00 00 00 00 00 00 00 00 90 00 00 00 00 00" | base64

The documentation says that only the bits described by the mask will be modified. So setting Cpuid1Data and Cpuid1Mask to that value will change two of the bits.

How to calculate the value:

The cpu id wikipedia page at https://en.wikipedia.org/wiki/CPUID says the bits we want to change (sse4.2 and popcnt) are bits 20 and 23 in the ECX part. As a 32 bit number, the value can be calculated using:
printf "%08x" $((1 << 20 | 1 << 23))
which is 00900000 (hex)

There are four parts for the Cpuid1Data and Cpuid1Mask: EAX, EBX, ECX, EDX. Each is four bytes (32 bit numbers). We only want to change the ECX part, so the first 8 bytes (EAX and EBX) will be zero and the last 4 bytes (EDX) will also be zero:
00000000 00000000 xxxxxxxx 00000000. xxxxxxxx is for ECX which we want to set to 00900000 like this:
00000000 00000000 00900000 00000000

The values should be converted to little-endian, which you can do like this:
xxd -p -r <<< "00000000 00000000 00900000 00000000" | xxd -e -g 4 | xxd -r | base64
which is AAAAAAAAAAAAAJAAAAAAAA==
which is the final base64 result that you want to use.

In your config.plist file (in the OC folder in the EFI folder of the EFI volume), find the location of the fields you want to change. They'll look like this in a text editor like BBEdit.app:

			<key>Cpuid1Data</key>
			<data>
			</data>
			<key>Cpuid1Mask</key>
			<data>
			</data>

You'll want to change it like this:

			<key>Cpuid1Data</key>
			<data>
			AAAAAAAAAAAAAJAAAAAAAA==
			</data>
			<key>Cpuid1Mask</key>
			<data>
			AAAAAAAAAAAAAJAAAAAAAA==
			</data>

A dedicated plist editor (such as the one in Xcode) may require you to enter the hex bytes
00 00 00 00 00 00 00 00 00 00 90 00 00 00 00 00 instead of base64.


Duplicate the config.plist file before you open it for editing to have a backup just in case.

View attachment 1935216

 

[Dayo]

Nice details ... Bookmarked for future reference

ConfigFactory creates two to four OpenCore instances and with SSE4.2 spoofing indicated, they would all have the SSE4.2 and POPCNT bits set (AAAAAAAAAAAAAJAAAAAAAA==). It is just that he only mentioned that the single instance that has the VMM bit added fails (AAAAAAAAAAAAAJCAAAAAAA==) ... hence my question about the others.

 

[freqrider]

both AAAAAAAAAAAAAJAAAAAAAA and AAAAAAAAAAAAAJCAAAAAAA are crashing my 3,1. Using AAAAAAAAAAAAAAAAAAAAA or AAAAAAAAAAAAAACAAAAAAA works only.

 

[freqrider]

Below is described how to set Cpuid1Data and Cpuid1Mask (this example is for setting sse4.2 and popcnt). I don't know if the example is useful. I don't know if it causes kernel panics. The description may be used to set other bits that are useful.

The settings are described in https://dortania.github.io/docs/latest/Configuration.html
The string is base64. You can translate it to hex like this:
base64 -d <<< AAAAAAAAAAAAAJAAAAAAAA== | xxd -p | sed -E 's/(..)/\1 /g'
which gives:
00 00 00 00 00 00 00 00 00 00 90 00 00 00 00 00

You can translate hex to base64 like this:
xxd -p -r <<< "00 00 00 00 00 00 00 00 00 00 90 00 00 00 00 00" | base64

The documentation says that only the bits described by the mask will be modified. So setting Cpuid1Data and Cpuid1Mask to that value will change two of the bits.

How to calculate the value:

The cpu id wikipedia page at https://en.wikipedia.org/wiki/CPUID says the bits we want to change (sse4.2 and popcnt) are bits 20 and 23 in the ECX part. As a 32 bit number, the value can be calculated using:
printf "%08x" $((1 << 20 | 1 << 23))
which is 00900000 (hex)

There are four parts for the Cpuid1Data and Cpuid1Mask: EAX, EBX, ECX, EDX. Each is four bytes (32 bit numbers). We only want to change the ECX part, so the first 8 bytes (EAX and EBX) will be zero and the last 4 bytes (EDX) will also be zero:
00000000 00000000 xxxxxxxx 00000000. xxxxxxxx is for ECX which we want to set to 00900000 like this:
00000000 00000000 00900000 00000000

The values should be converted to little-endian, which you can do like this:
xxd -p -r <<< "00000000 00000000 00900000 00000000" | xxd -e -g 4 | xxd -r | base64
which is AAAAAAAAAAAAAJAAAAAAAA==
which is the final base64 result that you want to use.

In your config.plist file (in the OC folder in the EFI folder of the EFI volume), find the location of the fields you want to change. They'll look like this in a text editor like BBEdit.app:

            <key>Cpuid1Data</key>
            <data>
            </data>
            <key>Cpuid1Mask</key>
            <data>
            </data>

You'll want to change it like this:

            <key>Cpuid1Data</key>
            <data>
            AAAAAAAAAAAAAJAAAAAAAA==
            </data>
            <key>Cpuid1Mask</key>
            <data>
            AAAAAAAAAAAAAJAAAAAAAA==
            </data>

A dedicated plist editor (such as the one in Xcode) may require you to enter the hex bytes
00 00 00 00 00 00 00 00 00 00 90 00 00 00 00 00 instead of base64.


Duplicate the config.plist file before you open it for editing to have a backup just in case.

View attachment 1935216

yes, the "J" crashes my 3,1

 

[Dayo]

AAAAAAAAAAAAAJAAAAAAAA and AAAAAAAAAAAAAJCAAAAAAA are crashing my 3,1.

Does either one work with Mojave? Presumably you tried Big Sur or Monterey

Also, can you try the following:
AAAAAAAAAAAAAJCEAAAAAA== ... Bits 20, 23, 26 and 31 for SSE42, POPCNT, XSAVE and VMM
AAAAAAAAAAAAAACEAAAAAA== ... Bits 26 and 31 for XSAVE and VMM
AAAAAAAAAAAAAAAEAAAAAA== ... Bit 26 for XSAVE

 

[freqrider]

Does either one work with Mojave? Presumably you tried Big Sur or Monterey

Also, can you try the following:
AAAAAAAAAAAAAJCEAAAAAA== ... Bits 20, 23, 26 and 31 for SSE42, POPCNT, XSAVE and VMM
AAAAAAAAAAAAAACEAAAAAA== ... Bits 26 and 31 for XSAVE and VMM
AAAAAAAAAAAAAAAEAAAAAA== ... Bit 26 for XSAVE

I will try later. Pretty sure it crashes with the J flag present. Mojave too

 

[joevt]

I will try later. Pretty sure it crashes with the J flag present. Mojave too

What about trying the Intel SDE? I don't know anything about it but it seems like it my be applicable for your photoshop issue.

 

[freqrider]

Does either one work with Mojave? Presumably you tried Big Sur or Monterey

Also, can you try the following:
AAAAAAAAAAAAAJCEAAAAAA== ... Bits 20, 23, 26 and 31 for SSE42, POPCNT, XSAVE and VMM
AAAAAAAAAAAAAACEAAAAAA== ... Bits 26 and 31 for XSAVE and VMM
AAAAAAAAAAAAAAAEAAAAAA== ... Bit 26 for XSAVE

Can confirm, the J flag crashes it every time. Mojave too.

 

[freqrider]

What about trying the Intel SDE? I don't know anything about it but it seems like it my be applicable for your photoshop issue.

I tried the latest SDE. Wouldn’t run on Monterey. It’s missing a dylib. May have to install it seperately, or with homebrew.

 

[Dayo]

Can confirm, the J flag crashes it every time.

Noted. Returned to the back burner until it can be looked at in detail.

 

[Dayo]

3: No H264 accel in Monterey, only HevC ? Works in Mojave.

No idea ... Ask on the Monterey thread perhaps?

Took at look and the loss of GPU Acceleration for H264 suggests you are running an instance that is only meant for updates (as labelled). Additionally, VMM based or "Spoofless" instances reportedly also come with a significant capacity/efficiency loss.

To avoid such feature and overall efficiency loss, you should use "Install/Update" instances for those indicated purposes only and switch back to regular "Hybridised" instances for normal use.

 

[freqrider]

Thanks Dayo! That was it! Changing update SYMBIOS to 'true' fixed it! I appreciate your tireless effort!

 

[MarkSt]

I am trying to use MyBootMgr to manage a native bootable Mojave on my 2TB SSD and then install Big Sur onto a 1TB NVMe using OC. I am following the instructions in the beginning of this thread and have completed Step2 of Stage1 to disable SIP with EnterRecovery. Stage2 ConfigFactory keeps throwing me an error whenever it looks like it will generate an EFI file. 'The variable SpaceFlagSBMM is not defined. (-2753)' Searching the forum didn't turn up any results

Any help with what I am doing wrong would be appreciated 🙏

 

[Dayo]

It is from a typo in the script ... an errant "M" attached to "SpaceFlagSBM".
Uploaded 077a with a fix. Give it 5 mins for a cache refresh. Thanks.

 

[two-mac-jack]

I've installed MyBootMgr, and I have RefindPlus working, but can't get it to load Mojave via OC.

MyBootMgr seems perfect for me. I want OC so I can run the latest apps on Big Sur / Monterey, but I also have a Windows 10 Legacy install that I don't want to risk via a UEFI conversion, and I also need to keep Mojave running (both native and hopefully under OC for video hardware acceleration) because of some 32-bit apps and plug-ins.

I've been through the install steps on post #1 three times now, with the same results every time. Doesn't matter if I pick the ConfigFactory option to make default choices for me, or if I make every choice manually.

RefindPlus shows 4 OC configs and my Windows Legacy drive, but it does NOT show my native Mojave drive as expected. It does boot into Windows 10 successfully.

When I select the OC_LEG config so I can boot Mojave under OC I get "Load Error When Loading OpenCore.efi... Invalid Loader". When I select the first OC config instead, the OC boot picker text screen appears, but it does not show any of my drives. If I press the 'esc' key it scans for drives again but finds nothing. But maybe this is expected, since I don't have any macOS newer than Mojave installed yet.

See attached log files and screen pix. This is using MyBootMgr 077a.

Machine is a cMP5,1 with latest firmware (144.x) and ROM recently cleaned by tsialex. Mojave is installed on APFS (drive name "Boot") on an AHCI Samsung SM951 in an Amfeltec Squid (version 1) in PCIe slot #2. The MyBootMgr EFI partition is on a SATA SSD in a drive bay (drive name "MyBootMgr"). Windows is on a SATA SSD in the extra CD bay (drive name "Windows").

My plan is to have the latest macOS (Big Sur and eventually Monterey) installed on the same SATA SSD as the MyBootMgr EFI. ConfigFactory wants you to pick an HFS+ drive target, so I divided that SATA SSD into a tiny 1 GB HFS+ partition called "MyBootMgr" and a 239 GB APFS partition called "LatestMacOS" where I intend to install Big Sur and then Monterey.

The GPU is a Radeon Sapphire RX580 I got from eBay several years ago that provides native boot screens. When I look at the EFI Driver Version it says "MacVidCards" so it must be a pirated version; didn't know that when I bought it! I found some posts on here and the OC thread implying that MVC ROM can cause problems with APFS drives not appearing. But I never have a problem with the native boot screen showing APFS drives, so maybe it's unique to OpenCore. I did try swapping out the GPU for an R9 280x, but got the exact same results.

Thanks in advance for any suggestions or insight you can provide.

 

[Dayo]

Wow. There is lot going on there. Best to start from the base and work up from there.

I'll read up properly and see but firstly, RefindPlus does not seem to be able to properly deal with the drive your Mojave is on. Basically, does not find any PreBoot partitions. Might be something to do with the adaptor ... Hence the NULL Volume UUID and the message about not being able to identify APFS Partitions.

I suspect this is the root cause as it appears OpenCore may have similar issues (Need to check that is not from a configuration issue). I'll need a zipped up package of the entire EFI folder as it stands.
After that, go into your OC config files and change the ScanPolicy token to 0 in each one, try again and share the OC log.

Also, you might be better off not creating an HFS+ partition just for MyBootMgr. The HFS+ thing is just a suggestion and not a requirement (Might even remove this suggestion if it is coming across as a requirement). That is, not something to jump through hoops to meet. Certainly not worth creating an exotic setup for.

 

[freqrider]

I've installed MyBootMgr, and I have RefindPlus working, but can't get it to load Mojave via OC.

MyBootMgr seems perfect for me. I want OC so I can run the latest apps on Big Sur / Monterey, but I also have a Windows 10 Legacy install that I don't want to risk via a UEFI conversion, and I also need to keep Mojave running (both native and hopefully under OC for video hardware acceleration) because of some 32-bit apps and plug-ins.

I've been through the install steps on post #1 three times now, with the same results every time. Doesn't matter if I pick the ConfigFactory option to make default choices for me, or if I make every choice manually.

RefindPlus shows 4 OC configs and my Windows Legacy drive, but it does NOT show my native Mojave drive as expected. It does boot into Windows 10 successfully.

When I select the OC_LEG config so I can boot Mojave under OC I get "Load Error When Loading OpenCore.efi... Invalid Loader". When I select the first OC config instead, the OC boot picker text screen appears, but it does not show any of my drives. If I press the 'esc' key it scans for drives again but finds nothing. But maybe this is expected, since I don't have any macOS newer than Mojave installed yet.

See attached log files and screen pix. This is using MyBootMgr 077a.

Machine is a cMP5,1 with latest firmware (144.x) and ROM recently cleaned by tsialex. Mojave is installed on APFS (drive name "Boot") on an AHCI Samsung SM951 in an Amfeltec Squid (version 1) in PCIe slot #2. The MyBootMgr EFI partition is on a SATA SSD in a drive bay (drive name "MyBootMgr"). Windows is on a SATA SSD in the extra CD bay (drive name "Windows").

My plan is to have the latest macOS (Big Sur and eventually Monterey) installed on the same SATA SSD as the MyBootMgr EFI. ConfigFactory wants you to pick an HFS+ drive target, so I divided that SATA SSD into a tiny 1 GB HFS+ partition called "MyBootMgr" and a 239 GB APFS partition called "LatestMacOS" where I intend to install Big Sur and then Monterey.

The GPU is a Radeon Sapphire RX580 I got from eBay several years ago that provides native boot screens. When I look at the EFI Driver Version it says "MacVidCards" so it must be a pirated version; didn't know that when I bought it! I found some posts on here and the OC thread implying that MVC ROM can cause problems with APFS drives not appearing. But I never have a problem with the native boot screen showing APFS drives, so maybe it's unique to OpenCore. I did try swapping out the GPU for an R9 280x, but got the exact same results.

Thanks in advance for any suggestions or insight you can provide.

Check to see than any AHCI kexts are present and enabled.

 

[two-mac-jack]

Wow. There is lot going on there. Best to start from the base and work up from there.

I'll read up properly and see but firstly, RefindPlus does not seem to be able to properly deal with the drive your Mojave is on. Basically, does not find any PreBoot partitions. Might be something to do with the adaptor ... Hence the NULL Volume UUID and the message about not being able to identify APFS Partitions.

I suspect this is the root cause as it appears OpenCore may have similar issues (Need to check that is not from a configuration issue). I'll need a zipped up package of the entire EFI folder as it stands.
After that, go into your OC config files and change the ScanPolicy token to 0 in each one, try again and share the OC log.

Also, you might be better off not creating an HFS+ partition just for MyBootMgr. The HFS+ thing is just a suggestion and not a requirement (Might even remove this suggestion if it is coming across as a requirement). That is, not something to jump through hoops to meet. Certainly not worth creating an exotic setup for.

Thanks for taking a look!

Here's a link to the EFI.zip -- too big for an attachment.

New logs are attached, after changing ScanPolicy to 0.

 

[two-mac-jack]

Check to see than any AHCI kexts are present and enabled.

Looks like "CtlnaAHCIPort.kext" is included and enabled in config.plist

 

[Dayo]

Thanks. I only found three instances in the zip and the "OC_LEG" one was missing. Was it not present when you zipped ... which is strange?

On the kexts, RefindPlus runs before OS and associated kexts come into play. Any issues there are not kext related.

Anyway, both RefindPlus and OpenCore are unable to properly read the Mojave APFS Volume on the adaptor. RefindPlus checks for the presence of PreBoot (not found) and does not list Recovery (presumably not found) while OpenCore checks for the presence of Recovery (not found). Whether this is because they are not present or just inaccessible is not clear yet. OpenCore should not be affected by RefindPlus in this respect but will need to eliminate this variable later.

To move forward and eliminate some variables, can you simplify a bit as follows:

• Disconnect all external drives if possible
• Rerun ConfigFactory and do not select the Monterey option to reduce the number of OpenCore instances created
• You can leave Big Sur as it does not trigger the additional instances

Next, PCIe Devices may run OptionROMs before bootloaders are run (immediately after the chime)

1. Level 1
   1. Swap in the alternative GPU and try with that. Just need to see whether Mojave shows up in RefindPlus wth this.
   2. Yes, the MacVids OptionROM has been observed to muck APFS up in the past.
   3. Could be stuff it needs to work within its target environment
2. Level 2
   1. Connect the Mojave Volume directly to a native port ... You may need to clone it to an SSD
   2. Then, disconnect the adaptor and try again

Can see how it goes from there.

 

[kirreip]

Is there any way to rebless RefindPlus from within OpenCore? I did a manual update of OpenCore (I know it's not recommended... but still) and now my MacPro boots directly the OC bootloader, so skips RefindPlus. And no: I have not replaced BOOTx64.efi, which is modified in our implementation (why it still didn't work, I don't know...).

It seems to me that somehow I would have to rebless RefindPlus, but BootBlesser.app won't let me as long as I boot from OC.

Worst case, I could set everything back to zero (so NVRAM reset) and then boot into my Mojave Backup to bless it again. But if there is an easyier solution...

 

[two-mac-jack]

I only found three instances in the zip and the "OC_LEG" one was missing. Was it not present when you zipped ... which is strange?

Correct, there was no OC_LEG in the EFI folder. I noticed that, probably why it complains that OpenCore.efi can't be loaded if you select that option. When ConfigFactory asked if I soon intended to install Big Sur I said "yes", and then when it asked if I soon intended to install Monterey I also said "yes". This is because my plan was to go to Big Sur first, verify that everything I need was working, then give Monterey a try.

Thanks for all the suggestions, I'm starting down your list of things to try and will reply back when I know more.

 

[Dayo]

my MacPro boots directly the OC bootloader, so skips RefindPlus.

There are instructions in Post 1 >> Other Considerations on how to recover from an OpenCore Boot Coup such as you describe. (OpenCore, Windows or Linux Has Staged a Boot Coup).

There are also instructions in Post 1 >> Implementation Process >> Stage 3 - Post Installation, marked "IMPORTANT", on what to avoid to prevent OpenCore Boot Coups from happening.

there was no OC_LEG in the EFI folder.

I see. Well, if there is a copy in the Users/Shared/MyBootMgr folder, you can mount and copy that to the EFI.
I will check the DeployConfig App to make sure it is copying all that it should.

 

[Dayo]

I will check the DeployConfig App to make sure it is copying all that it should.

Yep ... It wasn't copying OC_LEG indeed.
I need to issue an update but that will be the only change so you can just copy yours manually