Customized OpenCore with additional features

[Slice]

1 hour ago, 1Revenger1 said:

OpenCore has a pretty big note on the operation fields fix (ACPI->Quirks->RebaseRegions) which basically boils down to "Don't use it unless you really can't avoid it as it won't always work."

 

It always works in the case of Clover. I have enough observations to claim this.

[Matgen84]

6 hours ago, MaLd0n said:

The hardware and devices is same with some exceptions like smc.

Good example is comet lake imacs apple use a very custom dsdt with 11k lines and our mobo serie 400 have 70k lines with a bunch of trashes for windows.

About operation regions is a very old problem and bootloaders solve it with regions fix and after that is a personal choice, use it or not.

Correct but people need to stop lying about it. It's not dangerous, it's more complete because we can do everything directly on the main table and it has its advantages and disadvantages.

I have nothing against SSDTs. I use both methods and I tell you with my hands what is more complete and cleaner from someone who does more than 30 hacks a day(not always) on Olarila.com.

My ssdt for z690 with 13900kf in screenshot bellow.

Hi @MaLd0n Sorry for my stupid question: Is it necessary to have the same name for SSDT.aml, OEM Table Id and in DefinitionBlock items ! I don't remember.

Fo example, in your screenshot:

SSDT = SSDT.MaLdOn.aml

OEM Table ID = "Olarila"

DefinitionBlock ("", "SSDT", 2, "Apple", "Olarila", 0x00000000)

Let me know, please 

[MaLd0n]

7 hours ago, 1Revenger1 said:

You can get a great running hackintosh using a few very simple SSDTs

no question against it

 

1 hour ago, Matgen84 said:

Is it necessary to have the same name for SSDT.aml

no

if u set name here "DefinitionBlock ("", "SSDT", 2, "Apple", "Olarila", 0x00000000)" OEM Table ID is changed after compile.

 

7 hours ago, 1Revenger1 said:

OpenCore has a pretty big note on the operation fields fix

this "big note" is very very old. opencore was born a long time later.

[Anto65]

Opencore_NO_ACPI_Build , available directly from OCAT ( tnx Dev )

 

[deeveedee]

Forgive what is a noob/remedial question, but is OpenCore_NO_ACPI_Build the only way to prevent OC from applying ACPI patches when booting Windows with OC?

 

EDIT: Will this OC-MOD let me choose which config.plist I want to use for OC at boot time (so that I can have multiple configs and choose the one I want)?

Edited November 26, 2022 by deeveedee

[ndungu6678]

18 hours ago, deeveedee said:

I'm hoping for a call from Guinness World Records for the most SSDTs in my HackBookPro6,2.  I have some solutions that use a custom DSDT and some that use SSDTs.  Amazingly, they both work well.

Sorry to join this discussion late- I think it is a matter of choice here-just because your hack works perfect with or without DSDT or SSDT depends on preference - as a long time DSDT user for about 10 yrs or so, for me I still use one despite what they say. In certain instances for me DSDT patching has proved more effective in enabling non-compatible hardware on my hack-like a VIA chipset firewire card (not with the native Texas Instruments chipset ) that all the forums I visited had insisted would never work on a Hackintosh. I am sure a SSDT patch exists to do the same job.   I am not an expert but have greatly benefited from more knowledgable authorities on the intricate art of DSDT and SSDT patching like MaLd0n and Rehabman to mention a few. Incidentally I also use both SSDT and DSDT and they both serve me well.

 

NB: I have to admit that people who joined the hackintosh scene over the last few years are rather fortunate cause with the advances in UEFI enabled compatible boards adopted by most manufacturers and the ability to apply DSDT patching on the fly using tools like Clover and OC -it is much easier to build a hack without the need for DSDT (or SSDT).  But there was time when this was not the case and a fully patched DSDT was essential to get up and running.

 

Build 1: iMac20,2, i5-9400F, Samsung 16GB DDR4 RAM, MSI Z390 Gaming Plus, Radeon RX 580 8GB, OC 0.8.7

Edited November 26, 2022 by ndungu6678

[makk]

On 11/25/2022 at 2:44 PM, davidm71 said:

 

As I have no issues dual booting Windows I don't think this will not help my problem because as I understand ACPI still gets patched for OSX loading non the less.

 

Still feel my DSDT tables may be incorrect though considering the NVME errors I see in logs. Topic for another day.

 

Thanks

 

Apologies I spoke with short bias.

 

the NO ACPI means the ACPI in config.plist for MacOS is not loaded for Windows thus making it boot and not having to troubleshoot.

It prevents the ACPI ssdt's and what not from loading for WIndows. Thus Windows boots cleanly with the ACPI tables in the PC that is meant for the Intel based or IBM based PC's

and not Macintoshes or Apples.

 

NVMEfix.kext is needed for NVME drives and in one of the Quirks this can be set to ThirdParty Drives to enable in the config.plist TRIM feature built in and
not needing a patch to install.

 

Also the NVMEDXE.efi driver is most not necessary in config.plist unless you have some problems.  @1Revenger1 has replied to a post of mine concerning this.

 

However said, if you understand that MacOS requires some forms of ssdt. + dsdt in most cases, for a hacky to boot in the config.plist plus the files on the drive.

The problem we encounter here is that this is not a 'Real Mac' Computer and MacOS uses BSD Unix as the basis, while Windows uses their version.

 

you can use the Debug version of OpenCore and turn on all the necessaries in config.plist to find errors or issues.

 

As the @Ellybz has stated, no SSDT's nor DSDT created and it boots from OpeCore patching the necessary files. So that machine is
more closer to a real Mac and thus MacOS runs probably much smoother there.

Edited November 26, 2022 by makk

[makk]

As for BIOS and stuff, the DSDT that is created as a patch gets loaded.  However you may say, I've had to remove them from my board flash  pc several times causing issues on boot and cleaning NVRAM.

 

Enough said.

[startergo]

9 hours ago, deeveedee said:

Forgive what is a noob/remedial question, but is OpenCore_NO_ACPI_Build the only way to prevent OC from applying ACPI patches when booting Windows with OC?

 

EDIT: Will this OC-MOD let me choose which config.plist I want to use for OC at boot time (so that I can have multiple configs and choose the one I want)?

My approach always is to boot through rEFInd and chain load OC from there and Windows is not in the OC boot loader, but in rEFInd's. So if I want to boot Windows I don't even go to the OC bootloader. BOOT folder contains only rEFInd files. 

[deeveedee]

@startergo I just press F9 (or the appropriate function key) during boot to select my Windows boot disk if I configure a rig for dual-boot. The aspects of CLOVER that I miss with OC are no ACPI patching for Windows and the ability to select a config.plist at boot.  It sounds like this OC-MOD addresses the ACPI patching but not the config.plist.

[makk]

18 hours ago, startergo said:

My approach always is to boot through rEFInd and chain load OC from there and Windows is not in the OC boot loader, but in rEFInd's. So if I want to boot Windows I don't even go to the OC bootloader. BOOT folder contains only rEFInd files. 

 

On 11/26/2022 at 9:46 AM, deeveedee said:

Forgive what is a noob/remedial question, but is OpenCore_NO_ACPI_Build the only way to prevent OC from applying ACPI patches when booting Windows with OC?

 

EDIT: Will this OC-MOD let me choose which config.plist I want to use for OC at boot time (so that I can have multiple configs and choose the one I want)?

 

Well if you are using and used to using OpenCore and have OpenCore already installed, why go through the trouble of "Adding Another Bootloader in-between?" sounds like more work which equates to more headaches when trouble occurs. Have to check more apps. As in Windows doesn't have enough problems already....  

 

All you do is replace some files in OpenCore with the Mod OpenCore as follows below:

 

Bootx64.efi

OpenCore.efi

--all the drivers and tools remain.

--your config.plist for the rest remains

--all your ssdt's and kexts remain

A smart choice for OpenCore users who have problems or don't want to configure for Windows 

Pretty simple.

 

Then add these statements to the config.plist in Quirks for ACPI section and Booter:

 

1 EnableForAll -> and set to disabled or false depending on your editor.  This then allows Windows to boot straight and the ACPI and Booter are used exclusively for the MacOS you are using.

 

Forget the press F Keys and all that extra

You have a bootscreen with OpenCore Background of your choice. 

All the icons you placed and configured as well.

Two files to replace in EFI 

 

 

@antuneddu @Ellybz correct me if I'm wrong on the files to replace

 

Peace out

 

Edited November 27, 2022 by makk

[startergo]

3 minutes ago, makk said:

 

 

Well if you are using and used to using OpenCore and have OpenCore already installed, why go through the trouble of "Adding Another Bootloader in-between?" sounds like more work which equates to more headaches when trouble occurs. Have to check more apps. As in Windows doesn't have enough problems already....  

 

All you do is replace some files in OpenCore with the Mod OpenCore.

 

Bootx64.efi

OpenCore.efi

all the drivers and tools remain.

Pretty simple.

 

@antuneddu @Ellybz correct me if I'm wrong on the files to replace

 

Peace out

 

Because I don't want to modify OC with unapproved changes. There is a reason they keep it that way to provide native-like Bootcamp experience for original Macs. There is nothing complicated. You place all rEFInd files in the BOOT folder. That is it. OC stays in the OC folder.

[makk]

5 minutes ago, startergo said:

Because I don't want to modify OC with unapproved changes. There is a reason they keep it that way to provide native-like Bootcamp experience for original Macs. There is nothing complicated. You place all rEFInd files in the BOOT folder. That is it. OC stays in the OC folder.

@startergo what?

 

Have it your way at Burger King

[makk]

On 11/25/2022 at 4:32 PM, Ellybz said:

I'm one of these people 😆. I do not have a single SSDT of my Gigabyte X299 and I love it. I only have one RTC patch. CPU PM is managed thru the BIOS. Hardware is matched with Device Properties.

Opencore 0.8.6

 

 

@Ellybz  Right On There!!

 

The rest:

 

See folks you need to think and consider what you are doing and what is best.

I can see if you have an old PC and don't care what happens to your firmware, hardware, all the ACPI tables.

 

If you just bought a new one for the sake of running MacOS then you need to really consider.

A Hackintosh is patchwork. Does not really use drivers as used in MS Windows.

Versions of drivers are different from Windows drivers. 

 

Acronym Definition

KEXT  Kernel Extension

 

A kext is not really a driver but tables of what to use for hardware. Unix based.

Direct to the Kernel like an arm and a leg. 

 

Remember Apple is based on BSD UNIX --a Fork 

 

Windows is their own version of some form of a hybrid a mixture of the past with their new stuff

but uses .exe. dll's and so forth. --a Hybrid

 

If you screw up your DSDT the real one in the tables that's on you.

 

With all the changes that do take place at Apple for hardware, it is most advisable to use 'Hot Patching'

 

Think before you do.

 

Also with Clover you can run minimal like no SSDT's and no DSDT's I've seen users run straight and no problems.

Clover does the patching on the fly.

As stated by many many in the past, the closer your machine is to a 'real mac' the better and less configuring.

And it does boot Windows

 

N.D.K. is a --Fork of OpenCore 

now handled by BTWISE but remains in the --Fork of OpenCore

 

NOTE: it praises OpenCore and some kind soul decided to make a few changes to a few executables and make it available for users who
have tons of SSDT's which causes Windows to not boot through OpenCore.

So if you have more than 3 SSDT's and 'or' series of tables to patch in them, with no statements to tell OpenCore 
with OSI statements XOSI, to avoid Windows crashes, and really if you don't want to add these statements--

and spend more time writting, then NO ACPI makes it simple while Keeping OpenCore -- 

 

Peace out

 

 

 

Edited November 27, 2022 by makk

[makk]

5 hours ago, deeveedee said:

@startergo I just press F9 (or the appropriate function key) during boot to select my Windows boot disk if I configure a rig for dual-boot. The aspects of CLOVER that I miss with OC are no ACPI patching for Windows and the ability to select a config.plist at boot.  It sounds like this OC-MOD addresses the ACPI patching but not the config.plist.

@deeveedee yeah I miss that feature too!

 

In the meantime: However, you can just rename and leave them there.

Or USB EFI with all the config.plists to test.

 

Yes, @btwise can you be so kind as to work in the Clover feature of at boot screen choose any config.plist?

This may be done I think with Tools on the boot screen toggle

Can someone write a .efi to do this?

That would rock!

Peace Out  

Edited November 27, 2022 by makk

[deeveedee]

On 11/25/2022 at 3:59 PM, 1Revenger1 said:

SSDTs are much easier to share, and tend to be self documenting (or close to it) since they tend to boil down to just the changes you want to make. It also gives you the option to run the unpatched behavior pretty easily when booting Windows or Linux (in the case of Acidanthera's OpenCore). In my personal experience, I find it difficult to help someone who has a patched DSDT since I have no clue what is from the firmware and what is patched (at least not without doing a diff with the unpatched DSDT).

Having done both methods (custom DSDT and SSDTs) fairly extensively, I agree that reviewing SSDT patches can be easier than a custom DSDT.  The challenge with novice SSDT patches (including my early SSDT patches) are that much of the original ACPI gets duplicated in the SSDT, so it is still difficult to differentiate between the original and patched ACPI.  However, if the SSDTs have been created with care, the SSDT patches (in my opinion) are much easier to share, understand and especially to reuse.

Edited November 28, 2022 by deeveedee

[makk]

On 11/28/2022 at 1:29 PM, deeveedee said:

Having done both methods (custom DSDT and SSDTs) fairly extensively, I agree that reviewing SSDT patches can be easier than a custom DSDT.  The challenge with novice SSDT patches (including my early SSDT patches) are that much of the original ACPI gets duplicated in the SSDT, so it is still difficult to differentiate between the original and patched ACPI.  However, if the SSDTs have been created with care, the SSDT patches (in my opinion) are much easier to share, understand and especially to reuse.

In my opinion through doing both myself,  I've found it's safer than a DSDT.aml in all respects. 

 

DSDT CONS:

The long hours + the MaciASL complaining and so forth. Just a nightmare. 

One could spend days of hours, or weeks of hours.

Extract, write, make changes, then compile, test.

Unless you are an expert, you're in for the long haul for 1 file.

 

PROS SSDTS:
1 They're in abundance already written and can be changed on the fly, unlike DSDT.s.  

2 SSDT if it is not right doesn't hose the internals.  Can be rewritten any time.

3 Interchangeable on the fly.

 

Fly patching.

 

Peace Out

Edited November 30, 2022 by makk

[makk]

NOTE: None of this is easy and it requires much searching and asking the right questions. However upon starting for the first time we do not have 
the right questions because of knowledge and understanding to ask the right questions to get help.  Kind of catch 22.

Persistence is necessary and sometimes we run into disgruntled helpers that have tons of knowledge, understanding and experience. 
Don't get discouraged.  Just think of asking as a novice and be open to suggestions.  There are plenty of very helpful kind people.

And may have to use many sites to accomplish the goal.  

 

The Hacky is sort of a hybrid of Mac, where a thirdparty bootloader is necessary other than that you can get up to 99.9% of a working MacOS
if done right and it does take progression of time.  Best choices are that if you have the same hardware as someone else that is successfully running MacOS.

 

I should say, makes necessary patches and applies them on boot, but does not change the original DSDT in the tables.

I should also, reiterate this fact in UEFI shell or Open Shell which can be entered via boot menu for both Clover and OpenCore
there is a command to use to extract custom made DSDT's  that are placed and used for booting in some part of flash or nvram --I forget where exactly.

After some time, there are up to 255 copies of this custom made DSDT.  Which to my opinion is an issue.

The need is really 1 DSDT that comes with the motherboard and the need to keep this one and apply patches used in config.plist without them being

inserted in this fashion.

Hot Patching which Clover and OpenCore performs, does not touch the original in most cases--unless you do something to change this fact and it can  be done.

This is where a --such as beginners or even those who do not understand the complications, can have a messed up pc. Critical.

 

Thus to avoid having to curse Clover or OpenCore to blame these bootloaders, Hot Patching by the user on the user end avoids having to deal with
blame.   

 

Thus Rehabman in his earlier days, found this out and wrote extensively on his findings and recommends to hot patch using strictly SSDT's.

in the case where SSDT's fail to boot, that is when DSDT is necessary until you find the issue and correct it and then remove DSDT and boot using
SSDT's.  --Recommended highly by Rehabman-- Experienced guru.

 

 

First try to boot without custom made DSDT and SSDT in your config.plist, and on the EFI partition of USB,  see the errors, use Debug mode. 
Run from USB EFI first extensively.  Take the time here saves in the future days coming.

Download the Debug versions of OC MOD, enable debug mode found in Dortania Guide.

 

It is assumed that @Ellybz  and those alike have gone this route and found what is needed so that machine boots with no DSDT, no SSDT in the config.plist.  Intelligent.  Took the time to see what is necessary.

 

1 Device Properties has all the PCI root to run hardware

2 A RTC patch is applied in config.plist

3 Power management is handled by BIOS

 

On the otherhand there is so much written to run MacOS--Hacky on PC or UNIX, that people go the route of what is most used but not really what is truly necessary,  to see
first if your system can boot without custom made patched DSDT and SSDT files in EFI created.  <--OpenCore or Clover or some other.

 

Take the time to run and then you can have better knowledge to choose what is best in your case.  

Lastly enjoy running a hacky.

 

 

 

 

Edited December 5, 2022 by makk

[btwise]

On 11/28/2022 at 3:32 AM, makk said:

@deeveedee yeah I miss that feature too!

 

In the meantime: However, you can just rename and leave them there.

Or USB EFI with all the config.plists to test.

 

Yes, @btwise can you be so kind as to work in the Clover feature of at boot screen choose any config.plist?

This may be done I think with Tools on the boot screen toggle

Can someone write a .efi to do this?

That would rock!

Peace Out  

For some Hackers, it is very useful to select different config files at any time. But OpenCore has loaded the config.llist file when we saw the picker. It  is different from that of clover. I can't write such code. If there are professional coders, they can help me add this function!

[Slice]

11 minutes ago, btwise said:

For some Hackers, it is very useful to select different config files at any time. But OpenCore has loaded the config.llist file when we saw the picker. It  is different from that of clover. I can't write such code. If there are professional coders, they can help me add this function!

Clover loads config.plist twice. First time (early boot) to choose a theme (GUI) and second time to choose system settings after GUI. So the user can choose config.plist for the second stage.

[btwise]

12 minutes ago, Slice said:

Clover loads config.plist twice. First time (early boot) to choose a theme (GUI) and second time to choose system settings after GUI. So the user can choose config.plist for the second stage.

Yes, it comes from refind, but OpenCore is brand new. I can't change it yet. It needs coders  to rewrite it

[Slice]

Refind started in 2012 while Clover in 2011.

Sorry for offtop.

[btwise]

1 hour ago, Slice said:

Refind started in 2012 while Clover in 2011.

Sorry for offtop.

Well, I got it wrong

[makk]

Well there you go, we have some good people with good intentions that actually can do a good.

I wish I knew how to program other than simple scripts 

Thanks guys!

May the future be brighter and better for Hackers!

 

[makk]

9 hours ago, Slice said:

Refind started in 2012 while Clover in 2011.

Sorry for offtop.

Ah, so refind comes from the idea of Clover and so does a few others?