Jump to content
8755 posts in this topic

Recommended Posts

@Rodion2010 I had considered that, but I don't believe Device PRRE (I had incorrectly typed PREE) and PMCR are the same.  I tried searching for PRRE without any luck.  In my hack's original, unpatched ACPI, Device PRRE has _UID=PCHRESV and _HID=PNP0C02 (PNP Motherboard Resources, same as a real Mac ACPI LDRC and PDRC).

 

BTW - very good observation.  I should have indicated more about Device PRRE in my original post.

Edited by tonyx86
1 hour ago, tonyx86 said:

@Rodion2010 I had considered that, but I don't believe Device PRRE (I had incorrectly typed PREE) and PMCR are the same.  I tried searching for PRRE without any luck.  In my hack's original, unpatched ACPI, Device PRRE has _UID=PCHRESV and _HID=PNP0C02 (PNP Motherboard Resources, same as a real Mac ACPI LDRC and PDRC).

 

BTW - very good observation.  I should have indicated more about Device PRRE in my original post.

 

about the same devices

  • Like 2

@Rodion2010 Very interesting. I must have made the same "PREE" typo when I searched, which is why I didn't find the posts in the CLOVER discussion.  Thanks for posting this.

 

EDIT: @Rodion2010 My concern with the modified PRRE that Slice posted is that the reserved Memory32Fixed regions in ACPI may not actually govern the use of reserved memory by a Windows PC.  How can anyone be certain that the Device or Process using reserved memory at 

                    Memory32Fixed (ReadWrite,
                        0xFE000000,         // Address Base
                        0x00020000,         // Address Length
                        )

is "obeying" ACPI?  After all, we are running macOS on a Windows PC.

 

I don't know enough about this, so I'm thinking out loud and hoping that someone more knowledgeable can chime in.  As long as the modified PMCR that I posted here works for me, I think that's the safest patch.

 

EDIT2: I have concluded that the Acidanthera PMCR patch is fine as is and there is no need to patch Device PRRE in the original DSDT.  See here.

Edited by tonyx86
Concluded that no PMCR or PRRE changes are needed

For those with iCloud issues while booting Big Sur and older OSes, make sure the device name is the same. I think with the 1st Big Sur DP. the device name is only iMac or MacPro... on Catalina and earlier it was Yournames iMac. No issues here with Big Sur and Mojave. 

  • Like 2
2 hours ago, MifJpn said:

but the OpenCore team seems to continue to adhere to that philosophy dogmatically and continue to abandon proposals (Dualbooting Windows)  just because it's already decided.

Does anyone else want to chime in on pointless, unproductive personal comments or are we done? This community has become a bad joke.

  • Like 2
  • Thanks 1
2 hours ago, MifJpn said:

I hear that OpenCore's philosophy is to make the computer itself become a MAC.

it is obvious that default DSDT from BIOS works with Windows

if it does not - it means you broke it by your own hands

thats all, no meaningless debates.

  • Like 1
  • Thanks 1
  • Confused 1
On 4/23/2021 at 8: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.

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/

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.

  • Like 1
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 by 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

 

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 by tonyx86

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 by 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??

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 by tonyx86
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

 

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 by 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 by makk
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.

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 by tonyx86
Added command to show AVX2 support
×
×
  • Create New...