OpenCore General Discussion

[mhaeuser]

@eSaF There was "HideSelf" before, with which you could opt to have OC show itself, but is has been removed months ago.

[tmbt]

On 4/15/2021 at 6:00 PM, antuneddu said:

already @miliuco, but also 100mb if you see my efi it's 26mb so there should still be some space left, hidden files 

I just checked and have the same hidden folders. The biggest one is the Spotlight folder which is around 3MB. Trashes and the others are almost empty.

I'm not sure why my EFI is only 100MB because i've installed Big Sur from scratch on this laptop and to create the installer i used another Hackintosh and during the installation i initialize the ssd using the Disk Utility in Big Sur installer ... so it's strange ..

Is there something i can do to try to increase the EFI partition size ?

 

Thanks

Mattia

 

[HenryV]

Open Core 0.6.8 test menu anomaly.

 

Am not using the GUI for now with 0.6.8.

 

When adding a text menu item, either by enabling UEFI Shell option in config.plist, OR by adding only one entry via the menu entries area of config.plist, the menu displays and functions as expected in text mode.  

When adding an additional menu entry, such as another linux distro to the config.plist menu entries area, that is when the issue manifests with the picker text menu.

 

The list of menu items displays normally but the function does not correspond to the text.

 

For instance, if I have two entries from the vertical menu list, say:

 

UEFI Shell
GRUB bootloader

 

I have to click on GRUB bootloader to invoke the UEFI Shell.  If I want GRUB bootloader I have to click on the menu item directly below that entry.  If I want the last item in the menu list I have to click on the empty space below the last item on the list.  

 

The appearance of the menu list isn't necessarily the issue, but when adding more than one item to the list the functions associated with the new entry, and all the other entries, become disassociated.  The menu entry does not execute the expected function.

 

The function is shifted to the next line in the vertical menu.

 

If I remove all but one of the newly added entries then the menu works as expected.

I hope this is clear enough.

 

If you have duplicated this issue on your machine let know.  If it is a bug should it be reported to a developer in this forum?  Of not, where?

This is the first time trying to do custom menu entries, and because of changing code this issue may not have existed on previous releases of OC.

 

There are no hardware issues nor installed OS software issues.   Only the mismatch between the menu text entries and the expected function, and only when making more than one new menu entry.    I also used ProperTree to see if making the entries that way would produce a different result, and it didn't, so I don't think it is an issue of incorrect XML syntax/format.

 

Has anyone else experienced this issue?

Edited April 19, 2021 by HenryV
correction

[miliuco]

2 hours ago, eSaF said:

@miliuco - Bro here is the proof of that volume removed from the Boot Menu referring to the posts you and I sheared a few days back. 

You are right. When I used OC for the first time, HideSelf option did not exist, before I was a Clover user.

[sam298]

On 4/14/2021 at 3:17 PM, tonyx86 said:

According to Dortania Guide, USBX is required for USB power properties as an OC post-install step.  If we have USB power properties in USBPorts.kext, is USBX required?

 

I've seen multiple discussions about this topic (maybe even earlier in this thread), but there seem to be as many opinions as there are posts.  My last two rigs have a custom USB port map (USBPorts.kext) that includes USB power properties.  I update USBPorts.kext/Contents/Info.plist with the matching USB power properties for my selected SMBIOS (extracted from a real Mac ACPI).  I don't inject Device (USBX) on these rigs and USB seems to work perfectly (with the correct power properties in IORegistry).

 

What's the latest recommended way to configure USB power properties: Device (USBX) or USBPorts.kext?

I also heard from someone who tested different power properties in kext and SSDT and concluded that SSDT is not doing anything but kext is applying the power properties. I am currently using both SSDT and kext. Sleep works fine and I don't want to mess it up. There is no harm in using both.

[mhaeuser]

@HenryV Please

- Provide a DEBUG log

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

- Test whether OpenCanopy works as intended

[deeveedee]

OC Developers - I've been playing with ACPI hot-patching using Base, BaseSkip, Count.  VERY POWERFUL and intuitive.  Note that i never worked extensively with hot-patching via CLOVER, so I can't compare.  With OC, you've managed to eliminate the complexity and actually make it fun!   Outstanding work!  Thank you!

[deeveedee]

For anyone who's wondering "Does Rehabman's ACPI Debug still work in Open Core 0.6.8?"  The answer is YES!  Currently loading Rehabman's ACPIDebug.kext and injecting SSDT-RMDT with OC 0.6.8 to debug a new hack running Catalina 10.15.7.  Amazing tool from an Amazing contributor.

[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