Jump to content

OpenCore General Discussion

dgsga

By dgsga,
in OpenCore

 Share
8,888 posts in this topic

Recommended Posts

nmano
nmano
Posted
Posted (edited)

Hi guys

X299 system smcReadKey Error when booting 11.3 with OpenCore 0.6.9

(AppleSMCLMU) AppleLMUController::smcGetKeyInfo Error: received error 0x84 when getting key info for 'ALRV'
(AppleSMCLMU) AppleLMUController::smcReadKey Error: received error 0x84 when reading key 'MSLD'
(AppleSMCLMU) AppleLMUController::smcReadKey Error: received error 0x84 when reading key 'ALV0'

please look this image.

image0.thumb.jpeg.9f3755cdb87b8cffddaec9546481fd35.jpeg

 

image0-1.thumb.jpeg.d6bcd81e68f635ddad08ad2270be44fb.jpeg

Thanks for your help.

Edited by nmano
  • Sad 1
Link to comment
Share on other sites
matgeo
matgeo
Posted
Posted

I have a question about EC device.

Guide says that it is better to inject a fake EC device (rather than rename an existing one like ECDV) so as to avoid connecting AppleACPIEC.

Using the fake EC device, I have AppleACPIEC connected to my ECDV device and not to the fake EC device.

If I use renaming , AppleACPIEC connects to EC.

 

Which one is better?

Screen Shot 2021-05-01 at 07.30.05.pdf

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

@matgeo I'll go out on a limb and offer my own opinion (not so different from the Dortania guide, I don't think).   I think it's safer to inject a Fake EC (despite having posted guides that rename the original xECx to EC).  Details below...

 

 Note that I am booting only macOS with OC, so I don't know the potential pitfalls with EC and booting other non-Mac OSes.  After switching from CLOVER to OC, I have hacked 5 rigs (1 Kaby Lake laptop, 3 Kaby Lake or newer Desktops and 1 old Socket 1156 Desktop).  In all 5 cases, I began each hack by injecting a Fake EC (not renaming the existing xECx).  It just felt like the safer way to start.  I didn't disable the existing xECx device (the old rig didn't have an EC) and found, like you, that even with the Fake EC, AppleACPIEC bound to the original xECx because of the PNP0C09 IONameMatch.  I believe you'll see that the Dortania pre-built SSDT for Desktops attempts to disable the original xECx devices.  Until I started hot patching EC (below), I didn't notice any difference in system behavior/operation with Fake vs. Renamed EC.

 

The only case where I found renaming EC to be an issue was when I was hot-patching the existing EC0 for brightness keys and ACPI debugging on the Kaby Lake laptop.  When I didn't rename the original EC0 (and injected a Fake EC), my SSDT hot-patches needed to refer to the original EC0 device name.  If I did rename EC0 -> EC, my SSDT hot-patches needed to refer to EC (the renamed device).  Other than that, I haven't noticed a difference.

 

When I first started hacking with OC, I got caught-up in my own myth that renaming the original xECx was somehow a "purist" more "authentic" approach.  Now I believe that a Fake EC is just fine and injecting a Fake EC seems to have fewer potential complications.

Edited by tonyx86
Link to comment
Share on other sites
1Revenger1
1Revenger1
Posted
Posted
On 4/30/2021 at 9:30 PM, matgeo said:

I have a question about EC device.

Guide says that it is better to inject a fake EC device (rather than rename an existing one like ECDV) so as to avoid connecting AppleACPIEC.

Using the fake EC device, I have AppleACPIEC connected to my ECDV device and not to the fake EC device.

If I use renaming , AppleACPIEC connects to EC.

 

Which one is better?

Screen Shot 2021-05-01 at 07.30.05.pdf 234.53 kB · 4 downloads

We generally recommend creating the fake EC device. The comment about AppleACPIEC not connecting is meant if you also make SSDT-EC disable the original EC to help prevent panics in some cases.

I wouldn't recommend a rename because that's a lot of patching your making OC do without any real purpose other than the satisfy the requirement that some device named EC needs to exist, plus it can break booting Windows.

  • Like 3
Link to comment
Share on other sites
ghost8282
ghost8282
Posted
Posted

Hi!

I'm posting here in the forum rather than github bugtracker as I don't have any log at the moment (my bad!).

It's been a while (most probably from updating 11.2.2 (?)) that after downloading the update from system preferences the system reboots but hangs instead of automatically complete the update.

I'm running mac os in qemu, the vm state is "running", but in a "hang" state with no video output (monitor is off).

This happened for sure from 11.2.2 to 11.2.3, from 11.2.3 to 11.3 and just now from 11.3 to 11.3.1.

I always have opencore updated (developer debug version), usually at the latest 0 to 2-3 commits; right now I'm using the latest opencore with the latest commits at the time of writing.

I'm able to complete the update only by forcing opencanopy to show (it's hidden by default) and manually select the "Macintosh-HD" entry; after this the update completes automatically.

Anyone with this same issue?

Link to comment
Share on other sites
SavageAUS
SavageAUS
Posted
Posted

Just wanted to hop in and say great work. I have not used OpenCore for a while now but I jumped back last night, updated my old OC EFI, kexts and AMD patches and voila back in business. Running Big Sur 11.4, OC 6.9.0.
Was running Clover on the same system but the newest update ended in black screen. I’m yet to test sleep and shutdown but everything else is working as it should.


Sent from my iPhone using Tapatalk

  • Like 4
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

Haven't updated to OC 0.6.9 yet - just started looking.  ocvalidate fails with the following error on the sample.plist.  Is that to be expected?

  

OCS: Failed to parse string field as value with type boolean and <False> contents, context <CustomDelays>!
Serialisation returns 1 error!

SampleCustom.plist does not have the error.  Looks like just a simple miss in Sample.plist.

Edited by tonyx86
Link to comment
Share on other sites
SavageAUS
SavageAUS
Posted
Posted

After fixing my black screen with OC 0.6.9 for my Intel HD 630 graphics macOS runs as it should for now....but I am using a dsdt and when I boot windows from OC I get a acpi_bios_error. What is the recommendation for fixing this error and how. I would prefer to not use the bios boot menu to boot different OS’s as that’s what a boot loader is for.


Sent from my iPhone using Tapatalk

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

As a follow-up to @SavageAUS 's question here, a common ACPI patch (in OC config.plist) renames _DSM to XDSM (or to ZDSM).  I don't use OC to dual-boot macOS and Windows (on the rare cases where I have to run Windows, I use the BIOS boot menu).  I'm just wondering if the _DSM rename patch is something that could potentially break Windows.  If so, for those using SSDT "hot-patches" and not editing their DSDT, what's the best way to address the _DSM rename given that each _DSM is unique?

Edited by tonyx86
Link to comment
Share on other sites
Rodion2010
Rodion2010
Posted
Posted (edited)
5 minutes ago, tonyx86 said:

As a follow-up to @SavageAUS 's question here, a common ACPI patch (in OC config.plist) renames _DSM to XDSM (or to ZDSM).  I don't use OC to dual-boot macOS and Windows (on the rare cases where I have to run Windows, I use the BIOS boot menu).  I'm just wondering if the _DSM rename patch is something that could potentially break Windows.  If so, what's the best way to address this given that each _DSM is unique?

new OpenCore has "Base" option for ACPI patches, so you can rename only some _DSM's if it is really needed

Edited by Rodion2010
  • Like 2
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

... but then do you need to have an SSDT hotpatch for each _DSM that is renamed?

 

EDIT: In other words, if _DSM is renamed to XDSM, it looks to me like you would need SSDT patches that define _DSM for each affected ACPI Device.   For example, if ABC._DSM becomes ABC.XDSM, does there need to be an SSDT patch that defines ABC._DSM, where the new ABC._DSM matches the original ABC._DSM (with the _OSI("Darwin") condition)?

Edited by tonyx86
Link to comment
Share on other sites
TheBloke
TheBloke
Posted
Posted (edited)
9 minutes ago, tonyx86 said:

... but then do you need to have an SSDT hotpatch for each _DSM that is renamed?

The reason to apply the _DSM -> XDSM patch is because you have already added SSDTs that are trying to add _DSM sections, and they are conflicting with a _DSM in the same Device(s) in your system DSDT.

 

So yes, there would be an SSDT adding a _DSM for each specific _DSM ACPI patch, but not a new SSDT - the one you were already adding.  And if you don't have any SSDTs that include a _DSM and are resulting in an AE_ALREADY_EXISTS error, there's no reason to rename _DSM.

 

Before ACPI -> Base was added to OpenCore, we used to have to rename _DSM to XDSM globally, affecting all _DSM sections even if only adding a new _DSM to one Device.  Now we can target just the conflicting _DSMs for rename, and not patch anything that doesn't need to be.

Edited by TheBloke
  • Like 4
Link to comment
Share on other sites
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
Link to comment
Share on other sites
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
Link to comment
Share on other sites
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
Link to comment
Share on other sites
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
Link to comment
Share on other sites
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.

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

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...