[pre-release] macOS Ventura

[rubenpp]

On 6/12/2022 at 5:29 PM, Dragster27 said:

 

I had the exact same issue... it turned out to be a few quirks I had set the wrong way in my config.plist...I've fixed it and got it working now.. Do the following:

 

1. Update all necessary kexts and OpenCore to latest version from https://dortania.github.io/builds/

2.   Backup your config.plist

3. Open your config.plist with OpenCore Configurator and use the config checker from the tools menu to check your configuration for your specific platform.

3. Make the recommended changes to you config plist and save, pay special attention in the suggested changes for the quirks.

4. Save your updated configuration and reboot.

5. If you are upgrading from an existing Monterey install, boot into Monterey and run the upgrade process again, if you're installing from USB boot with it and you should be good.

 

This worked for me to solve the issue.

 

Good luck,

Dragster.

 

 

@Dragster Thank you !  I followed all the steps including adding some Security Quirks ,OC checker suggested . Except for running the upgrade process again . Will try the USB install next. But so far no luck

 

 

Edited June 16, 2022 by rubenpp
change addressing

[rubenpp]

On 6/12/2022 at 11:31 PM, eSaF said:

Unfortunately until you sort out the correct files and kexts your system actually needs, there is not much anyone can do to help. I don't believe you need all those there, I suggest you find an already constructed and running Monterey/or other OS X  installed EFI Folder with near enough specs as your rig and we can work from there.

With your current setup can you boot any OS X version i.e Monterey or Big Sur and reach the Desktop? Which I think is highly unlikely judging by your files. Meanwhile I will look around and see if I can find a working EFI Folder for you.

@eSaF Appreciate all the help !  My current build  has been running  Monterey with the EFI I provided  , and has been OK even with all the beta releases until Ventura. Again thank you ! 

[aben]

11 hours ago, 5T33Z0 said:

 

From my understanding the x86 variant of Ventura uses AVX2 for the dylyd chache while the M1 versions doesn't, so that's why the swapping trick works. It wouldn't make much sense to use a "middle-man technology" like rosetta to implement AVX2 and use it for caching on M1 because it would be super inefficient.

 

It is true that macOS 13's dyld shared cache no longer ships a non-AVX2 variant for the Intel side with the discontinuation of the famous 'Trash can" MacPro6,1 however if legacy x86 systems are able to successfully “run” macOS 13 via a post-install img from Apple Silicon (non x86), that means support for those x86 instruction set (non-AVX2) is clearly present (in dyld shared cache); thanks to Rosetta, which again is Apple’s planned offering (as part of their transition to Apple Silicon) to also help provide app developers using these ARM-based machines enough buffer period that would allow for a smooth transition of their apps to Apple Silicon as well while maintaining the necessary support for their x86 variant of the app to be able to run in parallel (via x86 instruction set present in Rosetta's dyld shared cache)

 

Basically, if Rosetta didn't exist OR had been updated to only support AVX2 instructions, none of these legacy systems would have seen macOS 13.

Edited June 16, 2022 by aben

[Dragster27]

3 hours ago, rubenpp said:

 

 

@Dragster Thank you !  I followed all the steps including adding some Security Quirks ,OC checker suggested . Except for running the upgrade process again . Will try the USB install next. But so far no luck

 

 

@Rubenpp No problem. try the install running the upgrade process again after doing the changes, otherwise it might not work. You can also try the installation via USB. 

 

Good luck,

Cheers.

D.

[Guest 5T33Z0]

The OCLP repo contains an informative post about all the things that were removed from Ventura: https://github.com/dortania/OpenCore-Legacy-Patcher/issues/998

[jsl2000]

On 6/15/2022 at 11:59 PM, Hervé said:

Of course! KBL layout 0x591B0000 is a mobile framebuffer... 'cannot understand why you went for that.

 

Make sure to:

1. use the appropriate desktop one
2. identify the output port (i.e. connector) against which your DP screen registers (using apps such IORegistryExplorer)

 

Recommended KBL desktop framebuffer is 0x59120000:

ID: 59120000, STOLEN: 38 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000110B
TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 115 MB, MAX OVERALL: 116 MB (122171392 bytes)
Model name: Intel HD Graphics KBL CRB
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
01050900 00040000 87010000
02040A00 00040000 87010000
03060A00 00040000 87010000

Of course, you'll need the appropriate SMBIOS too.

Thanks for your help and instruction.

Unfortunately even it can boot successfully with KBL desktop framebuffer is 0x59120000, its DP/HDMI audio still disabled and only ALC-662 working. My ioreg & config.plist of OC 0.8.2 are attached here for your reference. Please advise me how to fix it.

[Solved]

DP/HDMI audio can be enabled now after disabled SkylakeInjector.kext.

iMac.ioreg

config.plist

Edited June 16, 2022 by jsl2000

[Guest 5T33Z0]

@jsl2000 Try this:

 

• Add key hda-gfx <STRING> onboard-1 to your framebuffer
• Disable PciRoot(0x0)/Pci(0x1F,0x3) (put # in front of it) since it is it referencing "onboard-1" slot but that's already addressed by  PciRoot(0x0)/Pci(0x1b,0x0)
• Save, reboot, test
• If it doesn't work, disable PciRoot(0x0)/Pci(0x1b,0x0) and enable PciRoot(0x0)/Pci(0x1F,0x3)  instead.
• Save, reboot, test

Edited June 16, 2022 by 5T33Z0

[jsl2000]

24 minutes ago, 5T33Z0 said:

@jsl2000 Try this:

 

• Add key hda-gfx <STRING> onboard-1 to your framebuffer
• Disable PciRoot(0x0)/Pci(0x1F,0x3) (put # in front of it) since it is it referencing "onboard-1" slot but that's already addressed by  PciRoot(0x0)/Pci(0x1b,0x0)
• Save, reboot, test
• If it doesn't work, disable PciRoot(0x0)/Pci(0x1b,0x0) and enable PciRoot(0x0)/Pci(0x1F,0x3)  instead.
• Save, reboot, test

Thanks for your kind help and advice.

I have followed your instruction to test step by step, unfortunately all are in vain to fix this issue.

[Joshua60]

I'm experiencing something strange with my rig #2. OC and Kext are up to date. I'm not sure if my DeviceProperties are correct, so I kindly ask for help.

 

The DP for uhd630 in my config are:

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
    <dict>
        <key>AAPL,ig-platform-id</key>
        <data>AACbyA==</data>
        <key>framebuffer-patch-enable</key>
        <data>AQAAAA==</data>
    </dict>
</dict>
</plist>

 

The issue is with Safari, minimizing and maximizing the safari window takes a lot of time.

Is similar but not exactly the same in Ventura, Monterey and Big Sur.

 

Thanks for helping.
 

[aben]

Just now, surenmunoo said:

I was using 0.8.2 but had to revert to 081 because my Fenvi T919 worked sometimes and stopped. When I reverted to 081 it works properly. 

Hmm that's strange since OC shouldn't affect IONetworking in any way. Try once with 0.8.2 and see; if it works that means you do require current OC patched for Ventura.

 I also see an error with one of your boot-args: it's -lilubetaall not -lilubetaal; either remove or test with the correct value. 

[D3v1L]

Ok so, remove weg, remove brcram"etc" ,remove pikera and lilubetaall bootarg, update OC and kext to latest beta, and try ti boot

[Cyberdevs]

Guys I moved "Unknown CPU issue" posts to this topic

Please continue there:

 

[Guest 5T33Z0]

@Cyberdevs Unlles the guy gets his config in order so he can boot with OC 082, he cannot expect that the CPU info is displayer correctly in macOS 13 when he is using OC 081…

 

So  instead of him fixing his config issues moving this to a dedicated thread makes it look like this is a general issue when it's actually not.

[Cyberdevs]

@5T33Z0

Even if it is a misconfiguration on his part this issue is not related to Ventura per se, but there are other people with similar issue so it can be beneficial to everyone that this issue is discussed in its own topic.

 

P.S.:

on my 6700K rig the info isn't detected correctly either it show is i5 because of the SMBIOS so OC doesn't necessarily work correctly. What I mean is that revcpuname doesn't work so it can be a general issue.

[surenmunoo]

14 minutes ago, 5T33Z0 said:

@Cyberdevs Unlles the guy gets his config in order so he can boot with OC 082, he cannot expect that the CPU info is displayer correctly in macOS 13 when he is using OC 081…

 

So  instead of him fixing his config issues moving this to a dedicated thread makes it look like this is a general issue when it's actually not.

I am now booting with 0.8.2 but still the same. I will leave it as is and hope maybe it starts to work later on down the line. Thanks for the help.

[mav96]

Hey guys,

 

I have a skylake rig (i7-6700HQ) with HD530 iGPU and successfully installed macOS 13 without acceleration. The problem is when I try to spoof SKL as KBL. Changing AAPL,ig-platform-id -> <00001B59> and device-id to <16590000> results in the KP shown on the screenshot below. I discovered that this particular device-id causes the KP. If I change it to <16560000>, for example, it boots successfully but without acceleration. (I have aslo added SkylakeInjector.kext, but it does not seem to work).

 

Do you have any idea what the issue might be. Thanks for the help!

Edited June 16, 2022 by mav96

[Cyberdevs]

@mav96

You can try other id-platform-ids and device-ids and see which one works. You also need a specific version of WEG.

WhateverGreen.kext.zip

[ichelash]

15 hours ago, Cyberdevs said:

With the EFI folder I posted there's no retrying on my rigs, the boot process is just normal, I did try to update the OC and the kexts but it went straight back to retrying issue.

I can confirm that test 79 & 80 were a fail also. Going back to Monterey, Ventura wants to kill me 😂

Edited June 16, 2022 by ichelash

[Cyberdevs]

13 minutes ago, ichelash said:

I can confirm that test 79 & 80 were a fail also. Going back to Monterey, Ventura wants to kill me 😂

Last night I've updated my EFI folder and specially with updating WEG i git the same issue as you have.

The WEB i've posted couple of posts above is the one that actually works without that issue because later on they removed SKL to KBL spoofing so i guess you can give it a try and if that didn't work you can stop trying

On my rigs:

1. I only have iGPU activated

2. I don't use any other settings other then ig-platform-id and device-id

3. there are no other deviceproperties other than the iGPU. 

[ichelash]

26 minutes ago, Cyberdevs said:

Last night I've updated my EFI folder and specially with updating WEG i git the same issue as you have.

The WEB i've posted couple of posts above is the one that actually works without that issue because later on they removed SKL to KBL spoofing so i guess you can give it a try and if that didn't work you can stop trying

On my rigs:

1. I only have iGPU activated

2. I don't use any other settings other then ig-platform-id and device-id

3. there are no other deviceproperties other than the iGPU. 

On my rig, VirtualSMC plugins are causing mayhem..i think i will edit that EFI and remove those plugins...will see that in test 81.

[Guest 5T33Z0]

39 minutes ago, Cyberdevs said:

Last night I've updated my EFI folder and specially with updating WEG i git the same issue as you have.

The WEB i've posted couple of posts above is the one that actually works without that issue because later on they removed SKL to KBL spoofing so i guess you can give it a try and if that didn't work you can stop trying

On my rigs:

1. I only have iGPU activated

2. I don't use any other settings other then ig-platform-id and device-id

3. there are no other deviceproperties other than the iGPU. 

 

The Spoofing support has been removed from the master branch but there's another branch (skl-as-kbl-13) which still has it: https://github.com/acidanthera/WhateverGreen/actions/runs/2495481119

Edited June 16, 2022 by 5T33Z0

[mav96]

@Cyberdevs Many thanks for sharing the WhateverGreen.kext. This was indeed the reason and now I have graphics acceleration on HD530 (btw it works even better than on the supported Monterey without spooofing ). So the kernel panic I posted before was indeed related to the spoofing commit that they removed from WEG.

Now the only issue left for me is the HDMI, which does not work at all on Ventura for me. I guess this KBL spoof also changed something regarding the HDMI bus configuration.

[Guest 5T33Z0]

11 minutes ago, ichelash said:

On my rig, VirtualSMC plugins are causing mayhem..i think i will edit that EFI and remove those plugins...will see that in test 81.

 

If you have Intel Power Gadget installed, you can use HWMonitor SMC2 and enable to use Intel Power Gadgets Monitoring capabilities in the options. Then you can disable the virtualsmc plugins

 

[Cyberdevs]

14 minutes ago, 5T33Z0 said:

The Spoofing support has been removed from

Yes I know, thanks for the link by the way it will be useful for future references.

 

@mav96

You're welcome.

HDMI works on my rig tho, although I don't have HDMI audio which is simply because I haven't added any properties to activate it.

[mboy]

I can boot Ventura OS on my build using OpenCore package compiled on June 7 (DBG-082-2022-06-07) with AvoidRuntimeDefrag=NO.  When I use today's build of OpenCore the drive does not boot when selected in the F12 bootloader. What can cause this?