Jump to content

OpenCore General Discussion


dgsga
8,805 posts in this topic

Recommended Posts

OT (but could help for some memory or Nvram corruption)

Asus has messed latest x299 bios for many motherboard
They produce some memory issue with it

IE 1001 for x299 sage ws 10g

They retired it for many x299 board

 

Link to comment
Share on other sites

Latest OC not build

build.py...

OpenCorePkg/UDK/OpenCorePkg/OpenCorePkg.dsc(...): error 4000: Instance of library class [OcMemoryLib] is not found

in [OpenCorePkg/UDK/OcSupportPkg/Library/OcSmbiosLib/OcSmbiosLib.inf] [X64]

consumed by module [OpenCorePkg/UDK/OpenCorePkg/Platform/OpenCore/OpenCore.inf]

Link to comment
Share on other sites

3 minutes ago, HmO said:

Latest OC not build

build.py...

OpenCorePkg/UDK/OpenCorePkg/OpenCorePkg.dsc(...): error 4000: Instance of library class [OcMemoryLib] is not found

in [OpenCorePkg/UDK/OcSupportPkg/Library/OcSmbiosLib/OcSmbiosLib.inf] [X64]

consumed by module [OpenCorePkg/UDK/OpenCorePkg/Platform/OpenCore/OpenCore.inf]

 

I still can built it with macbuild.tool

image.png.444a499983e6db6ac60ded93c843a6b8.png

6 minutes ago, HmO said:

Latest OC not build

build.py...

OpenCorePkg/UDK/OpenCorePkg/OpenCorePkg.dsc(...): error 4000: Instance of library class [OcMemoryLib] is not found

in [OpenCorePkg/UDK/OcSupportPkg/Library/OcSmbiosLib/OcSmbiosLib.inf] [X64]

consumed by module [OpenCorePkg/UDK/OpenCorePkg/Platform/OpenCore/OpenCore.inf]


And i tested it again with
source edksetup.sh
build -a X64 -b RELEASE -t XCODE5 -p OpenCorePkg/OpenCorePkg.dsc

Built is still fine
image.png.684abe0328d180ff9b260ed21fbe3f5d.png

Link to comment
Share on other sites

@Andres ZeroCross

- Done -

Build end time: 22:01:07, Jul.16 2019

Build total time: 00:00:18

 

~/OpenCorePkg/Binaries/DEBUG ~/OpenCorePkg

~/OpenCorePkg/Binaries/DEBUG/tmp ~/OpenCorePkg/Binaries/DEBUG ~/OpenCorePkg

~/OpenCorePkg/Binaries/DEBUG ~/OpenCorePkg

~/OpenCorePkg

~/OpenCorePkg/Binaries/RELEASE ~/OpenCorePkg

~/OpenCorePkg/Binaries/RELEASE/tmp ~/OpenCorePkg/Binaries/RELEASE ~/OpenCorePkg

~/OpenCorePkg/Binaries/RELEASE ~/OpenCorePkg

~/OpenCorePkg

  • Like 1
Link to comment
Share on other sites

I'm working on setting up an Opencore EFI folder for a friend who has my old Asus X99 mobo + a Haswell-E 5930K CPU. It's so long since I owned it I don't know if I need to fill in Kernel>Emulate>Cpuid1Data to get the processor recognised and XCPM to work (I don't have access to the machine at present). I know I need to use the AppleXcpmExtraMsrs quirk. Can anyone help with the config for this setup?

Thanks very much

Link to comment
Share on other sites

On 7/16/2019 at 1:30 PM, hardcorehenry said:

Sorry, wasn't precise. When I put back my patched DSDT everything works, but I have KP in other systems, so removed it. Trying with only hotpatches, my HPET looks like this:

 

// Fix HPET devices

DefinitionBlock("", "SSDT", 2, "hack", "HPET", 0)
{
    External(_SB.PCI0.LPCB, DeviceObj)

    Scope(_SB.PCI0.LPCB)
    {
        Device (HPET)
        {
            Name (_HID, EisaId ("PNP0103"))  // _HID: Hardware ID
            Name (_UID, Zero)  // _UID: Unique ID
            Name (BUF0, ResourceTemplate()
            {
                IRQNoFlags() { 0, 8, 11, 15 }
                Memory32Fixed (ReadWrite,
                               0xFED00000,         // Address Base
                               0x00000400,         // Address Length
                               _Y30)
            })

            Name (_STA, 0x0F)
            Method (_CRS, 0, NotSerialized)
            {
                Return (BUF0)
            }
        }
    }
}

 

and it doesn't seems to load. Renaming HPET to XPET, also doesnt help. Attaching my OC.zip

HPET “problem” SOLVED! Renaming as in instruction below was sufficient (a bit different sequence, but method worked), now _STA returns 0xf as it should.  Thanks everyone who tried to help me.

 

  • Refreshing HPET (or another device) method header to avoid compatibility checks by _OSI on legacy hardware. _STA method with if ((OSFL () == Zero)) { If (HPTE) ... Return (Zero) content may be forced to alwaysreturn0xFbyreplacingA0 10 93 4F 53 46 4C 00withA4 0A 0F A3 A3 A3 A3 A3.

 

 

 

Link to comment
Share on other sites

Hi Open Core Project team !

 

I have a few questions related to patching process in general with Open Core.

First of all i did check and did read 3 times the documentation.pdf of Open Core and it is very well-perfectly explained for what it has so far, but i have a few questions that i couldn't find answer into it regarding some patching and how to do it in Open Core compared to Clover.

With Clover, all of my setups are fully hotpatched (no DSDT on patched Folder, no patched SSDTs) just addon SSDTs and the rest done in config.plist.

My questions and some suggestions are:

 

1.(Clover) config.plist /DSDT/Fixes like "FixHPET", "FixIPIC", "FixTMR", "FixRTC", "FixMutex":

What would be the best approach to do these patches as some of these are important to have working audio setup.

On many of my setups "especially fixHPET" is required as a fix to enable Audio.

Or it may be a good idea to include them on the fullsample.plist since they are often necessary or would/do you consider to set them as Quirks ?

 

2. What about (Clover) config.plist /DSDT/Patches: TgtBridge [HEX] ?

One example is that on my Lenovo V330-15IKB i have ELAN I2C Touchpad and like i mentioned i don't patch DSDT and place it on Patched folder (Clover) or ACPI in (Open Core).

I do rename the TPD0._CRS to XCRS and Rename TPD0._DSM to XDSM and then place the patched SSDT-I2C that contains the patched-pinned methods to fix the touchpad to work with VoodooI2C.

My question on this is how to do the TgtBridge patch, clover example is:


Comment: Rename TPD0._CRS to XCRS

Find: 5F435253

Replace: 58435253

TgtBridge: 54504430

How do i add the TgtBridge/this patch on Open Core config.plist ?

 

3. What about the Kernel and kext patches / KextsToPatch: infoPlistPatch ?

Example (Clover):


Name: com.apple.driver.AppleIntelLpssI2C

Find: 494F4B69 74

Replace: 494F4B69 73

Comment: Prevent Apple I2C kexts from attaching to I2C controllers, credit CoolStar

InfoPlistPatch=YES

Is this one same as on Clover ? like:

InfoPlistPatch (Boolean) YES ?

 

4. KernelToPatch:

Is the identifier a required value ?, in case of a kernel patch i wasn't very clear on the pdf should i type only kernel and type the find and replace value ?

Also is the AppleRTC patch available on FullSample.plist the one we use on clover config.plist / KernelandKextPatches/ AppleRTC=YES ?

 

Thanks for the excellent work that you people are doing, the documentation pdf is short and well explained and aside from these questions i listed everything else was a super easy transition from Clover to OC thanks to the excellent documentation.

 

With big respect,

Sniki

 

@vit9696 @vandroiy2012 @Download-Fritz @PMheart

Edited by "Sniki"
Tags
  • Like 1
Link to comment
Share on other sites

1 hour ago, "Sniki" said:

Hi Open Core Project team !

 

I have a few questions related to patching process in general with Open Core.

First of all i did check and did read 3 times the documentation.pdf of Open Core and it is very well-perfectly explained for what it has so far, but i have a few questions that i couldn't find answer into it regarding some patching and how to do it in Open Core compared to Clover.

With Clover, all of my setups are fully hotpatched (no DSDT on patched Folder, no patched SSDTs) just addon SSDTs and the rest done in config.plist.

My questions and some suggestions are:

 

1.(Clover) config.plist /DSDT/Fixes like "FixHPET", "FixIPIC", "FixTMR", "FixRTC", "FixMutex":

What would be the best approach to do these patches as some of these are important to have working audio setup.

On many of my setups "especially fixHPET" is required as a fix to enable Audio.

Or it may be a good idea to include them on the fullsample.plist since they are often necessary or would/do you consider to set them as Quirks ?

 

2. What about (Clover) config.plist /DSDT/Patches: TgtBridge [HEX] ?

One example is that on my Lenovo V330-15IKB i have ELAN I2C Touchpad and like i mentioned i don't patch DSDT and place it on Patched folder (Clover) or ACPI in (Open Core).

I do rename the TPD0._CRS to XCRS and Rename TPD0._DSM to XDSM and then place the patched SSDT-I2C that contains the patched-pinned methods to fix the touchpad to work with VoodooI2C.

My question on this is how to do the TgtBridge patch, clover example is:

 


Comment: Rename TPD0._CRS to XCRS

Find: 5F435253

Replace: 58435253

TgtBridge: 54504430

 

How do i add the TgtBridge/this patch on Open Core config.plist ?

 

3. What about the Kernel and kext patches / KextsToPatch: infoPlistPatch ?

Example (Clover):

 


Name: com.apple.driver.AppleIntelLpssI2C

Find: 494F4B69 74

Replace: 494F4B69 73

Comment: Prevent Apple I2C kexts from attaching to I2C controllers, credit CoolStar

InfoPlistPatch=YES

 

Is this one same as on Clover ? like:

InfoPlistPatch (Boolean) YES ?

 

4. KernelToPatch:

Is the identifier a required value ?, in case of a kernel patch i wasn't very clear on the pdf should i type only kernel and type the find and replace value ?

Also is the AppleRTC patch available on FullSample.plist the one we use on clover config.plist / KernelandKextPatches/ AppleRTC=YES ?

 

Thanks for the excellent work that you people are doing, the documentation pdf is short and well explained and aside from these questions i listed everything else was a super easy transition from Clover to OC thanks to the excellent documentation.

 

With big respect,

Sniki

There is no info.plist patching with OC

  • Like 1
Link to comment
Share on other sites

Hi @"Sniki",

1. Automatic patches are unused by most modern boards, so we decided to not include them. HPET patches, which can be made reasonably generic, are discussed on the previous pages of this thread.

2. We do not support TgtBridge as it is not needed by most modern boards. You can use custom DSDT for that.

3. Info.plist patches are not planned for implementing. Implementing them properly would require a complex interface, and our research on the matter proved that they are not needed in all known cases. See: https://github.com/acidanthera/bugtracker/issues/394.

4. All fields are currently required, including but not limited to Identifier. Writing kernel to Identifier is mandatory for kernel patches.

Vit

  • Like 3
Link to comment
Share on other sites

2 hours ago, vit9696 said:

1. Automatic patches are unused by most modern boards, so we decided to not include them. HPET patches, which can be made reasonably generic, are discussed on the previous pages of this thread.

Yes, i saw that post on previous page after i wrote my post.

2 hours ago, vit9696 said:

2. We do not support TgtBridge as it is not needed by most modern boards. You can use custom DSDT for that.

Patching DSDT is a bit painful for the fact that even a single change in bios settings or small hardware upgrade will require you to dump, re-extract and patch DSDT again because of changes that happen on memory address.

While with full hotpatch that is not the case.

It is also important for guides as for example a single laptop or pc, can use your addon SSDTs and config.plist without trouble and have everything working, while with static DSDT patching everyone is required to do the patching process of DSDT individually.

2 hours ago, vit9696 said:

3. Info.plist patches are not planned for implementing. Implementing them properly would require a complex interface, and our research on the matter proved that they are not needed in all known cases. See: https://github.com/acidanthera/bugtracker/issues/394.

I will check that issue by browsing manually as the link seems to not open.

2 hours ago, vit9696 said:

4. All fields are currently required, including but not limited to Identifier. Writing kernel to Identifier is mandatory for kernel patches.

Thanks for clarifying that so whenever it is a Kernel Patch i have to just type kernel on the identifier.

 

I do agree with your points regarding Desktops.

Most of these things i mentioned are rarely needed but unfortunately for laptops, they are required as they need more complex patches to have everything working properly.

Some of these allow us to have vanilla macOS kexts and just patch them on the fly by bootloader (the case of info.plist patch).

All of this taking into account the moves that Apple is taking on limiting system like read only to keep the integrity of the system. (macOS Catalina) and the steps that they may take in the future.

 

Those were just some questions and suggestions that i think can make every hackintosh user life easier.

 

Open Core seems the future and i already enjoy it as it is on 0.0.3

Whatever you think is the best way let it be so, i trust all of your amazing skills and projects.

Im thankful for all the amazing work that you people have done and do for the hackintosh community.

 

With respect,

Sniki

 

 

Edited by "Sniki"
  • Like 2
Link to comment
Share on other sites

6 hours ago, "Sniki" said:

Yes, i saw that post on previous page after i wrote my post.

Patching DSDT is a bit painful for the fact that even a single change in bios settings or small hardware upgrade will require you to dump, re-extract and patch DSDT again because of changes that happen on memory address.

While with full hotpatch that is not the case.

It is also important for guides as for example a single laptop or pc, can use your addon SSDTs and config.plist without trouble and have everything working, while with static DSDT patching everyone is required to do the patching process of DSDT individually.

I will check that issue by browsing manually as the link seems to not open.

Thanks for clarifying that so whenever it is a Kernel Patch i have to just type kernel on the identifier.

 

I do agree with your points regarding Desktops.

Most of these things i mentioned are rarely needed but unfortunately for laptops, they are required as they need more complex patches to have everything working properly.

Some of these allow us to have vanilla macOS kexts and just patch them on the fly by bootloader (the case of info.plist patch).

All of this taking into account the moves that Apple is taking on limiting system like read only to keep the integrity of the system. (macOS Catalina) and the steps that they may take in the future.

 

Those were just some questions and suggestions that i think can make every hackintosh user life easier.

 

Open Core seems the future and i already enjoy it as it is on 0.0.3

Whatever you think is the best way let it be so, i trust all of your amazing skills and projects.

Im thankful for all the amazing work that you people have done and do for the hackintosh community.

 

With respect,

Sniki

 

 

https://www.insanelymac.com/forum/topic/338516-opencore-discussion/?do=findComment&comment=2678273

  • Like 1
Link to comment
Share on other sites

2 hours ago, vit9696 said:

@"Sniki", insanelymac parser misparsed the link:

https://github.com/acidanthera/bugtracker/issues/394

It clearly explains that plist-patches are just suboptimal ways to do things.

Thanks @vit9696

Yes thanks to the "block" function i personally don't need plist patch for now as i can simply block the entire kext from loading, thanks for pointing me in the right direction.

 

However TGT Bridge seems more required as i can't justify myself to use Patched DSDT as it's really a going back in time thing and not viable option in my opinion, with hotpatch you simply forget about dealing with ACPI until something major changes with a future release or a better alternative shows up.

 

@Andrey1970  did mention the skip and count function that can do the trick for the TGT Bridge patch

( i do not care about breaking functions on windows since i usually boot it from bios boot menu - Windows Boot Manager.)

macOS is my default for 90% of the time and that way i bypass the macOS specific patches by booting from Windows Boot Manager.

 

So what i need to be informed more into this is: the "Skip" and "Count" feature.

So let's say take an example for my I2C Elan Touchpad fix, i use this SSDT-I2C:


// VoodooI2C (TPD0) Patch for Lenovo V330-15IKB with ELAN I2C TouchPad.

#ifndef NO_DEFINITIONBLOCK
DefinitionBlock("", "SSDT", 2, "V330", "_I2C", 0)
{
#endif
    External(_SB.PCI0.I2C0, DeviceObj)
    External(_SB.PCI0.I2C0.TPD0, DeviceObj)
    External(HIDG, FieldUnitObj)
    External(HID2, FieldUnitObj)
    External(HIDD, MethodObj)
    External(TP7G, FieldUnitObj)
    External(TP7D, MethodObj)
    External(SBFB, FieldUnitObj)
    Scope(_SB.PCI0.I2C0)
    {
         Scope(TPD0)
         {
            // SBFX is modified SBFG
            Name (SBFX, ResourceTemplate ()
            {
                GpioInt(Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000,
                    "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                   )
                   {   // Pin list
                       0x001B
                   }
            })
            Method (_DSM, 4, Serialized)  // _DSM: Device-Specific Method
            {
                If (LEqual (Arg0, HIDG))
                {
                    Return (HIDD (Arg0, Arg1, Arg2, Arg3, HID2))
                }

                If (LEqual (Arg0, TP7G))
                {
                    Return (TP7D (Arg0, Arg1, Arg2, Arg3, SBFB, SBFX))
                }

                Return (Buffer (One)
                {
                     0x00                                          
                })
            }
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Return (ConcatenateResTemplate (SBFB, SBFX))
            }
        }
    }
#ifndef NO_DEFINITIONBLOCK
}
#endif
//EOF

So on config.plist i patch/rename the TPD0._CRS to XCRS and TPD0._DSM to XDSM to have hotpatched Touchpad.

 

On OC example the SSDT is all fine but as @Andrey1970 showed that example it seems possible and no need for TGT Bridge thanks to skip and count function.

But im not very clear yet how to use it ?

Does the "Skip" works as the first occurrence like let's say i counted my DSDT _CRS methods and the number 7 is the one of the TPD0, so in that case should the skip value be 6 ?

About "Count" does the count value mean how many of the found _CRS methods should be counted for patching ?

If that's the case then if my _CRS of TPD0 is the 7-th _CRS i assume my Skip value should be 6 and if i need only that occurence/value (in my case the seventh _CRS) and the rest no needed, the count value should be 1, am i correct ? (is this how it works ?)

Edited by "Sniki"
Link to comment
Share on other sites

@"Sniki", please make a feature request in acidanthera/bugtracker describing

- what exactly you need to do (e.g. write custom implementation for _CRS method)

- where you need it (e.g. laptop of brand X of CPU generation Y, etc.)

- what other people need to do (e.g. write X/Y/Z)

- what approach you believe is most functional to resolve this problem in your opinion (could write what clover offers with its semantics or think of your own approach)

- what are the all other approaches you know about (e.g. custom DSDT, Skip/Count method), and why do you think they are unsuitable 

We will need to discuss this to understand how & when to implement a workaround (if at all).

Link to comment
Share on other sites

1 hour ago, "Sniki" said:

Thanks @vit9696 

 

I will make a feature request and provide more scenarios with examples to describe it as clear as possible as you requested on the last post.

 

With respect,

Sniki

Binary patches ACPI in OpenCore much more exceed a functionality binary patches ACPI in Clover.
Here the user used my help. Address to it for details.

 

Edited by Andrey1970
  • Like 1
Link to comment
Share on other sites

2 hours ago, Andrey1970 said:

Binary patches ACPI in OpenCore much more exceed a functionality binary patches ACPI in Clover.
Here the user used my help. Address to it for details.

 

Thanks @Andrey1970 i saw that post but im still not certain how the skip and count works.

Can you just explain a bit more in details, here i did breakthrough with pictures so you can understand what i don't know and which should be the skip and which should be the count value ?

 

Take a look at my DSDT:

TPD0.thumb.png.9191c729675659ee830622451f63f195.png

Should i count every _CRS (including comments - with green) or just other _CRS that are available in usable code inside DSDT or only Method (_CRS) ?

 

If it is all, then my TPD0 _CRS is number 83, should 83 be the count or the skip value in this case ?

Or skip 82 and count 1 ?, im not certain how the logic works on this.

 

I attached the DSDT.aml for reference.

DSDT.aml

Edited by "Sniki"
Link to comment
Share on other sites

16 minutes ago, "Sniki" said:

Thanks @Andrey1970 i saw that post but im still not certain how the skip and count works.

Can you just explain a bit more in details, here i did breakthrough with pictures so you can understand what i don't know and which should be the skip and which should be the count value ?

 

Take a look at my DSDT:

TPD0.thumb.png.9191c729675659ee830622451f63f195.png

Should i count every _CRS (including comments - with green) or just other _CRS that are available in usable code inside DSDT or only Method (_CRS) ?

 

If it is all, then my TPD0 _CRS is number 83, should 83 be the count or the skip value in this case ?

Or skip 82 and count 1 ?, im not certain how the logic works on this.

 

I attached the DSDT.aml for reference.

DSDT.aml

Comments shall not be counted.
You shall stop count on one step before that place where the patch is necessary.

If you execute some patches in in a row identical Find, that you shall consider actions of the previous patches.

  • Like 1
Link to comment
Share on other sites

14 minutes ago, Andrey1970 said:

Comments shall not be counted.
You shall stop count on one step before that place where the patch is necessary.

If you execute some patches in in a row identical Find, that you shall consider actions of the previous patches.

Ok so without comments, the 43 _CRS value is my TPD0 _CRS

Counting one step before that place should be 42

But now i don't know if 42 should be the skip or the count value ?

 

Sorry for the dumb questions, my brain is lagging for now, need more details so i clearly understand how this works exactly

Edited by "Sniki"
Link to comment
Share on other sites

13 minutes ago, "Sniki" said:

Ok so without comments, the 43 _CRS value is my TPD0 _CRS

Counting one step before that place should be 42

But now i don't know if 42 should be the skip or the count value ?

 

Sorry for the dumb questions, my brain is lagging for now, need more details so i clearly understand how this works exactly


I thought it should be "count"

Sorry, it should be "SKIP"

Edited by Andres ZeroCross
Link to comment
Share on other sites

14 minutes ago, "Sniki" said:

Ok so without comments, the 43 _CRS value is my TPD0 _CRS

Counting one step before that place should be 42

But now i don't know if 42 should be the skip or the count value ?

 

Sorry for the dumb questions, my brain is lagging for now, need more details so i clearly understand how this works exactly

skip

  • Like 1
Link to comment
Share on other sites

Just now, Andrey1970 said:

skip

Thanks @Andrey1970 for the explanation.

 

My last question regarding this, what do we use the count for ?

Is it to count how many of these found values to patch after the skip value

 

In my case i want only that number 43 to be patched so should the count value be 1 ?

  • Thanks 1
Link to comment
Share on other sites

22 minutes ago, "Sniki" said:

Thanks @Andrey1970 for the explanation.

 

My last question regarding this, what do we use the count for ?

Is it to count how many of these found values to patch after the skip value

 

In my case i want only that number 43 to be patched so should the count value be 1 ?

Skip to a patch place. Count you shall look the Device, which you a patch in ACPI.

In this place Count 1

862082981_2019-07-2022_24_41.png.5d46f7e0310374ea576e37ef4ce33fb9.png

Edited by Andrey1970
  • Thanks 1
Link to comment
Share on other sites

×
×
  • Create New...