Jump to content
8755 posts in this topic

Recommended Posts

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

  • Like 1
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
  1. RequireVault
    Type: plist boolean
    Default value: true
    Description: 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

  • Like 2
  • Haha 2

@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?

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

  • Like 2
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. 

ioreg_OC.png

sysctl -a | grep xcpm_OC.png

ioreg_clover.png

sysctl -a | grep xcpm_clover.png

Screenshot 2019-05-29 at 11.55.20.png

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.

  • Like 1
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???

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

 

  • Like 5

Take a look.

Screenshot 2019-06-14 at 16.46.29.png

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.

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, ?

Screenshot 2019-06-14 at 17.31.20.png

@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 ;)

 

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?

 

Screenshot 2019-06-14 at 17.50.37.png

Edited by obus
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.:wallbash:

Changed that and everything works like a charm. Thank you @fabiosun for showing sharing your SSDT-PLUG.aml.

 

  • Like 1

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:317938829_Screenshot2019-06-14at19_36_10.thumb.png.c87238869b9263aa2601d039da2bc647.png

Edited by obus
  • Like 1
9 minutes ago, obus said:

Can't load my USBPortlimitKext if I inject it trough OC:

 

 

If I install it into Library/Extensions it works fine:

 

Tried booth wit and without ExecutablePath in config.

What am I doing wrong?

 

 

 

Not sure, tbh I'm still figuring this out. I just finally got my Aorus Pro Z390 running with OC. But what I did notice was that when I used an SMBIOS for iMac 1.1 , I had all my ports injected from SSDT-UIAC plus an extra 6 ports that where not defined inside  SSDT-UIAC ! 

But when I changed SMBIOS to iMac 19,1 I have exact amount of ports injected as per my  SSDT-UIAC.  As I am using USBInjectAll.kext, I have 

 

I never install anything in Library/Extension. I use OC kext folder. 

 

 

907298898_Screenshot2019-06-14at20_49_40.thumb.png.bf34b3b472bb2e6cff351a78cc703c43.png

 

 

1032509574_Screenshot2019-06-14at20_57_30.thumb.png.35da2ec71699208a01e2f6868131bc5d.png

 

 

 

 

 

 

 

 

1 hour ago, obus said:

Can't load my USBPortlimitKext if I inject it trough OC:

 

If I install it into Library/Extensions it works fine:

 

Tried booth wit and without ExecutablePath in config

What am I doing wrong?

Problems solved with help from my saver @PMheart the kext is now injected correctly from OC. 

After changing bundles in kext and removing ExecutablePath in OC config. :thumbsup_anim:

Edited by obus
3 hours ago, glasgood said:

 

 

 

Not sure, tbh I'm still figuring this out. I just finally got my Aorus Pro Z390 running with OC. But what I did notice was that when I used an SMBIOS for iMac 1.1 , I had all my ports injected from SSDT-UIAC plus an extra 6 ports that where not defined inside  SSDT-UIAC ! 

But when I changed SMBIOS to iMac 19,1 I have exact amount of ports injected as per my  SSDT-UIAC.  As I am using USBInjectAll.kext, I have 

 

I never install anything in Library/Extension. I use OC kext folder. 

 

 

907298898_Screenshot2019-06-14at20_49_40.thumb.png.bf34b3b472bb2e6cff351a78cc703c43.png

 

 

1032509574_Screenshot2019-06-14at20_57_30.thumb.png.35da2ec71699208a01e2f6868131bc5d.png

 

 

 

 

 

 

 

 

My kext is working fine with iMacPro1,1 SMBIOS after changing bundles in kext and removing ExcutablePath in OC config.

Here is my kext. Just take the port info from your SSDT-UIAC and copy to the kext and then activate portlimitpatch in OC XhciPortLimit. -->  YES

 

 

C422-XHCI.kext.zip

Edited by obus
New kext
1 hour ago, obus said:

Problems solved with help from my saver @PMheart the kext is now injected correctly from OC. 

After changing bundles in kext and removing ExecutablePath in OC config. :thumbsup_anim:

 

Can you please screenshot how it looks after the change as I think I have the same problem?

×
×
  • Create New...