Hervé

It's probably something else in your OC config. What if you enable quirk SyncRuntimePermissions? Check your BIOS settings too (and have Legacy Options ROM disabled).

KBL frame buffer layout 0x591B0000 should work Ok but I suggest you revert to the usual layout 0x59160000 instead, i.e. replace "00001B59" by "00001659" against property AAPL,ig-platform-id key. Remember to reset NVRAM at OC Picker when you reboot after changing your config file. I also suggest your clear out all those commented out lines you've got in your config to clean things up: but you must reinstate the line that allows patching of connector con1 and probably the 2 lines that patch DVMT settings, i.e. remove the heading '#' character:

Tried not to use that SSDT-Shutdown ACPI table? What does it do/fix?

-+-+-+-+-+-+-+-+-+-+ /!\ Sonoma and later /!\ -+-+-+-+-+-+-+-+-+-+ Sonoma dropped all official support for what Apple calls legacy cards that remained supported up to Ventura; this includes cards based on the BCM4350 chipset. The above solution for Big Sur, Monterey and Ventura remains applicable in Sonoma but comes as a complement to the solution required to support legacy wireless cards in macOS 14 and which is explained here.

Further to my communication of July 2023 and Jake Lo's post above, I can confirm that Clover r5157 now supports blocking of vanilla kext IOSkywalkFamily kext which is required to support and use "legacy" wireless cards in Sonoma, i.e. cards that worked perfectly, natively or not, up to Ventura. This is basically equivalent to the kext exclusion available in OpenCore but limited to IOSkywalkFamily kext. The blocking is available as kext patch called BlockSkywalk and is integrated to latest versions of CloverConfigurator too. Process with Clover is therefore as follows: update or install Clover r5157 (versions r5155 and r5156 are supposed to provide the patch too but I found that it was not working and resulted in a freeze at startup) apply/enable Kernel & Kexts patch BlockSkywalk in your Clover config either add boot arg -amfi_get_out_of_way=1 in your config or add AMFIPass kext provided above by Jake to your kexts/14 or kexts/Other Clover folder and add boot arg -amfipassbeta boot arg in your Clover config add kexts IOSkywalk (renamed copy of older version of IOSkywakFamily kext) and IO80211FamilyLegacy kexts provided above by Jake to your kexts/14 or kexts/Other Clover folder you can keep SIP disabled with CsrActiveConfig set to 0xFEF, I found there was no need to change to, say, 0x803 install and run OCLP Patcher and apply Networking: modern wireless or Networking legacy wireless (depending on the card) root patch which should be automatically offered reboot and enjoy recovered wireless services out of your PCIe wireless card Clover_r5157.pkg.zip Clover Configurator.zip Example with the Apple BCM94360CS2 card fitted with an adapter board to the M.2 WLAN slot of my Dell Latitude E7270: or (as text): <key>BlockSkywalk</key> <true/>

Also revisited Sonoma guide to reflect on latest version of Clover that now fully supports blocking of vanilla IOSkywalkFamily kext, something mandatory to be able to support and use legacy wireless cards that were fully supported up to Ventura but officially dropped in Sonoma. See this thread for details.

Revisited all bootpacks to replace the SSDT-GPRW patched ACPI table. I added a test applicable to all ACPI devices RPxx, specifically RP05@1C (i.e. WLAN port), to fix an intermittent loss of Bluetooth on wake, requiring Bluetooth to be switched off and on at macOS level (PrefPane or Finder's bar icon) to recover services. This fix applies to combo Wifi/Bluetooth M.2 cards fitted to the WLAN slot. If (LEqual (0x69, Arg0)) { Return (Package (0x02) { 0x69, Zero }) }

You can check the type of touchscreen in IOReg or in SysInfo->Hardware->USB. Here are the details of the Atmel USB touchscreen fitted to my Skylake E7270. Since Big Sur, in which Apple dropped support for old USB hardware, the USB HID fix/patch is necessary for the touchscreen to work (touchscreen worked OOB in previous macOS versions up to Catalina). Details of the USB HID patch are readily available on the Net and I copied them in my E7270 guide here. Depending on the type of touchscreen fitted to the E7440, this may not be applicable of course.

You can of course use Clover to boot and run OS X/macOS on the D series, even the Intel GMA models. See my High Sierra (and later) guides for the D630/D830 nVidia models. Bootpacks and versions of Clover are available in the guides. Most of those packs should be re-usable on the GMA models after minor modifications (use of suitable DSDT and relevant kexts). It should be noted that the bootpacks posted in the MLPF guides are about 11 years old and deprecated having never been revisited, contrary to the packs posted in the D6xx/D8xx support sections (in the threads pinned at the top of the sections) and that were 1st made available 2 years later in 2015. You should be using those last Lion packs with MLPF. This being said, there's absolutely nothing to gain by using Lilu and its PlugIns (eg: AppleALC/Whatevergreen) on these Intel GMA D Series given the ancient hardware and the fact that they are limited to running ML at best. As for VirtualSMC, I doubt there is any benefit to gain from using the tuned FakeSMC versions that I had provided. With regards to the touchpad, you also have very little chances to find a better driver than what we had all those years ago for these old ALPS hardware. Have fun in your experiments anyway.

That would be perfectly normal since CFL framebuffer layout 0x3E9B0007 is for desktop computers and offer 3 x DP connectors but no LVDS connector for laptops: ID: 3E9B0007, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00801302 TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel UHD Graphics 630 Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x000003C7 - ConnectorDP 01050900 00040000 C7030000 02040A00 00040000 C7030000 03060800 00040000 C7030000 You would need to patch connector con0 to laptop's settings to hope for your built-in screen to work. For instance to this: 00000800 02000000 98000000 as per CFL framebuffer layout 0x3EA50009 as I illustrated above. Setting the framebuffer layout to mobile may help too.

Did you clear NVRAM at OC Picker when rebooting after changing your OC config?

Your issue has no relation to a VGA connector being present. Yes, your Kaby Lake R i7-8650u isfitted with UHD620 graphics which carries id 8086:5917. What happens when, HDMI output being connected to the laptop, you put it to sleep and wake it? Also check your BIOS settings, you may compare them to the recommended/working ones I had posted for the 7490 in the Latitude 7xxx Series section.

You inject KBL framebuffer layout 0x87C00000 which natively defines the following output ports: ID: 87C00000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000078B 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: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 You need to add the properties that patch connector con1 to HDMI: framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA Whilst HDMI output usually works natively out of a DP port, sometimes it does not or not properly and the patch is required. It is necessary for HDMI audio output anyway. I also doubt you need those, as seen in your config: AAPL,GfxYTile 01000000 DATA disable-external-gpu 01000000 DATA enable-backlight-registers-alternative-fix 01000000 DATA I would remove those or, at least, comment them out with a leading # character. If you still do not obtain HDMI output with the above changes, experiment with other KBL framebuffer layouts such as: 1) 0x59160000 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 2) 0x591B0000 ID: 591B0000, STOLEN: 38 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000130B TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 136 MB, MAX OVERALL: 137 MB (144191488 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 [2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI [3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 02040A00 00080000 87010000 03060A00 00040000 87010000 which will require to patch connector con1 from 02040A00 to 01050900 as explained here. This can be done with the following injection that also contains the patch to HDMI type: framebuffer-con1-enable 1 NUMBER framebuffer-con1-alldata 010509000008000087010000 DATA Know that you may actually need to set DVMT to 64MB in your BIOS, at least for 4K output though it certainly was not required on my Kaby Lake Refresh 7490 to get HDMI output. See our FAQ topic on the matter.

Your IOReg properly reports the Intel Bluetooth module: You inject the following kexts, in that order: IntelBTPatcher.kext IntelBluetoothFirmware.kext BlueToolFixup.kext Maybe that's what make your Intel card appear as a Broacom-based Apple device in Hackintool app, I don't know. What about SysInfo? This being said, whether the BT module of your Intel card is supported or not is something you have to check at the ITLWM repo. I don't use such cards so no idea.

Remember to always apply Clear NVRAM at OC Picker once you reboot after changing your config file...

In all future posts, please make sure to place your debug stuff (that no-one will read) in a spoiler. Ideally as code. We don't want pages ans pages of data of that nature simply dumped as regular text in posts; it's... crap!

It's probably something you incorrectly inject in your setup/config. You can always click on the magnifier icon at the left of the BT line to see what kext is loaded for that device. You may also consult the USB tab to check what's reported for Bluetooth and against which port. Finally, check your IOReg; ideally post it. But given that I see that the "FW Loaded" case is checked, I reckon you probably inject one of those Broadcom firmware kexts and/or Broadcom injector. After all, I see that the last EFI linked by @ZainAnjum does contain the following kexts: BrcmBluetoothInjector BrcmFirmwareData BrcmPatchRAM3 and a config file called config_Broadcom. Maybe you've mixed or used some of those things, we cannot know.

Generally speaking and as stated in our published rules (which I invite you to read), you should not use any distro found on the Net. There's just no need given that all OS X and macOS versions are freely made available by Apple since Mavericks (Lion and Mountain Lion having been made available for free in June 2021). As such, the references to the distro you mentioned above have been removed.

DW1395 is not natively support. Did you install the pre-patched kexts or patch the vanilla IO80211Family kext. It's required; consult our Wireless card inventory thread. As stated in the MLPF v0.3 thread I linked above, airportd deamon also needs to be replaced. It's mentioned in our Wireless card inventory thread too. MLPF takes care of that but you chose to go your own way, so... Good luck with the rest. I'm sure you'll find the existing answers.

Tuh, tuh, tuh, exactly what I was saying: you're doing it wrong. The new/separate/temp installer has to be an MLPF installer, not a vanilla one on which you run MLPF. So, just follow the guide's very detailed steps 3 to 10 of phase 2 and: from the booted vanilla/unaccelerated ML installation, run MLPF app and create an MLPF installer, either on your USB key or on a small partition of your internal disk copy the bootpack (Extra folder) to the root of that MLPF installer boot that MLPF installer with boot args/flags DSDT=/Extra/DSDT.aml arch=i386 -f that you'll type at the prompt at the bottom of the screen after you've interrupted the bootloader process at the delay bar by pressing a key once this MLPF installer has booted up, do not install anything but click on Utilities menu of the Finder's bar and select MLPostFactor once MLPF app loads, click Continue until you're offered to select a destination volume under the HDD icon, make sure to: select your original vanilla/unaccelerated ML installation (not your MLPF installer partition) select/tick ML 10.8.4 in the list of ML versions given that your initial vanilla/unaccelerated ML installation should be 10.8.5 with all security updates installed click Install MLPostFactor once it's all done, click Quit MLPostFactor reboot your (now modified) initial ML installation with boot arg/options -f arch=i386 you should then reach a fully accelerated ML desktop from which you may now finish your MLPF'ed installation (steps 11 to 13 of phase 2) You need to thoroughly follow the process and not derive from it, otherwise you see what happens... NB: you say you create an OS X installer with asr. What's that?

It has to be something you're not doing properly. Can't see why the tool would not be able to write to your USB media. It's always worked flawlessly. And there is no patching of the kernel, it's plain replacement of kernel, kexts and graphics libraries by older fat binary versions from ML Developper Preview #1. Remember that you cannot boot the initial full vanilla ML installation in 32bit mode, the kernel does not support it. I reckon this is what you're doing. You have to boot the MLPF installer, whether you've made it on a USB key/disk or on a small partition of the internal disk as the guide suggests to do. When Chameleon (or Enoch) kicks in, you have to interrupt the process by pressing a key when you see the delay bar at the bottom of the screen, then choose the MLPF partition to boot. I think this is where you go wrong; that or you've not created the MLPF partition properly.

Hello, you're not really on the right track, no... For Sonoma (not Sanoma), go directly to the Sonoma guide, which is currently the last post of the entire thread; it's based on OpenCore v0.9.5 bootloader/tool hence the attached bootpack E7470_EFI_OC_0.9.5 (which you need to unzip before use). Just skip the El Capitan-related post at the top of the thread and all the subsequent ones for other macOS versions that do not apply. You obviously did not understand that each post was a guide in itself for a specific macOS version and that each guide contained its own Clover or OpenCore bootpack. Then, as a newcomer, do consult our FAQ section where you'll find answers to some of those questions like creating a USB installer from Windows.

I've updated my MLPF guide given that it was written in April 2013, i.e. before the release of ML versions 10.8.4 and 10.8.5. It's a step-by-step guide so you can't go wrong normally.

This comes out a little late (but better late than never) but there's been a couple of recent inquiries re: MLPF for installing and running ML on old laptops with GPUs dropped by OS X 10.8. After more than 10 years and given that MLPF was deleted from its original thread at MacRumors and that the authors have long moved on, I feel it's pretty harmless to post a copy of this old tool here for those who may be interested to use it. So here we go, MLPF v0.3: https://drive.google.com/file/d/1IXQAnhMBTLhJ7cFc0IXILmfMNu3cgwBi/view?usp=sharing The tool never got updated for ML 10.8.5 but it's only a cosmetic matter and it's totally safe to apply it as it is on 10.8.5. Upon completion, update file /System/Library/CoreServices/SystemVersion.plist to adjust reported ML version from 10.8.4 to 10.8.5. My recommendation for Hackintosh is to install ML 10.8.5 + all updates in initial (and slow) vanilla unaccelerated mode before applying MLPF for 10.8.4 on the installation. This will include reverting airportd to pre-10.8.4 version as newer one caused issues with certain wireless networks, as stated in the footer note #1 here.