Qonfused / ASUS-ZenBook-Duo-14-UX481-Hackintosh

OpenCore configuration for the ASUS ZenBook Duo 14" (UX481FA/FL)
https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh
BSD 3-Clause "New" or "Revised" License
31 stars 1 forks source link

Reduce boot time by removing redundant firmware in AirportItlwm and IntelBluetoothFirmware #33

Closed shiecldk closed 1 year ago

shiecldk commented 1 year ago

Hi @Qonfused, please see the updated sections 3.4 and 3.5 on UX582 guide to reduce the boot time. I successfully implemented these tweaks on UX582; however, there are some issues with compiling IntelBTPatcher.kext (IntelBTPatcher.kext/IntelBTPatcher/MacOS is empty and fw_name is missing after the implementation).

I have these files loaded with OpenCore 0.8.8: BlueToolFixup.kext (only for after macOS Monterey) IntelBluetoothInjector.kext (only for before macOS Monterey) IntelBluetoothFirmware.kext IntelBTPatcher.kext

Screen Shot 2023-01-26 at 11 25 58 PM
Qonfused commented 1 year ago

@shiecldk Just to give an idea, how much of a reduction in boot time does this create? I believe the Info.plist for these kexts have a list of PCI ids for matching to firmware, though editing these won't update kext cache without a kext version bump.

Qonfused commented 1 year ago

IntelBluetoothFirmware doesn't expose a fw_name property in IO registry; only AirportItlwm does. Here's a bash script for cloning and building the pruned AirportItlwm kexts:

prune-airportitlwm.sh ```sh #!/usr/bin/env bash BUILD_DIR=~/itlwm-build mkdir $BUILD_DIR && cd $BUILD_DIR # Clone itlwm repo git clone https://github.com/OpenIntelWireless/itlwm.git . \ --filter=blob:none \ --quiet &>/dev/null # Clone MacKernelSDK to /itlwm folder git clone https://github.com/acidanthera/MacKernelSDK.git \ --filter=blob:none \ --quiet &>/dev/null # Remove redundant firmware fw=$(ioreg -rxn AirportItlwm -d1 | grep IOModel | cut -d'"' -f 4) echo "Found firmware match \"$fw\"."; echo "Pruning redundant firmware entries." find itlwm/firmware/ -type f ! -name $fw -delete # Build kexts echo $'\nBuilding AirportItlwm kexts...' while read -r os_version; do target="AirportItlwm-$(sed 's/\\//g' <<< $os_version)" # Build kext target echo "--> Building $target.kext..." xcodebuild clean build \ -project itlwm.xcodeproj \ -target "$target" \ -configuration Release \ -sdk macosx \ -quiet > /dev/null # Copy kext to project root kext=$(find build/Release/*/*.kext -maxdepth 0 -type d) cp -a "$kext" "$target.kext" &>/dev/null if [[ -n $kext ]]; then cp -a "$kext" "$target.kext" echo " Done." else echo " Failed." fi done <<< $'Catalina\nBig\ Sur\nMonterey\nVentura' # Cleanup build folder find . ! -name 'AirportItlwm-*.kext' -exec rm -fr {} \; &>/dev/null echo $'\nBuild finished.';echo "You can find kexts located in $BUILD_DIR." ```

For IntelBluetoothFirmware, you can prune firmware entries the same way as with the AirportItlwm script in the IntelBluetoothFirmware/fw/ directory. Additionally, IntelBluetoothFirmware and IntelBluetoothInjector can have redundant firmware entries removed from their IOKitPersonalities (in the kext Info.plist).

The boot-time improvements between either (and with IntelBTPatcher) appear quite marginal, despite improvements to the Bluetooth firmware bundle size while operating on USB 2. There's a good explainer for why this is here: https://github.com/OpenIntelWireless/itlwm/issues/353#issuecomment-709922418

I can help develop/support a toolchain for building these kexts if desired, though at the moment I do not plan on incorporating this into the project. Not only does this afford very a marginal improvement, but it costs significant runner time if automated as part of CI on github actions.

shiecldk commented 1 month ago

@Qonfused I updated my guide for this in here. Check the "3.4 Build and minimize Intel WiFi Driver" section: https://www.tonymacx86.com/threads/guide-asus-zenbook-pro-duo-15-oled-ux582-opencore.315661/post-2274273

shiecldk commented 1 month ago

I can help develop/support a toolchain for building these kexts if desired, though at the moment I do not plan on incorporating this into the project. Not only does this afford very a marginal improvement, but it costs significant runner time if automated as part of CI on github actions.

This sounds good. I can also help working on this too.