Jump to content

990 posts in this topic

Recommended Posts

Posted (edited)
23 minutes ago, PMheart said:

One difference is that Clover handles ACPI modifications to macOS *ONLY*, while OC applies to all OS.

 

You have to ensure the compatibility with every OS booted.

This is one thing I think OC should stay completely away from in my opinion, use regular mobo boot menu to use Windows/Linux, OC should stay strictly to MacOS only. Or at least strictly work only on the MacOS part until its "completely" done, until adding other OS support.

Edited by Pavo

Share this post


Link to post
Share on other sites
Advertisement

@Pavo, while appreciate other opinions, I am afraid you mislead people saying that OpenCore should not play any role in changing environment for all operating systems but macOS.

 

I already explained why it is impractical to decide on modifications specifically for the OS, and do not want to do it again, just flip a few pages back. Using the approach we took opens new routes for third-party development and unification, so we believe it is the only right way to follow. Sure, it adds some nuances for the older users, who potentially have to adopt, but it does not affect new users, so it is really just a legacy tradition to finally abandon.

 

Of course you could always use the BIOS boot menu if you continue using BOOTx64.efi like now, but in case you plan deeper integration with OpenCore in the future, you should not rely on it. For example, it may be replaced and prevented from launching for firmware boot or registered driver boot.

 

For those trying to disagree, just think of it as a Mac. On your Mac the firmware does not distinguish from Windows and macOS, it provides both with same SMBIOS and ACPI. So does OpenCore.

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, vit9696 said:

@Pavo, while appreciate other opinions, I am afraid you mislead people saying that OpenCore should not play any role in changing environment for all operating systems but macOS.

 

I already explained why it is impractical to decide on modifications specifically for the OS, and do not want to do it again, just flip a few pages back. Using the approach we took opens new routes for third-party development and unification, so we believe it is the only right way to follow. Sure, it adds some nuances for the older users, who potentially have to adopt, but it does not affect new users, so it is really just a legacy tradition to finally abandon.

 

Of course you could always use the BIOS boot menu if you continue using BOOTx64.efi like now, but in case you plan deeper integration with OpenCore in the future, you should not rely on it. For example, it may be replaced and prevented from launching for firmware boot or registered driver boot.

 

For those trying to disagree, just think of it as a Mac. On your Mac the firmware does not distinguish from Windows and macOS, it provides both with same SMBIOS and ACPI. So does OpenCore.

Maybe I should clarify my previous post then. Where I do agree with your decision to support multiple OS environments. I disagree that the focus of development to support those environments should be done now, all efforts for development should be focused on MacOS environment until completed, then move to supporting another OS environment. 

 

Thinking like how a real Mac does it is completely different though because a real Mac has ACPI support for both OS environments built-in the ACPI tables themself, where PC motherboards do not. The only reason people need ACPI patches, additions or deletion of ACPI components is for MacOS and only MacOS environment. You wouldn't patch your ACPI tables for Windows nor for Linux and I would assume any bootpicker alike wouldn't do that either.

 

But I must say you have given a new life to the hackintosh community with your evolutionary ways of doing things from drivers, to kexts and now bootpicker, so thank you and your team for the efforts that you have done and continue to provide.

Edited by Pavo

Share this post


Link to post
Share on other sites

I realise OC is still in the development stage but I would very much like to try it on my rig as I did in the early days with Chameleon and then Clover. From what I've read so far I find it a fascinating and exciting project. Can anyone point in the direction of a tutorial on how to make a usb installer if that is the process or basically the rudiments on getting started - Thanks.

Share this post


Link to post
Share on other sites
3 hours ago, eSaF said:

I realise OC is still in the development stage but I would very much like to try it on my rig as I did in the early days with Chameleon and then Clover. From what I've read so far I find it a fascinating and exciting project. Can anyone point in the direction of a tutorial on how to make a usb installer if that is the process or basically the rudiments on getting started - Thanks.

your config will be much diff maybe from mine

Share this post


Link to post
Share on other sites
3 hours ago, eSaF said:

I realise OC is still in the development stage but I would very much like to try it on my rig as I did in the early days with Chameleon and then Clover. From what I've read so far I find it a fascinating and exciting project. Can anyone point in the direction of a tutorial on how to make a usb installer if that is the process or basically the rudiments on getting started - Thanks.

 

Same here, this may help: https://github.com/khronokernel/Getting-Started-With-OpenCore

Share this post


Link to post
Share on other sites

@ WarDoc - Thank you so much for the video link - @ e97 thanks also, very much appreciate the info. Please forgive my enthusiasm but for me the onset of a new OS X and the excitement surrounding OC, takes me back to my time with S/Leopard and Chameleon that gave me countless hours of hair pulling and large bags under my eyes :lol: Thankfully and hopefully those days are behind me because instead of lurking (fearful of sounding stupid by asking dumb questions) I will ask the Knowledgeable my particular query. Thanks again guys.

Share this post


Link to post
Share on other sites
7 hours ago, eSaF said:

I realise OC is still in the development stage but I would very much like to try it on my rig as I did in the early days with Chameleon and then Clover. From what I've read so far I find it a fascinating and exciting project. Can anyone point in the direction of a tutorial on how to make a usb installer if that is the process or basically the rudiments on getting started - Thanks.

 

Howdy :)

 

Just been reading about OC this morning and it seems that OC has better optimizations, patching and  implementation of devices from EFI boot, indeed looks like an exciting project. Thinking of giving this a blast, may upload an experimental EFI folder to my Aorus Pro Guide ( If I get it working :D ) 

 

As far as I know you can't use Drivers from Clover, correct me if I'm wrong anyone!

 

 

 

Share this post


Link to post
Share on other sites
9 hours ago, PMheart said:

One difference is that Clover handles ACPI modifications to macOS *ONLY*, while OC applies to all OS.

 

You have to ensure the compatibility with every OS booted.

 

Ok, 
1. I don't make any patch about LPC/LPCB device to my DSDT.
2. I am Zeroing STA of HDAS in my DSDT and create new HDEF with _DSM.
3. I made Zeroing STA of GFX0 too and create new device IGPU + _DSM

Result with OC,
1. My LPC/LPCB get problem in Windows (no issues with CLOVER with same DSDT)
2. My Audio controller get problem too in Windows (no issues with clover with same DSDT)
3. My IGPU, external GPU (GFX0), SATA, and other working fine in windows with OC except 2 device above (i made Zeroing old device and create new device for patch).

So, what i miss?? If it about method of patch, all device include SATA, external GPU, IGPU should get problem too. I don't use any ACPI patch in config.plist of OC. Can you show me source of the problem???


280529379_Annotation2019-06-13133040.thumb.png.a340d4149152028a4d692a3517537933.png

Share this post


Link to post
Share on other sites

@ glasgood and Andres ZeroCross - WarDoc and e97 posted two great links, check them out - So excited I'm wetting my self :hysterical: 

Share this post


Link to post
Share on other sites
3 minutes ago, eSaF said:

@ glasgood and Andres ZeroCross - WarDoc and e97 posted two great links, check them out - So excited I'm wetting my self :hysterical: 

I have OC bootloader in my system,, no piece of problem in my PC if i use OC bootloader to boot to MacOS. The problem is OC to Windows

Share this post


Link to post
Share on other sites
13 minutes ago, Andres ZeroCross said:

Ok, 
1. I don't make any patch about LPC/LPCB device to my DSDT.
2. I am Zeroing STA of HDAS in my DSDT and create new HDEF with _DSM.
3. I made Zeroing STA of GFX0 too and create new device IGPU + _DSM

 

Why are you doing this? 

In the majority of the cases ACPI patches are not useful and harmful. 

 

AppleALC can make on-the-fly rename in Ioreg and you can inject custom properties with DeviceProperties in config.plist. 

WhateverGreen can make on-the-fly rename for IGPU and PEG0 in Ioreg. It automatically inject IGPU properties for IQSV and you can manually inject custom properties with DeviceProperties in config.plist for both cards. 

 

Your motherboard does not need any patches at all.

 

 

Quote

 Avoid renaming devices with ACPI patches. This may fail or perform improper renaming of unrelated devices (e.g. EC and EC0), be unnecessary, or even fail to rename devices in select tables. For ACPI consistency it is much

safer to rename devices at I/O Registry level, as done by WhateverGreen.

  • Avoid patching _OSI to support a higher level of feature sets unless absolutely required. Commonly this enables a number of hacks on APTIO firmwares, which result in the need to add more patches. Modern firmwares generally do not need it at all, and those that do are fine with much smaller patches.

  • Try to avoid hacky changes like renaming _PWR or _DSM whenever possible. Several cases, where patching actually does make sense, include:

    • Refreshing HPET (or another device) method header to avoid compatibility checks by _OSI on legacy hardware._STA method with if ((OSFL () == Zero)) { If (HPTE) ... Return (Zero) content may be forced to alwaysreturn0xFbyreplacingA0 10 93 4F 53 46 4C 00withA4 0A 0F A3 A3 A3 A3 A3.

    • To provide custom method implementation with in an SSDT, for instance, to report functional key presses on a laptop, the original method can be replaced with a dummy name by patching _Q11 with XQ11.

 

Share this post


Link to post
Share on other sites
12 minutes ago, Andres ZeroCross said:

 

Ok, 
1. I don't make any patch about LPC/LPCB device to my DSDT.
2. I am Zeroing STA of HDAS in my DSDT and create new HDEF with _DSM.
3. I made Zeroing STA of GFX0 too and create new device IGPU + _DSM

Result with OC,
1. My LPC/LPCB get problem in Windows (no issues with CLOVER with same DSDT)
2. My Audio controller get problem too in Windows (no issues with clover with same DSDT)
3. My IGPU, external GPU (GFX0), SATA, and other working fine in windows with OC except 2 device above (i made Zeroing old device and create new device for patch).

So, what i miss?? If it about method of patch, all device include SATA, external GPU, IGPU should get problem too. I don't use any ACPI patch in config.plist of OC. Can you show me source of the problem???

...

...

 

Just a thought. How did you create your DSDT?

Extracted from Firmware or from running OS with active Clover patches?

Share this post


Link to post
Share on other sites
1 minute ago, Andres ZeroCross said:

I have OC bootloader in my system,, no piece of problem in my PC if i use OC bootloader to boot to MacOS. The problem is OC to Windows

 

Ok - As It is still in its infancy stage and I am at this moment completely ignorant of its operation, maybe the Devs or the knowledgeable ones will offer a tangible solution. With all the possible early stage bugs and pitfalls I still intend to give it a try as I've heard great things about it i.e faster boot times compared to clover and a cleaner EFI Partition.

Share this post


Link to post
Share on other sites
Posted (edited)

@Andres ZeroCross, it is very simple: you do not have an idea to what is written here https://uefi.org/specifications, and thus your DSDT is simply borked. The only thing that makes macOS work with it, is that macOS is by far more tolerant to inadequate changes.

 

@vandroiy2012 is perfectly right that people should not be modding ACPI when they have no good grasp of the spec. If we had time to explain how to write dsl code, sure, you may not have made mistakes, but we cannot help everyone.

Edited by vit9696

Share this post


Link to post
Share on other sites
Posted (edited)
26 minutes ago, vandroiy2012 said:

 

Why are you doing this? 

In the majority of the cases ACPI patches are not useful and harmful. 

 

AppleALC can make on-the-fly rename in Ioreg and you can inject custom properties with DeviceProperties in config.plist. 

WhateverGreen can make on-the-fly rename for IGPU and PEG0 in Ioreg. It automatically inject IGPU properties for IQSV and you can manually inject custom properties with DeviceProperties in config.plist for both cards. 

 

Your motherboard does not need any patches at all.

 

 

 


I prefer make patch to DSDT than config.plist, some properties just for cosmetics.
I have built many hackintosh, if patch is broken then should be a problem with it. If you need i can upload my OC folder.
I have checked kernel log and boot verbose and no acpi error. It's only about different method i thought. The problem is only in windows maybe because OC still use DSDT.aml for windows?? and that you mean? :)

24 minutes ago, uglyJoe said:

 

Just a thought. How did you create your DSDT?

Extracted from Firmware or from running OS with active Clover patches?

Of course from firwmare,, just press F4 at GUI CLOVER and you can get all oem acpi dump from CLOVER/ACPI/Origin.

Edited by Andres ZeroCross

Share this post


Link to post
Share on other sites
6 minutes ago, Andres ZeroCross said:

The problem is only in windows maybe because OC still use DSDT.aml for windows?? and that you mean? :)

 

OC use DSDT.aml for ALL operating systems. 

Read this post carefully

 

Share this post


Link to post
Share on other sites
Posted (edited)
36 minutes ago, vandroiy2012 said:

 

Your motherboard does not need any patches at all.

 


I thought this wrong, eg Gigabyte Z170X gaming 7 still need USBX device and EC device. Both device is very important for USB Power management. I think will collect information from other or similar chipset if they have problem or not in windows with OC.
 

Edited by Andres ZeroCross

Share this post


Link to post
Share on other sites
Posted (edited)
7 minutes ago, Andres ZeroCross said:


I thought this wrong, eg Gigabyte Z170X gaming 7 still need USBX device and EC device. Both device is very important for USB Power management. I think will collect information from other or similar chipset if they have problem or not in windows with OC.
 

 

It can be "fixed" with custom SSDT. 

https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/SSDT-EC-USBX.dsl

 

This is the most correct way. 

 

P.S. I have very similar chipset and i have no problems running Windows. Because i don't touch original DSDT. Everything i need i inject with SSDT and with DeviceProperties.  

Edited by vandroiy2012

Share this post


Link to post
Share on other sites

Ok as previously stated my lurking days are over so I am about to ask dumb questions or make dumb statements so please be kind :) - As I understand it one must remove all instances of Clover to implement the operation of OC - correct? - I have a few spare ssd drives around so my intention is to vanilla install either Mojave or Catalina, then mount the EFI Partition of the drive and construct OC there (how am I doing so far?). Now the for the next stage, I remove all other drives (I am Quadruple booting Catalina, Mojave, H/Sierra and Win10 Pro all on respective drives) to test the new drive with OC as the boot loader, Am I on the right track?

Share this post


Link to post
Share on other sites
Posted (edited)
14 minutes ago, eSaF said:

Ok as previously stated my lurking days are over so I am about to ask dumb questions or make dumb statements so please be kind :) - As I understand it one must remove all instances of Clover to implement the operation of OC - correct? - I have a few spare ssd drives around so my intention is to vanilla install either Mojave or Catalina, then mount the EFI Partition of the drive and construct OC there (how am I doing so far?). Now the for the next stage, I remove all other drives (I am Quadruple booting Catalina, Mojave, H/Sierra and Win10 Pro all on respective drives) to test the new drive with OC as the boot loader, Am I on the right track?

I still use CLOVER and OC as bootloader. Both of them (Bootloader) in my SSD partition.
But i still use different way,
1. I have renamed BOOTX64.efi of OC files to BOOTX64-OC.efi and paste to EFI/BOOT
2. Then add manual entry from shell (use CLOVER SHELL) to add entry of OC with BCFG and point file boot to BOOTX64-OC.efi (bcfg boot add 05 "BOOTX64-OC.efi" "OC BOOTLOADER")

Edited by Andres ZeroCross

Share this post


Link to post
Share on other sites
Posted (edited)
15 minutes ago, Andres ZeroCross said:

I still use CLOVER and OC as bootloader. Both of them (Bootloader) in my SSD partition.
But i still use different way,
1. I have renamed BOOTX64.efi of OC files to BOOTX64.efi to BOOTX64-OC.efi to EFI/BOOT
2. Then add manual entry from shell (use CLOVER SHELL) to add entry of OC with BCFG and point file boot to BOOTX64-OC.efi (bcfg boot add "BOOTX64-OC.efi" "OC BOOTLOADER")

 

Ok thanks for the clarification but I am going to take baby steps to fully get the grasp before I start swopping around boot files. Thanks for the tip though for future 'How to Reference'. I have actually made a note of your Tip - Thanks.

Edited by eSaF

Share this post


Link to post
Share on other sites
1 minute ago, dgsga said:

@Download-Fritz

Here are the logs, before and after applying the IgnoreInvalidFlexRatio quirk...

opencore-noquirk.log.zip

opencore-fixed.log.zip

Our suspicion was correct. While it is a valid bug, this has no effect on x86 machines, so it can be ignored during normal boot with a RELEASE build. Thanks!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By Slice
      OK, 4988 released.
      Now, @vector sigma, what have we do to update translations?
    • By dracoflar
      So you've been reading the forum on this brand new boot loader called OpenCore hoping to try it out but you take one look at the configurations PDF and take a step back in shock at the complexity! Well if you've been feeling a bit intimidated by the DOCS well you've come to the right place:
       
      OpenCore Vanilla Desktop Guide
       
      If you have any issues or suggestions please feel free to comment
       
      - Your local neighbourhood Hackintosh Slav
    • By vit9696
      OpenCorePkg / Documentation / Configuration Template / Bugtracker   Discussion and installation should be done in a separate thread! This thread is for development only!
      Current status as of April 2019: Support for UEFI and DuetPkg (legacy) booting APFS and HFS+ compatibility ACPI patcher (adding, dropping, binary patching, relocation) Apple-compatible bless implementation DeviceProperties injection DataHub and SMBIOS generation Symbolic kext and kernel patcher Direct kext injection/patching/blocking within prelinkedkernel Installation/Recovery/FileVault 2 support  Configuration in config.plist with open documentation Simple boot picker for quick launch Direct boot from dmg images  
      Known defects live here.  
      For those, who are not familiar with the history, OpenCore is a project initially born in HermitCrabs Lab that unfortunately almost died before its birth. This release is both a rebirth and a complete rewrite of OpenCore, which brings a number of new ideas, and tries to preserve the smart moves incorporated by iNDi and his team. Other than that, I wish to express my deepest words of gratitude to Acidanthera and WWHC members: your participation was and remains the key for project success, and you are simply the best.
×