OpenCore General Discussion

[vit9696]

@netgear, thanks for your tests, these are really helpful.

 

We still have a couple of questions in regards to Windows compatibility, and it is probably the time to request information from everyone affected as soon as possible as we plan to decide by next week.

 

Currently OpenCore has an ACPI Quirk called IgnoreForWindows. This quirk entirely disables OpenCore ACPI modifications when it detects Windows boot. We implemented this option as a really really temporary solution to let our team perform an easier bringup of their tested boards with least ACPI changes. This option is not necessary when ACPI stack is written properly and all the patches made (if any) are target operating system agnostic. This quirk presently has many downsides some of which can be avoided, some of which cannot be:

 

— Chainloading operating systems (e.g. UEFI Shell → Windows or UEFI Shell → macOS) is not detected, and macOS is always assumed.

— Chainloading operating systems may result in ACPI modifications (tables, patches) to be applied multiple times.

— Operating system failed launch (i.e. boot error and subsequent return to Boot Menu) may result in ACPI modifications to be applied multiple times.

— Changing operating system type (e.g. macOS → Windows) after failed launch will not "undo" the ACPI modifications once they are applied.

— Debugging of ACPI modifications becomes harder as we have to delay their application till OS start unlike all the other changes.

 

Our present experience shows that it is perfectly doable to have OpenCore boot both Windows and macOS with IgnoreForWindows = NO, and on our side the transition period is almost over, so we would like to drop this option entirely as of 0.0.3. The reasons stated above hopefully explain our strong belief that this option is too ugly and too useless to exist. We like Unix, including BSD and Linux based systems, and we believe that we can even live side by side with Windows, but we do not want to implement any kind of "detection" mechanisms in places they should not exist.

 

Even so, we do not have a good grasp on how widespread this hack is among the community, and would like everyone, who uses other operating systems (from macOS) with OpenCore, answer these questions:

— Which operating systems do you use?

— Will you need to makes changes if ACPI → IgnoreForWindows disappears?

— Do you have issues with Windows Activation which you cannot resolute?

 

Notes to remember:

— Answer this question with the assumption that OpenCore Boot Menu is the only available boot menu (i.e. assume that GRUB2, rEFIt, and built-in BIOS boot menu do not existent).

— Last question is not about ACPI → IgnoreForWindows, but rather SMBIOS changes that we make, and the decision on the two will most likely be separate.

— After answering the questions an elaborate express of your opinion is welcome. Potentially with the suggestions on the route you see being beneficial to all parties.

— We will not detect any operating system but Windows (i.e. implement exceptional quirks for any other OS).

— We will not detect macOS and apply changes uniquely to it, in the end it can be Windows and any other OS or just any other OS.

 

Thanks!

[Guest]

@vit9696

 

1) Windows 10 pro 64 bit serial number licence / OSX high sierra and Mojave

2) yes, otherwise i have bsod and windows error

3) no licensing problem for me

 

for point 2 i think is a my fault and i have to understand better about acpi table rename

 

[dgsga]

@vit9696

 

1) Windows 10 LTSC (uses up less disk space and no Metro )

2) No, I just use the OSDW switch to implement macOS only changes

3) No activation issue for me

[vit9696]

@fabiosun, even in our team there formerly were loads of confusion with select things.

 

Here is a small list you can find helpful (even though it is really out of the scope of this thread):

— Many people cause a lot of harm to their systems trying to rename devices for no sane reason. Do not do that.

— EC device is often misconfigured, and even 0.0.2 shipped with a half-broken example. We updated our samples here.

— HPET/RTC must always be enabled, but be very careful about the IRQs, some people remove them, yet this is usually strongly undesired.

 

Good luck

Edited May 30, 2019 by vit9696

[netgear]

Windows 10 Retail should have no activation problems as this is serial based. LTSC LTSB etc. are systems that are activated with Volume Licensing, so you must always specify how the system is activated . The problem in my opinion remains only on OEMs based on the hardware mac address.

-

Non-OEM activations always work:

-

 

 

[tmbt]

12 hours ago, vit9696 said:

@fabiosun, even in our team there formerly were loads of confusion with select things.

 

Here is a small list you can find helpful (even though it is really out of the scope of this thread):

— Many people cause a lot of harm to their systems trying to rename devices for no sane reason. Do not do that.

— EC device is often misconfigured, and even 0.0.2 shipped with a half-broken example. We updated our samples here.

— HPET/RTC must always be enabled, but be very careful about the IRQs, some people remove them, yet this is usually strongly undesired.

 

Good luck

@vit9696 First of all thanks for the immense work you're doing for the hackintosh community!

I've a question about the second point you've done in that reply. I've tried to use your EC patch while disabling the EC0 rename to EC as you suggested but if i do that at reboot i've no more battery icon (nor i can re enable it), under mac info -> Power it says that my charger is connected to my laptop when it is not and according to Intel power gadget my laptop watt consumption is insane (like 3Watt on idle when i had 0,6Watt before the change). 

Where i can start searching for some clues ?

 

Thanks

Mattia

 

[vit9696]

@tmbt, laptops are a particular nuance, where the "try" part in the comment hides some details. Without builtin EC controller most laptops will indeed malfunction, and disabling it is not an option.

 

In an ideal world the "correct" solution for a laptop is to make a conditional _HID method for EC0 that will return some random name (e.g. ACID0002) for Darwin and normal PNP for other systems (e.g. Windows). This will prevent AppleACPIEC from matching on EC0, and will leave your EC controller visible from ACPI for battery functioning and such.

 

In a real world it may be painful to mess with _HID method (in case you are unwilling to make a custom DSDT, for example) especially when AppleACPIEC does not crash your system. In this case you can just add a EC device and "forget" about EC0/AppleACPIEC incompatibility until it starts to cause problems.

 

Some people would suggest just renaming EC0 to EC, which technically has the same level of quality as the "real world" variant. You could do that, but I would rather avoid this method, as these embedded controllers despite the same class are really different in their nature, and merging two different devices into one may cause a lot of confusion to arise.

[Shaneee]

Touchy subject I know but we've managed to get AMD CPUs to get detected correctly in OpenCore. Well Zen at least.

00:000 00:000 Found AMD Ryzen 5 2400G with Radeon Vega Graphics    
00:000 00:000 Signature 10 Stepping 0 Model 11 Family F Type 0 ExtModel 1 ExtFamily 8
00:000 00:000 TSC Frequency  4000000000  4000MHz
00:000 00:000 CPU Frequency  4000000000  4000MHz
00:000 00:000 FSB Frequency   100000000   100MHz

Now the issue we have is patching the kernel from within OpenCore. With the Vanilla kernel in place and all the patches written into the config the log shows that the patch was a success,

Kernel patcher result 0 for kernel - Success

However it doesn't boot past boot.efi. Now if we take the same patches hex edit the vanilla kernel using find and replace on the values, OpenCore will boot the patched vanilla kernel on AMD just fine. In fact I'm typing from it just now. I've attached my config below in case I've maybe missed something on the kernel patching part but we can't work out why.

config.plist

[vit9696]

@Shaneee, my best guess is that some patches you have are somehow different from your hex editing efforts.

We have a dedicated program to debug our prelinkedkernel patcher in userspace:

https://github.com/acidanthera/OcSupportPkg/blob/master/TestsUser/Prelinked/Prelinked.c

 

In case you have someone with C knowledge, you can put the patches into this program, compile it, and debug as a general macOS program with lldb.

This will help you understand what is patched, and what is not. Once you find the problem, please give me the details, and we will try to help.

[MacPato]

AMD CPU Implementation is something i'm looking forward too, with Open Core.

[Rocky12]

i am still waiting please can someone with more experience can create a installer packeg for legacy booting 

Edited June 2, 2019 by Rockey12

[stevezheng]

On 5/31/2019 at 6:11 AM, vit9696 said:

— HPET/RTC must always be enabled

I have a question about that. I see MBP14,1 MBP14,2 and MBP15,2's DSDTs, and their HPET devices are all disabled. The _STA method in HPET looks like this :

Device (HPET)
                {
                    Name (_HID, EisaId ("PNP0103") /* HPET System Timer */)  // _HID: Hardware ID
                    Name (_CID, EisaId ("PNP0C01") /* System Board */)  // _CID: Compatible ID
                    Name (BUF0, ResourceTemplate ()
                    {
                        IRQNoFlags ()
                            {0}
                        IRQNoFlags ()
                            {8}
                        Memory32Fixed (ReadWrite,
                            0xFED00000,         // Address Base
                            0x00004000,         // Address Length
                            )
                    })
                    Method (_STA, 0, NotSerialized)  // _STA: Status
                    {
                        If (OSDW ())
                        {
                            Return (Zero)
                        }

                        If ((OSYS >= 0x07D1))
                        {
                            Return (0x0F)
                        }
                        Else
                        {
                            Return (0x0B)
                        }

                        Return (Zero)
                    }

And HPET device is not shown in ioreg. Maybe Kabylake+ devices do not need HPET device to boot in macOS?

 

Another question is that BlockTable function may need to be disabled in other OS, because some users have to drop cpupm tables, which causes PM troubles in Windows or other OS. (And drop DRAM will cause unworking Vt-d technology) Adding a quirk option about this may better? I am not sure.

Edited June 2, 2019 by zhengshiqi

[applCore]

@vit9696 or anyone who might know, where can one contribute to helping OpenCore run on native Apple hardware?

 

I think everyone can see the writing on the wall and those of us with some of the more capable systems (2009 Mac Pro on up) that can run Metal without a problem due to upgraded video cards would like to be able to start having more robust boot options. Heck, I think every Apple user could benefit from this, but it obviously has to start with someone and somewhere.

 

 

[uglyJoe]

On 5/30/2019 at 1:49 PM, vit9696 said:

...

 

Even so, we do not have a good grasp on how widespread this hack is among the community, and would like everyone, who uses other operating systems (from macOS) with OpenCore, answer these questions:

— Which operating systems do you use?

— Will you need to makes changes if ACPI → IgnoreForWindows disappears?

— Do you have issues with Windows Activation which you cannot resolute?

 

Notes to remember:

— Answer this question with the assumption that OpenCore Boot Menu is the only available boot menu (i.e. assume that GRUB2, rEFIt, and built-in BIOS boot menu do not existent).

— Last question is not about ACPI → IgnoreForWindows, but rather SMBIOS changes that we make, and the decision on the two will most likely be separate.

— After answering the questions an elaborate express of your opinion is welcome. Potentially with the suggestions on the route you see being beneficial to all parties.

— We will not detect any operating system but Windows (i.e. implement exceptional quirks for any other OS).

— We will not detect macOS and apply changes uniquely to it, in the end it can be Windows and any other OS or just any other OS.

 

Thanks!

 

With and without rEFInd:

1. Windows 10 Pro 64bit

2. No

3. No

[vandroiy2012]

OK. 

So OpenCore boots latest beta macOS 10.15 without any problem!

Kext injection is working without any interference. 

 

Thanks @vit9696

[gengik84]

Yeah
OpenCore is  

Thx Acidanthera team !

[MacPato]

2 hours ago, vandroiy2012 said:

OK. 

So OpenCore boots latest beta macOS 10.15 without any problem!

Kext injection is working without any interference. 

 

Thanks @vit9696

Mine didn't boot it, Shows ACPI KextStall

[vandroiy2012]

15 minutes ago, MacFriedIntel said:

Mine didn't boot it, Shows ACPI KextStall

Bootarg -lilubetaall or build latest Lilu + Plugins from GitHub. 10.15 support already added to major plugins. 

[MacPato]

42 minutes ago, vandroiy2012 said:

Bootarg -lilubetaall or build latest Lilu + Plugins from GitHub. 10.15 support already added to major plugins. 

This fixed the issue, Thanks

[namine207]

On 5/1/2019 at 10:58 AM, MrTrip said:

Bumping with my issue again since it got buried... honestly I don't know why we have these mega threads when questions get buried faster than they can be viewed or answered.

 

Z390 Chipset, macOS is installed to my NVME Samsung 960 Pro, is seen by Clover when booting but not seen by OC when booting. Another Z390 user has this same issue. Z370 seems to not have this issue, we've tried the exact same setup as the Z370 user and no go. An issue was posted on the bug tracker and it was closed and told people to come here for support. 

Was a solution ever found for this? Also experiencing this issue. I can see my recovery volume and it boots great, but it doesn't show my main volume the 960 EVO in either SATA or PCIE mode.

[Pavo]

1 hour ago, namine207 said:

Was a solution ever found for this? Also experiencing this issue. I can see my recovery volume and it boots great, but it doesn't show my main volume the 960 EVO in either SATA or PCIE mode.

Check Scan Policy settings.

[xtddd]

6 hours ago, vandroiy2012 said:

OK. 

So OpenCore boots latest beta macOS 10.15 without any problem!

Kext injection is working without any interference. 

 

Thanks @vit9696

can you share your opencore-efi? thank you.

[namine207]

2 hours ago, Pavo said:

Check Scan Policy settings.

At the moment it seems the scan policy isn't set in the plist. What would be an ideal value to set it to? Should it pick up my NVME drive using the default value of 

0xF0103?

[blackosx]

4 hours ago, xtddd said:

can you share your opencore-efi? thank you.

You will need to set up your own EFI.

Check the Manual for full details

 

2 hours ago, namine207 said:

At the moment it seems the scan policy isn't set in the plist. What would be an ideal value to set it to? Should it pick up my NVME drive using the default value of 

0xF0103?

 

As stated in the manual:

Note: Given the above description, 0xF0103 value is expected to allow scanning of SATA, SAS, SCSI, and NVMe devices with APFS file system, and prevent scanning of any devices with HFS or FAT32 file systems in addition to not scanning APFS file systems on USB, CD, USB, and FireWire drives.

 

I use zero to allow all devices and all filesystems. 

[vit9696]

@zhengshiqi, HPET is unused on all(?) systems that use XCPM power management from Broadwell or about that time. It looks like my memory failed me, and I provided some outdated news.

 

For DMAR we are preparing a kernel quirk, which will disable VT-d on macOS level. We believe it is a better place than DMAR dropping given that one day we should probably make APTIO VT-d support compatible with macOS. Added as DisableIoMapper in this commit.

 

To support CPU PM in macOS modern boards (starting with Haswell at the very least) using XCMP do not need table dropping for CPU PM support. Legacy systems works fine with dropping. For particular legacy systems (we currently do not have) we believe it should be doable to write compatible ACPI tables with both Windows and macOS.

 

@applCore, OpenCore is supposed to work on Apple hardware just fine, and I will be surprised if it does not. However, you will have to be very careful with UI, it needs to be set to Text mode to make boot picker visible.

 

Edited June 4, 2019 by vit9696