OpenCore General Discussion

[HenryV]

On 4/17/2021 at 3:56 AM, Download-Fritz said:

@HenryV Please

- Provide a DEBUG log

- Provide a (depersonalised) config, or even better whole ESP

- Test whether OpenCanopy works as intended

Thank you for responding to my post.

 

Note that the issue with the text menu occurs before booting Big Sur, and Big Sur boots ok.

 

I was not able to get OpenCanopy to work, and the guide to debug Open Core indicated it was better to debug without it.  So the debug versions of the 068 files ( except bootstrap.efi, which appears to have been deprecated since the guide was written) were substituted in the attached EFI/config.plist.  Kexts were deleted to reduce size of zip but they are of recent release.  To reiterate, booting the OS works fine, only the text boot menu entries appear to be vertically out of sync with the expected function when two or more custom boot entries are made.  The custom boot entries boot their respective OSs as expected.

 

I should also mention that I am chainloading from Refind to Open Core 068 because the main bootloader, GRUB2, does not chainload version 065 and later of Open Core.   I don't know whether this issue can be reversed to allow GRUB2 to directly chainload 068, or whether Open Core code changes have permanently eliminated this option.  Perhaps the maintainers of GRUB2 should update their code.  Please give me your input on this chainloading issue.

 

I am booting Open Core 068 from a FAT32 partition separate from the ESP so I can make changes without disturbing the working ESP bootloader.

 

The attachment contains the sanitized EFI and bootlog made with the info from debug.png.

 

 

OC_EFI_bootlog.zip

Edited April 19, 2021 by HenryV
add info

[mhaeuser]

@HenryV Cannot reproduce the issue in QEMU; log is not from a DEBUG build, i.e. useless.

[STLVNUB]

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.

Edited April 24, 2021 by STLVNUB

[Allan]

Selecting which OS we will inject ACPI patches will be a good idea also. 

For me, can avoid headaches 

[mhaeuser]

@STLVNUB No, this is rubbish, no machine incl. Macs works this way.

 

@Allan Also probably no, but can you briefly explain what exactly you need it for?

[STLVNUB]

Like I said......

I do it myself with v6.0

[STLVNUB]

5 minutes ago, Hervé said:

@STLVNUB when you say you run multiple macOS versions, did you mean on the same computer? Because I do that too on 2 x Hacks (High Sierra+Big Sur on my old desktop and Catalina+Big Sur on my Dell E6230) and I made sure to always use the same SMBIOS data (incl. ROM, MLB, serial #, etc.) in each OS versions. As long as I do that, I've no issues with iCloud. iCloud only asks me to re-sign if I switch between Clover and OC where config files have different numbers.

Yeah its weird, but it probably happening to a few people

Still a good update as I've said also Allans Idea is good to

How hard would that be to code in, or do we have to do it ourselves

 

[TheBloke]

While we are doing requests, there is one that I feel would be very helpful:

DeviceProperties -> Add:  add a "Comment" and "Enabled" field, so that DeviceProperties sections can be documented and easily enabled/disabled, in the same way that ACPI->Add and other sections can be.

 

Possible example structure change:

<key>DeviceProperties</key>
<dict>
    <key>Add</key>
    <array>
        <dict>
            <key>Comment</key>
            <string>iGPU setup</string>
            <key>Enabled</key>
            <true/>
            <key>Path</key>
            <string>PciRoot(0x0)/Pci(0x2,0x0)</string>
            <key>Properties</key>
                <dict>
                    ....
                </dict>
        </dict>
        <dict>
            <key>Comment</key>
            <string>dGPU disable</string>
            <key>Enabled</key>
            <true/>
            <key>Path</key>
            <string>PciRoot(0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)</string>
            <key>Properties</key>
            <dict>
                <key>disable-gpu</key>
                <data>AQ==</data>
            </dict>
        </dict>
    </array>
    <key>Delete</key>
    <dict/>
</dict>

 

Reasons:

1. When testing a new DeviceProperties change, currently the only way to disable it is to completely cut it from the file - or keep multiple config.plist files
2. When many DeviceProperties->Add sections are included, it can be very helpful to document what each one is doing.
3. Recently I have been helping a lot of newbies on Discord with installing their first Hack (following Dortania guide), and they often get confused about the iGPU properties. Having a comment in sample.plist of "iGPU setup" or similar would help some to know immediately what this section is for, especially when they later need to come back to make ig-platform-id changes.

 

Thanks for considering this, and for all your amazing work at Acidanthera!

[mhaeuser]

@TheBloke You can add comments by prefixing the key with "#". I've not been much of a fan of the dedicated "Comment" key so far as it has no use yet, but maybe it could be changed for consistency. Enabled doesn't really make much sense to me the way you sketched it as it would apply to arbitrarily many properties (i.e. all in the list of the one device), or what would be the use-case to toggle *all* properties of a device at once? Same as before, you can prefix with "#" to disable a single property. Ping if it doesn't work for some reason.

[Rodion2010]

11 hours ago, 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.

 

 

it seems to be a bug (or feature?) of Big Sur, because Mavericks, Sierra and Mojave at the same PC do not have any problems with iCloud

[mhaeuser]

@Rodion2010 Possible, that or user error, I'm not sure myself. I know OS-coexistence has been working correctly prior to Big Sur, but many people I know have either abandoned Big Sur or use it exclusively, so I don't know the expected behaviour from it. In any case, if it's a bug it's something to file with Apple, and if it's a user-error, well, fix the config. Running multiple versions of macOS on a Mac should yield identical behaviour to with a correctly configured instance of OpenCore, so everything works as expected to my knowledge.

 

Trying to tie the UUID that identifies the machine to the kernel version loaded is well beyond ridiculous.

[Allan]

7 hours ago, Download-Fritz said:

@Allan Also probably no, but can you briefly explain what exactly you need it for?

Hello @Download-Fritz 

I have had experience some issues in Windows when I use my patched DSDT. In macOS everything is working great, but not in Windows.

 

The issues are:

 

*Trackpad and keyboard just don't work.

*Windows take much more time to boot.

 

[mhaeuser]

44 minutes ago, Allan said:

*Trackpad and keyboard just don't work.

Do you have a "rename" patch? What you would do is disable the original device if and only if macOS is booted (_OSI == "Darwin"), and add a new device, that is enabled under the same condition. I.e. Windows will see the ACPI as if there was no change, and macOS only will see the device with the new name.

 

46 minutes ago, Allan said:

*Windows take much more time to boot.

No idea, could be a side-effect of above. If not, you'd have to to disable the patches one-by-one to see which causes this I guess.

[Rodion2010]

1 hour ago, Allan said:

Hello @Download-Fritz 
I have had experience some issues in Windows when I use my patched DSDT. In macOS everything is working great, but not in Windows.

 

the problem is related with your patched DSDT not Windows neither Opencore

use  If (_OSI ("Darwin"))
                    {
                        code for macOS
                    }
                    Else
                    {
                       code for Windows
                    }
 where needed

Edited April 24, 2021 by Rodion2010

[deeveedee]

Does anyone have guidelines or opinions on how to factor Memory32Fixed resource settings into our Open Core ACPI Adds (patches)?  Do we need to be careful not to specify ACPI patches that designate Memory32Fixed resource settings that are already designated by existing Devices in our hack's original ACPI?  Details below...

 

 

@theroadw observed that the Device PMCR that I was injecting via SSDT patch (same PMCR as a real MacMini8,1 and same PMCR as in the Dortania guide) includes a Memory32Fixed resource setting that matches that of existing Device PRRE in my HP EliteDesk 800 Mini's original ACPI.    With my added Device PMCR, both the added Device PMCR and the existing (original) Device PRRE include resource setting

 

                Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
                {
                    Memory32Fixed (ReadWrite,
                        0xFE000000,         // Address Base
                        0x00010000,         // Address Length
                        )
                })

 

I have been using the Dortania PMCR patch without any problems.  Maybe I've just been lucky?  Maybe this is because Device PRRE is ignored by MacOS?

 

If Memory32Fixed resource setting is already designated by Device PRRE (an existing device in the hack's original ACPI), is it a mistake to include that same Memory32Fixed resource setting in the PMCR patch (especially given that both resource settings designate the memory resource as ReadWrite)?

 

In response to what might be a potential resource conflict, I have tested my hack with a modified PRRE._STA=0 (to disable Device PRRE) and I have tested with the modified PMCR below.  I haven't found any difference in my hack's behavior with these approaches.  My hack seems to behave the same with the Dortania recommended PMCR, with the modified PMCR below (that does not have a Memory32Fixed resource) and with disabled Device PRRE.  My gut tells me that if there's no observable difference in behavior, the safe approach is to use the modified PMCR below.

 

EDIT: 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.

 

Thanks for listening and for your thoughts/opinions.

 

Modified PMCR

I reviewed the ACPI dumps of other Macs (including iMac18,x) and see that some real Mac ACPIs include a Device PMCR that does not have any Memory32Fixed resource setting.  I have operated my HackMIni8,1 with the following Device PMCR and don't notice any difference in behavior (no difference in sleep/wake, shutdown, startup, GeekBench5...).

 

            Device (PMCR)
            {
                Name (_HID, EisaId ("APP9876"))  // _HID: Hardware ID
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If (_OSI ("Darwin"))
                    {
                        Return (0x0B)
                    }
                    Else
                    {
                        Return (Zero)
                    }
                }
            }

 

Edited April 27, 2021 by tonyx86
Concluded that no PMCR or PRRE changes are needed

[STLVNUB]

4 hours ago, Download-Fritz said:

Trying to tie the UUID that identifies the machine to the kernel version loaded is well beyond ridiculous.

Good way to test iCloud connection issues. Far from ridiculous.

if running 3 of the latest Mac OS, would be like having 3 seperate machines.

But that is only my opinion which apparently don't mean Jack {censored}

[Rodion2010]

24 minutes ago, tonyx86 said:

PMCR as in the Dortania guide) includes a Memory32Fixed resource setting that matches that of existing Device PREE in my HP EliteDesk 800 Mini's original ACPI.    With my added Device PMCR, both the added Device PMCR and the existing (original) Device PREE include resource setting

if PREE and PMCR is the same device, you may try to rename it, no need to create another one

Edited April 24, 2021 by Rodion2010

[deeveedee]

@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 April 24, 2021 by tonyx86

[Rodion2010]

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

[deeveedee]

@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 April 27, 2021 by tonyx86
Concluded that no PMCR or PRRE changes are needed

[wern apfel]

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. 

[mhaeuser]

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.

[Rodion2010]

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.

[Allan]

8 hours ago, MifJpn said:

I find it easier and smarter to use eEFInd as a preselector than a messy, ad hoc adjustment.

 

https://github.com/dortania/Hackintosh-Mini-Guides/blob/master/refind.md

Nice! Thank you 

[HenryV]

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/