OpenCore General Discussion

[miliuco]

17 minutes ago, tonyx86 said:

Not sure I understand your answer.  I'm guessing that EnableVectorAcceleration has something to do with Intel AVX Extensions.  I'm currently booting Catalina 10.15.7 with OC 0.6.8.  When I run 

sysctl -a | grep machdep.cpu.features

I see the response below, which indicates that AVX1.0 is already recognized.  Does the new quirk enable AVX2?  Sorry if these are naive/remedial questions...

I read that this quirk enables AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms so I did the test of starting the picker (with password) with this quirk enabled and disabled and when it is enabled the password is decrypted in a while  shorter. That is why I think it has to do with the speed of decryption of these algorithms. But I’m not sure at 100%. 

 

[Rodion2010]

1 hour ago, tonyx86 said:

What is the purpose of the new OC 0.6.9 UEFI > Quirk EnableVectorAcceleration?  To which CPU / System Architectures is this quirk relevant?  Thank you.

it is for CPU with AVX support

sysctl machdep.cpu | grep AVX

Edited April 28, 2021 by Rodion2010

[deeveedee]

31 minutes ago, miliuco said:

I read that this quirk enables AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms so I did the test of starting the picker (with password) with this quirk enabled and disabled and when it is enabled the password is decrypted in a while  shorter. That is why I think it has to do with the speed of decryption of these algorithms. But I’m not sure at 100%. 

 

If the OC release punch list now includes vectorizing the picker password, we must be getting close to the final release.

 

EDIT: @miliuco - My search now finds EnableVectorAcceleration in the OC 0.6.9 manual.  Thanks for your answer.

Edited April 28, 2021 by tonyx86

[TheBloke]

13 minutes ago, tonyx86 said:

If the OC release punch list now includes vectorizing the picker password, we must be getting close to the final release.

 

The new code was submitted via push request by someone who doesn't seem to have contributed to OC before. So I would guess it's more a case of someone in the community thinking it would be useful and providing the code, rather than Acidanthera thinking it was vital to do at this stage 

Edited April 28, 2021 by TheBloke

[miliuco]

I thought about algorithms and decryption because the changes are in OpenCore files related to this:

• Include/Acidanthera/Library/OcCryptoLib.h
• Library/OcCryptoLib/OcCryptoLib.inf
• Library/OcCryptoLib/Sha2.c
• Library/OcCryptoLib/Sha512AvxDummy.c
• Library/OcCryptoLib/X64 / Sha512Avx.nasm.

 

Edited April 28, 2021 by miliuco

[deeveedee]

29 minutes ago, TheBloke said:

 

The new code was submitted via push request by someone who doesn't seem to have contributed to OC before. So I would guess it's more a case of someone in the community thinking it would be useful and providing the code, rather than Acidanthera thinking it was vital to do at this stage 

In fairness to the person who submitted the code, I read here that the picker password can take 30 seconds to verify on older platforms.  Maybe vectorizing the password hash calculations can speed this up a lot.

[miliuco]

Just now, tonyx86 said:

In fairness to the person who submitted the code, I read here that the picker password can take 30 seconds to verify on older platforms.  Maybe vectorizing the password hash calculations can speed this up a lot.

On my hackintosh (and I suppose on all modern machines) the difference is small, approx. 3 versus 1.5 sec., although seen in relative terms it is half the time.

[Stefanalmare]

18 hours ago, miliuco said:

On my hackintosh (and I suppose on all modern machines) the difference is small, approx. 3 versus 1.5 sec., although seen in relative terms it is half the time.

In my z390 aorus master, i9 9900K a lot faster than before.

Edited April 29, 2021 by Stefanalmare

[nmano]

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.

 

Thanks for your help.

Edited April 29, 2021 by nmano

[deeveedee]

@nmano is this issue related to your issue?

[matgeo]

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

[deeveedee]

@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 May 2, 2021 by tonyx86

[Avery B]

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.

[pkdesign]

Is it just me or is it getting easier to update to next version?

[miliuco]

5 minutes ago, pkdesign said:

Is it just me or is it getting easier to update to next version?

 

Less complicated than the previous step. Yes.

[ghost8282]

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?

[SavageAUS]

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

[deeveedee]

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 May 5, 2021 by tonyx86

[deeveedee]

@MifJpn It appears that a new OC 0.6.9 has been committed to github.  Sample.plist now has the correct Boolean type for CustomDelays..

[SavageAUS]

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

[deeveedee]

@SavageAUS include _OSI("Darwin") conditions in your DSDT edits.

[deeveedee]

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 May 7, 2021 by tonyx86

[Rodion2010]

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 May 7, 2021 by Rodion2010

[deeveedee]

... 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 May 7, 2021 by tonyx86

[TheBloke]

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 May 7, 2021 by TheBloke