Hervé

Thanks for posting the specs; a very old laptop indeed. You should be using SMBIOS of MacBookPro7,1 rather than MBP6,2 which was a 1st gen Arrandale platform. Also note that OpenCore does not properly care for CPU power management of pre-SandyBridge systems. As such you may want to consider switching to Clover (r5150 or later for instance). Re: wake issue, did you disable hibernation? It's enabled by default and certainly needed to be disabled on most platforms in the past and still today. You may lookup our dedicated thread on the matter in our FAQ section. Re: DSDT, don't hesitate to list the various patches you applied/implemented; this is not something we'll be able to guess. One final comment about your OC config and the graphics properties you inject, I'm not sure you got that right. The IO location you specified looks erroneous to me; but it sure does not prevent you to gain graphics acceleration according to your IOReg. For your info, your nVidia dGPU is PCI0.PVGA.GFX0 so the correct device location is "PciRoot (0x0)/Pci(0x1, 0x0)/Pci(0x0,0x0)". You should therefore adjust your config to remove what I believe to be a typo of some sort in your config:

Can you please post the full specifications of this computer? Is it a desktop or a laptop?

According to kronokernel, patch for BCM43224 still works in Monterey (or, at least, it did in the summer of 2021 and Monterey beta days): https://forums.macrumors.com/threads/macos-12-monterey-on-unsupported-macs-thread.2299557/post-30034783 https://forums.macrumors.com/threads/macos-12-monterey-on-unsupported-macs-thread.2299557/post-30038647 I've not looked at what the OCLP solution does in that respect but, assuming it breaks the seal and somehow copies the necessary kext in /L/E or /S/L/E for caching, then the on-the-fly patch (in the bootloader's config file) would work. You'd have to target MacBookAir5,2 or MacBook7,1 for OCLP to install the necessary kext and patch macOS accordingly.

Then I guess the old patched kext has had its time... Try OCLP as alternative.

It was mentioned on p1 but macOS OTA updates require that your booted system complies with a set of pre-requisites: SMBIOS of a fully supported Mac model (unsupported models will not attract updates) no -no_compat_check boot arg no Apple_Internal SIP flag enabled (5th bit of csr_active_config parameter). See our SIP-related FAQ topic for details These apply to systems using Clover. For systems using OpenCore, I vaguely remember that there's another pre-requisite around SecureBootModel or something of that essence; you'll have to look that up. You may therefore need to have 2 x configs at hand to be able to obtain and install Ventura updates on your unsupported platform: your current config and a specific "supported model" config (eg: MBP14,1 SMBIOS, no -no_compat_check, SIP=0xFEF) that you'll use exclusively for updates. Given that you're running Ventura on a Haswell Latitude E5440 with HD4400 graphics, you used OCLP patching to apply root patching and gain graphics acceleration. Make sure the option you selected/unselected in the tool do not prevent OTA updates. Check out the tool's documentation. On a real Mac, default parameter for the targeted system do support OTA updates, but that's real Mac...

https://dortania.github.io/Getting-Started-With-ACPI/Universal/smbus.html Consider it entirely optional; if, in your own particular case, it breaks sleep just get rid of it. 'never used it on any of my Hacks.

So, what you actually do is binary patch the AirPortBrcm4360 PlugIn of that IO802Catalina kext, right? What patch do you apply? For what target SMBIOS model?

Where are you with your current config ? Are you sure you have the best possible settings in place?

You'd have to explain in details the various steps you followed to try and recover support for your DW1520 card in Monterey but, as stated here several years ago, Big Sur dropped support for Broadcom BCM43224 chipset so follow the suggested/recommended procedure to try and regain support for your card.

You're not using a suitable SMBIOS for your laptop. For some strange reason, you've opted for MB11,1, i.e. a Haswell platform that does not carry Ivy Bridge (Capri) HD4000 graphics nor supports CPU PM for Ivy Bridge CPUs. MBP11,1 being a Haswell platform with Haswell (Azul) graphics, there's just not a chance in the world that OCLP will apply HD4000 patching for such a target profile. Please follow the recommendations you're given and read the OCLP documentation to try and understand what it does (bearing in mind it's made for real Mac computers, not for Hackintosh). Until you do so, you're wasting your time and ours.

Can't really help much without proper troubleshooting info. You asked if the method I described in my E6230 guide would work on the E6530 and I said "try it", not "grab everything meant for the E6230 and apply it". You said you had Big Sur running on that E6530 before; well, take that setup and adjust it for Ventura by adding the kexts and config changes I described in my E6230 guide: AppleIntelCPUPowerManagementClient kext (of Monterey origin) pre-patched AppleIntelCPUPowerManagement kext (of Monterey origin) if you use those (something entirely optional), updated FakePCIID + FakePCIID_XHCIMux kexts, the old versions causing KP CryptexFixup kext AMFIExemption kext -crypt_force_avx and amfi_get_out_of_my_way=1 boot args SMBIOS MBP14,1 of course, it's advisable to update Lilu & its PlugIns to latest versions so that you run versions that support Ventura (but really should go without saying) I don't even know if you're using Clover or OpenCore but assuming you use the former, follow the method described in my E6230 guide and have a dedicated MBP14,1 config file to start with. Also make sure your nVidia dGPU remains fully disabled. Once you run OCLP, do target the SMBIOS of your original bootloader's config, whether it be MBP9,x or MBP10,x. I've no idea on the matter and you've not be forthcoming with any specific info on anything. All in all, just try and apply good common sense. Once you've completed the OCLP root patching, you simply reboot and run with the same config file you used for Big Sur. Do not go for Ventura 13.3 beta, stick to mainstream releases. Maybe you should have experimented with Monterey to begin with, at least for the OCLP patching if nothing else..

My E6230 pack contains patched DSDT, SSDTs or kexts that apply to the E6230; they do not apply to your E6530 especially as it's a model with NVIDIA graphics and totally different CPU. It should be obvious not to re-use the E6230 pack "as is" on your E6530 and you should re-use the ACPI patched tables and most kexts (eg: for USB ports) you were previously using on your E6530.

So... you installed Ventura Ok, albeit without graphics acceleration, right ? you applied the OCLP root patches with the settings detailed in my E6230 guide ? on reboot, blank screen when graphics are supposed to initialize ? You'll have to be more specific and, say, post your (default) config as I suspect you got something incorrect there. Possibly a mismatch between the SMBIOS in your config and the target SMBIOS (MBP10,2) selected in the OCLP settings. If your config is not set with the same SMBIOS as selected in the patcher, I don't think it'll work... It should be obvious but maybe you missed that essential point.

We still get the question regularly so a FAQ topic seems appropriate... Injecting a laptop built-in screen's EDID information in OS X/macOS is sometimes required when the freshly installed OS does not display the desktop properly on screen due to incorrect detection of the screen's hardware properties/capabilities (frequencies, size, etc.). The following describes one easy way to collect a screen's EDID info through an off-the-shelf Windows app but they're are several other methods too (see this somehow complicated method in this deprecated thread for instance): I can recommend Monitor Asset Manager. I've used it several times in the past. Very simple to use and works without failure. You'll get the EDID info at the very bottom of the application's main window where it is displayed as a long string of comma separated hexadecimal values. This is what you need to collect and edit to remove all commas and spaces. You may then inject the resulting raw long string of hexadecimal characters as device property in the iGPU settings of your bootloader's config: AAPL00,override-no-connect <EDID's hexadecimal string> DATA See the WEG User Manual for reference

Ok, you misunderstood a few things: You do not patch a framebuffer's connector to set an external screen in mirror mode; that's done from the booted OS, either from the Display Preference Panel or with keyboard shortcuts ([COMMAND-low brightness] combination). Make sure you remove those incorrect patches in your bootloader config. The only patch you ought to have is to set con1 to HDMI type (00080000) in order to gain HDMI audio output. Framebuffer connectors effectively define physical video outputs. Grabbing your screen EDID from IOReg to then inject it in your bootloader's config is utterly useless; you effectively inject what the system natively detects. See this FAQ topic for details of the procedure to follow.

Try it!

HDMI audio requires connector to be patched to HDMI type (00080000); in your case (and as is usually the case): connector con1. No need to patch con0 to LVDS/eDP, it's its native setting. ID: 59160000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000B0B TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00080000 87010000 I also see that you inject your screen's EDID. I guess it made no difference. Which tool did you grab it with?

So, built-in screen still garbled with HDMI connected and running in mirror mode? Looking at your IOReg, I can see that the built-in screen is fully detected on connector con0 ("AppleBacklightDisplay") with LVDS/eDP type (02000000). Strangely enough, I see that you patched connector con1 (used for external HDMI screen) to type LVDS/eDP too. What's the reason for that?

I'm surprised by your iGPU settings/properties injection: No need to inject any fbmem or stolenmem patches for Haswell graphics/HD4600. Get rid of those. And cursormem patch is entirely optional, use it only if you experience cursor corruption. Azul framebuffer #12 0x0a260006 defines the following video memory and ports settings: ID: 0A260006, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes) Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP [2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 HDMI output usually attaches to connector con1, not con2. So that's what you'd usually set to HDMI type. Pipe needs to be changed to 12 too for both connectors. So you'd therefore inject the following adjusted settings: framebuffer-con1-enable 1 NUMBER framebuffer-con1-pipe 12000000 DATA framebuffer-con1-type 00080000 DATA framebuffer-con2-enable 1 NUMBER framebuffer-con2-pipe 12000000 DATA See here.

Take and post a new zipped IOReg extract.

Good to know and glad you sorted it out. NB: your Google drive link is not opened to public access.

macOS Ventura dropped support for pre-Kaby Lake platforms and that includes dropped CPU Power Management for pre-Haswell legacy CPUs, i.e. Wolfdale/Penryn (Core2Duo/Core2Quad and associated Xeon) processors Nehalem/Westmere (Lynnfield, Clarkdale/Arrandale) processors Sandy Bridge processors Ivy Bridge processors Adding kexts to S/L/E or /L/E for caching being so difficult in Ventura (and since Big Sur), CPU power management for the above pre-Haswell legacy CPUs can only easily be achieved by injecting the missing AICPUPMClient + AICPUPM kexts through the bootloader (Clover or OpenCore). The kexts from macOS Monterey can be re-used to that effect. The trouble then is that, for Sandy Bridge and Ivy Bridge CPUs, no on-the-fly AICPUPM patch can be applied to the cache since the kexts do no exist in cache. As an exception, Ivy Bridge CPUs may be able to benefit from XCPM but that does not necessarily work on all platforms. Luckily for us, the good old (pre-Clover/pre-OpenCore) solution of manually patching the AppleIntelCPUPowerManagment kext can be revived and re-used to satisfy our needs on Sandy Bridge and Ivy Bridge platforms. The patched AICPUPM kext can then be injected in Ventura to provide full CPU power management without incurring the good old dreaded Kernel Panic. The method has not changed since its inception all those years ago and the patch details remain courtesy of Pimentel and his tools as published at IM. In order to ensure the tool is not lost, I attach a copy of it, I trust the author won't mind. AICPMPatch.zip Usage of the patching script is as follows: cd <script path>/AICPMPatch to check on the patching requirements (i.e. list of wrmsr instances in the kext's binary): sudo perl AICPMPatch.pl <kext path>/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement to patch the kext's binary: sudo perl AICPMPatch.pl <kext path>/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement --patch The kexts are of Monterey 12.6.x origin and carry version v222.0. Vanilla AppleIntelCPUPowerManagementClient and patched AppleIntelCPUPowerManagement kexts for Sandy/Ivy Bridge CPUs: AppleIntelCPUPowerManagementClient.kext.zip Patched_AppleIntelCPUPowerManagement.kext.zip Place the unzipped kexts in the bootloader's target kexts folder and that's it: full CPU power management in Ventura for pre-Haswell CPUs. Caution though because I'm not certain this fully works after wake.

Injecting EDID info will do no harm. This being said, you should get rid of all those patched SSDT tables you do not use; this will avoid all possible confusion. Also check that the PNLF table is correct in order to ensure it's not the cause of your issue. You could experiment with the PNLF table included in the Ventura pack of my E7270 guide. On the kexts side, I've noticed you inject Lilu v1.6.4, WhateverGreen v1.6.4 and AppleALC v1.7.9. For WhateverGreen and AppleALC, these were only published today afaik and Lilu is only at v1.6.3, all that at Acidanthera's Github repo. I'd recommend you grab your kexts from there: https://github.com/acidanthera.

Make sure to reset NVRAM at OC Picker after you make changes to your config/setup.

Your posted IOReg and Opencore EFI indeed have incorrect graphics settings for Ventura. In addition, I don't believe you'd need all those igfx boot args for any macOS version, especially if they come as duplicates of your iGPU injected properties (eg: force-online vs. igfxonln=1). I'm pretty sure all you may require is the force-online injected property or the igfxonln=1 boot arg. See the Whatevergreen User Manual for references. Also note that, afaik, Latitude E5x70 are limited to HDMI1.4, so no HDMI2.0 capability. Given that Ventura dropped support for Skylake platforms and therefore SKL graphics (no SKL drivers provided), one of the easiest trick is to spoof Kaby Lake (KBL) settings and modify your setup as follows: AAPL,ig-platform-id 0x59160000 or 0x591b0000 (these work for SKL HD520) device-id 0x5916 (this works for SKL HD520) use Whatevergreen kext v1.6.1 minimum (and no need of specific boot args) SMBIOS MBP14,1 during installation after which you may revert to SMBIOS MBP13,1 with -no_compat_check boot arg Those settings are visible in the Ventura OC EFI posted at the place you linked in post #1, even if it were for the beta version. I can't see why these would not work for you if you have the exact same laptop but see our existing guidance/information on the matter of Skylake graphics in Ventura. For instance: https://osxlatitude.com/forums/topic/8238-supportedunsupported-gpus-graphics-cards/#comment-117952 https://osxlatitude.com/forums/topic/17292-macos-ventura-130-beta1-early-feedback-and-findings https://osxlatitude.com/forums/topic/17336-macos-ventura-130-beta3-is-out/ https://osxlatitude.com/forums/topic/15648-dell-latitude-e7270-with-i7-6600u-hd520-and-1920x1080-touchscreen-high-sierramojavecatalinabig-surmontereyventura/?do=findComment&comment=116192 I suggest you go back to basics: 1) injected properties AAPL,ig-platform-id 00001659 DATA // KBL mobile framebuffer device-id 16590000 DATA // KBL iGPU id framebuffer-patch-enable 1 NUMBER // Enables framebuffer patching framebuffer-fbmem 00009000 DATA // Sets fbmem to 9MB framebuffer-stolenmem 00003001 DATA // Sets stolenmem to 19MB framebuffer-con1-enable 1 NUMBER // Enables connector con1 patching framebuffer-con1-type 00080000 DATA // Sets connector con1 to HDMI type hda-gfx onboard-1 STRING // Built-in digital audio capability 2) boot args for graphics (may come in addition to other unrelated boot args like audio settings or boot mode) -igfxonln=1 // forces all displays on-line 3) SMBIOS MBP14,1 for installation, then MBP13,1 with -no_compat_check boot arg if you want to revert to SKL profile.