Andres ZeroCross Posted June 13, 2019 Share Posted June 13, 2019 (edited) PROBLEM SOLVED MUST : Apply Windows Emulation patch in my DSDT. Thanks @vandroiy2012 and @vit9696, i check your sample "SSDT-EC-USBX.dsl". I found interesting method about _STA Method (_STA, 0, NotSerialized) // _STA: Status { If (_OSI ("Darwin")) { Return (0x0F) } Else { Return (Zero) } } And i got idea for my patch, example. I always Zeroing STA of HDAS in ACPI and create new device HDEF + _DSM, and make new device EC + USBX because default device is H_EC. So my step I add this code below to HDAS, Method (_STA, 0, NotSerialized) // _STA: Status { If (_OSI ("Darwin")) { Return (Zero) } Else { Return (0x0F) } } Then i make new device HDEF + DSM + STA, Method (_STA, 0, NotSerialized) // _STA: Status { If (_OSI ("Darwin")) { Return (0x0F) } Else { Return (Zero) } } So, when i boot to windows, HDAS will get STA 0x0F and HDEF get STA Zero. And when i boot to macOS, HDEF get STA 0x0F and HDAS get STA Zero. No problem now boot to windows, i implemented that patch to my all "new devices" Edited June 13, 2019 by Andres ZeroCross 4 Link to comment Share on other sites More sharing options...
Badruzeus Posted June 13, 2019 Share Posted June 13, 2019 Cool, I learn something today: After doing: bcfg driver add 00 FS0:\EFI\OC\OpenCore.efi "OC Boot" .. I'm no longer able to access my BIOS (Aptio UEFI 2.0) with combo key. It drives me directly to OC, yeah my bad IDK what does this command mean but.. nevermind, I've done disassembling my laptop parts then unplug CMOS Battery to fix it. OK, guessing not bcoz of OC but my fault. My question is, how to access UEFI Shell via OpenCore? Link to comment Share on other sites More sharing options...
blackosx Posted June 13, 2019 Share Posted June 13, 2019 (edited) You could have booted in to macOS, mounted ESP and renamed EFI\OC\OpenCore.efi to something else so the driver option you added would fail to find it's target, in this case EFI\OC\OpenCore.efi. EDIT: Then, of course, recover as described here Edited June 14, 2019 by blackosx 2 Link to comment Share on other sites More sharing options...
PMheart Posted June 13, 2019 Share Posted June 13, 2019 1 hour ago, Badruzeus said: Cool, I learn something today: After doing: bcfg driver add 00 FS0:\EFI\OC\OpenCore.efi "OC Boot" .. I'm no longer able to access my BIOS (Aptio UEFI 2.0) with combo key. It drives me directly to OC, yeah my bad IDK what does this command mean but.. nevermind, I've done disassembling my laptop parts then unplug CMOS Battery to fix it. OK, guessing not bcoz of OC but my fault. My question is, how to access UEFI Shell via OpenCore? It can be done via OpenCore Tools. See https://github.com/acidanthera/OpenCorePkg/blob/e39cd101db97168bbd18d5922a90c342c2fa73d8/Docs/Sample.plist#L432-L441 for example. As for Shell.efi, you know it. (You can either use TianoCore edk2 ShellPkg, or our fork of it, whatever fits you best.) 2 1 Link to comment Share on other sites More sharing options...
MacPato Posted June 13, 2019 Share Posted June 13, 2019 (edited) Having an issue with Legacy on Q9300 CPU and Dell Optiplex, i'm testing a legacy build and seems to crash i have included a log opencore.log Edited June 13, 2019 by MacFriedIntel 1 Link to comment Share on other sites More sharing options...
vit9696 Posted June 13, 2019 Share Posted June 13, 2019 @MacFriedIntel that HFSPlus driver is not compatible with your CPU supposedly due to missing rdrand instruction (most of exception data is not probably screenshoted). You must use the one from an older Mac like MacPro5,1 or similar. Link to comment Share on other sites More sharing options...
MacPato Posted June 13, 2019 Share Posted June 13, 2019 54 minutes ago, vit9696 said: @MacFriedIntel that HFSPlus driver is not compatible with your CPU supposedly due to missing rdrand instruction (most of exception data is not probably screenshoted). You must use the one from an older Mac like MacPro5,1 or similar. its okay i fixed the issue and now fully boots. Legacy is a tough one but it's fully working. at least i now know OC works 1 Link to comment Share on other sites More sharing options...
Orion's Sword Posted June 14, 2019 Share Posted June 14, 2019 I've got the following error: OC: Configuration requires vault but no vault provided! What does it mean? Link to comment Share on other sites More sharing options...
vandroiy2012 Posted June 14, 2019 Share Posted June 14, 2019 38 minutes ago, Muntashir said: I've got the following error: OC: Configuration requires vault but no vault provided! What does it mean? This mean you didn't read the manual Quote RequireVaultType: plist booleanDefault value: trueDescription: Require vault.plist file present in OC directory. This file should contain SHA-256 hashes for all files used by OpenCore. Presence of this file is highly recommended to ensure that unintentional file modifications (including filesystem corruption) do not happen unnoticed. To create this file automatically use create_vault.sh script. Regardless of the underlying filesystem, path name and case must match between config.plist and vault.plist.Note: vault.plist is tried to be read regardless of the value of this option, but setting it to true will ensure configuration sanity, and abort the boot process. The complete set of commands to: • Create vault.plist.• Create a new RSA key (always do this to avoid loading old configuration).• Embed RSA key into OpenCore.efi.• Create vault.sig. Can look as follows: cd /Volumes/EFI/EFI/OC /path/to/create_vault.sh . /path/to/RsaTool -sign vault.plist vault.sig vault.pub off=$(($(strings -a -t d OpenCore.efi | grep "=BEGIN OC VAULT=" | cut -f1 -d' ')+16))dd of=OpenCore.efi if=vault.pub bs=1 seek=$off count=520 conv=notrunc rm vault.pub Note: While it may appear obvious, but you have to use an external method to verify OpenCore.efi andBOOTx64.efi for secure boot path. For this you are recommended to at least enable UEFI SecureBoot with a custom certificate, and sign OpenCore.efi and BOOTx64.efi with your custom key. More details on customising secure boot on modern firmwares can be found in Taming UEFI SecureBoot paper (in Russian). You can just disable it - RequireVault=false 2 2 Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 @vit9696 Sorry if I bring this up again but I need to know why I need to produce a SSDT-PM with PikerAlpha:s ssdtPRGen.sh to get X86PlatformPlugin/shim to work. I am sure I didn't need that in the first beta release of OC and I definitely don't need it in clover. In clover I just need to check plugin and then I have Fully working Powermanagment an XPCM. Have I missed something? Link to comment Share on other sites More sharing options...
Pavo Posted June 14, 2019 Share Posted June 14, 2019 12 minutes ago, obus said: @vit9696 Sorry if I bring this up again but I need to know why I need to produce a SSDT-PM with PikerAlpha:s ssdtPRGen.sh to get X86PlatformPlugin/shim to work. I am sure I didn't need that in the first beta release of OC and I definitely don't need it in clover. In clover I just need to check plugin and then I have Fully working Powermanagment an XPCM. Have I missed something? Because there is no automatic quirk in OC that injects plugin-type into your original ACPI tables for CPU. You don't have to generate a SSDT using ssdtPRGen.sh, you can simply use the one on OC's GitHub. https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/SSDT-PLUG.dsl 2 Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 (edited) Sorry @Pavo if I wasn't clear enough but this doesn't work even with the SSDT-PLUG for me. I tried to explain it in this post: Edited June 14, 2019 by obus Link to comment Share on other sites More sharing options...
Pavo Posted June 14, 2019 Share Posted June 14, 2019 3 minutes ago, obus said: Sorry if I wasn't clear enough but this doesn't work even with the SSDT-PLUG for me. I tried to explain its in this post above. Thats because the "example" SSDT-PLUG from GitHub is for CPUs that are named CPU0, your original ACPI table for your specific CPU is named PR00 as highlighted in your IOReg screenshot. You have 2 options, either rename all your PR0x to CPUx or change the SSDT-PLUG from CPU0 to PR00. 1 Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 1 minute ago, Pavo said: Thats because the "example" SSDT-PLUG from GitHub is for CPUs that are named CPU0, your original ACPI table for your specific CPU is named PR00 as highlighted in your IOReg screenshot. You have 2 options, either rename all your PR0x to CPUx or change the SSDT-PLUG from CPU0 to PR00. All my CPU is renamed to PRXX and my plugin too??? Link to comment Share on other sites More sharing options...
gengik84 Posted June 14, 2019 Share Posted June 14, 2019 You need to change it It is not always the same as everyone... Docs/SSDT_PLUG is just an example You don't have Scope (\_PR.CPU0) Change to: SB.PR00 and try... EDIT:Sorry for the double answer, but the forum is slow here 5 Link to comment Share on other sites More sharing options...
Pavo Posted June 14, 2019 Share Posted June 14, 2019 Just now, obus said: All my CPU is renamed to PRXX and my plugin too??? Then you need to do more research and make sure that you have the correct scope in the SSDT-PLUG. \_PR.PRO0 vs \_SB.PR.PRO0 etc. 1 Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 Take a look. SSDT-PLUG.aml 1 minute ago, gengik84 said: You need to change it It is not always the same as everyone... Docs/SSDT_PLUG is just an example You don't have Scope (\_PR.CPU0) Change to: SB.PR00 and try... Ok. I will try that. Link to comment Share on other sites More sharing options...
Orion's Sword Posted June 14, 2019 Share Posted June 14, 2019 3 hours ago, vandroiy2012 said: This mean you didn't read the manual Oh my! I skipped the whole security section. Probably because I was snoozing . 1 Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 44 minutes ago, Pavo said: Then you need to do more research and make sure that you have the correct scope in the SSDT-PLUG. \_PR.PRO0 vs \_SB.PR.PRO0 etc. So this is a screenshoot from my original SSDT-0_PM. Is the right scope according to this: (_SB_.SCK0.CP00, ? And if so if I renamed CPU:s on my rig to PRxx the right Scope should be:(_SB_.SCK0.PR00, ? Link to comment Share on other sites More sharing options...
Guest Posted June 14, 2019 Share Posted June 14, 2019 @obus without any CPU renames in config..I use this DefinitionBlock ("", "SSDT", 2, "CpuRef", "CpuSsdt", 0x00003000) { External (_SB_.SCK0.CP00, DeviceObj) Scope (\_SB.SCK0.CP00) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Debug = "Writing plugin-type to Registry!" If ((Arg2 == Zero)) { Return (Buffer (One) { 0x03 // . }) } Return (Package (0x02) { "plugin-type", One }) } } } thanks to macos86.it for help to solve it Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 (edited) 13 minutes ago, fabiosun said: @obus without any CPU renames in config..I use this DefinitionBlock ("", "SSDT", 2, "CpuRef", "CpuSsdt", 0x00003000) { External (_SB_.SCK0.CP00, DeviceObj) Scope (\_SB.SCK0.CP00) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Debug = "Writing plugin-type to Registry!" If ((Arg2 == Zero)) { Return (Buffer (One) { 0x03 // . }) } Return (Package (0x02) { "plugin-type", One }) } } } thanks to macos86.it for help to solve it Unfortunately it doesn't work for my rig. I don't know what I'am doing wrong? Edited June 14, 2019 by obus Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 20 minutes ago, fabiosun said: @obus without any CPU renames in config..I use this DefinitionBlock ("", "SSDT", 2, "CpuRef", "CpuSsdt", 0x00003000) { External (_SB_.SCK0.CP00, DeviceObj) Scope (\_SB.SCK0.CP00) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Debug = "Writing plugin-type to Registry!" If ((Arg2 == Zero)) { Return (Buffer (One) { 0x03 // . }) } Return (Package (0x02) { "plugin-type", One }) } } } thanks to macos86.it for help to solve it My Bad I made a TYP0. Changed that and everything works like a charm. Thank you @fabiosun for showing sharing your SSDT-PLUG.aml. 1 Link to comment Share on other sites More sharing options...
Guest Posted June 14, 2019 Share Posted June 14, 2019 @obus credits to @gengik84 ( http://www.macos86.it )which help me solving this Link to comment Share on other sites More sharing options...
glasgood Posted June 14, 2019 Share Posted June 14, 2019 Can USBInjectAll.kext with associated SSDT or USBMaps.kext be used with OpenCore. Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 (edited) It works fine for me but according to @vit9696 we shouldn't use it or with his own words: UsbInjectAll, do not use it, create legacy kext describing your USB ports, even at a price of losing some. So I made my own kext instead and put XhciPortLimit to YES: Edited June 14, 2019 by obus 1 Link to comment Share on other sites More sharing options...
Recommended Posts