Hervé

I get the impression you don't fully understand half of what you're doing/writing. 1) "BIOS patched to max 2048MB" ? Very much doubt you'd need to set DVMT to that much. I don't believe macOS framebuffers will make any use of that. 2) '#' character is used to comment something out in a bootloader's config and boolean values can be expressed as decimal NUMBER or 32bit hexadecimal DATA types (0 is 0 and 1 is 1, no matter the size of the data unit you opt for). You also need to understand that some of those injected properties are purely cosmetic (eg: labels, IO locations, slot names, etc.). 3) Your linked IOReg bears no relevance to the screenshots and OC EFI you posted (it shows Monterey kernel, MBP13,3 SMBIOS and SKL iGPU settings). To top it all, the Dortania display documentation you refer to is incorrect; most likely due to copy/paste errors. For instance, there's no such thing as device id 1b59006 for Intel HD 630 iGPU; trouble is that it is totally misleading and the Dortania folks are not (re)known for acknowledging and acting on requests for documentation adjustments. Looks like you're getting all confused (who wouldn't?). You need to do much further reading on the matter of properties injection and graphics settings. Or maybe it's time to give it a rest... I can suggest these links to begin with: https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units https://github.com/acidanthera/WhateverGreen https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md https://osxlatitude.com/forums/topic/8238-supportedunsupported-gpus-graphics-cards https://osxlatitude.com/forums/topic/17804-what-are-dvmt-stolenmem-fbmem-cursormem-why-do-we-patch-these-for-broadwell-and-later/ https://osxlatitude.com/forums/topic/17292-macos-ventura-130-beta1-early-feedback-and-findings https://osxlatitude.com/forums/topic/17587-how-to-spoof-hd520-to-hd620-in-monterey-in-preparation-for-ventura

Alternative links to https://xxxx can be macappstores://xxxx. Example for Ventura: macappstores://apps.apple.com/app/macos-ventura/id1638787999?mt=12

You need to understand that -no_compat_check boot arg applies to SMBIOS/Mac models dropped by the targeted macOS version. The parameter's sole purpose is to allow installing and/or booting a given macOS version on an officially unsupported platform; it's of no (direct) use for graphics acceleration. As such, it's entirely useless with SMBIOS MBP14,x, these Mac models remaining officially and fully supported under macOS Ventura. You would only use it with SMBIOS MBP13,x. Until now, unlike Haswell and Broadwell counterparts, Skylake systems have been able to obtain full graphics acceleration by using/faking KBL graphics with KBL SMBIOS and without any need for OCLP patching. Granted graphics acceleration has been difficult to obtain on HD 530 iGPU, not to say impossible on some platforms. You may consult the threads I had posted for Ventura beta (now in the Archive), my current E7270 guide or the initial Ventura beta thread at InsanelyMac. This being said, feel free to experiment with OCLP if you wish. The Precision 5510 EFI you've referred to clearly makes no use of stolenmem/fbmem patches/injections because DVMT already has the required value (64MB appears to be the default value according to your screenshot on p2). Do take good note that, if DVMT is set to 32MB, it is absolutely necessary to patch it for 4K output. Patching stolenmem and fbmem framebuffer properties won't do. That is clearly mentioned in Jake's FAQ on DVMT BIOS patching to which you had previously referred. In your case, you may experiment patching DVMT to higher values than 64MB. It also looks like you need to learn about the stolenmem/fbmem patches so you have some catching-up to do; it's been covered in all angles since 2015 when gurus such as Firewolf troubleshooted the issue of KP on Broadwell platforms due to DVMT vs. BDW framebuffer native settings. As for the RAM, it really is off-topic and unrelated to Hackintosh but it wouldn't be the 1st time Dell specs state something that's not entirely true on the matter (eg: good old Latitude D630/D830). How do you go about fitting 64GB of RAM? The answer is very likely to be so simple and obvious that it would leave you red-faced... Real question is whether you would need 64GB or not. But, again, off-topic, so let's close the subject.

SMBIOS for Hackintosh is basically a set of faked Mac computers hardware info (model, board id, serial number, etc, etc.) you inject to install and run OS X/macOS. There are various tools/apps to create/inject/update this if it's old/deprecated or if it needs to be changed to support a given macOS version (like after a new version drops older Mac models). OCC, CC, CLI tool (see Dortania documentation), etc. provide built-in SMBIOS generation facilities.

It probably will. Common sense dictates you experiment using a bootable USB key... As simple (and obvious) as that.

Experiment by yourself, you'll find out soon enough. The parameter usually applies to non-Metal GPUs and HD5500, albeit dropped in Ventura, is Metal compatible/capable though possibly not with Metal3.

You forgot the most important piece of information: details of your combo wifi/BT card.

We have a few guides for Sandy Bridge/HD3000 Dell Latitude models; look these up (eg: my Latitude E6220 guide). HD3000 graphics is last officially supported in macOS High Sierra. Thereafter, support can be provided with specific patches but limited to OpenGL mode only. HD3000 has no support for Metal and was already buggy on Hackintosh past OS X Yosemite 10.10 (over time: horizontal lines across the screen, pixelisation). Please note that this kind of platform is kinda obsolete for Hackintosh purposes given Apple's long abandonment for such 12yr old hardware. SSD can't be NVME since that the laptop is built on Intel QS67 chipset; so it can only be a good old SATA or mSATA model. Dell did not sold laptops with NVME-capable SSDs until Broadwell/Skylake generations.

As Jake said: leave SIP disabled (whether partially or fully), do not re-enable it (i.e. DO NOT set csr-active-config to 0). SMBIOS is irrelevant here, it's the OCLP patch for unsupported Haswell iGPU that requires SIP to be kept disabled.

Whilst these old Sandy Bridge E6x20 made great Hackintosh laptops in their days, they're unfortunately obsolete for recent versions of macOS given that Apple has long dropped support for HD3000 and nVidia Fermi graphics. Former was last officially supported in macOS High Sierra 10.13, latter in OS X El Capitan 10.11. Of course there are patches and various tools that'll bring back OpenGL-only support for HD3000 in Mojave and later but, since, Big Sur, such support is pretty poor and HD3000 was already buggy on Hackintosh laptops when it was still officially supported. You may refer to my old E6220 guide which goes up to Catalina (I subsequently sold the laptop). No such workarounds for the nVidia Fermi dGPU, it's a dead-end. If you insist on trying to run Monterey: make sure you install it without any config for HD3000, i.e. in VESA mode only. if you have a model with nVidia graphics, make sure you enable Optimus in BIOS (or laptop will only use nVidia dGPU) and disable the nVidia dGPU through a dedicated SSDT (available on the Net and Hackintosh forums through a Google search). Of course, Monterey will then run like crap due to lack of graphics acceleration. thereafter, install OCLP tool and apply only the graphics patches for HD3000. Make sure to install and boot Monterey with SMBIOS MacBookPro8,1 and the -no_compat_check boot arg. afaik, E6x20 laptops do not boot macOS USB installers when BIOS is set in UEFI mode, they only do so in Legacy mode. Once macOS is installed, you may change to UEFI mode and adjust your bootloader setup accordingly; it'll then work Ok. or you may simply opt to install say, High Sierra or Mojave, then upgrade to Monterey and apply the OCLP patch. That may be the easiest way to proceed. Good luck. Remember to post your E6520 specs in signature.

There's no official support for SKL HD5x0 graphics in Ventura. See our posted documentation in the hardware info section. You must use SMBIOS MBP14,1 + latest version of Lilu + Whatevergreen + inject the correct KBL graphics parameters. You may also consult my E7270 Ventura guide for pointers. See the Whatevergreen Github page + User Manual.

No, you did not, there's absolutely no SSDT that disables the dGPU and that's mandatory.

This is an E6530 with nVidia NVS 5200M which is totally unsupported beyond OS X El capiton 10.11. You have to enable Optimus in BIOS, then disable the nVidia dGPU through ACPI patching (DSDT or SSDT) to run solely on HD4000 iGPU. HD4000 is last officially supported in Catalina but remained natively supported in Big Sur with a little trick on the SMBIOS and boot arg side. It's unsupported with special patches in Monterey and, I guess, Ventura. Your OC config is largely unsuitable to old E6x30 Ivy Bridge laptops. You're trying to apply an config meant for Broadwell or later platforms and that's incorrect. For instance: the graphics properties you inject for HD4000 iGPU in your OC config are incorrect: no need to patch fbmem or stolenmem the way it's done for Broadwell iGPUs and later; all you need to patch is reduce fbmem from 16MB to 8Mb to avoid graphics corruption on screen. you've specified the target Capri framebuffer layout incorrectly; use little endianness, not big endianness. no such thing as I2C keyboard or TouchPad on on the E6x30; you need to use good old kexts for ALPS TouchPads. SMBIOS MBP11,1 is for Haswell/HD4x00 platforms, not for Ivy Bridge/HD4000 ones What version of macOS are you trying to install and run? Please try to, at least, provide the bare minimum required to obtain support. Do consult the various Latitude E6x30 guides available in our Guides section as well as the Hardware info section where you'll find information about supported platforms, supported macOS versions, etc.

Disk mode (RAID/AHCI/IDE) is something you set in BIOS. Do consult your product's documentation on Dell support web site.

Remove those manually, then reboot.

Weird, but the card certainly appears to be properly detected and registered when you inject the compatibility with pci14e4,43a0 statement. It's just that wireless is turned off. No way to turn it back on through the Wireless PrefPane?

That card is based on a chipset natively supported by macOS; as such, you should not require any add-on kexts to get it working.

Looks like you've retained settings for a DW1560 card in your configuration... You may want to review that. DW1830's PCI is 14e4,43ba remains natively supported by AirportBrcmNIC kext so I was not expecting you to require declaring compatibility with 14e4,43a0.

Not sure you need these boot args: agdpmod=vit9696 igfxagdc=0 Also try and add the ACPI patch that renames GFX0 to IGPU through Whatevergreen kext should normally take care of that.

@Senia Suazo Yes, those graphics settings are Ok but, if you've made changes to your OC config, remember to reset NVRAM from the OC Picker at next reboot.

Even though a Skylake iGPU is listed with 1536MB, you don't appear to have graphics acceleration in place (Finder's bar + Dock should be translucent, not greyed out). For Monterey, make sure you use the following settings on your Skylake/HD 520 laptop: MacBookPro13,1 SMBIOS SKL framebuffer layout 0x19160000 iGPU id 0x1916 of your i7-6600u is fully and natively supported so no need to inject it as a property (does no harm though of course). Nothing more to setup for graphics is video memory is set to 64MB in BIOS as stated by Jake. You may only need to patch the connector used for HDMI output if you need/want HDMI audio. Don't hesitate to look here for pointers (my Latitude E7270 is also fitted with i7-6600u CPU + HD 520 graphics) and post a zipped copy of your EFI folder.

http://www.linux-usb.org/usb.ids 05ac:820a is an Apple Bluetooth keyboard so clearly not the built-in one.

Yes, sorry I indeed made a confusion thinking you had the Intel card in that WWAN slot when it's clearly a half-size mini-PCIe card you had in the WLAN slot. E7270's WWAN slot is M.2 Key B so unsuitable for Key A/E Wifi/BT cards. What I meant was that, in the case of my E7270, there is no instant wake issue due to replacement GPRW method not caring for values provided in the GPRW (0x69, 0x04) call programmed under the WLAN ACPI device. It'd be interesting to see what call is made in your DSDT under the RP0x.PXSX device used by the WLAN card/slot.

Afaik, Sandy Bridge Latitude E6x20 laptops do not support installation of OS X/macOS from a USB key/disk in UEFI BIOS mode, only legacy mode. Thereafter, once OS X/macOS has been installed, you may indeed switch to UEFI BIOS mode and, provided you've installed your bootloader accordingly, OS X/macOS will boot and run Ok from internal disk in UEFI mode; I've detailed this in my E6220 guide. Taking that into account, you'll probably have to use Clover rather than Opencore, at least to boot in legacy mode. Is it an E6520 with HD3000 iGPU only or is it also fitted with the Fermi-based nVidia NVS 4200M dGPU? Former is supported OOB up to macOS High Sierra 10.13 (with patches in later macOS versions though poorly supported in Big Sur and later), latter up to Sierra only (no support in later versions). Don't hesitate to read the existing E6x20 threads and guides available on our forum. An E6520 with nVidia graphics will require that you enable Optimus in BIOS (to be able to run on HD3000 iGPU), then disable the dGPU via SSDT to prevent it from draining your battery unnecessarily. If Optimus is disabled, only the dGPU is available. Please note that, in old OS X El Capitan 10.11 and all subsequent macOS versions, HD3000 gets buggy over time and you'll experience graphics artefacts, like horizontal lines across the screen or pixelisation. There are no fixes for this, only reboots will do. Note that, even though they run Win10/Win11 just fine, those E6x20 laptops are to be considered obsolete for Hackintosh purposes. NB: Don't use distros, we don't support those here.

Interesting... No such additional patches required on my E7270 which is fitted with a BCM94360CS2. The card also attached to RP05.PXSX and _PRW method does call on GPRW with (0x69,0x4D) arguments; same applies to SD card reader attached to RP11.PXSX. Add-on patched table SSDT-GPRW.aml does not care for Arg0 being set to 0x69, yet sleep works perfectly well. On the PCIe side, it's kinda weird that wake was working when you had an Intel card in that slot but not when the BCM94360CS2 was installed. Hence why I assumed it would be the USB-based Bluetooth module that caused instant wake. Well done on your fix.