Jump to content

OpenCore General Discussion

dgsga

By dgsga,
in OpenCore

 Share
8756 posts in this topic

Recommended Posts

deeveedee
deeveedee
Posted
Posted (edited)

Ok - so the mistake I'm making in my config.plist is that I'm still using an ACPI patch that renames all _DSM to XDSM.  I should create a separate rule for each _DSM that I want to rename (where the rules are distinguished from each other by their Base).  Thank you.

Edited by tonyx86
TheBloke
TheBloke
Posted
Posted
Just now, tonyx86 said:

 I should create a separate rule for each _DSM that I want to rename (where the rules are distinguished from each other by their Base)

Ideally, yes, for neatness and peace of mind.  Your system booted fine before and it's very likely there was no problem caused by the global rename.  But now the ability exists to target it, it's cleanest to do so.

  • Like 3
deeveedee
deeveedee
Posted
Posted (edited)

... and if I'm not redefining any _DSMs, I don't need any _DSM rename patches.  Thank you @Rodion2010 and @TheBloke.  This is another example (one of many) where I realized that I've always been doing something without understanding why I was doing it.  I've learned quite a bit after switching from CLOVER to OC and I'd much rather understand what I'm doing and why I'm doing it.

 

EDIT: My rig boots macOS just fine without the _DSM->XDSM rename patch.  Thanks again.  Always learning.

 

EDIT2: OC 0.6.9 boots Windows 10 without issues.  On the rare occasion where I need to boot Windows (just booted Windows for the first time this year to test this), I now have a choice of booting Windows with OC or the BIOS boot picker.

Edited by tonyx86
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted (edited)

Is there an equivalent to Clover's "FixACST" ACPI Fix in OpenCore?

 

EDIT: Analyzing the DSDT after applyng this patch in Clover revealed that this Fix renames `ACST` to `OCST`. So I just created a binary rename for it which had the same result in OpenCore.

 

According to the Clover manual, some DSDTs can have a device, method or variable named `ACST`, but this name is also used by macOS 10.8+ to control C-States. As a result, a completely implicit conflict with very unclear behavior can occur. This fix renames all occurrences of `ACST` to something safe. On my T530 Notebook,`ACST` refers to Device `AC` and Method `_PSR`(_PSR: PowerSource).

 

 

 

Edited by 5T33Z0
deeveedee
deeveedee
Posted
Posted

@5T33Z0 What tool are you using to "analyze the DSDT after applying the patch in Clover?"  I'd like to do the same after applying patches with OC.  In other words, I'd like to extract ACPI after OC applies adds and patches.  Thanks.

Guest 5T33Z0
Guest 5T33Z0
Posted
Posted
17 minutes ago, tonyx86 said:

@5T33Z0 What tool are you using to "analyze the DSDT after applying the patch in Clover?"  I'd like to do the same after applying patches with OC.  In other words, I'd like to extract ACPI after OC applies adds and patches.  Thanks.

 

Just open macIASL and select "Open System DSDT by default" under "Startup". This will open the DSDT which has been patched by the Bootloader Clover/OC

deeveedee
deeveedee
Posted
Posted (edited)

I've had "Open System DSDT" preference disabled for so long, that I completely forgot about it.  Thanks!

 

@5T33Z0 As you can see, I'm not afraid to ask what are probably very naive and remedial questions.  I guess I should have been more specific.  I see that ACPI renames are visible with macIASL.  Is there a way to extract ACPI such that OC's ACPI "Adds" are visible (e.g. if I add Device (ABC) using an SSDT patch, is there a way to extract ACPI after that hotpatch is applied so that I can see my added Device (ABC)?

Edited by tonyx86
Rodion2010
Rodion2010
Posted
Posted
25 minutes ago, 5T33Z0 said:

File > New from ACPI

 

This shows all the Tables present in ACPI – including the SSDTs you added.

 

 

 

 

 

2021-05-09 17:05:21.499319+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform) ACPI:

2021-05-09 17:05:21.499320+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform) ACPI:

2021-05-09 17:05:21.499322+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform) Dynamic OEM Table Load:

2021-05-09 17:05:21.499323+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform) Dynamic OEM Table Load:

2021-05-09 17:05:21.499325+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform)

2021-05-09 17:05:21.499326+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform)

2021-05-09 17:05:21.499526+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform) ACPI:

2021-05-09 17:05:21.499527+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform) ACPI:

2021-05-09 17:05:21.499531+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform) SSDT 0xFFFFFF802625CE10 0001D2 (v01 AMI    CPU1PM   00000001 INTL 20060113)

2021-05-09 17:05:21.499533+0300 0x286      Default     0x0                  0      kernel: (AppleACPIPlatform) SSDT 0xFFFFFF802625CE10 0001D2 (v01 AMI    CPU1PM   00000001 INTL 20060113)

 

how can I see this table? maciasl does not show it in the list

Rodion2010
Rodion2010
Posted
Posted (edited)
13 hours ago, 5T33Z0 said:

WHICH "THIS" Table? This is a Log and it's refering to a Kernel Patch…

This is a partial log about Dynamic OEM Table Load: absolutely nothing related to Kernel Patch there

"This" table is "Dynamic OEM Table SSDT 0xFFFFFF802625CE10 0001D2 (v01 AMI    CPU1PM   00000001 INTL 20060113)" as shown at the log, no other ACPI tables there

Edited by Rodion2010
Rodion2010
Rodion2010
Posted
Posted
13 minutes ago, 5T33Z0 said:

Yeah, well shorten it's name to a reasonable size and it may work. There's a reason why SSDT's only consist of a couple of letters…

 

Do you read the question? it is "Dynamic OEM Table"

it is created and loaded by BIOS, not by me, so I do not have any possibility to change its name

Rodion2010
Rodion2010
Posted
Posted (edited)
43 minutes ago, 5T33Z0 said:

Follow the OpenCore Installation Guide for your CPU (what are your specs anyway?) and Drop the table by adding the appropriate Patch with OEMTableID to ACPI > Delete in the config

Why?

I have no problems with OpenCore installation

I did not ask how to drop the table

I asked how to see the content of the table if it is possible, it is not the same

the Table is Dynamic and it is not shown in maciasl

maybe my English is not perfect, sorry, but the question is clear enough I think

Edited by Rodion2010
makk
makk
Posted
Posted (edited)
8 hours ago, Hervé said:

@makk if you would please read what people write and avoid posting inappropriate replies, that'd be great. Thank you.

 

sure, what the other guy was talking about was not what the other guy was interested in. So I gave a picture for the first guys.  obviously they were not on the same wavelength.

No problems. sometimes a photo goes a long ways.

 

Edited by makk
HenryV
HenryV
Posted
Posted (edited)
On 5/9/2021 at 10:26 AM, SavageAUS said:

Has anything changed in OC to stop this from working? Is it still correct? To boot bootstrap from refind?
https://github.com/dortania/Hackintosh-Mini-Guides/blob/master/refind.md


Sent from my iPhone using Tapatalk

Using GRUB2 to chainload Refind to chainload Open Core 0.7.0 as GRUB2 will not directly chainload Open Core after 0.6.4.

 

Recently encountered the issue that chainloading Open Core from GRUB2-->Refind-->Open Core the AirportIntel.kext for Big Sur loads and scans but does not detect networks.  AirportItlwm for Catalina loads and scans but does not detect networks.

 

However, AirportItlwm does load and work with Clover 5134 when injected while booting Big Sur.  AirportItlwm for Catalina only works when added to S/L/E when Catalina booted with Clover 5134. 

 

Yes, refind chainloads Open Core and boots both Big Sur and Catalina, but apparently does not properly inject some kexts.

 

https://www.insanelymac.com/forum/topic/347139-big-sur-113b4-multibooting-chainloading-tweaks-brew-migrating-apps/

 

 

Edited by HenryV
HenryV
HenryV
Posted
Posted
23 hours ago, theroadw said:

I used to use GRUB2, but switched to only using refind to chainload Linux, Windows and Opencore (Mojave and Catalina) and have zero issues injecting kexts from OC.

There are presently no issues with injecting kexts booting with OC other than AirportItlwm and Itlwm.

 

I am wondering why this is an issue with OC but not Clover.

 

This link indicates Refind does not support OC:

https://github.com/dortania/Hackintosh-Mini-Guides/blob/master/refind.md

  • We do not support the use of rEFInd with OpenCore, this is just to shut up those who won't stop complaining that OpenCore injects data into all OSes but for some reason are too lazy to press F8 at boot. Using rEFInd can break both bless and Startup Disk, and can be concidered a security risk.
  • Please note that rEFInd has also been know to break macOS booting

 

  • Sad 1
theroadw
theroadw
Posted
Posted
21 hours ago, HenryV said:

There are presently no issues with injecting kexts booting with OC other than AirportItlwm and Itlwm.

 

I am wondering why this is an issue with OC but not Clover.

 

This link indicates Refind does not support OC:

https://github.com/dortania/Hackintosh-Mini-Guides/blob/master/refind.md

  • We do not support the use of rEFInd with OpenCore, this is just to shut up those who won't stop complaining that OpenCore injects data into all OSes but for some reason are too lazy to press F8 at boot. Using rEFInd can break both bless and Startup Disk, and can be concidered a security risk.
  • Please note that rEFInd has also been know to break macOS booting

 

Never said there were any issues with any kexts, I was just stating that I switched from GRUB2 to refind for my main chainloader because GRUB2 kept overwriting the Bios boot defaults on every update, but using refind, everything works perfectly, I'm using OC 6.9 and no issues injecting any kexts, including the itlwm wifi.

 

In my case I needed to have a pre-OC chainloader because my Mojave system uses a DGPU that my Catalina system can't use, so I need 2 completely different OC configs, and I also needed to boot linux, and refind offers those options seamlessly. And to avoid going from picker to picker, my OC and linux refind options boot directly to their respective OS's

 

I don't know about the "no support" for refind, but at least in my case it does not break OC, or Clover or Linux or Windows, and it is way more convenient than hitting F9 and trying to figure out which drive has what. Bless and startup disk work correctly

  • Like 2
HenryV
HenryV
Posted
Posted
5 hours ago, theroadw said:

 

Never said there were any issues with any kexts, I was just stating that I switched from GRUB2 to refind for my main chainloader because GRUB2 kept overwriting the Bios boot defaults on every update, but using refind, everything works perfectly, I'm using OC 6.9 and no issues injecting any kexts, including the itlwm wifi.

 

In my case I needed to have a pre-OC chainloader because my Mojave system uses a DGPU that my Catalina system can't use, so I need 2 completely different OC configs, and I also needed to boot linux, and refind offers those options seamlessly. And to avoid going from picker to picker, my OC and linux refind options boot directly to their respective OS's

 

I don't know about the "no support" for refind, but at least in my case it does not break OC, or Clover or Linux or Windows, and it is way more convenient than hitting F9 and trying to figure out which drive has what. Bless and startup disk work correctly

Can you send me the version of Itlwm/Heliport you are using with 6.9?

 Share
Go to topic listing
×
×
  • Create New...