Jump to content

OpenCore General Discussion


dgsga
8,887 posts in this topic

Recommended Posts

14 hours ago, telepati said:

Are you holding or repeatedly press? Cause I tried both it never worked.

 

But with AppleUsbKbDxe.efi its working like a crazy.

 

Update: I've switched the KeySupportMode to AMI and it seems i have to wait to press the keys until after the BIOS splash screen to disappear (Gigabyte Z170). I press and hold. Both book picker via opt and verbose mode tested and work fine this way, and even am able to wait around 1sec after the bios splash screen disappears to get the hotkeys working. (0.5.5 release)

Hope that helps!

  • Thanks 1
Link to comment
Share on other sites

3 hours ago, canyondust said:

 

Update: I've switched the KeySupportMode to AMI and it seems i have to wait to press the keys until after the BIOS splash screen to disappear (Gigabyte Z170). I press and hold. Both book picker via opt and verbose mode tested and work fine this way, and even am able to wait around 1sec after the bios splash screen disappears to get the hotkeys working. (0.5.5 release)

Hope that helps!

If you don't mind could you please share your config.plist I want to compare with mine.

 

BTW is your timeout set 0 or 5? To be sure set 0 then try is it still working or not?

 

I tried Auto and AMI too with timeout 0 it's never working. It always boots with the default drivers. Also set TakeOffDelay 5.000 and 10.000 but it never helped either. For me best options looks like AppleUsbKbDxe.efi. With this efi works like a real make. I don't even think when I must press its always accurate and its always working. 

 

I attached my config.plist.

 

config.plist

Edited by telepati
Link to comment
Share on other sites

39 minutes ago, mathew2019 said:

Why I am getting these errors when I use latest OC V5.5, the booting is stuck on this screen. OC 5.4 is working fine.

IMG_5872.JPG

Looks like you missed quite of few updates to the config, compare yours to the newer Sample.plist

Link to comment
Share on other sites

6 minutes ago, SV0911 said:

I upgraded OpenCore to V. 0.5.6 , everything works great, only on boot a little error occurs:

 

"ocr: only 19 acpi tables out of 20 were valid"

 

Maybe someone can give me a hint.. how to fix it. I've searched a few hours, found nothing....

Big thanks for help

 

 

 

 

myabe you can post your EFI folder and debug log file

Link to comment
Share on other sites

10 hours ago, telepati said:

If you don't mind could you please share your config.plist I want to compare with mine.

 

BTW is your timeout set 0 or 5? To be sure set 0 then try is it still working or not?

 

I tried Auto and AMI too with timeout 0 it's never working. It always boots with the default drivers. Also set TakeOffDelay 5.000 and 10.000 but it never helped either. For me best options looks like AppleUsbKbDxe.efi. With this efi works like a real make. I don't even think when I must press its always accurate and its always working. 

 

I attached my config.plist.

 

config.plist

I will next time I’m at my machine. I switched from AppleUsbKbDxe because it kept key presses in a buffer; in order to choose a picker option I had to press the number more than once and found that annoying.

  • Like 2
Link to comment
Share on other sites

I want to ask the developers if they could consider adding these features after all:

  • ACPI patches are optional for non macOS with setting ACPI->Quirks->EnableForAll to yes (default is no).
  • Booter Quirtks, SMBIOS and Device Properties patches will only applied to macOS.

I have read the reasons why you do not want to implement these functions, but after considering all the pros and cons, I think the lesser evil is to have these functions implemented.

What do you think guys?

  • Like 1
Link to comment
Share on other sites

1 hour ago, darthsian said:

I want to ask the developers if they could consider adding these features after all:

  • ACPI patches are optional for non macOS with setting ACPI->Quirks->EnableForAll to yes (default is no).
  • Booter Quirtks, SMBIOS and Device Properties patches will only applied to macOS.

I have read the reasons why you do not want to implement these functions, but after considering all the pros and cons, I think the lesser evil is to have these functions implemented.

What do you think guys?

Cause enables all quirks to make the system unusable.

Link to comment
Share on other sites

22 minutes ago, telepati said:

Cause enables all quirks to make the system unusable.

I do not know what you mean by this. I dont want to enable all quirks. I want ACPI patches to be applied only to macOS with Quirk "EnableForAll set to NO".

  • Like 1
Link to comment
Share on other sites

24 minutes ago, darthsian said:

I do not know what you mean by this. I dont want to enable all quirks. I want ACPI patches to be applied only to macOS with Quirk "EnableForAll set to NO".

Then write your ACPI patches to only be effected when its macOS, this is easily done with a if {} else {} statement in the SSDT. Look at the examples.

  • Like 5
Link to comment
Share on other sites

3 hours ago, vit9696 said:

This has already been answered many times, but long story short, we will not make ACPI patches OS-dependent. There are many reasons for them, and there is a good explanation here: 

.

I read that explanation before... and i still think that its not good idea to "simulate" Mac on Windows with "Windows native" hardware and BIOS which is already ACPI ready for Windows, Linux etc. You cant use proprietary logic board software, many hardware sensors are missing etc. But of course I respect that this is your project and your decision :)

Edited by darthsian
  • Like 3
Link to comment
Share on other sites

@darthsian That point does not relate to ACPI, which there is no good point for such a quirk, but only to SMBIOS. The thing with SMBIOS is, we consider OpenCore to be an environment, where we expose Mac information to seamlessly boot macOS. Now, if you do not want Windows to be part of that environment, the most intuitive solution is to just not boot Windows through this environment. Why do you want to boot Windows via OpenCore "so badly" if it causes trouble?

  • Like 3
Link to comment
Share on other sites

16 hours ago, Pavo said:

Looks like you missed quite of few updates to the config, compare yours to the newer Sample.plist

HI Pavo

 

Thank you, you were right. I have used old config.plist to the updated OC version which made this issue. 

 

One more question, how can I add CPU type to OC?

Link to comment
Share on other sites

11 minutes ago, mathew2019 said:

HI Pavo

 

Thank you, you were right. I have used old config.plist to the updated OC version which made this issue. 

 

One more question, how can I add CPU type to OC?

Either by using Kernel > Emulate or PlatformInfo > SMBIOS

Link to comment
Share on other sites

1 hour ago, Download-Fritz said:

@darthsian That point does not relate to ACPI, which there is no good point for such a quirk, but only to SMBIOS. The thing with SMBIOS is, we consider OpenCore to be an environment, where we expose Mac information to seamlessly boot macOS. Now, if you do not want Windows to be part of that environment, the most intuitive solution is to just not boot Windows through this environment. Why do you want to boot Windows via OpenCore "so badly" if it causes trouble?

Because i just want one environment for multi boot purpose. Never mind, I just wanted to share some of my opinions. You are doing great job with OpenCore. Thanks for that.

Link to comment
Share on other sites

When i play video 1920x1080 60fps with quicktime player the screen flickering black

When i play video 1920x1080 30fps or 25fps video worked  fine no flickering

What is this issue 

anyone can tell me about this issue i think this issue is related shiki or quicktime player

Link to comment
Share on other sites

On 1/30/2020 at 5:44 PM, Sniki said:

In case you added a kext or ACPI table and it's causing the system trouble and not being able to boot anymore:

is there a way to edit the config.plist file of OpenCore in boot picker/or using a OC tool so you can drop that specific ACPI table or not inject that specific kext that is causing trouble ?

 

For now i always make a USB flash drive with current working EFI so in case i mess, i boot from the USB as a last known good working bootloader configuration.

 

Enter shell from picker:

fs0:
cd EFI/OC
edit config.plist

You'll figure out rest.

  • Like 1
  • Thanks 3
Link to comment
Share on other sites

8 hours ago, hardcorehenry said:

If anyone is interested in disabeling divices that aren’t present in real MAC like AMW0, SIO1, MBDA, TPMX here some small SSDT examples. They are reenabled for other OSes( If (_OSI ("Darwin”)…). Check if you have the same scopes and rename “fits”. Works for ASUS H81M-E. Tested for over month no issue.REM_DEV.zip

AMW0, for example, just ignored by macOS. Not needed to disable it manually.

Tested for nine years by thousands users no issue.

  • Like 2
Link to comment
Share on other sites

3 hours ago, Slice said:

AMW0, for example, just ignored by macOS. Not needed to disable it manually.

Tested for nine years by thousands users no issue.

 

You right removing AMW0 from IOReg is rather cosmetic, but for example device CWDT which also not present in real Mac, may confuse monitoring(here older topic), I’m far from being expert, thou. As I mentioned I have no issue after removing them, the only non MAC devices in my IOReg are FAN(0,1…)  and TZ01,2

 

CWDT.png.dcf3e1d23c01b818120bc0d7c40c42a3.png

 

DefinitionBlock ("", "SSDT", 2, "hack", "CWDT", 0x00000000)
{
    External (_SB_.PCI0.LPCB.CWDT, DeviceObj)
    External (_SB_.PCI0.LPCB.CWDT.XSTA, MethodObj)    // 0 Arguments
    External (XSTA, MethodObj)    // 0 Arguments

    Scope (\_SB.PCI0.LPCB.CWDT)
    {
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (_OSI ("Darwin"))
            {
                Return (Zero)
            }
            Else
            {
                Return (XSTA)
            }
        }
    }
}

 

Link to comment
Share on other sites

So I am testing OC.

I "transplanted" my Clover config over to OC 0.5.6 for my Z77X-UP5-TH motherboard and now booting Mojave & Catalina.

 

Questions about DEBUG output:

 

1. With the debug build, at boot I see the following on the screen :

OC-start2.thumb.jpg.7f8884c89befebee243cb52089708326.jpg

 

I have removed Clover on the EFI Partition and installed OC on it. Why is OC starting two times ?

 

2. Is there a way to have this initial text redirected to the OC log file on the root of the EFI together with he rest of the log ?

 

In my config.plist, I have set :

Root->Misc->Debug->DisplayLevel->0x80000042

Root->Misc->Debug->Target->0x45

 

I have tried different settings of DisplayLevel and Target but the initial screen output (shown above) never makes it to the log file.

 

3. With the Non-DEBUG version of OC, is it possible to still have the PREBOOT log (like Clover) instead of:

00:000 00:000 Starting ApfsDriverLoader ver. 2.1.5
01:384 01:384 EfiBootRecord located at: 5833904 block
01:389 00:004 Real image size: 628216
01:396 00:007 Signature verified!
01:777 00:380 EfiBootRecord located at: 0 block
05:126 03:349 EfiBootRecord located at: 16033038 block
05:131 00:004 Real image size: 602936
05:138 00:007 Signature verified!
05:359 00:220 EfiBootRecord located at: 4300351 block
05:364 00:005 Real image size: 583992
05:371 00:007 Signature verified!

PS. Alt/Esc, CMD+R, etc keys work well and even got the BootChime :)

Link to comment
Share on other sites

×
×
  • Create New...