Pavo Posted June 12, 2019 Share Posted June 12, 2019 (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 June 12, 2019 by Pavo 1 Link to comment Share on other sites More sharing options...
vit9696 Posted June 12, 2019 Share Posted June 12, 2019 @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. 6 Link to comment Share on other sites More sharing options...
Pavo Posted June 12, 2019 Share Posted June 12, 2019 (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 June 12, 2019 by Pavo 2 Link to comment Share on other sites More sharing options...
eSaF Posted June 12, 2019 Share Posted June 12, 2019 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. 1 Link to comment Share on other sites More sharing options...
MattsCreative Posted June 12, 2019 Share Posted June 12, 2019 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 2 Link to comment Share on other sites More sharing options...
e97 Posted June 13, 2019 Share Posted June 13, 2019 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 2 Link to comment Share on other sites More sharing options...
eSaF Posted June 13, 2019 Share Posted June 13, 2019 @ 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 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. Link to comment Share on other sites More sharing options...
glasgood Posted June 13, 2019 Share Posted June 13, 2019 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 ) As far as I know you can't use Drivers from Clover, correct me if I'm wrong anyone! 2 Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted June 13, 2019 Share Posted June 13, 2019 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??? Link to comment Share on other sites More sharing options...
eSaF Posted June 13, 2019 Share Posted June 13, 2019 @ glasgood and Andres ZeroCross - WarDoc and e97 posted two great links, check them out - So excited I'm wetting my self 2 Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted June 13, 2019 Share Posted June 13, 2019 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 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 Link to comment Share on other sites More sharing options...
vandroiy2012 Posted June 13, 2019 Share Posted June 13, 2019 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. 3 Link to comment Share on other sites More sharing options...
uglyJoe Posted June 13, 2019 Share Posted June 13, 2019 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? Link to comment Share on other sites More sharing options...
eSaF Posted June 13, 2019 Share Posted June 13, 2019 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. Link to comment Share on other sites More sharing options...
vit9696 Posted June 13, 2019 Share Posted June 13, 2019 (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 June 13, 2019 by vit9696 7 Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted June 13, 2019 Share Posted June 13, 2019 (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 June 13, 2019 by Andres ZeroCross Link to comment Share on other sites More sharing options...
vandroiy2012 Posted June 13, 2019 Share Posted June 13, 2019 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 Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted June 13, 2019 Share Posted June 13, 2019 (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 June 13, 2019 by Andres ZeroCross Link to comment Share on other sites More sharing options...
vandroiy2012 Posted June 13, 2019 Share Posted June 13, 2019 (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 June 13, 2019 by vandroiy2012 2 Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted June 13, 2019 Share Posted June 13, 2019 Just now, vandroiy2012 said: It can be "fixed" with custom SSDT. https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/SSDT-EC-USBX.dsl That what i mean still need patch. i call this patch,, Link to comment Share on other sites More sharing options...
eSaF Posted June 13, 2019 Share Posted June 13, 2019 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? Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted June 13, 2019 Share Posted June 13, 2019 (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 June 13, 2019 by Andres ZeroCross 2 Link to comment Share on other sites More sharing options...
eSaF Posted June 13, 2019 Share Posted June 13, 2019 (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 June 13, 2019 by eSaF Link to comment Share on other sites More sharing options...
dgsga Posted June 13, 2019 Author Share Posted June 13, 2019 13 hours ago, Download-Fritz said: Yes, please do if you have time. @Download-Fritz Here are the logs, before and after applying the IgnoreInvalidFlexRatio quirk... opencore-noquirk.log.zip opencore-fixed.log.zip 3 Link to comment Share on other sites More sharing options...
mhaeuser Posted June 13, 2019 Share Posted June 13, 2019 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! Link to comment Share on other sites More sharing options...
Recommended Posts