Jump to content

Customized OpenCore with additional features

n.d.k

By n.d.k,
in OpenCore

 Share
1,348 posts in this topic

Recommended Posts

  • 4 weeks later...
oldman20
oldman20
Posted
Posted

I using OC official with *.aml edit without OC Mod and multiboot well

On 9/24/2022 at 3:21 PM, oldman20 said:

Can u add icons for EFI part and storage, please? thank!

Screen Shot 2022-09-24 at 15.18.55.png

 

And after replace Resources folder, icons didnt applied, what i missing?

24082318.png

Solved it!

  • Like 1
Link to comment
Share on other sites
  • 2 weeks later...
makk
makk
Posted
Posted (edited)

Question:  I've installed Windows prior to installing OC MOD and vice versa which has left UEFI Shell with no reference to Windows except the EFI directory.

How to resolve this without installing again? so the UEFI Shell or OpenShell has the data for the drive?

 

FS0: = EFI\Boot\Microsoft

FS1 = EFI\OC\OpenCore and EFI\Boot\Microsoft

**the Windows on the laptop and Big Sur on the laptop.

I've had to change drives several times to offset storage usage which has the data portion in cahoots.

 

 

Edited by makk
Link to comment
Share on other sites
makk
makk
Posted
Posted (edited)

I remember a while back someone had database for OCAT of this BTWISE NDK MOD. I'm wondering how they were able to redirect to OCAT the updates?

 

On 11/4/2022 at 6:49 AM, oldman20 said:

I using OC official with *.aml edit without OC Mod and multiboot well

Solved it!

@oldman20 Just to let you know DSDT sucks.  it limits your actions on your puter.  Thus toasty shipwrecks after a while.

RehabMan has the jam!  You should consider hotpatches  SSDT.aml's OC does the DSDT patching no need for DSDT

 

Plus with ENABLEFORALL feature you can run this on Windows with ten Windows OS's {{ All the previous Windows Versions }} if you want. or perhaps some other Type of Windows similar to Windows like DOS

Or BEOS, maybe even IBM Windows :)

 

 

Edited by makk
Link to comment
Share on other sites
oldman20
oldman20
Posted
Posted
8 hours ago, makk said:

I remember a while back someone had database for OCAT of this BTWISE NDK MOD. I'm wondering how they were able to redirect to OCAT the updates?

 

@oldman20 Just to let you know DSDT sucks.  it limits your actions on your puter.  Thus toasty shipwrecks after a while.

RehabMan has the jam!  You should consider hotpatches  SSDT.aml's OC does the DSDT patching no need for DSDT

 

Plus with ENABLEFORALL feature you can run this on Windows with ten Windows OS's {{ All the previous Windows Versions }} if you want. or perhaps some other Type of Windows similar to Windows like DOS

Or BEOS, maybe even IBM Windows :)

 

 

cant read much, but i think u said about DSDT? no, OC i just using all is SSDT-*.aml with darwin method to inject only macOS

8 hours ago, makk said:

@antuneddu I went there and had a Chinese Hanzi characters showup for the party and no account with Gmail. ;) {censored}

They must be censoring USA login attempts??

 

Peace out

i dint using this, unofficial! btw, why using that when can control with *.aml

Link to comment
Share on other sites
davidm71
davidm71
Posted
Posted
On 11/18/2022 at 2:53 AM, makk said:

 

@oldman20 Just to let you know DSDT sucks.  it limits your actions on your puter.  Thus toasty shipwrecks after a while.

RehabMan has the jam!  You should consider hotpatches  SSDT.aml's OC does the DSDT patching no need for DSDT

 

Plus with ENABLEFORALL feature you can run this on Windows with ten Windows OS's {{ All the previous Windows Versions }} if you want. or perhaps some other Type of Windows similar to Windows like DOS

Or BEOS, maybe even IBM Windows :)

 

 


 

Confused on what exactly is the OC mod version in that it doesnt use a dsdt? You also say the dsdt is a limitation? I thought you needed one. Right now having an issue getting a Highpoint 7204 card working and I suspect that its the dsdt at fault. I used generator apps to create it through the usual ways most guides out there tell you. Is this possible and perhaps will the mod version help me with my issue?

 

thanks

Link to comment
Share on other sites
makk
makk
Posted
Posted (edited)
7 hours ago, davidm71 said:


 

Confused on what exactly is the OC mod version in that it doesn't use a dsdt? You also say the dsdt is a limitation? I thought you needed one. Right now having an issue getting a Highpoint 7204 card working and I suspect that its the dsdt at fault. I used generator apps to create it through the usual ways most guides out there tell you. Is this possible and perhaps will the mod version help me with my issue?

 

thanks

Hi @davidm71

 

NO ACPI means that ACPI's are disabled for WIndows only but are enabled for booting MacOS.

Like a gatekeeper which says ah Windows is booting must keep the ACPI's from loading.

It watches what OS is booting to enable or disable.

 

and there is some other feature I forgot what it is. However, the MOD version is called NO ACPI.

 

Some APCI ssdt's cause Windows to Not Boot. but are needed necessary required to Boot MacOS 

interferes in the boot up process.
 

yes, dsdt is a limitation in several ways. Unless your pc requires it.  You can get by with just SSDT's using OpenCore.

OpenCore patches the DSDT tables so you don't really need to make a patched DSDT.

 

On some hardware, I've seen people just run OpenCore without even an SSDT. Straight up boot.  Which is unusual. 

If you take the time to match the hardware to what is in a real mac then I can see where the ACPI portion is not necessary

in your config.plist. 

 

 

Edited by makk
  • Like 3
Link to comment
Share on other sites
MaLd0n
MaLd0n
Posted
Posted
2 hours ago, makk said:

yes, dsdt is a limitation in several ways.

You are thinking backwards. Complete solution only with DSDT. It's what Apple has always done. Just check the Apple tables and you will see that the DSDT of an Apple is fully patched against the same chipset for a regular computer. You may not like or know how to patch, but that's not true. It's better to believe in Apple than people who want to sell their own fish.

 

 

  • Like 5
  • Haha 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
2 hours ago, makk said:

Hi @davidm71

 

NO ACPI means that ACPI's are disabled for WIndows only but are enabled for booting MacOS.

Like a gatekeeper which says ah Windows is booting must keep the ACPI's from loading.

It watches what OS is booting to enable or disable.

 

 

 

No, ACPI is not disabled for Windows. Custom DSDT and other ACPI tables will not replace OEM tables so Windows will work with OEM ACPI tables provided by BIOS.

  • Like 5
Link to comment
Share on other sites
makk
makk
Posted
Posted
3 hours ago, Slice said:

No, ACPI is not disabled for Windows. Custom DSDT and other ACPI tables will not replace OEM tables so Windows will work with OEM ACPI tables provided by BIOS.

Let me rephrase that, For OpenCore not BIOS.

It passes Windows to use what is in BIOS and not what is in config.plist--MacOS.  

Yes it disables ACPI in Bootloader called OpenCore. Bypass, go around does not use.

 

Does that satisfy your thinking? 

Link to comment
Share on other sites
makk
makk
Posted
Posted (edited)
4 hours ago, MaLd0n said:

You are thinking backwards. Complete solution only with DSDT. It's what Apple has always done. Just check the Apple tables and you will see that the DSDT of an Apple is fully patched against the same chipset for a regular computer. You may not like or know how to patch, but that's not true. It's better to believe in Apple than people who want to sell their own fish.

 

 

Actually it isn't backwards.

 

Hot patching is much more effective, when the Thirdparty Bootloader applies patches by reading the DSDT on boot. and not changing it  Just use SSDT's. 

Whenever a new firmware update is needed to patch for the Updated OS, a patch is placed to replace.

A hacky is not Apple. It is whatever maker your board is to run MS Windows. there is if, perhaps we can say language differences.

 For instance Wifi and Bluetooth parameters changed at Apple the new thing that came out with Monterey where you can

mouse from Ipad to Mac.  A software change that made hardware that is not on their list non-working.  Bluetooth. So, many users using Intel Wifi/BT combo found themselves

In cohoots.  

 

I take it you haven't read Rehabmans take on SSDT hot patching vs creating a DSDT to replace. It really isn't isn't patching it is telling the computer to use these parameters on this list.
Whereas SSDT"s are patching to mimic and fake not making any changes to the actual DSDT. When you extract the actual DSDT from firmware to make a change and then 
have it outside the firmware and not back inside the firmware like BIOS, and others, it is telling the computer to use what is outside, or foreign to the computer

Use this one instead is what is stating, which is a good thought, but however it is not residing where it was designed to be. 

So it is best to leave it and then patch by faking and mimicing an Apple hardware.  Ecplise. 


Simply put, a DSDT can screw up your pc if done wrong and there is greater chance of this.

Hot patching tosses a patch on to make your DSDT work the one that is in the tables in the firmware and is not touched.

the bootloader which patches on the fly by the choices selected by the user which is done in config.plist. 

It's all patch work anyway.  The choice is ultimately the users regardless.

 

When making a DSDT to circumvent, it replaces the DSDT in firmware, you can download up to 255 copies of DSDT that was inserted by creating a replacement DSDT.

There's a tool that does this.  So it fills up the memory in firmware or flashware or whatever it is but it is there.  This having other DSDT's causes problems.

Just need 1 DSDT that comes stock.  A BIOS update can have a DSDT update but not worded as such.


With these new BIOS and newer hardware an OS's it's better to hot patch.  Leave the DSDT alone let the Bootloader do its patching.

 

In the end is ultimately upto the user.  I don't use DSDT. In fact there are a few who don't even need SSDT's or DSDT's and have
no problems running MacOS's everything works.

 

Edited by makk
  • Confused 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
1 hour ago, makk said:

Let me rephrase that, For OpenCore not BIOS.

It passes Windows to use what is in BIOS and not what is in config.plist--MacOS.  

Yes it disables ACPI in Bootloader called OpenCore. Bypass, go around does not use.

 

Does that satisfy your thinking? 

I have a feeling that you speak right. But

52 minutes ago, makk said:

 

 

When making a DSDT to circumvent, it replaces the DSDT in firmware, you can download up to 255 copies of DSDT that was inserted by creating a replacement DSDT.

 

 

What? Our bootloaders aren't going to write something into firmware.  

DSDT and other ACPI tables are copied from firmware to RAM and then the bootloader will patch it or not. That's all.

We should tell the bootloader if we want to patch ACPI tables or not depending on OS loaded. And so patching DSDT is very safe procedure.

Adding new SSDT is also safe procedure but novices have a misunderstanding that new SSDT must correspond to his DSDT in naming and often have failures.

  • Like 3
Link to comment
Share on other sites
davidm71
davidm71
Posted
Posted
7 hours ago, Slice said:

No, ACPI is not disabled for Windows. Custom DSDT and other ACPI tables will not replace OEM tables so Windows will work with OEM ACPI tables provided by BIOS.

 

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

Link to comment
Share on other sites
Planet X
Planet X
Posted
Posted (edited)

In short with official OpenCore my Windows 10 had a Mainboard is called Acidanthera and with OC mod NO ACPI my Windows 10 (now 11) is called Asus with the real hardware I use shown in Device Manager. That's how I wanted it to be. If I wouldn't need to use Citrix I would not even have Windows on that PC, as I had for many years too. B.t.w. It's all about resolution and scaling nothing else. 

Edited by Planet X
Link to comment
Share on other sites
1Revenger1
1Revenger1
Posted
Posted
9 hours ago, MaLd0n said:

You are thinking backwards. Complete solution only with DSDT. It's what Apple has always done. Just check the Apple tables and you will see that the DSDT of an Apple is fully patched against the same chipset for a regular computer. You may not like or know how to patch, but that's not true. It's better to believe in Apple than people who want to sell their own fish.

 

 

Apple uses quite a few SSDTs too. I don't think the comparison even makes sense here either way, since we aren't making Macs - we're making PCs run macOS. As long as you end up with the devices that macOS needs for all the functionality you want, I don't see any point going further beyond that in ACPI patches. It's not like it's functionally different as well, the SSDTs are loaded directly after the DSDT so you still end up with the same device tree.
There are quite a few disadvantages to patching the DSDT directly as well. The ACPI in a Windows system is not set in stone, it can change if UEFI settings are changed or when updating the firmware. Additionally, some ACPI field addresses are filled in during boot. When you put in a DSDT, your basically creating a "Snapshot" of your system at that point in time, when the underlying system can end up changing each time you boot. For these reasons, it can be harmful to patch in a DSDT directly.

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

  • Like 1
  • Thanks 1
Link to comment
Share on other sites
Ellybz
Ellybz
Posted
Posted (edited)
12 hours ago, makk said:

On some hardware, I've seen people just run OpenCore without even an SSDT. Straight up boot.  Which is unusual. 

If you take the time to match the hardware to what is in a real mac then I can see where the ACPI portion is not necessary

in your config.plist. 

 

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

image.png.b1d831252732bb611a74674baeb3c6bc.png

 

 

Edited by Ellybz
  • Like 1
  • Thanks 1
Link to comment
Share on other sites
MaLd0n
MaLd0n
Posted
Posted
5 hours ago, 1Revenger1 said:

we're making PCs run macOS.

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.

5 hours ago, 1Revenger1 said:

SSDTs are much easier to share

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.

KhfBcvu.png

  • Like 2
  • Thanks 2
Link to comment
Share on other sites
1Revenger1
1Revenger1
Posted
Posted
2 minutes 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.

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

 

I still don't see the value in cutting down the DSDT or making a custom one. You can get a great running hackintosh using a few very simple SSDTs, which is far less likely to break with BIOS updates. Why does the 70k lines of "Trash for Windows" matter? Most of this doesn't interfere with macOS, and leaving it in allows the edited ACPI to work with Windows and Linux still. Sure, it won't look like Apple ACPI, but this doesn't matter. What should matter is whether or not macOS is working well. This doesn't need a "Complete Solution" which by your definition also includes editing the entire DSDT such that it's unrecognizable from the original dump. I'd trust the original manufacturer of the motherboard more than Apple to know how the system should work, even in macOS.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...