Jump to content

OpenCore General Discussion


dgsga
8,888 posts in this topic

Recommended Posts

5 hours ago, Matgen84 said:

Do you try this:

cd UDK
. ./edksetup.sh
make -C BaseTools
build -a X64 -b RELEASE -t XCODE5 -p OpenCorePkg/OpenCorePkg.dsc

Then only as usual, for new commit and next build

build -a X64 -b RELEASE -t XCODE5 -p OpenCorePkg/OpenCorePkg.dsc

 

Yeah, I did. That was weird.

Edited by Badruzeus
  • Sad 1
Link to comment
Share on other sites

If you downloaded OC 0.9.0 when it was first released, download it again.  The initial release had the wrong version of OpenCore.efi.  Leaving my post below for historical purposes.

 

Spoiler

415964406_ScreenShot2023-03-06at11_14_40AM.png.a3c369edc7920261504fd7d7c6be414b.png

 

695313827_ScreenShot2023-03-06at11_29_29AM.png.77b8910c4e21612b17eb48dc0d865aec.png

 

==================================

 

I downloaded and installed OC 0.9.0 this morning.  I noticed that OpenCore.efi in the RELEASE build has a date of Feb 14, 2023 and Open Core version is still detected as 0.8.9.  Is it possible that the release this morning did not include the correct version of OpenCore.efi?

 

OpenCore-0.9.0-RELEASE

Spoiler

628764052_ScreenShot2023-03-06at11_07_16AM.png.e6ba3280503423a6f37675c468f59885.png

 

Detected OpenCore Version

Spoiler

654049697_ScreenShot2023-03-06at11_08_15AM.png.223c772202084ac43eedfefa0b06b4f8.png

 

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

2 minutes ago, deeveedee said:

I downloaded and installed OC 0.9.0 this morning.  I noticed that OpenCore.efi in the RELEASE build has a date of Feb 14, 2023 and Open Core version is still detected as 0.8.9.  Is it possible that the release this morning did not include the correct version of OpenCore.efi?

 

Maybe, Re-download OC 0.9.0. Because  the release is uploaded two hours ago.

  • Like 1
Link to comment
Share on other sites

25 minutes ago, SavageAUS said:

@Matgen84
 

 

 

  Reveal hidden contents

 


Sent from my iPhone using Tapatalk

 

 

 

@SavageAUS Sorry, I don't understand this issue. (Laptop or Desktop ?). If you are a working hackintosh, download OC latest Release, create a bootable USB key and try again...

Link to comment
Share on other sites

17 hours ago, Matgen84 said:

 

@SavageAUS Sorry, I don't understand this issue. (Laptop or Desktop ?). If you are a working hackintosh, download OC latest Release, create a bootable USB key and try again...

Sorry,

 

This is for my laptop. This is a fresh install updated to 13.3 beta with a fresh minimal config.

Prior to the 13.3 bet update it was working perfectly but now this is the best i get.

Login screen then text screen.

Running latest OC as of yesterday 0.9.1, kexts up to date at the same time as well.

When i get home I will add my config.

 

I was also going to try a fresh install of 13.2.1 and see what happens.

  • Sad 2
Link to comment
Share on other sites

Prior to 13.2.1 everything is fine here. Problem comes up with 13.3 Beta. Screen stays dark on login for 10 minutes and despite VideoProc declares that iGPU has acceleration, it feels like it doesn't. Awful performance. Assuming this is still beta we have to wait until the official release and check again. I think it's more OC related problem, than Ventura problem. I am using latest version of OC and kexts.

Edited by CloverLeaf
Link to comment
Share on other sites

14 minutes ago, CloverLeaf said:

Prior to 13.2.1 everything is fine here. Problem comes up with 13.3 Beta. Screen stays dark on login for 10 minutes and despite VideoProc declares that iGPU has acceleration, it feels like it doesn't. Awful performance. Assuming this is still beta we have to wait until the official release and check again. I think it's more OC related problem, than Ventura problem. I am using latest version of OC and kexts.

This is a laptop as well yeah?

 

I am going to reinstall 13.2.1 tonight hopefully with the same config I have used for ages and I will post result.

  • Like 1
Link to comment
Share on other sites

Unfortunately trying different versions of Ventura did not help me. I think I need to rebuild my EFI from scratch and minimal to get it working again. Or maybe even go back to Monterey.
Funnily my AMD machine is going strong on Ventura latest beta.


Sent from my iPhone using Tapatalk

  • Like 1
Link to comment
Share on other sites

On 3/9/2023 at 4:07 PM, CloverLeaf said:
Prior to 13.2.1 everything is fine here. Problem comes up with 13.3 Beta. Screen stays dark on login for 10 minutes and despite VideoProc declares that iGPU has acceleration, it feels like it doesn't. Awful performance. Assuming this is still beta we have to wait until the official release and check again. I think it's more OC related problem, than Ventura problem. I am using latest version of OC and kexts.

Now that I have my laptop booting again I too am seeing this issue, although it is not 10 minutes at a black screen it is a good 5 minutes.
I have full video acceleration and performance is fine except for the delayed boot.
Hopefully the Acidanthera team are aware of it and are looking into it.
I am happy to provide EFI / config and or any logs required to look into it, just let me know what’s needed.Just to add more information seeing as this is it gaining any traction.

 

I have added back in my HDMI output settings into my config.plist and HDMI output is working again and it works at boot, prior to the internal laptop screen working, takes a few more minutes for the internal LCD screen to come alive.

 

 

 

Screenshot 2023-03-12 at 12.53.33 pm.png

config.plist

Edited by SavageAUS
Link to comment
Share on other sites

I was trying to help someone with Open Core kernel patches (OC config.plist, Kernel > Patch) and realized that I don't know as much as I thought (not the first time and definitely won't be the last).  Does anyone know of a guide with examples that explains the following Open Core kernel patching concepts:

  • When to use "Base" and how to determine "Base"
  • How to determine "Identifier" and when to specify "kernel" vs a specific kext
  • When determining "Find" for a specific kext, is it sufficient to use HexFiend (or similar) to examine the binary in the kext's Contents/MacOS
  • When patching a specific kext, does it matter whether the kext is installed in /System/Library/Extensions or /Library/Extensions?

These are probably remedial questions for the experienced kernel patcher.  Thanks for any suggested guides with examples.

Link to comment
Share on other sites

High guys,

Have a strange problem. I've made a fanless computer with macos installed, been using "turbo boost switcher" for years but tired to enter passsword each time it asks (which is quite often).
 had no idea about kexts but have some experience in programming, so, Ive spent a hour or two reading dev.apple.com and wrote a simple kext which disables turbo on load and on sleep/wake and so on.

Long story short - kext is working pretty well with "kextload", but does not work when I try to load it from OpenCore. I mean, there's no kext at all in case I use OC to load it.
 

viktor@work:~ $ kextstat|grep -i turbo
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release

viktor@work:~ $

I thought OC just loads, no matter what. Like, OC would load any valid kext specified in the config. And as this kext works fine from command line, I suppose it is valid. What could be a problem with me, my kext and OC?
Please help. Thank you

oc_kext.tgz

  • Like 1
Link to comment
Share on other sites

3 hours ago, viktr said:

High guys,

Have a strange problem. I've made a fanless computer with macos installed, been using "turbo boost switcher" for years but tired to enter passsword each time it asks (which is quite often).
 had no idea about kexts but have some experience in programming, so, Ive spent a hour or two reading dev.apple.com and wrote a simple kext which disables turbo on load and on sleep/wake and so on.

Long story short - kext is working pretty well with "kextload", but does not work when I try to load it from OpenCore. I mean, there's no kext at all in case I use OC to load it.
 

viktor@work:~ $ kextstat|grep -i turbo
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release

viktor@work:~ $

I thought OC just loads, no matter what. Like, OC would load any valid kext specified in the config. And as this kext works fine from command line, I suppose it is valid. What could be a problem with me, my kext and OC?
Please help. Thank you

oc_kext.tgz 7.09 kB · 2 downloads

Your kext is run from the command line. OpenCore will not launch the command line and include the kext for you. Most likely you need to write a script to run kext on boot.

Link to comment
Share on other sites

1 hour ago, pitrysha said:

Your kext is run from the command line. OpenCore will not launch the command line and include the kext for you. Most likely you need to write a script to run kext on boot.

Sorry, but isn’t “kernel - add section” in the oc cinfig is just intended to tell oc what kexts should it load? Like, lilu, mausi, wakefixup, radeonsensors - whatever?

  • Like 1
Link to comment
Share on other sites

10 hours ago, viktr said:

High guys,

Have a strange problem. I've made a fanless computer with macos installed, been using "turbo boost switcher" for years but tired to enter passsword each time it asks (which is quite often).
 had no idea about kexts but have some experience in programming, so, Ive spent a hour or two reading dev.apple.com and wrote a simple kext which disables turbo on load and on sleep/wake and so on.

Long story short - kext is working pretty well with "kextload", but does not work when I try to load it from OpenCore. I mean, there's no kext at all in case I use OC to load it.
 

viktor@work:~ $ kextstat|grep -i turbo
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release

viktor@work:~ $

I thought OC just loads, no matter what. Like, OC would load any valid kext specified in the config. And as this kext works fine from command line, I suppose it is valid. What could be a problem with me, my kext and OC?
Please help. Thank you

oc_kext.tgz 7.09 kB · 4 downloads

Well, OC debug shows kext has been loaded, but absent then:

 

viktor@work:~/Volumes/EFI $ grep -i -A2 -B2 turbo opencore-2023-03-21-180607.txt
08:626 00:003 OC: Prelinked injection NVMeFix.kext v1.1.0
08:629 00:003 OCAK: Local relocs 4 on FFFFFF80045C0000
08:632 00:003 OC: Prelinked injection TurboDisabler.kext () - Success
08:635 00:002 OC: Prelinked injection TurboDisabler.kext v1.0.0
08:642 00:007 OCAK: Patching invalid size DFE0 with ED7000 for com.apple.kec.Libm
08:654 00:012 OCAK: Local relocs 703 on FFFFFF80045CA000
viktor@work:~/Volumes/EFI $ kextstat|grep -iv apple
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
Index Refs Address Size Wired Name (Version) UUID <Linked Against>
54 8 0 0x2f000 0x2f000 as.vit9696.Lilu (1.6.4) FA02BB0A-0769-30FD-8938-136A6467C42B <9 7 6 3 2 1>
55 0 0 0xf000 0xf000 as.lvs1974.HibernationFixup (1.4.8) 9D079C9A-A937-3A0A-8420-666F0EF69705 <54 9 7 6 3 2 1>
56 0 0 0x81000 0x81000 as.vit9696.WhateverGreen (1.6.4) 02E3858A-716B-3B71-800A-EABB12994893 <54 17 9 7 6 3 2 1>
58 0 0 0xd000 0xd000 org.acidanthera.NVMeFix (1.1.0) F978B25E-5239-3FE8-8227-51301AC0A00D <54 9 7 6 3 2 1>
59 0 0 0x14000 0x14000 aluveitie.RadeonSensor (0.3.3) C05A7C6F-BD34-300A-9139-C53245A18CAA <54 17 13 7 6 3 2 1>
60 2 0 0x1a000 0x1a000 as.vit9696.VirtualSMC (1.3.1) 693F7102-42E4-38EA-9342-04D674D1EB1E <54 16 9 7 6 3 1>
61 0 0 0xf000 0xf000 as.vit9696.SMCProcessor (1.3.1) D469B63D-D814-3996-9C64-CF5AA9C336B9 <60 54 16 9 7 6 3 2 1>
79 0 0 0x2a000 0x2a000 as.acidanthera.mieze.IntelMausi (1.0.7) 82B83B99-6FE0-3D1F-91BF-E22233968775 <50 17 7 6 3 1>
80 0 0 0x1f000 0x1f000 ru.joedm.SMCSuperIO (1.3.1) E06ECB01-C755-3647-9390-D2254E221AB7 <60 54 16 9 7 6 3 2 1>
112 0 0xffffff7f9714d000 0x1ff2 0x1ff2 com.intel.driver.EnergyDriver (3.7.0) 35E739F9-BF6C-3024-A67C-750711B3FB64 <9 7 6 3>
180 0 0xffffff7f9722b000 0x3fffe 0x3fffe com.paragon-software.filesystems.ntfs (559.10.15) 20BAD71D-B58F-3E37-A218-C95C4892F072 <9 7 6 1>
viktor@work:~/Volumes/EFI $


 

Link to comment
Share on other sites

Hi all

 

I can't build latest commit (Monterey 12.6.3 / XCode 14.2 on my old Ivybridge) Command Lines Tools installed. Any ideas ? Please.

 

Spoiler

Using EDK2 in-source Basetools

WORKSPACE: /Users/mathieu/OC/UDK

EDK_TOOLS_PATH: /Users/mathieu/OC/UDK/BaseTools

CONF_PATH: /Users/mathieu/OC/UDK/Conf

Testing...

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C Source/C

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C Source/Python

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ImageTool

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C MicroTool

make[1]: Nothing to be done for `all'.

Attempting to detect HOST_ARCH from 'uname -m': x86_64

Detected HOST_ARCH of X64 using uname.

mkdir -p .

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C Common

make[2]: *** No rule to make target `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0/include/stdint.h', needed by `BasePeCoff.o'.  Stop.

make[1]: *** [Common] Error 2

make: *** [Source/C] Error 2

make: *** Waiting for unfinished jobs....

/Applications/Xcode.app/Contents/Developer/usr/bin/make all CFLAGS="-c -fshort-wchar -Wall -Wextra -D EFIUSER -Wno-unused-parameter -Wno-implicit-fallthrough -Wno-strict-aliasing -Wno-address -mmacosx-version-min=10.6 --target=x86_64-apple-darwin -D ENTRY_POINT=main -g -O0 -D EFIUSER_DEBUG -I../../OpenCorePkg/User/Include -I../../OpenCorePkg/Include/Acidanthera -I../../OpenCorePkg/Include/Apple -I../../OpenCorePkg/Include/Apple/X64 -I../../OpenCorePkg/Include/Generic -I../../OpenCorePkg/Include/Intel -I../../OpenCorePkg/Include/Microsoft -I../../OpenCorePkg/Include/Nvidia -D NO_MSABI_VA_FUNCS -D OC_TARGET_DEBUG -I../../MdePkg/Include -I../../MdePkg/Include/Library -I../../MdePkg/Include/X64 -I../../MdePkg/Library/BaseLib -I../../MdeModulePkg/Include -I../../UefiCpuPkg/Include -include ../../OpenCorePkg/User/Include/UserPcd.h -include ../../OpenCorePkg/User/Include/UserGlobalVar.h -include Pcds.h -Werror -DEFI_TARGET32" PRODUCT=ImageTool32 INFIX=_Tool32

/Applications/Xcode.app/Contents/Developer/usr/bin/make all CFLAGS="-c -fshort-wchar -Wall -Wextra -D EFIUSER -Wno-unused-parameter -Wno-implicit-fallthrough -Wno-strict-aliasing -Wno-address -mmacosx-version-min=10.6 --target=x86_64-apple-darwin -D ENTRY_POINT=main -g -O0 -D EFIUSER_DEBUG -I../../OpenCorePkg/User/Include -I../../OpenCorePkg/Include/Acidanthera -I../../OpenCorePkg/Include/Apple -I../../OpenCorePkg/Include/Apple/X64 -I../../OpenCorePkg/Include/Generic -I../../OpenCorePkg/Include/Intel -I../../OpenCorePkg/Include/Microsoft -I../../OpenCorePkg/Include/Nvidia -D NO_MSABI_VA_FUNCS -D OC_TARGET_DEBUG -I../../MdePkg/Include -I../../MdePkg/Include/Library -I../../MdePkg/Include/X64 -I../../MdePkg/Library/BaseLib -I../../MdeModulePkg/Include -I../../UefiCpuPkg/Include -include ../../OpenCorePkg/User/Include/UserPcd.h -include ../../OpenCorePkg/User/Include/UserGlobalVar.h -include Pcds.h -Werror -DEFI_TARGET64" PRODUCT=ImageTool64 INFIX=_Tool64

make[1]: Nothing to be done for `all'.

make[2]: Nothing to be done for `all'.

make[2]: Nothing to be done for `all'.

 

Edit: Solved. I recreate new local repo. All works fine now.

Edited by Matgen84
  • Sad 1
Link to comment
Share on other sites

I had previously reported that I needed to use FakeSMC instead of VirtualSMC to reliably boot Big Sur, Monterey and Ventura on my HackBookPro6,2.  I have found that I can use VirtualSMC if I specify boot-arg vsmcgen=1. Continued here.

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

Not sure if this an OC problem or a user problem but my trackpad is detected but it does not function.

I have attached config & ioreg and bootlog from hackintool.

I mostly use an external mouse but having the touchpad work is needed too.

Archive.zip

 

Ok I have managed to get the touchpad working but I have to have the tracking speed turned all the way up to get proper cursor movement.

New files here

Archive.zip

 

Edited by SavageAUS
Link to comment
Share on other sites

On 2/19/2023 at 10:54 PM, Stefanalmare said:

Ventura beta 13.3 killed "enable-backlight-registers-fix" on DeviceProperties (same -igfxblr on Boot argument).
My Dell Vostro 5490 (i5-10210u) after update, is acting like without this Whatevergreen proprieties. Very dim light screen on boot and after some time backlight restore to normal.
Anybody else? Solutions?

 

Ventura 13.3 RC fix it.

Edited by Stefanalmare
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

×
×
  • Create New...