Jump to content

OpenCore General Discussion

dgsga

By dgsga,
in OpenCore

 Share
8,888 posts in this topic

Recommended Posts

Pavo
Pavo
Posted
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
  • Like 1
Link to comment
Share on other sites
vit9696
vit9696
Posted
Posted

@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.

  • Like 6
Link to comment
Share on other sites
Pavo
Pavo
Posted
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
  • Like 2
Link to comment
Share on other sites
eSaF
eSaF
Posted
Posted

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.

  • Like 1
Link to comment
Share on other sites
MattsCreative
MattsCreative
Posted
Posted
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

  • Like 2
Link to comment
Share on other sites
e97
e97
Posted
Posted
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

  • Like 2
Link to comment
Share on other sites
eSaF
eSaF
Posted
Posted

@ 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.

Link to comment
Share on other sites
glasgood
glasgood
Posted
Posted
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!

 

 

 

  • Like 2
Link to comment
Share on other sites
Andres ZeroCross
Andres ZeroCross
Posted
Posted
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

Link to comment
Share on other sites
Andres ZeroCross
Andres ZeroCross
Posted
Posted
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

Link to comment
Share on other sites
vandroiy2012
vandroiy2012
Posted
Posted
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.

 

  • Like 3
Link to comment
Share on other sites
uglyJoe
uglyJoe
Posted
Posted
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
eSaF
eSaF
Posted
Posted
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
vit9696
vit9696
Posted
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
  • Like 7
Link to comment
Share on other sites
Andres ZeroCross
Andres ZeroCross
Posted
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
Link to comment
Share on other sites
Andres ZeroCross
Andres ZeroCross
Posted
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
Link to comment
Share on other sites
vandroiy2012
vandroiy2012
Posted
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
  • Like 2
Link to comment
Share on other sites
eSaF
eSaF
Posted
Posted

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
Andres ZeroCross
Andres ZeroCross
Posted
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
  • Like 2
Link to comment
Share on other sites
eSaF
eSaF
Posted
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
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...