Hervé

The .dsl file is source code whilst the .aml file is the compiled table, i.e. the one you need. From memory, the tool may put a .dsl on the desktop (or offers you to open/view it?) but you'll find the compiled table under the Library/ssdtPRGen folder of your home directory. This subfolder is available after you execute the script. Re: audio, it looks like you're looking at it the wrong and complicated way. AppleALC fully supports IDT 92HD93 if you inject correct layout id 12. If you go for VoodooHDA, you need to disable AppleHDA kext through the AppleHDADisabler kext that usually accompanies VoodooHDA. Do not delete AppleHDA from /S/L/E, that really is a bad idea. Keep that system folder full vanilla and untouched. Look for my Toshiba R50 guide, it contains a pack that includes those VoodooHDA+AppleHDADisabler kexts. Can't see why CC would not mount your EFI partition but you sure can mount it manually with a simple Terminal command: sudo diskutil mount EFI It really is as simple as that.

Careful because the pack I posted for the E6230 does not fully apply to your E6430 which has Optimus technology. In your case, you need to make sure Optimus is enabled in BIOS settings so that HD4000 iGPU is enabled and you have to use an ACPI patch to disable the unsupported nVidia dGPU (this will avoid unnecessary battery drain by the dGPU). Re: CPU power management, don't use the SSDT from my E6230 guide, it's not for your CPU. You can generate your own CPU power management through Pike R Alpha's script tool; it's still available on the Net: https://github.com/Piker-Alpha/ssdtPRGen.sh Just follow the indications. If you require them, the specs of your i7-3520M are available here but they should already be in the script's CPU database.

Re: DW1510, it's perfectly normal given that Catalina dropped support for such cards. All the necessary information was published in the relevant wireless card inventory available in our Technical Info section. Re: audio, you probably have a duff config setting re: layout id. Please post a zipped copy the the following EFI contents you use: Clover config file ACPI folder of injected patched tables kexts folder Which version of Clover do you use?

? You're mistaken; I do not own any HP laptop...

I don't know the difference between your 820 G3 model and the 840 G3 but the bootpack you use is for the 840 G3. Maybe the SSDTs do not entirely apply to the 820 model. I've noticed that the device properties in Jake Lo's bootpack add a 4th video output port. This is possibly unnecessary or irrelevant to the 820 G3. You may also want to use KBL framebuffer 0x56160000 and device id 0x5916 rather then the values of the bootpack.

What make and model of SSD do you have in that laptop?

Your Big Sur EFI should be able to boot Ventura without issues. Sonoma probably too. Just make sure to update your kexts and bootloader to latest versions.

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.