OpenCore General Discussion

[MacNB]

On 4/23/2021 at 11:56 PM, STLVNUB said:

FEATURE REQUEST:

If you run multiple Mac OS then you constantly have to resign in to iCloud

because using same SMBIOS but different Mac OS

e.g I have Catalina and Big Sur and constantly switch between the two.

 

My idea would be to use same SMBIOS but have unique UUID, Serial and MLB numbers.

This should eliminate the need to constantly fixing up iCloud.

 

Could you PLEASE implement this as IMHO is a NEEDED upgrade.

 

Thanks

 

edit:

I'm running 6.0 at this time, too lazy to upgrade my config

Any takers to help me?

edit2:

How can I get source of 6.0

WayBack Machine comes in handy

This version is working very well for me.

I want to give it the much needed update as per above.

 

On my trusty old Dell Inspiron 530, I was able to boot with OC 0.6.7 all the way from Snow Leopard to Catalina. Each macOS installed on it's own partition/drive but each macOS configured with same SMBIOS model ID. No issues booting multiple OS's.

[STLVNUB]

2 hours ago, MacNB said:

 

On my trusty old Dell Inspiron 530, I was able to boot with OC 0.6.7 all the way from Snow Leopard to Catalina. Each macOS installed on it's own partition/drive but each macOS configured with same SMBIOS model ID. No issues booting multiple OS's.

Try with Big Sur

4 hours ago, HenryV said:

You can make an additional FAT32 partition and put a bootloader for one OS there and have a bootloader for another OS on the ESP.

 

See here:

https://www.insanelymac.com/forum/topic/347139-big-sur-113b4-multibooting-chainloading-tweaks-brew-migrating-apps/

Thanks for that but I'm not an amateur

Been doing this stuff since 2008

Point being ONE loader should be doing it!

Edited April 25, 2021 by STLVNUB

[Rodion2010]

36 minutes ago, STLVNUB said:

Try with Big Sur

 

Will this problem occur on the original Mac with two systems installed?

[STLVNUB]

2 minutes ago, Rodion2010 said:

Will this problem occur on the original Mac with two systems installed?

Don't know, but I would'nt think so

 

[deeveedee]

I'm guessing that this "two systems" problem is only for multi-booting single systems?  I have two HP EliteDesk Mini 800 PCs described here.  One is a G4 (i7-8700 UHD630) and one is a G5 (i7-9700 UHD630).  My primary hack is the G5 running Catalina 10.15.7.  My test hack is the G4 running Big Sur 11.2.3.  Both are booting with the same OC 0.6.8 EFI with SMBIOS MacMini8,1.  I have no problems with separate machines using the same EFI - neither requires me to sign-in with my AppleID and both interchangeably access the same iMessages, App Store Account, etc.  They are never running MacOS at the same time (the G4 is a Windows Server that I occasionally boot into Big Sur for testing my EFI changes).  I'm sure this is not the norm, but I'm offering this in case it helps to understand a problem.

Edited April 25, 2021 by tonyx86

[1Revenger1]

This is in the context of the older NDK bootloader, but this explains a bit more about why the ACPI patching is as it is currently.

As for the iCloud issues, I have no such issues using the same SMBIOS data between Mojave, Catalina, and Big Sur.

[STLVNUB]

Just did it again, Big Sur back to Catalina, there more to this than meets the eye

Whats the bet that when I go back to BS that it happens again!!!

P.S this is NOT OFF TOPIC

 

Edited April 26, 2021 by STLVNUB

[Rodion2010]

12 hours ago, STLVNUB said:

Don't know, but I would'nt think so

 

If it works OK at Mac - the problem is not with SMBIOS. Maybe there are some other settings we dont know as for now

[STLVNUB]

4 minutes ago, Rodion2010 said:

If it works OK at Mac - the problem is not with SMBIOS. Maybe there are some other settings we dont know as for now

That is probably right

Ok, I have a plan

I'm going to run my MacBook Pro with different SMBIOS and see what happens.

Will use rEFIND as the loader nd make a SMBIOS driver that it loads.

Any takers on helping me to code the driver??

[deeveedee]

EDIT: I used Rehabman's ACPI Debug to dump the value of PWRM in my rig's ACPI.  Maybe not so surprisingly, the value of PWRM is

kernel: (ACPIDebug) ACPIDebug: { "PWRM: ", 0xfe000000, }

Based on my own review of my rig's ACPI and comparison to a real MacMini8,1's ACPI, IntObj PWRM (in my rig's unpatched DSDT) is equal to the Base address of the Memory32Fixed buffer in a real Mac's PMCR._CRS.  Therefore, the original Acidanthera PMCR patch can be used without any modification to the original DSDT (no need to change any Memory32Fixed buffers in PRRE).  This exercise was a long way of confirming that there is no PMCR._CRS memory conflict and the Acidanthera PMCR patch is correct.

 

Based on the response to my post here, I'm guessing that either there is no concensus on how to handle the potential memory conflict in PMCR._CRS or that PMCR._CRS doesn't matter.  Assuming it does matter,  here's another possible approach.  This new approach attempts to find a free memory region in which to allocate buffer space for Device PMCR.  Note that based on the method described, this free region will be platform dependent.

Edited April 27, 2021 by tonyx86

[STLVNUB]

38 minutes ago, Hervé said:

@STLVNUB Tried to switch between Big Sur & High Sierra on my old legacy C2D Vostro200 desktop and Big Sur and Catalina on my Ivy Bridge E6230 laptop. Was using the same single config on each system and no issues with iCloud, i.e. no need to re-sign after switching between OS versions. Maybe something wrong in your own config?

Im using 0.6.0 OC I don't think its config problem but will check it out

 

[makk]

Have a problem Need to talk with Vit about this.

I have Opencore booting up 6.8.

But no audio cannot get audio in Normal Desktop.  Need another pair of eyes and minds.

 

I am attaching my EFI as is.

 

battery does not register and the trackpad as well.

 

Clover 5133

Everything works with Clover 5133 with QcQuirks in Catalina and Big Sur.

In Big Sur no wifi. It is Atheros and cannot write to the root to install kext.

 

Catalina 10.15.7

Big Sur 11.2.3

I just noticed 11.3 in update

 

EFI.zip

Edited April 27, 2021 by makk

[Rodion2010]

13 hours ago, makk said:

 It is Atheros and cannot write to the root to install kext.

 

 

no need to install into system, use bootloader kext inject

[makk]

6 hours ago, Rodion2010 said:

 

no need to install into system, use bootloader kext inject

Greetings I think it may be the version I am using that is not working correctly with clover was using 5133 with Kext set to Inject.

 

It any case it should not matter with the version of Clover as long as "Inject" is selected. Was not injecting even after F11 to clear NVRAM. F11 Freezes on 5127 and locks the screen. With 5133 have to hold F11 for a few seconds to have the screen flash off and on.

However in Kernel and Kext section there is a sure fire way as well.  I just don't recall how to write it in.
Need an example.

 

With OC 6.8 not sure why I don't get audio and battery. I looked at the reference for OC for Battery Patching using Rehabman's incredible example but too complicated for me at the moment with all these issues.  I don't have all my apples in order sort to speaking.

I was looking for an already made one. But in the SSDT that Rehabman's Project created all the battery patches are in it along with ACPI patches for the battery in config.plist.  However not sure how to translate it into OC without borking the boot up process. A bit complicated for me at this time.

 

I think I will go back to 6.7 or lower.

 

Normally on my Legacy unit I only used AppleALC.Kext and it did the trick.  
For the battery did was on and off with ACPI Battery manager SSDT and the kext. That has DSDT.aml.

 

With this HP Probook using Rehabman's Project Codec_Commander.kext is installed by default, along with AppleALC.kext. A bit confusing and complicated I think because the Clover version and AppleALC was probably not able to handle both Audios on this Laptop --Broadwell-U. 

When you look at his project build they are all built into these .asl's which he uses to create and I feel without his total and complete explanation of his creation, sort of stuck. Gaps need to be filled in.

 

HP Probook is not using DSDT.aml at all. Using hot patches Rehabman's Project which works great in Clover.  But has problems translating to OC.

This is where I run into the problem.  

1 Patches for ACPI. Mostly Battery and power.

2 Audio --kexts

3 Battery --spitting out ACPI errors on boot and in the log

4 Wifi - No driver.  However I found a fix for the Wifi with two kexts from PG7 here on the forum.

 

Also I am not 100% certain if this unit HP Probook has NVRAM built in as in Rehabs Project the driver for Emulating NVRAM was never selected and it Clover Drivers section.  However I did install it afterwards thinking it might need it

because I read Laptops mostly do not come with NVRAM.  Or Data for that matter.

I don't recall the proper way to test interrogate the BIOS CMOS to find out.

 

Thanks a great deal that find did work for Atheros wifi.!!

 

Have a great day!

Edited April 27, 2021 by makk

[deeveedee]

What is the purpose of the new OC 0.6.9 UEFI > Quirk EnableVectorAcceleration?  To which CPU / System Architectures is this quirk relevant?  Thank you.

[miliuco]

37 minutes ago, tonyx86 said:

What is the purpose of the new OC 0.6.9 UEFI > Quirk EnableVectorAcceleration?  To which CPU / System Architectures is this quirk relevant?  Thank you.

 Enabling OC password, I have observed that the time to open the picker is shorter.  I don't know if this will also work for any process that uses these encryptions.

[deeveedee]

Not sure I understand your answer.  I'm guessing that EnableVectorAcceleration has something to do with Intel AVX Extensions.  I'm currently booting Catalina 10.15.7 with OC 0.6.8.  When I run 

sysctl -a | grep machdep.cpu.features

 

I see the response below, which indicates that AVX1.0 is already recognized.  Does the new quirk enable AVX2?  Sorry if these are naive/remedial quesitons.

 

machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C

 

EDIT: When I run

sysctl -a | grep machdep.cpu.leaf7_features

I see that my system already "supports" AVX2.  Still wondering what EnableVectorAccleration quirk does.  Maybe AVX-512?

 

machdep.cpu.leaf7_features: RDWRFSGS TSC_THREAD_OFFSET SGX BMI1 AVX2 SMEP BMI2 ERMS INVPCID FPU_CSDS MPX RDSEED ADX SMAP CLFSOPT IPT SGXLC MDCLEAR IBRS STIBP L1DF ACAPMSR SSBD

 

Edited April 28, 2021 by tonyx86
Added command to show AVX2 support

[miliuco]

17 minutes ago, tonyx86 said:

Not sure I understand your answer.  I'm guessing that EnableVectorAcceleration has something to do with Intel AVX Extensions.  I'm currently booting Catalina 10.15.7 with OC 0.6.8.  When I run 

sysctl -a | grep machdep.cpu.features

I see the response below, which indicates that AVX1.0 is already recognized.  Does the new quirk enable AVX2?  Sorry if these are naive/remedial questions...

I read that this quirk enables AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms so I did the test of starting the picker (with password) with this quirk enabled and disabled and when it is enabled the password is decrypted in a while  shorter. That is why I think it has to do with the speed of decryption of these algorithms. But I’m not sure at 100%. 

 

[Rodion2010]

1 hour ago, tonyx86 said:

What is the purpose of the new OC 0.6.9 UEFI > Quirk EnableVectorAcceleration?  To which CPU / System Architectures is this quirk relevant?  Thank you.

it is for CPU with AVX support

sysctl machdep.cpu | grep AVX

Edited April 28, 2021 by Rodion2010

[deeveedee]

31 minutes ago, miliuco said:

I read that this quirk enables AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms so I did the test of starting the picker (with password) with this quirk enabled and disabled and when it is enabled the password is decrypted in a while  shorter. That is why I think it has to do with the speed of decryption of these algorithms. But I’m not sure at 100%. 

 

If the OC release punch list now includes vectorizing the picker password, we must be getting close to the final release.

 

EDIT: @miliuco - My search now finds EnableVectorAcceleration in the OC 0.6.9 manual.  Thanks for your answer.

Edited April 28, 2021 by tonyx86

[TheBloke]

13 minutes ago, tonyx86 said:

If the OC release punch list now includes vectorizing the picker password, we must be getting close to the final release.

 

The new code was submitted via push request by someone who doesn't seem to have contributed to OC before. So I would guess it's more a case of someone in the community thinking it would be useful and providing the code, rather than Acidanthera thinking it was vital to do at this stage 

Edited April 28, 2021 by TheBloke

[miliuco]

I thought about algorithms and decryption because the changes are in OpenCore files related to this:

• Include/Acidanthera/Library/OcCryptoLib.h
• Library/OcCryptoLib/OcCryptoLib.inf
• Library/OcCryptoLib/Sha2.c
• Library/OcCryptoLib/Sha512AvxDummy.c
• Library/OcCryptoLib/X64 / Sha512Avx.nasm.

 

Edited April 28, 2021 by miliuco

[deeveedee]

29 minutes ago, TheBloke said:

 

The new code was submitted via push request by someone who doesn't seem to have contributed to OC before. So I would guess it's more a case of someone in the community thinking it would be useful and providing the code, rather than Acidanthera thinking it was vital to do at this stage 

In fairness to the person who submitted the code, I read here that the picker password can take 30 seconds to verify on older platforms.  Maybe vectorizing the password hash calculations can speed this up a lot.

[miliuco]

Just now, tonyx86 said:

In fairness to the person who submitted the code, I read here that the picker password can take 30 seconds to verify on older platforms.  Maybe vectorizing the password hash calculations can speed this up a lot.

On my hackintosh (and I suppose on all modern machines) the difference is small, approx. 3 versus 1.5 sec., although seen in relative terms it is half the time.

[Stefanalmare]

18 hours ago, miliuco said:

On my hackintosh (and I suppose on all modern machines) the difference is small, approx. 3 versus 1.5 sec., although seen in relative terms it is half the time.

In my z390 aorus master, i9 9900K a lot faster than before.

Edited April 29, 2021 by Stefanalmare