OpenCore General Discussion

[Erroruser]

On 7/11/2019 at 5:58 PM, PMheart said:

That can be taken into account WITH LOWEST PRIORITY.

 

lol just like the NVRAM for some of the z390 boards..... right?
lol

[MacPato]

Edited July 13, 2019 by MacFriedIntel

[PMheart]

1 hour ago, errorexists said:

lol just like the NVRAM for some of the z390 boards..... right?
 lol

That's totally another story I guess.

Currently we are having a tremendous number of new features to implement, which makes us too exhausted to investigate a specific platform. I suppose it would be sensible for users tending to build a new hack to avoid it.

 

As for theming, well, I guess one of the biggest reasons to use OpenCore is to enjoy the fun macOS brings us, instead of themes one might only see for several seconds, which are too fleeting to be enjoyed.

 

Either way, we wish somebody who were willing to and capable to participate in the problem, and finally we would have a solution. We are sorry for lack of time to do it compared to other TODOs that may appear more worthwhile.

 

Best Regards,

PMheart

[mhaeuser]

@WarDoc Thank you for your feedback. I especially like the harmony of the modern OC logo design with the serif font. /s

@MacFriedIntel This one without sarcasm, thank you for your effort, but the logo went through a design process and has been decided on as final, it is not going to be changed any time soon. For your future creations for whatever purpose you should consider (C), as that usage of the Apple logo clearly violates their rights. Personally, we wanted something simple, besides the common "C embedded in the O" concept, a colour palette close to the one of the Mavericks default background bas been used. As for the "Core" inside, unfortunately the name is not established enough for the "Open" part to be implicit.

@errorexists If you think the problems you are facing deserve higher priority, you are welcome to submit a fix and it will be reviewed, tested and merged within a day. Meanwhile we will concentrate on issues a lot more people are facing and are a lot easier to solve with the free time we have next to work, education and maybe some free time not spent on maintaining hobby projects.

 

Edited July 14, 2019 by Download-Fritz

[MacPato]

3 hours ago, Download-Fritz said:

@WarDoc Thank you for your feedback. I especially like the harmony of the modern OC logo design with the serif font. /s

@MacFriedIntel This one without sarcasm, thank you for your effort, but the logo went through a design process and has been decided on as final, it is not going to be changed any time soon. For your future creations for whatever purpose you should consider (C), as that usage of the Apple logo clearly violates their rights. Personally, we wanted something simple, besides the common "C embedded in the O" concept, a colour palette close to the one of the Mavericks default background bas been used. As for the "Core" inside, unfortunately the name is not established enough for the "Open" part to be implicit.

@errorexists If you think the problems you are facing deserve higher priority, you are welcome to submit a fix and it will be reviewed, tested and merged within a day. Meanwhile we will concentrate on issues a lot more people are facing and are a lot easier to solve with the free time we have next to work, education and maybe some free time not spent on maintaining hobby projects.

 

Should of guessed that there would been an element of inadvertent sarcasm towards the copyright issue (LOL) and i guess a response like that was predictable but as for the design effort, i can see you have taken a minimal approach to the logo. but i can see that AppleLife's community only has a say and an input to anything. @WarDoc was spot on with his comments, to me it doesn't represent a bootloader i feel i should be applying for a credit card or joining to fight climate change. and @errorexists has asked for weeks for someone @vit9696 to look at the Z390 problem and yet again, unless  it seems AppleLife has listed it as an issue, it doesn't get looked it. If you plan to let opencore gain ground in a wider community, At least accept there's an issue with these boards and at least try to fix or address the problem. or give some clear indication and instructions on how to fix this in the short term.

[mhaeuser]

@MacFriedIntel I find it hard to judge that a logo does not "represent a bootloader" because usually bootloaders do not have logos, there is very little reference material for associations. Your logo is not something one would find in the wild at all, so I find it hard to have literally any associations with it. I personally dislike it for the hard gradient, but that is nothing that makes sense discussing and it comes down to preference. We liked the smoother gradients of the current logo and the colour palette reflecting the one of the Mavericks default background on the part which happens to have a circular form similiar to the wave of said image. If you dislike our choice, you are free to use different logos for whatever material you happen to provide (like for a theme for a future GUI, if such appears). As for the copyright, that was not sarcastic, we are not looking to violate intellectual property, and neither should you.

 

As you seem to be more reasonable than your friend, I will lay down the Z390 problem once and hope it will be clear enough. First, there already is a workaround, which is the same as for Clover: Use EmuVariable. This has been supported for some time and is what people do to work around the issue for Clover, and has been mentioned and partially discussed throughout the thread. Infact, as it is a good-enough workaround, it had a somewhat high priority.

Now, the actual issue why hardware NVRAM is unusable is very unexplored and complex. Basically, UEFI offers a "SetVariable" service to macOS, macOS calls it, but UEFI never returns from the operation, it must get stuck in some kind of deadloop. This is nothing like actual OpenCore issues or other firmware quirks, where a couple of prints provide enough information on what the problem is, this requires an analytic approach on how to find out where the code execution gets stuck. This involves reverse engineering, targeted test cases (replace UEFI modules, write a pre-boot app to simulate OS launch and check effects, etc) and toying with a debug environment via serial, as this is unsed by macOS. Short, it is dramatically more effort to investigate than any other issue we had come across previously. Added to that, an alright workaround is already available and it only affects a small user base. Now you tell me, why should we make it a high priority? Because @errorexists keeps whining about it in this thread and our bugtracker? To a bunch of hobbyists from which work he profits without giving literally anything but complaints back? This is beyond ridiculous, and so is that you try to make a point out of frequent complaints by a single person.

 

Z390 is a simple cost/usage equation. Very high cost, very small impact. I do not see how that can be made any clearer than I have tried to make it above, so except for questions requestion clarification on what I already said, any further complaints are going to be ignored and may be silently reported if we feel like they clutter this thread. If anyone wants to turn that into a "a bug report is being censored" because they're upset, enjoy believing that.

 

AppleLife issues usually get preference because the community is more firm with a proper debugging workflow, end of story. If we get a complete set of information that makes a bug obvious or describes a solution anywhere, it will be looked into with the same effort, but that simply does not happen.

Edited July 14, 2019 by Download-Fritz

[MacPato]

7 minutes ago, Download-Fritz said:

@MacFriedIntel I find it hard to judge that a logo does not "represent a bootloader" because usually bootloaders do not have logos, there is very little reference material for associations. Your logo is not something one would find in the wild at all, so I find it hard to have literally any associations with it. I personally dislike it for the hard gradient, but that is nothing that makes sense discussing and it comes down to preference. We liked the smoother gradients of the current logo and the colour palette reflecting the one of the Mavericks default background on the part which happens to have a circular form similiar to the wave of said image. If you dislike our choice, you are free to use different logos for whatever material you happen to provide (like for a theme for a future GUI, if such appears). As for the copyright, that was not sarcastic, we are not looking to violate intellectual property, and neither should you.

 

As you seem to be more reasonable than your friend, I will lay down the Z390 problem once and hope it will be clear enough. First, there already is a workaround, which is the same as for Clover: Use EmuVariable. This has been supported for some time and is what people do to work around the issue for Clover, and has been mentioned and partially discussed throughout the thread. Infact, as it is a good-enough workaround, it had a somewhat high priority.

Now, the actual issue why hardware NVRAM is unusable is very unexplored and complex. Basically, UEFI offers a "SetVariable" service to macOS, macOS calls it, but UEFI never returns from the operation, it must get stuck in some kind of deadloop. This is nothing like actual OpenCore issues or other firmware quirks, where a couple of prints provide enough information on what the problem is, this requires an analytic approach on how to find out where the code execution gets stuck. This involves reverse engineering, targeted test cases (replace UEFI modules, write a pre-boot app to simulate OS launch and check effects, etc) and toying with a debug environment via serial, as this is unsed by macOS. Short, it is dramatically more effort to investigate than any other issue we had come across previously. Added to that, an alright workaround is already available and it only affects a small user base. Now you tell me, why should we make it a high priority? Because @errorexists keeps whining about it in this thread and our bugtracker? To a bunch of hobbyists from which work he profits without giving literally anything but complaints back? This is beyond ridiculous, and so is that you try to make a point out of frequent complaints by a single person.

 

Z390 is a simple cost/usage equation. Very high cost, very small impact. I do not see how that can be made any clearer than I have tried to make it above, so except for questions requestion clarification on what I already said, any further complaints are going to be ignored and may be silently reported if we feel like they clutter this thread. If anyone wants to turn that into a "a bug report is being censored" because they're upset, enjoy believing that.

 

AppleLife issues usually get preference because the community is more firm with a proper debugging workflow, end of story. If we get a complete set of information that makes a bug obvious or describes a solution anywhere, it will be looked into with the same effort, but that simply does not happen.

Thank You for the Clarification, It does seem to be an isolated issue with 2 users of Asus Z390 Boards, i had a Similar issue with a MSI Z390 Board and even EmuVariable wasn't successful in my case, i gave up and switched to a working Z370. I'm sure @errorexists will see your post, And the frustration with him is the fact the board he has was a gift from his children, which i think as to why he gets upset with the fact it doesn't work with or without the workaround. checking NVRAM after bootup doesn't indicate its working and yes i think there is some issues with the way the UEFI is getting stuck in a loop as you said. I personally don't see any advantage over the Z370 to upgrade to Z390 as the Z370 along with Z97's are most compatible. I will today make a New EFI for him and get him to post me a log so that we can see for sure what the issue is. if this is something you are willing to look at.

[MacPato]

@Download-Fritz  Example of NVRAM.plist is missing from the Tools Directory on build of OC, it says it's there in the manual but doesn't seem to be there.

Edited July 14, 2019 by MacFriedIntel

[justin]

10 minutes ago, MacFriedIntel said:

Example of NVRAM.plist is missing from the Tools Directory on build of OC, it says it's there in the manual but doesn't seem to be there.

 

 

You need to compile OpenCore from latest git commit and you'll find Utilities/LogoutHook/LogoutHook.command, this tool is used to create nvram.plist. 

 

Even without third party tools, the Documents is already very clear on the structure: Root {Version, Add} , "Add" is the same structure as config.plist/UEFI/Add/  attached is an example. 

nvram.plist

Edited July 14, 2019 by justin

[MacPato]

1 hour ago, justin said:

 

You need to compile OpenCore from latest git commit and you'll find Utilities/LogoutHook/LogoutHook.command, this tool is used to create nvram.plist. 

 

Even without third party tools, the Documents is already very clear on the structure: Root {Version, Add} , "Add" is the same structure as config.plist/UEFI/Add/  attached is an example. 

nvram.plist

 

Okay so might be an idea to add that to the manual. but thanks

[Andres ZeroCross]

@Download-Fritz, I can't build latest OpenCorePkg or AppleSupportpkg with macbuild.tool for each folder., there is line about "Repository https://github.com/acidanthera/OcSupportPkg named OcSupportPkg contains CRLF line endings"

But build is ok if i just build with 
source edksetup.sh
build -a X64 -b RELEASE -t XCODE5 -p OpenCorePkg/OpenCorePkg.dsc

Edited July 15, 2019 by Andres ZeroCross

[mhaeuser]

@Andres ZeroCross One just gotta love VS... fixed

[Andres ZeroCross]

On 7/12/2019 at 11:35 PM, vit9696 said:

Generally that's fine. It should not change unless /S/L/E kexts change.

 

> I reboot My PC and boot to openCore, 

Do not do that. Please boot straight to UEFI Shell (add it as EFI/BOOT/BOOTx64.efi) then load OpenCore. I have a suspect that EFI file system drivers are faulty, so better not to reboot.

 

On 7/12/2019 at 11:35 PM, vit9696 said:

Generally that's fine. It should not change unless /S/L/E kexts change.

 

> I reboot My PC and boot to openCore, 

Do not do that. Please boot straight to UEFI Shell (add it as EFI/BOOT/BOOTx64.efi) then load OpenCore. I have a suspect that EFI file system drivers are faulty, so better not to reboot.

 

SOLVED : i have checked the PrelinkedKernel date in System/Library/PrelinkedKernel and the date is 3 July 2019. Weird

I run kext utility.app and PrelinkedKernel's date is not change,, then i open terminal and run "sudo mount -uw /" and "sudo killall Finder' then i re-Run Kext utility.app. The date of Prelinked kernel is change 

 

Now reboot and i can see patch is succesfull,, i am boot with Salado Framebuffer now. 

[hardcorehenry]

Could someone help me with HPET.  I don’t have DSDT in OC/ACPI on my Haswell  
hackintosh, only SSDT hotpatches . No SSDT-HPET.aml hotpatch can make _STA return 0xf. My original OEM HPET looks like this:

 

 Device (HPET)
                {
                    Name (_HID, EisaId ("PNP0103") /* HPET System Timer */)  // _HID: Hardware ID
                    Name (_UID, Zero)  // _UID: Unique ID
                    Name (BUF0, ResourceTemplate ()
                    {
                        Memory32Fixed (ReadWrite,
                            0xFED00000,         // Address Base
                            0x00000400,         // Address Length
                            _Y0F)
                    })
                    Method (_STA, 0, NotSerialized)  // _STA: Status
                    {
                        If (LGreaterEqual (OSYS, 0x07D1))
                        {
                            If (HPAE)
                            {
                                Return (0x0F)
                            }
                        }
                        ElseIf (HPAE)
                        {
                            Return (0x0B)
                        }

                        Return (Zero)
                    }

                    Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
                    {
                        If (HPAE)
                        {
                            CreateDWordField (BUF0, \_SB.PCI0.LPCB.HPET._Y0F._BAS, HPT0)  // _BAS: Base Address
                            If (LEqual (HPAS, One))
                            {
                                Store (0xFED01000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */
                            }

                            If (LEqual (HPAS, 0x02))
                            {
                                Store (0xFED02000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */
                            }

                            If (LEqual (HPAS, 0x03))
                            {
                                Store (0xFED03000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */
                            }
                        }

                        Return (BUF0) /* \_SB_.PCI0.LPCB.HPET.BUF0 */
                    }
                }

 

[justin]

1 hour ago, hardcorehenry said:

Could someone help me with HPET.  I don’t have DSDT in OC/ACPI on my Haswell  
hackintosh, only SSDT hotpatches . No SSDT-HPET.aml hotpatch can make _STA return 0xf. My original OEM HPET looks like this:

 

 Device (HPET)
                {
                    Name (_HID, EisaId ("PNP0103") /* HPET System Timer */)  // _HID: Hardware ID
                    Name (_UID, Zero)  // _UID: Unique ID
                    Name (BUF0, ResourceTemplate ()
                    {
                        Memory32Fixed (ReadWrite,
                            0xFED00000,         // Address Base
                            0x00000400,         // Address Length
                            _Y0F)
                    })
                    Method (_STA, 0, NotSerialized)  // _STA: Status
                    {
                        If (LGreaterEqual (OSYS, 0x07D1))
                        {
                            If (HPAE)
                            {
                                Return (0x0F)
                            }
                        }
                        ElseIf (HPAE)
                        {
                            Return (0x0B)
                        }

                        Return (Zero)
                    }

                    Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
                    {
                        If (HPAE)
                        {
                            CreateDWordField (BUF0, \_SB.PCI0.LPCB.HPET._Y0F._BAS, HPT0)  // _BAS: Base Address
                            If (LEqual (HPAS, One))
                            {
                                Store (0xFED01000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */
                            }

                            If (LEqual (HPAS, 0x02))
                            {
                                Store (0xFED02000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */
                            }

                            If (LEqual (HPAS, 0x03))
                            {
                                Store (0xFED03000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */
                            }
                        }

                        Return (BUF0) /* \_SB_.PCI0.LPCB.HPET.BUF0 */
                    }
                }

 

 

upload your orig DSDT.aml, i can help create a find and replace patch for you to make sure the HPET always return 0xF 

[HmO]

Device (HPET)
                {
                    Name (_HID, EisaId ("PNP0103") /* HPET System Timer */)  // _HID: Hardware ID
                    Name (_UID, Zero)  // _UID: Unique ID
                    Name (BUF0, ResourceTemplate ()
                    {
                        Memory32Fixed (ReadWrite,
                            0xFED00000,         // Address Base
                            0x00000400,         // Address Length
                            _Y0F)
                    })
                    Method (_STA, 0, NotSerialized)  // _STA: Status
                    {                       
                        Return (0x0F)                       
                    }
                    Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
                    {                       
                        Return (BUF0) /* \_SB_.PCI0.LPCB.HPET.BUF0 */
                    }
                }

 

[hardcorehenry]

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

[justin]

what do you want? if you only want to have HPET return 0xF, as i've said, upload your untouched DSDT.aml, i can help to make a find/replace patch. 

 

36 minutes ago, hardcorehenry said:

but I have KP in other systems

 

what is the "other systems" ?

 

[Pavo]

Why are you messing with HPET in the first place?

[Guest]

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

 

[HmO]

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]

[Andres ZeroCross]

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

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

[HmO]

@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

[dgsga]

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

[MacPato]

Anyone know if ConsoleGOP is required for iGPU? if the BIOS is UEFI and CSM is disabled.