diff --git a/.markdownlintignore b/.markdownlintignore index 0b3616b7..715ef1be 100644 --- a/.markdownlintignore +++ b/.markdownlintignore @@ -6,4 +6,5 @@ /icons/ /images/ /styles/ -/.vuepress/ +.travis.yml +/.vuepress/ \ No newline at end of file diff --git a/README.md b/README.md index fee8eeb6..3efa69c8 100644 --- a/README.md +++ b/README.md @@ -63,7 +63,7 @@ This guide is split into 6 parts: * [Fixing Resolution and Verbose](./cosmetic/verbose.md) * Helps fix the resolution of OpenCore, and allows you to get that sweet Apple logo while booting! -### Multiboot +### Multiboot * [Setting up Bootstrap.efi](./multiboot/bootstrap.md) * Ensures Windows doesn't remove OpenCore from our system. @@ -77,4 +77,4 @@ This guide is split into 6 parts: * [Fixing CFG Lock](./misc/msr-lock.md) * Allows use to remove some kernel patches for better stability * [Emulated NVRAM](./misc/nvram.md) - * For users who have broken NVRAm, or need to test it. + * For users who have broken NVRAM, or need to test it. diff --git a/cosmetic/verbose.md b/cosmetic/verbose.md index f425bc41..0ef1af0a 100644 --- a/cosmetic/verbose.md +++ b/cosmetic/verbose.md @@ -1,11 +1,7 @@ # Fixing Resolution and Verbose - - Wanting a more clean booting experience with macOS without all that verbose text while booting? Well you need a couple things: - - ## macOS Decluttering **`Misc -> Debug`** diff --git a/dictionary/dictionary.txt b/dictionary/dictionary.txt new file mode 100644 index 00000000..59a386d0 --- /dev/null +++ b/dictionary/dictionary.txt @@ -0,0 +1,1335 @@ +(15|16)h +(No)?TouchID +.aml +.chunklist +.dmg +.dsl +.kext +.plist +.txt +00010D13 +01050A00 +01xx0900 +02000A00 +02xx0A00 +0x0 +0x00-0x01 +0x00-0x7F +0x00-0xFF +0x0006E6 +0x0006F2 +0x010676 +0x0106A2 +0x0106E0 +0x0206A0 +0x0206C0 +0x0306A0 +0x0306C0 +0x0306D4 +0x0306E0 +0x0406E3 +0x0506e3 +0x06 +0x0706E5 +0x0806E0 +0x0806E9 +0x0806EA +0x0906E0 +0x0906E9 +0x0906EA +0x0F41 +0x1 +0x16 +0x1C +0x1b +0x2 +0x3E9B0007 +0x4 +0x58-0x59 +0x591B0000 +0x60000000 +0x80-0x81 +0x80-0xBF +0x80-0xFF +0x8000000000000001 +0x81 +0xB2100000 +0xB3180000 +0xC0-0xFF +0xE2 +0xF +0xFE000000 +0xFEC00000 +0xFED00000 +0xFEE00000 +0xFF000000 +100MBe +100MHz +1024x768 +120Hz +1300Mhz +144Hz +14F1 +14e4 +16XX +18G103 +18G95 +19H +19h +1Revenger1 +20XX +2200S +2B-i +2B-iii +32MB +3700X +390X +3990X +3D +43a0 +4G +4k +50F4 +5700XT +64MB +64bit +6970M +6XX +7920x +7980xe +7F-80 +7XX +7zip +970EvoPlus +A320 +A520 +AAPL +ACPI-path +ACPIBatteryManager +AE-9PE +AGDC +AGPM +AHCI +AHCIPortInjector +AIDA64 +AIOs +ALC +ALC1220 +ALC3601 +ALZA +ANS1 +ANS2 +APIC +APTIO +APUs +ARPT +AS43 +ASR +ASRock +ASUS +ASentientBot +ATA +ATAPortInjector +ATH9KFixup +AVX +AWAC +AZAL +Above4G +Above4GDecoding +Acidanthera +Acidanthera's +Acpi +AcpiSamples +AirportAtheros40 +AirportBrcmFixup +AirportItlwm +AlGrey +Aleksander +Aleksander's +AlpsT4USB +AmazonBasics +Andrey's +Andrey1970AppleLife +ApECID +ApfsDriverLoader +Apianti +Apianti's +AppStore +AppeALC's +AppleACPICPU +AppleAHCIPort +AppleALC +AppleALC's +AppleGVA +AppleHDA +AppleHDAController +AppleHDAInput +AppleHV +AppleHV's +AppleID +AppleImage4 +AppleIntelCPUPM +AppleIntelCPUPowerManagement +AppleIntelCPUPowerManagment +AppleIntelFramebuffer@1 +AppleIntelI210Ethernet +AppleIntelPchSeriesAHCI +AppleIntelPowerManagement +AppleIntele1000e +AppleLPC +AppleLife +AppleMCEReporter +AppleMCEReporterDisabler +AppleRTC +AppleSMBus +AppleSupport +AppleSupportPkg +AppleTV +AppleUSB20XHCIPort +AppleUSB30XHCIPort +AppleUSBLegacyRoot +Aptio +AptioMemoryFix +Architected +Arg +Arrandale +Arrendale +AsMedia +AsRock +AssetCache +Asus +Asus's +Ath3kBT +Ath3kBTInjector +AthBluetoothFirmware +Atheros +AtherosE2200Ethernet +Atmel +Attribution-NonCommercial-ShareAlike +AudioDxe +Auth +Azul +B0D3 +B360 +B450 +B460 +B550 +B75 +B8 +BCM43224 +BCM4331 +BCM5722 +BCM5722D +BCM94331 +BCM94331CD +BCM94352Z +BCM94360 +BGRT +BOOTICE +BT +Backlight +BaseSystem +BeyondCompare +Big +BitLocker +Blackscreen +BlueScreen +BootCamp +BootInstall +Bootable +Bootcamp +BrcmBluetoothInjector +BrcmFirmwareData +BrcmPatchRAM[0-3]? +Bridge-E5 +Broadcom +Broadwell +Broadwell-E +BudID +Bugtracker +BusID +BusIDs +C3 +C7030000 +CAVS +CFBundleIdentifier +CFG +CFG-Lock +CLKT +CMD +CMOS +CONFIGURATORS +CP00 +CPU0 +CPUFriend +CPUFriendDataProvider +CPUFriendFriend +CPUID +CPUID's +CPUs +CR0 +CSM +CSTS=0xffffffff +Capitan +Carcraftz +Celeron +Celerons +Chipset +Chipsets +Clarkdale +Clarksfield +CloverV2 +Cmd +Codec +Codecs +CoffeeLake +Config +Configurator +ConsoleControl +ConsoleGOP +Core2 +CorpNewt +CorpNewt's +Cpu +Cpu0Ist +CpuPm +CpuTscSync +Crestline +Crohn +Crohn's +CsrDecode +CtlnaAHCIPort +Ctrl +Cupertino +CustomSMBIOSMode +DAC +DACs +DBG +DC7900 +DCB +DMAR +DMGs +DRM +DSDT +DSDTs +DSMOS +DVI +DVMT +DVMT-prealloc +DaVinci +DarkWake +Decluttering +Dev +DeviceManager +DevicePath +DeviceProperty +DhinakG +DiskArbitrationFixup +DiskUtility +DisplayPort +DisplayPorts +DmgLoading +Dont +Dortania +Dortania's +DriveDroid +DuetPkg +E2 +E2500 +EB +EC0 +ECDV +ECID +ECs +EDID +EDK +EDKII +EFI +EFI's +EFI32 +EFI64 +EH01 +EH02 +EHC1 +EHC2 +EHCI +ELAN1200 +ELANs +EPP +ETH0 +EUSB +EVGA +EVO +EfiBoot +EfiPkg +EfiReservedMemoryType +El +El Capitan +EmuVariableUEFI +En0 +EnableWriteUnprotected +Enclos +EndRandomSeed +Endian +Endianness +Esc +EveryMac +Evo +ExitBootServices +Explainer +ExtendBTFeatureFlags +F10 +F12 +FAT32 +FPU +FSB +FTE1001 +FW +FX +Facetime +Factor-Aut +Factor-Auth +FairPlay +FakeSMC +FakeSMC-32 +FakeSMC-32's +FakeSMC3_with_plugins +Fenvi +Fewt's +Fewtarius +FileVault +FireWire +Firmwares +FixHPET +FixShutdown-USB-SSDT +Fn +ForceKextsToLoad +Framebuffer +FredWst +FwRuntimeServices +G6 +GA-X299-UD4 +GBE1 +GCN +GFX +GFX0 +GLAN +GMA +GMA950 +GPE +GPIO +GPRW +GPT +GPT. +GPUs +GSync +GT1 +GT2 +GTX +GUID +GenSMBIOS +GenSMBIOS's +GibMacOS +GitBook +Github +Goldfish64 +Goldfish64's +GraphicsEnabler +GraphicsEnabler=Yes +Greenwhich +GuC +Gui +H310 +H370 +H61 +HD +HDA +HDAS +HDAU +HDCP +HDDs +HDEF +HDMI-hotplug +HD[0-9]* +HEC1 +HECI +HEDT +HFS +HM[0-9]{2} +HPET +HPs +HS01 +HS02 +HSxx +HWPEnable +Hackintool +Hackintosh +Hackintosher +Hackintoshes +Hackintoshing +Handoff +Haswell +Haswell-E +Hfs +HfsPlus +HfsPlus's +HfsPlus32 +HfsPlusLegacy +HiDPI +HiiDatabase +HoRNDIS +Hx6x +I211 +I211-AT +I2C +I7, +IA32 +IDER +IGP +IGPEnabler +IGPEnabler=Yes +IGPU +IM +IMEI +IMEI's +IO80211 +IO80211Family +IOClass +IOHDACodecDevice +IOHIDFamily +IOIIIO +IOKit +IONVMe +IONameMatch +IONetworkingFamily +IOPCIFamily +IOPMrootDomain's +IOPathMatch +IOProviderClass +IOProviderMergeProperties +IOReg +IORegistryExplorer +IOService +IOUSBHostFamily +IOreg +IPIC +IQSV +IRQ +IRQs +IceLake +Icelake +Icelake's +InjectAMD +InjectAti +InjectIntel +InjectNvidia +InsanelyMac +Inspiron +InstallMacOSX +Insyde +IntelBluetoothFirmware +IntelMausi +IntelMausiEthernet +IntelSnowMausi +InyextcionES +InyextcionES' +IvyBridge +JDK +JRE +JS's +JackFix +Journaled +KASLR +KBL-R +KDK +KVM +KVMs +Kaby +KabyLake +Kabylake +KernelAndKextPatches +KernelCollections +KernelPM +Kernelspace +Kext +Kext's +KextBeast +Kexts +Keychain +Khronokernel +L305 +L8200A +LANC +LAPIC +LD:OFS +LFM +LPC +LPC0 +LPCB +LPM +LVDS +LegacyBoot +LegacyCommpage +Lenovo +Lexa +Lilu +Lilu-independent +LoadImage +LoadVBIOS +LucyRTL8125Ethernet +Lynnfield +MADT +MBR +MBR-based +MBs +MEI +MEID +MKext +MMIO +MSI +MSR +MSR_FLEX_RATIO +MT2 +MacBook +MacBook7 +MacBook8 +MacBook9 +MacBookAir[0-9]+ +MacBookPro13 +MacBookPro14 +MacBookPro[0-9]+ +MacInfoPkg +MacMini +MacMini6 +MacMini7 +MacOS +MacPro5 +MacPro6 +MacPro7 +MacProMemoryNotificationDisabler +MacRecovery's +MacRumors +MacSerial +MaciASL +Mackie +Mackie's +Macmini6 +Macmini7 +Macmini8 +MakeInstall +MasterBootRecord +MediaKit +Mellanox +Memfast +MemoryFix +Merom +MinMultiplier +Misconfigured +MonitorControl +MountEFI +MultiBeast +Multiboot +Multitouch +NIC +NICs +NOOPT +NPM +NTFS +NUC +NUCs +NVCAP +NVCAP-Calculator +NVCAP-settings +NVMe +NVMeFix +NVRAM +Navi +Nehalem +Niresh +NoOne +NodeJS +Notiflux +NullCPUPowerManagement +NullCPUPowerManagment +Nvidia +Nvidia's +OC +OC's +OC/ +OCABC +OCB +OCConfigCompare +OCSCAN_ALLOW_DEVICE +OCSCAN_ALLOW_FS +OC_SCAN_ALLOW_DEVICE_NVME +OC_SCAN_ALLOW_DEVICE_PCI +OC_SCAN_ALLOW_DEVICE_SASE +OC_SCAN_ALLOW_DEVICE_SASEX +OC_SCAN_ALLOW_DEVICE_SATA +OC_SCAN_ALLOW_DEVICE_SCSI +OC_SCAN_ALLOW_DEVICE_US +OC_SCAN_ALLOW_DEVICE_USB +OC_SCAN_ALLOW_FS_APFS +OC_SCAN_DEVICE_LOCK +OC_SCAN_FILE_SYSTEM_LOCK +OEM +OEM's +OEMs +OHCI +OPENCORE +OSI +OSX +OSX's +OcAppleKernelLib +OcQuirks +OpenCanopy +OpenCore +OpenCore's +OpenCorePkg +OpenCorePkg's +OpenRuntime +OpenShell +OpenUsbKbDxe +Optane +Optimus +OsxAptioFixDrvX +Osy's +OtherOS +Overclocks +P50 +P530 +PBR +PC00 +PCI +PCIO +PCIRoot +PCIRootUID +PCIRootUID=Value +PCIe +PEG0 +PEGP +PGEC +PLIST +PListPath +PM981 +PM991 +PMHeart +PNLF +PO22 +POT3 +PR00 +PRs +PS2 +PTCP +PTS +PTXH +PXSX +PXSX-1 +PXSX-2 +PXTX +PartitionDxe +PartitionDxe32 +PartitionDxeLegacy +Patch1 +Pathname +Pci +PciRoot +PciRoot's +Penryn +Penyrn +Plist +Plists +PowerNap +PowerProperties +Pre-Allocated +Pre-existing +Preboot +Prebuilt +Prelinked +ProperTree +ProperTree's +Psystar +Q8300 +QE/CI +QEMU +Qlogic +Quicklook +R5/R7 +R9 +RC6 +RDRAND +README +RHUB +ROMs +RSA +RSA-2048 +RST +RTC +RTCMemoryFixup +RTVariables +R[5|7] +Radeon +Radeon-Denit-SSDT +Ramus +Realtek +Realtek's +RealtekRTL8100 +RealtekRTL8111 +RecoveryImage +ReddestDream's +RehabMan's +Rehabman +Rehabman's +Reinstalls +Rename-SSDT +Repo +RtcMemoryFixup +Ryzen +S0 +S3 +S4 +S5 +SAS +SAT0 +SAT1 +SATA +SATA-Unsupported +SATA-unsupported +SGX +SHA-1 +SHCI +SL01 +SMBIOSes +SMBUS +SMBus +SMBus-based +SMC +SMCAMDProcessor +SMCBatteryManager +SMM +SS01 +SS02 +SSD +SSDT +SSDT-.* +SSDTTime +SSDTTime's +SSDTs +SSDs +SSE3 +SSE4 +SSSE3 +SSxx +STAS +Safemode +SandyBridge +SecureBootModel +SetVirtualAddresses +Shannee +SharedSupport +Shiki +ShowPackageContents +SidecarEnabler +Siri +Skylake +Skylake-SP +Skylake-X +SmUUID +SmallTree +SmallTreeIntel82576 +Speccy +Stompy +StopSign-fixv +StopSign-fixv5 +Strix +Subreddit +Sur +Sur's +Synaptics +Syrah +SystemAudioVolume +SystemParameters +SystemPreferences +SystemProfilerMemoryFixup +T2 +T2's +TDP +TIMR +TMR +TR4 +TRX40 +TRx40 +TSC +TSCAdjustReset +Takedowns +TechPowerUp +Technopat +Telemetrap +TetherMe +TextEdit +TextMate +TextMode +TgtBridge +ThinkPad +Thinkpad +ThreadRipper +Threadripper +ThunderboltPkg +ThunderboltReset +TimeMachine +Touchbase +Trackpad +Trackpads +TransMac +Typora +UEFI-based +UEFIExtrac +UEFIExtract +UEFITool +UHCI +UHD +UI +UID +UPRW +USBE +USBInjectAll +USBMap's +USBR +USBX +USBmap +USBmap's +USR1 +USR2 +USRx +UUID +UUIDs +Ubuntu +UniBeast +Universal-IFR-Extractor +Unmanaged +UsbConnector +UsbInjectAll +UselessBanana +Userspace +V1 +VBIOS +VDADecoderChecker +VDI +VESA +VIAO +VIRTIO +VM +VMDK +VMWare +VMs +VMware +VPN +VRAM +VSCode +VerifyMsrE2 +VirtualBox +VirtualSMC +VirtualSMC's +Vit +Vit's +VmAssetCacheEnable +VoiceOver +VoodooGPIO +VoodooHDA +VoodooHDA-FAT +VoodooI2C +VoodooI2CHID +VoodooI2CServices +VoodooInput +VoodooPS2 +VoodooPS2's +VoodooPS2Controller +VoodooRMI +VoodooSMBus +VoodooTSCSync +VoodooTsc +VuePress +WHFR +WHQL +WIFI +WIP +WLAN +WOL +WakeOnLAN +WakeOnUSB +Welp +Westmere +WhateverGreen +WhateverGreen's +Wifi +X299 +X299-E +X3100 +X399 +X520 +X540 +X570 +X64 +X79 +X86 +X86-based +X86PlatformPlugin +X86PlatformShim +X99 +XCPM +XHC +XHC0 +XHC1 +XHC2 +XHCI +XHCI-unsupported +XHCX +XLNCUSBFIX +XLNCUSBFix +XNU +XNU's +XOSI +XPoint +XXX-XXXXX +Xcode +Xeon +Xeons +XhciUnsupported +Xserve +Yonah +Z170 +Z270 +Z370 +Z390 +Z490 +Z67 +Z68 +Z77 +Z87 +Z87-Pro +Z97 +ZPTS +[0-9]+GB +[0-9]+MB +[0-9]+XXX +\.efi +acidanthera +acpica +actionLink +actionText +al3xtjames +alcid +algrey +architected +args +arse +auth +automagically +autopoweroff +ba10b5d +backports +base64 +bitmask +blackscreen +boot-arg +boot-args +boot-args. +bootable +bootcamp +bootloader +bootloaders +bootups +borked +breakless +bugtracker +build-repo +busID +busId +busid +busid=00 +busids +cacheless +cd +cdfon +checksums +chipset +chipset's +chipsets +chunklist +codec +codecs +con0 +con1 +con2 +conX +config +config's +configs +configurator +configurators +createinstallmedia +cryptographically +csr-active-config +csrstat +customizations +dGPU +dGPUs +darkwake +debug=0x100 +decompile +decrypt +dev +devirt +diskXsY +diskutil +distro +distro's +distros +dmg +dmg's +dortania +dreamwhite's +eDP +eMMC +en0 +endian +entires +erroring +ethernet +executables +explainer +fakeID +fassl's +filesystem +firmwares +framebuffer +framebuffer-con0-alldata +framebuffer-con0-enable +framebuffer-con1-alldata +framebuffer-con1-enable +framebuffer-con2-alldata +framebuffer-con2-busid +framebuffer-con2-enable +framebuffer-con2-index +framebuffers +fs +gIOLockState +gdisk +gfxutil +gibMacOS +gibMacOS's +gitbook +gitbook-cli +google-fu +grey +hackintosh +hackintoshes +hackintoshing +hacky +handoff +hardcoded +heroImage +heroText +holyfield +hotplug +i210 +i211 +i218 +i219 +i225 +i225-V +i225LM +i3 +i3-3110M +i3-4150 +i3-4330 +i7 +i7-10700K +i7-9700T +i9 +i9-10850K +i9-10900K +i9-10910 +i9-9900K +iASL +iCloud +iDrakus +iGPU +iGPU's +iGPU-less +iGPU-only +iGPU. +iGPUs +iMac +iMac10 +iMac11 +iMac12 +iMac13 +iMac14 +iMac15 +iMac16 +iMac17 +iMac18 +iMac19 +iMac20 +iMac6 +iMacPro1 +iMacs +iMessage +iServices +iStat +iasl +ie +ie\. +ig-platform-id +ig-platform-id's +igfxcdc +igfxfw +img +ix-3xxx +jailbroken +kDarkWakeFlagAudioNotSuppressed +kDarkWakeFlagHIDTickleLate +keepsyms=1 +kernelcache +kernelspace +kext +kext's +kext(\.)? +kextd +kexts +keypress +laggy +lapic +lappie +licensor +linter +lsblk +macOS +macOS's +macOS(\.)? +macOS-limited +macOS-only +macOS86 +maciASL +macrecovery +macserial +markdownlint-cli +max_cpus_from_firmware +midi1996 +mini-explainer +msi +multiboot +multibooting +natively +nms42 +non-Fenvi +non-UEFI +non-latin +npci +nvda_drv=1 +ok +one-key-cpufriend +osxaptiofix2drv.efi +overclocks +passthrough +patcher +pathing +pathing. +pci +pentiums +personalization +plist +plist-only +plists +powernap +pre- +pre-2017 +pre-Skylake +pre-built +pre-builts +pre-compiled +pre-existing +pre-hex +pre-made +preboot +prebuilt +precompiled +prelinked +prelinkedkernel +prelinker +probs +r10 +r4 +rEFInd +raw2vmdk +re-architecting +rebranded +reenumerate +reimplements +renderer +repo +repo's +repos +rom-revision +savvamitrofanov +shiki +shikigva +slav +slavs +slowgeek +smcread +snapshotting +snb-platform-id +socketed +soooooo +spacebar +spellchecker-cli +ssdtPRGen +ssdtPRgen +ssdtPRgen's +stolenmem +subreddit +sudo +sysctl +takedowns +tbh +threadripper +totalsize +touchpad +touchpads +trackpad +trackpads +trackpoints +trashOS +ubuntu +unallocated +unbootable +uncore +unenroll +unmount +unoptimized +untrusted +userspace +v1 +v3006 +v5210 +vSMC +ver +verifications +vit9696 +vit9696's +vmdk +vmx +vmxf +wakeup +webserver +wifi +x10 +x64 +x86 +x86-based +xcpm +Как +завести +сервисы \ No newline at end of file diff --git a/dictionary/opencorekeys.txt b/dictionary/opencorekeys.txt new file mode 100644 index 00000000..8dd12e1c --- /dev/null +++ b/dictionary/opencorekeys.txt @@ -0,0 +1,202 @@ +4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14 +4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 +7C436110-AB2A-4BBB-A880-FE41995C9F82 +ACPI +APFS +ARTFrequency +AdviseWindows +AllowNvramReset +AllowSetDefault +AppleAudio +AppleBootPolicy +AppleCpuPmCfgLock +AppleDebug +AppleDebugLog +AppleEvent +AppleImageConversion +AppleKeyMap +ApplePanic +AppleRtcRam +AppleSmcIo +AppleUserInterfaceTheme +AppleXcpmCfgLock +AppleXcpmExtraMsrs +AppleXcpmForceBoost +AudioCodec +AudioDevice +AudioOut +AudioSupport +AuthRestart +AvoidRuntimeDefrag +BID +BIOSReleaseDate +BIOSVendor +BIOSVersion +BlessOverride +BoardAssetTag +BoardLocationInChassis +BoardManufacturer +BoardProduct +BoardRevision +BoardSerialNumber +BoardType +BoardVersion +Boot1f32 +BootProtect +Booter +BundlePath +ChassisAssetTag +ChassisManufacturer +ChassisSerialNumber +ChassisType +ChassisVersion +ClearScreenOnModeSwitch +ConnectDrivers +ConsoleAttributes +ConsoleMode +Cpuid1Data +Cpuid1Mask +CustomSMBIOSGuid +DataHub +DevicePathsSupported +DeviceProperties +DevirtualiseMmio +DirectGopCacheMode +DirectGopRendering +DisableIoMapper +DisableRtcChecksum +DisableSingleUser +DisableVariableWrite +DisableWatchDog +DiscardHibernateMap +DisplayDelay +DisplayLevel +DummyPowerManagement +EnableJumpstart +EnableSafeModeSlide +EnableWriteUnprotector +ExecutablePath +ExistBootServicesDelay +ExposeSensitiveData +ExternalDiskIcons +FSBFrequency +FadtEnableReset +FindMask +FirmwareFeatures +FirmwareFeaturesMask +FirmwareVolume +ForceExitBootServices +HaltLevel +HashServices +HibernateMode +HideAuxiliary +HideSelf +HideVerbose +IgnoreInvalidFlexRatio +IgnoreTextInGraphics +IncreasePciBarSize +InitialTSC +JumpstartHotPlug +JumpstartHotplug +KeyFiltering +KeyForgetThreshold +KeyMergeThreshold +KeySupport +KeySupportMode +KeySwap +LapicKernelPanic +LegacyEnable +LegacyOverwrite +LegacySchema +Lifewire +MLB +MaxKernel +MemoryFormFactor +MinDate +MinKernel +MinVersion +MinimumVolume +MmioWhitelist +NormalizeHeaders +OSInfo +OemTableId +PickerAttributes +PickerAudioAssist +PickerMode +PlatformFeature +PlatformInfo +PlatformNVRAM +PlatformName +PlayChime +PlistPath +PointerSupport +PointerSupportMode +PollAppleHotKeys +PowerTimeoutKernelPanic +ProcessorType +ProtectMemoryRegions +ProtectSecureBoot +ProtectUefiServices +ProtocolOverrides +ProvideConsoleGop +ProvideCustomSlide +Quirks +ROM +RebaseRegions +RebuildAppleMemoryMap +ReconnectOnResChange +ReleaseUsbOwnership +ReplaceMask +ReplaceTabWithSpace +RequestBootVarFallback +RequestBootVarRouting +ReservedMemory +ResetHwSig +ResetLogoStatus +Resolution +SMBIOS +SanitiseClearScreen +ScanPolicy +SerialInit +SetupVirtualMap +ShowPicker +SignalAppleOS +SmcBranch +SmcPlatform +SmcRevision +SmcVersion +SpoofVendor +StartupPowerEvents +SyncRuntimePermissions +SysReport +SystemFamily +SystemManufacturer +SystemMemoryStatus +SystemProductName +SystemSKUNumber +SystemSerialNumber +SystemUUID +SystemVersion +TableLength +TableSignature +TakeoffDelay +Target +TextRenderer +ThirdPartyDrives +TimerResolution +UEFI +UIScale +UnblockFsConnect +UnicodeCollation +UpdateDataHub +UpdateNVRAM +UpdateSMBIOS +UpdateSMBIOSMode +Vault +VolumeAmplifier +WriteFlash +XhciPortLimit +boot0 +bootia32 +bootx64 +snapshotted \ No newline at end of file diff --git a/gpu-patching/README.md b/gpu-patching/README.md index 30ddbf67..5788b6b4 100644 --- a/gpu-patching/README.md +++ b/gpu-patching/README.md @@ -1,16 +1,15 @@ # GPU Patching in macOS - This section is dedicated to GPU patching, currently we support the following: ## Intel iGPU Patching -* [Modern iGPU patching](./intel-patching/README.md) +* [Modern iGPU patching](./Intel-patching/README.md) * Sandy and newer is supported -* [Legacy iGPU patching](./legacy-intel/README.md) +* [Legacy iGPU patching](./legacy-Intel/README.md) * GMA series is supported ## Nvidia Patching * [Legacy Nvidia Patching](./nvidia-patching/README.md) - * Tesla through Fermi series are supported \ No newline at end of file + * Tesla through Fermi series are supported diff --git a/gpu-patching/intel-patching/README.md b/gpu-patching/intel-patching/README.md index 898f25a5..83846a62 100644 --- a/gpu-patching/intel-patching/README.md +++ b/gpu-patching/intel-patching/README.md @@ -40,24 +40,25 @@ By default in Macs with iGPUs, there are a few configurations: The reason why this is important is due to the amount of iGPU configurations Apple supports in the iGPU kexts, specifically known as framebuffer personalities. These personalities determine many things including number of displays, types of displays allowed, location of these displays, minimum VRAM required, etc, and so we need to either hope one of these profiles matches our hardware or try to patch it. To specify a framebuffer personality in macOS, we use the DeviceProperties section in OpenCore to add an entry called `AAPL,ig-platform-id` + * Note: on Sandy Bridge, we use `AAPL,snb-platform-id` instead The format of this entry is hexadecimal, and is byte swapped from the actual value. A full list of these values can be found in WhateverGreen's manual: [FAQ.IntelHD.en.md](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md) -For this example, lets try to find a framebuffer compatible for a desktop HD 4600 iGPU. We'll first want to scroll down the manual until we hit the [Intel HD Graphics 4200-5200 (Haswell processors)](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#intel-hd-graphics-4200-5200-haswell-processors) entry. Here we're given a list of all supported framebuffers in macOS, including the hardware type(ie. Mobile vs desktop), VRAM requirements, etc. If you scroll to the bottom of this list, you're also given some recommended options: +For this example, lets try to find a framebuffer compatible for a desktop HD 4600 iGPU. We'll first want to scroll down the manual until we hit the [Intel HD Graphics 4200-5200 (Haswell processors)](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#Intel-hd-graphics-4200-5200-haswell-processors) entry. Here we're given a list of all supported framebuffers in macOS, including the hardware type(ie. Mobile vs desktop), VRAM requirements, etc. If you scroll to the bottom of this list, you're also given some recommended options: ``` Desktop : - 0x0D220003 (default) + 0x0D220003 (default) Laptop : - 0x0A160000 (default) - 0x0A260005 (recommended) - 0x0A260006 (recommended) + 0x0A160000 (default) + 0x0A260005 (recommended) + 0x0A260006 (recommended) Empty Framebuffer : - 0x04120004 (default) + 0x04120004 (default) ``` -The first 2 entires are pretty obvious, however the last one(Empty Framebuffer) refers to systems where they have a dGPU already setup but still have an iGPU enabled in the background to handle tasks such as hardware accelerated decoding in tasks it excels at. +The first 2 entries are pretty obvious, however the last one(Empty Framebuffer) refers to systems where they have a dGPU already setup but still have an iGPU enabled in the background to handle tasks such as hardware accelerated decoding in tasks it excels at. Now since we're using the desktop HD 4600, we'll grab the corresponding framebuffer profile: `0x0D220003` @@ -88,7 +89,7 @@ From here, lets open up our config.plist and head to DeviceProperties -> Add. No To determine whether you need a new `device-id` injected, you'll want to compare [WhateverGreen's list of supported IDs](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md) to what you have. -For this example, lets take a look at the i3-4150 with an HD 4400 iGPU. Using [Intel's ARK page](https://ark.intel.com/content/www/us/en/ark/products/77486/intel-core-i3-4150-processor-3m-cache-3-50-ghz.html), we can see the following: +For this example, lets take a look at the i3-4150 with an HD 4400 iGPU. Using [Intel's ARK page](https://ark.Intel.com/content/www/us/en/ark/products/77486/Intel-core-i3-4150-processor-3m-cache-3-50-ghz.html), we can see the following: ``` Device ID = 0x41E @@ -96,18 +97,17 @@ Device ID = 0x41E Now that we have our actual Device ID, lets compare it to [WhateverGreen's list](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md): - ``` Native supported DevIDs: - 0x0d26 - 0x0a26 - 0x0a2e - 0x0d22 - 0x0412 + 0x0d26 + 0x0a26 + 0x0a2e + 0x0d22 + 0x0412 ``` -Unfortunately the ID is not present in macOS, so we'll need to find a similar iGPU to ours and use their Device ID. The HD 4600 found in the [i3-4330](https://ark.intel.com/content/www/us/en/ark/products/77769/intel-core-i3-4330-processor-4m-cache-3-50-ghz.html) is a very close match, so we'll use its Device ID: +Unfortunately the ID is not present in macOS, so we'll need to find a similar iGPU to ours and use their Device ID. The HD 4600 found in the [i3-4330](https://ark.Intel.com/content/www/us/en/ark/products/77769/Intel-core-i3-4330-processor-4m-cache-3-50-ghz.html) is a very close match, so we'll use its Device ID: ``` Device ID = 0x412 @@ -144,7 +144,6 @@ Now that we've gone over the basics of setting up an iGPU, lets getting into som * `DeviceProperties -> Add -> PciRoot(0x0)/Pci(0x2,0x0)` has been correctly setup * Refer to your specific generation in the [config.plist section](https://dortania.github.io/OpenCore-Install-Guide/) - Now head forth into your framebuffer patching journey!: * [Patching the VRAM requirement of macOS](./vram.md) @@ -152,4 +151,4 @@ Now head forth into your framebuffer patching journey!: * [Patching the display type](./connector.md) * Relevant for systems where you may get distorted colors on certain monitors * [Patching the display connections](./busid.md) - * Relevant for systems where certain display outputs do not work \ No newline at end of file + * Relevant for systems where certain display outputs do not work diff --git a/gpu-patching/intel-patching/busid.md b/gpu-patching/intel-patching/busid.md index b1800209..f7c7ed41 100644 --- a/gpu-patching/intel-patching/busid.md +++ b/gpu-patching/intel-patching/busid.md @@ -28,7 +28,6 @@ Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 03060800 00040000 C7030000 ``` - Now lets parse it down to the BudID information, as this is what we will be patching: ``` @@ -40,7 +39,6 @@ Now lets parse it down to the BudID information, as this is what we will be patc 03060800 00040000 C7030000 ``` - Here we see that this framebuffer personality has 3 Bus IDs listed, lets try to break them down to be a bit more understandable. Lets take entry 1: ``` @@ -123,7 +121,6 @@ framebuffer-con2-enable | Data | 01000000 framebuffer-con2-alldata | Data | 01050A00 00080000 87010000 ``` - #### Replace sections of the entry To replace sections of the entry, we'll first want to locate our entry and ensure it's enumerated correctly. This is because Apple's has entries starting at 0 and progresses through that: @@ -142,6 +139,7 @@ Next lets make the patch, we know that port needs to be patched to 01 and BusID * framebuffer-con2-busid = 05 And finally, we get these patches: + ``` framebuffer-patch-enable | Data | 01000000 framebuffer-con2-enable | Data | 01000000 @@ -166,13 +164,12 @@ For this example, we'll use the 0x3E9B0007 framebuffer again. To start, we'll be trying to go through entry 1's BusIDs in hope we find working value. +##### 1. Here plug in your HDMI display -1. Here plug in your HDMI display +##### 2. Set Port 1 to the HDMI connector type -2. Set Port 1 to the HDMI connector type: +* 01xx0900 **00080000** C7030000 - * 01xx0900 **00080000** C7030000 - ::: details Supported Connector Types Common connector types supported in macOS @@ -192,17 +189,17 @@ Reminder that VGA on Skylake and newer are actually DisplayPort internally, so u ::: -3. Disable ports 2 and 3 with busid=00: +##### 3. Disable ports 2 and 3 with busid=00 - * 02**00**0A00 00040000 C7030000 - * 03**00**0800 00040000 C7030000 +* 02**00**0A00 00040000 C7030000 +* 03**00**0800 00040000 C7030000 -4. Walk through busids for Port 1 if the previous didn't work. The maximum busid on most platforms generally 0x06 +##### 4. Walk through busids for Port 1 if the previous didn't work. The maximum busid on most platforms generally 0x06 - * 01**01**0900 00080000 C7030000 - * 01**02**0900 00080000 C7030000 - * 01**03**0900 00080000 C7030000 - * etc +* 01**01**0900 00080000 C7030000 +* 01**02**0900 00080000 C7030000 +* 01**03**0900 00080000 C7030000 +* etc If you still get no output, set port 1's busid to 00 and start going through busids for port 2 and so on @@ -214,18 +211,18 @@ If you still get no output, set port 1's busid to 00 and start going through bus You'll now want to add the following patches to `DeviceProperteies -> Add -> PciRoot(0x0)/Pci(0x2,0x0)`: - ``` framebuffer-patch-enable | Data | 01000000 -framebuffer-con0-enable | Data | 01000000 -framebuffer-con1-enable | Data | 01000000 -framebuffer-con2-enable | Data | 01000000 -framebuffer-con0-alldata | Data | port 1 (ie. 01010900 00080000 C7030000) +framebuffer-con0-enable | Data | 01000000 +framebuffer-con1-enable | Data | 01000000 +framebuffer-con2-enable | Data | 01000000 +framebuffer-con0-alldata | Data | port 1 (ie. 01010900 00080000 C7030000) framebuffer-con1-alldata | Data | port 2 (ie. 02000A00 00040000 C7030000) -framebuffer-con2-alldata | Data | port 3 (ie. 03000800 00040000 C7030000) +framebuffer-con2-alldata | Data | port 3 (ie. 03000800 00040000 C7030000) ``` Note that: + * port 1 would be labeled as con0 * port 1's BusID is set to 01 * port 2 and 3's BusID are set to 00, disabling them @@ -235,5 +232,3 @@ When done, you should get something similar: ![](../../images/gpu-patching/path-done.png) And as mentioned before, if this combo doesn't work, increment port 1's BusID and if that doesn't work disable port 1's busID and try port 2 and so forth. - - diff --git a/gpu-patching/intel-patching/connector.md b/gpu-patching/intel-patching/connector.md index d816cc7c..d8018ccb 100644 --- a/gpu-patching/intel-patching/connector.md +++ b/gpu-patching/intel-patching/connector.md @@ -6,17 +6,15 @@ This section is mainly relevant for users who either get black screen or incorre For this example, lets take a UHD 630 system with an HDMI display attached. The machine has already been correctly setup however there's a Pink/Purple tint on the HDMI display. -Grab a copy of [IOReg](https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-302.zip) and serach for the `iGPU` entry: +Grab a copy of [IOReg](https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-302.zip) and search for the `iGPU` entry: ![](../../images/gpu-patching/igpu-entry.png) - Next, clear out the entry so we can see the children of the iGPU device: ![](../../images/gpu-patching/igpu-children.png) - -As we can see in the above screenshot, we have a few framebuffer entires listed. These are all display personalities present in the framebuffer personality, and all have their own settings. +As we can see in the above screenshot, we have a few framebuffer entries listed. These are all display personalities present in the framebuffer personality, and all have their own settings. For us, we care about the entries that have a `display0` child, as this is what's driving a physical display. In this example, we can see it's `AppleIntelFramebuffer@1`. When we select it, you'll see in the left pane it has the property `connector-type` with the value `<00 04 00 00>`. And when we look to the below list: @@ -30,12 +28,12 @@ For us, we care about the entries that have a `display0` child, as this is what' <04 00 00 00> DVI (Dual Link) <00 02 00 00> DVI (Single Link) ``` + * Note: VGA on Skylake and newer are DisplayPorts internally and so are supported by macOS. Please use the DisplayPort connector for these systems. Looking closer, we see that the HDMI port was actually listed as a DisplayPort. This is where WhateverGreen's patching mechanisms come into play. - -Since the incorrect port was located at AppleIntelFramebuffer@1, this is port 1. Next we'll to enable WhateverGreen's patching mechanism for con1, and then set the connector type to HDMI. To do this, we set the following Properties under `DeviceProperties -> Add -> PciRoot(0x0)/Pci(0x2,0x0)`: +Since the incorrect port was located at AppleIntelFramebuffer@1, this is port 1. Next we'll to enable WhateverGreen's patching mechanism for con1, and then set the connector type to HDMI. To do this, we set the following Properties under `DeviceProperties -> Add -> PciRoot(0x0)/Pci(0x2,0x0)`: * `framebuffer-patch-enable = 01000000` * Enables WhateverGreen's patching mechanism @@ -46,4 +44,4 @@ Since the incorrect port was located at AppleIntelFramebuffer@1, this is port 1. Note: Remember to replace the `conX` in both patches with `con1` to reflect the port that we want fixed, then set the values as listed above. -![](../../images/gpu-patching/connector-type-patch.png) \ No newline at end of file +![](../../images/gpu-patching/connector-type-patch.png) diff --git a/gpu-patching/intel-patching/vram.md b/gpu-patching/intel-patching/vram.md index 64f40fe3..139b4342 100644 --- a/gpu-patching/intel-patching/vram.md +++ b/gpu-patching/intel-patching/vram.md @@ -2,10 +2,9 @@ This section is mainly relevant for users who cannot unlock their BIOS to increase the allocated VRAM for their iGPU which results in a kernel panic in macOS. To work around this, we'll first want to identify the minimum amount of VRAM required for the framebuffer and then patch it to require less. - For this example, lets take a Haswell Lake Framebuffer that's commonly used on desktop Haswell iGPUs: `0x0D220003`(`0300220D` when hex swapped) -Now lets take a look at the corresponding information in [WhateverGreen's manual](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md)(note you'll need to click "Spoiler: Azul connectors") +Now lets take a look at the corresponding information in [WhateverGreen's manual](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md)(note you'll need to click "Spoiler: Azul connectors") ``` ID: 0D220003, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x00000402 @@ -36,7 +35,7 @@ Here the main entries we care about: | TOTAL CURSOR | 1 MB | Memory reserved for cursor | | TOTAL STOLEN | 52 MB | Combination of the above | -Now lets say for example your motherboard only allocates 32MB for the iGPU, this will be too little for what the framebuffer expects and so will most likely kernel panic when it tries to write into an area of memory that does not exist. +Now lets say for example your motherboard only allocates 32MB for the iGPU, this will be too little for what the framebuffer expects and so will most likely kernel panic when it tries to write into an area of memory that does not exist. That's where WhateverGreen's patching capabilities come in, here we're able to set the exact amount of iGPU memory the framebuffer expects with the following properties: @@ -46,7 +45,6 @@ That's where WhateverGreen's patching capabilities come in, here we're able to s | framebuffer-stolenmem | This sets the value used by `STOLEN` entry | | framebuffer-fbmem | This sets the value used by `FBMEM` entry | - ## Creating our patch So to lower this VRAM requirement, we'll want to set `STOLEN` to 19MB and `FBMEM` to 9MB. This will get us underneath the 32MB limit. @@ -56,11 +54,11 @@ To do this, we run the following commands to covert 9MB: ```md # Convert 9MB Megabytes to Bytes echo '9 * 1024 * 1024' | bc - 9437184 + 9437184 # Convert from decimal to hexadecimal echo 'obase=16; ibase=10; 9437184' | bc - 900000 + 900000 # Hexswap so it can be injected correctly # ie. swap in pairs @@ -90,4 +88,3 @@ And when we punch it into our WhateverGreen properties: Now with our patch made, head into your config.plist then under `DeviceProperties -> Add -> PciRoot(0x0)/Pci(0x2,0x0)` and add the properties: ![](../../images/gpu-patching/vram.png) - diff --git a/gpu-patching/legacy-intel/README.md b/gpu-patching/legacy-intel/README.md index 3b5abe6a..f7160767 100644 --- a/gpu-patching/legacy-intel/README.md +++ b/gpu-patching/legacy-intel/README.md @@ -8,7 +8,7 @@ Covers support for the following GPU models: * GMA 3150's can be spoofed for support, however proper acceleration is missing * GMA X3100(10.5-10.7) * Note only mobile models(ie. 965 Express Chipset Family) - + Please note this page is more of an info dump, we won't be going to too great of detail on setup though we plan to expand this page more for it. Information is based off of [Clover's InjectIntel](https://github.com/CloverHackyColor/CloverBootloader/blob/2961827dce9c0ab26345c00fb5a9c581f96c0d6b/rEFIt_UEFI/Platform/gma.cpp) ## Prerequisites @@ -42,9 +42,9 @@ Within AppleIntelGMA950.kext's Info.plist, the following Device IDs are supporte ```md # Values pulled from OS X 10.7.0 0x2582 - GMA 900 - Grantsdale - 945GM/GMS/940GML -0x2592 - GMA 900 - Alviso - 945G +0x2592 - GMA 900 - Alviso - 945G 0x2772 - GMA 950 - Lakeport - 915GM/GMS/910GML -0x27A2 - GMA 950 - Calistoga - 82915G/GV/910GL +0x27A2 - GMA 950 - Calistoga - 82915G/GV/910GL ``` If your iGPU is from one of the above families, but the device ID is not present you can easily add a fake device-id: @@ -53,13 +53,12 @@ If your iGPU is from one of the above families, but the device ID is not present # GMA 950(Calistoga) Fake ID config.plist: |-DeviceProperties - |- Add - |- PciRoot(0x0)/Pci(0x2,0x0) - |- device-id | Data | A2270000 + |- Add + |- PciRoot(0x0)/Pci(0x2,0x0) + |- device-id | Data | A2270000 ``` For a full list of supported GPU families, see below: - ::: details GMA Device families @@ -87,12 +86,10 @@ Following pulled from Clover's GMA.c: ::: - ### Property injection To ensure proper acceleration with OpenCore, head to your config.plist then `DeviceProperties -> Add`. Create a new child called `PciRoot(0x0)/Pci(0x2,0x0)` and we'll be adding our needed properties: - Desktops need very little properties, and most of the time can boot without any: * Desktop: @@ -106,11 +103,11 @@ Desktops need very little properties, and most of the time can boot without any: ``` | model | String | GMA 950 | // Mainly cosmetic -| AAPL,HasPanel | Data | 01000000 | +| AAPL,HasPanel | Data | 01000000 | | AAPL01,BacklightIntensity | Data | 3F000008 | | AAPL01,BootDisplay | Data | 01000000 | | AAPL01,DataJustify | Data | 01000000 | -| AAPL01,DualLink | Data | 00 | +| AAPL01,DualLink | Data | 00 | * Set AAPL01,DualLink to 01 if your internal display is higher than 1366x768 ``` @@ -147,7 +144,6 @@ The below properties is what Clover will inject for GMA 900/950 series iGPUs: ::: - For GMA 3150 users, you'll also want to add this patch: ::: details GMA 3150 Patch @@ -166,7 +162,6 @@ MinKernel = 8.00.00 Source: [GMA.c](https://github.com/CloverHackyColor/CloverBootloader/blob/2961827dce9c0ab26345c00fb5a9c581f96c0d6b/rEFIt_UEFI/Platform/gma.cpp#L1735L1739) - ::: ## GMA X3100 Setup @@ -186,13 +181,12 @@ If your iGPU is from the Crestline family, however the device ID is not present # GMA X3100(Crestline) Fake ID config.plist: |-DeviceProperties - |- Add - |- PciRoot(0x0)/Pci(0x2,0x0) - |- device-id | Data | 022A0000 + |- Add + |- PciRoot(0x0)/Pci(0x2,0x0) + |- device-id | Data | 022A0000 ``` For a full list of supported GPU families, see below: - ::: details GMA Device families @@ -223,7 +217,7 @@ X3100 need very little properties, and most of the time can boot without any: | AAPL01,BacklightIntensity | Data | 38000008 | | AAPL01,BootDisplay | Data | 01000000 | | AAPL01,DataJustify | Data | 01000000 | -| AAPL01,DualLink | Data | 00 | +| AAPL01,DualLink | Data | 00 | * Set AAPL01,DualLink to 01 if your internal display is higher than 1366x768 ``` @@ -248,7 +242,7 @@ The below properties is what Clover will inject for GMA 900/950 series iGPUs: | AAPL01,Dither | Data | 00000000 | | AAPL01,Interlace | Data | 00000000 | | AAPL01,Inverter | Data | 00000000 | -| AAPL01,InverterCurrent | Data | 08520000 | +| AAPL01,InverterCurrent | Data | 08520000 | | AAPL01,LinkFormat | Data | 00000000 | | AAPL01,LinkType | Data | 00000000 | | AAPL01,Pipe | Data | 01000000 | @@ -277,7 +271,7 @@ Example SSDT: DefinitionBlock ("", "SSDT", 2, "DRTNIA", "SsdtDvi", 0x00001000) { External (_SB_.PCI0.SBRG.GFX0.DVI_, DeviceObj) - + Scope (\_SB.PCI0.SBRG.GFX0.DVI) { Method (_STA, 0, NotSerialized) // _STA: Status @@ -298,11 +292,10 @@ DefinitionBlock ("", "SSDT", 2, "DRTNIA", "SsdtDvi", 0x00001000) Another odd issues with 10.6 and older is that the PciRoot's _UID value **must** be Zero else the kernel panic will happen. Example of bad UID entry: - ```c Device (PCI0) { - Name (_HID, EisaId ("PNP0A08")) // Use PNP0A08 to find your PciRoot - Name (_CID, EisaId ("PNP0A03")) - Name (_ADR, One) - Name (_UID, Zero) // Needs to be patched to Zero -``` \ No newline at end of file + Name (_HID, EisaId ("PNP0A08")) // Use PNP0A08 to find your PciRoot + Name (_CID, EisaId ("PNP0A03")) + Name (_ADR, One) + Name (_UID, Zero) // Needs to be patched to Zero +``` diff --git a/gpu-patching/nvidia-patching/README.md b/gpu-patching/nvidia-patching/README.md index d2a5d100..ddc49bd6 100644 --- a/gpu-patching/nvidia-patching/README.md +++ b/gpu-patching/nvidia-patching/README.md @@ -1,7 +1,6 @@ # Legacy Nvidia Patching -* Please note this page is more of an info dump, we won't be ging to too great of detail on setup though we plan to expand this page more for it. - +* Please note this page is more of an info dump, we won't be going to too great of detail on setup though we plan to expand this page more for it. With legacy Nvidia GPUs, macOS has difficulties enabling acceleration due to many missing properties. To work around this, we can inject properties into IOService for macOS to easily interpret. @@ -14,7 +13,6 @@ To start off, we'll be assuming the following: * Lilu and WhateverGreen are loaded * verify by running `kextstat | grep -E "Lilu|WhateverGreen"` - ### Finding the GPU pathing First lets grab [gfxutil](https://github.com/acidanthera/gfxutil/releases) and run the following: @@ -23,7 +21,6 @@ First lets grab [gfxutil](https://github.com/acidanthera/gfxutil/releases) and r path/to/gfxutil -f display ``` - This should spit out something like the following: ``` @@ -36,7 +33,6 @@ What we care about is the PciRoot section, as this is where our GPU is located a PciRoot(0x2)/Pci(0x0,0x0)/Pci(0x0,0x0) ``` - ### Building our DeviceProperties With Nvidia GPUs, there's actually not too many properties required for setup. The main ones that are recommended are the following: @@ -55,7 +51,6 @@ With Nvidia GPUs, there's actually not too many properties required for setup. T | @1,device_type | display | Always set as `display` | | @1,name | NVDA,Display-B | Always set as `NVDA,Display-B` | - And to calculate the properties few properties: * [model](#model) @@ -82,11 +77,11 @@ For this example, lets convert 1024MB to hexadecimal: ```md # Convert 1024MB Megabytes to Bytes echo '1024 * 1024 * 1024' | bc - 1073741824 + 1073741824 # Convert from decimal to hexadecimal echo 'obase=16; ibase=10; 1073741824' | bc - 40000000 + 40000000 # Hexswap so it can be injected correctly # ie. swap in pairs @@ -101,7 +96,7 @@ VRAM,totalsize = 0000004000000000 ### rom-revision -Simply can be any value, however the property must exist as some GPUs fail to initialise without it(ex. GT 220's) +Simply can be any value, however the property must exist as some GPUs fail to initialize without it(ex. GT 220's) ``` rom-revision = Dortania @@ -113,7 +108,6 @@ This is where the fun comes it, as we'll now need to calculate the NVCAP value. To use this program, simply grab your VBIOS([TechPowerUp hosts most VBIOS](https://www.techpowerup.com/vgabios/)) and run NVCAP-Calculator: - ```bash git clone https://github.com/1Revenger1/NVCAP-Calculator cd NVCAP-Calculator @@ -123,7 +117,6 @@ npm run run * Note this will require NodeJS, either grab this via brew or [Node JS's site](https://nodejs.org/en/) - Once its running, you should see the following: ![](../../images/gpu-patching/nvidia/nvcap-start.png) @@ -162,6 +155,7 @@ Once done, enter in `c` to calculate the NVCAP value ![](../../images/gpu-patching/nvidia/nvcap-calculated.png) You now have your NVCAP value! + ``` NVCAP: 05000000 00000300 0c000000 0000000f 00000000 ``` @@ -214,4 +208,4 @@ NVCAP | Data | Data | 05000000 00000300 0c000000 0000000f 00000000 Open your config.plist and head to `DeviceProperties -> Add`, next create a new child with the name of your GPU's path(ie the one with gfxutil). Then, finally add the properties as children to the PciRoot. You should end up with something similar: -![](../../images/gpu-patching/nvidia/deviceproperties.png) \ No newline at end of file +![](../../images/gpu-patching/nvidia/deviceproperties.png) diff --git a/misc/msr-lock.md b/misc/msr-lock.md index 3e17f106..3bafda2c 100644 --- a/misc/msr-lock.md +++ b/misc/msr-lock.md @@ -10,14 +10,14 @@ CFG-Lock is a setting in your BIOS that allows for a specific register(in this c So to fix it we have 2 options: -1. Patch macOS to work with our hardware +#### 1. Patch macOS to work with our hardware * This creates instability and unnecessary patching for many * The 2 patches we use for this: * `AppleCpuPmCfgLock` for AppleIntelPowerManagement.kext * `AppleXcpmCfgLock` for the Kernel(XNU) -2. Patch our firmware to support MSR E2 write +#### 2. Patch our firmware to support MSR E2 write * Very much preferred, as avoids patching allowing for greater flexibility regarding stability and OS upgrades @@ -31,10 +31,9 @@ To check it, you can proceed into two ways: 1. [Use the DEBUG version of OpenCore and check what the log says about CFG Lock](#checking-via-opencore-logs) 2. [Use a tool called `VerifyMsrE2` which will speed up the whole checking process](#checking-via-verifymsre2) - ### Checking via OpenCore logs -For users who prefer using DEBUG release, you'll want to enabe the DEBUG variant of OpenCore with `Target` set to `67` and boot OpenCore. This should provide you with a file in the format of `opencore-YYYY-MM-DD-hhmmss.txt` on the root of the drive. +For users who prefer using DEBUG release, you'll want to enable the DEBUG variant of OpenCore with `Target` set to `67` and boot OpenCore. This should provide you with a file in the format of `opencore-YYYY-MM-DD-hhmmss.txt` on the root of the drive. Within this file, search for `OCCPU: EIST CFG Lock`: @@ -42,11 +41,10 @@ Within this file, search for `OCCPU: EIST CFG Lock`: OCCPU: EIST CFG Lock 1 ``` -If it returns `1`, then you proceed with this guide here: [Disabling CFG Lock](#disabling-cfg-lock). +If it returns `1`, then you proceed with this guide here: [Disabling CFG Lock](#disabling-cfg-lock). Otherwise(ie. `0`), no reason to continue and you can simply disable `Kernel -> Quirks -> AppleCpuPmCfgLock` and `Kernel -> Quirks -> AppleXcpmCfgLock`. - ### Checking via VerifyMsrE2 To start, download [VerifyMsrE2](https://github.com/acidanthera/OpenCorePkg/releases) and add this tool inside `EFI/OC/Tools` and `config.plist`(this can be done with ProperTree's snapshot function(ie. Cmd+R)). Next, boot OpenCore and select the `VerifyMsrE2.efi` entry. This should provide you one of the following: @@ -110,21 +108,23 @@ Now the fun part! ``` If you get an error such as `error: offset is out of range` run the following command: - + ``` setup_var2 0x5A4 ``` + Just as before, if you still get `error: offset is out of range` you'd need to use this command: - + ``` setup_var_3 0x5A4 ``` + If you don't get any type of error, write the command which doesn't lead to `error: offset is out of range` (e.g. `setup_var_3 0x5A4`) and write `0x00` after it: - + ``` setup_var_3 0x5A4 0x00 ``` - + At this point, run either `reset` in the shell or simply reboot your machine. And with that, you should have `CFG Lock` unlocked! To verify, you can run over the methods listed at [Checking if your firmware supports CFG Lock unlocking](#checking-if-your-firmware-supports-cfg-lock-unlocking) to verify whether the variable was set correctly then finally disable `Kernel -> Quirks -> AppleCpuPmCfgLock` and `Kernel -> Quirks -> AppleXcpmCfgLock`. * Do note that variable offsets are unique not just to each motherboard but even to its firmware version. **Never try to use an offset without checking.** diff --git a/misc/nvram.md b/misc/nvram.md index af5d0fca..cb998ab0 100644 --- a/misc/nvram.md +++ b/misc/nvram.md @@ -1,9 +1,5 @@ # Emulated NVRAM - - - - So this section is for those who don't have native NVRAM, the most common hardware to have incompatible native NVRAM with macOS are X99 and some X299 series chipsets: * X99 diff --git a/misc/rtc.md b/misc/rtc.md index 203e1901..737789f4 100644 --- a/misc/rtc.md +++ b/misc/rtc.md @@ -4,9 +4,9 @@ What this section attempts to teach is how to resolve RTC(CMOS) issues on reboot ![credit to u/iDrakus for the image](../images/post-install/rtc-md/cmos-error.png) -The reason that these CMOS and safe mode errors happen is due to AppleRTC writing to certain areas that are not supported by the hardware properly and thus resulting in panics and errors. +The reason that these CMOS and safe mode errors happen is due to AppleRTC writing to certain areas that are not supported by the hardware properly and thus resulting in panics and errors. -To get around this, we've commonly blocked out all RTC writes with [these types of patches](https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/blob/master/config_parts/config_master.plist#L291L296) but they're not ideal for many reasons including both breaking Windows and linux and disabling potential supported regions like for power management. +To get around this, we've commonly blocked out all RTC writes with [these types of patches](https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/blob/master/config_parts/config_master.plist#L291L296) but they're not ideal for many reasons including both breaking Windows and Linux and disabling potential supported regions like for power management. So with OpenCore, we've got a few options to choose: @@ -19,7 +19,6 @@ So with OpenCore, we've got a few options to choose: * Much easier for the end user to patch * Prevents EfiBoot from breaking your system as well - The former is actually already integrated into OpenCore with the `DisableRtcChecksum` quirk, but has the downfall of only blocking regions 0x58-0x59 and only working in the kernel level. Best way to know if this option is best, enable it and try. If this doesn't work, disable as it's an unnecessary patch. With the latter, we're able to block very specific regions of our choice that match our exact model. And we're able to do this both in the kernel level and firmware aiding with hibernation support. This however will requires much more time and [RTCMemoryFixup](https://github.com/acidanthera/RTCMemoryFixup/releases/tag/1.0.6). @@ -39,27 +38,33 @@ For the rest of this guide, we're going to assume you've tested option 1(`Disabl Regarding splitting out chunks, what we'll be doing is omitting chunks of RTC regions until we've narrowed down far enough to the exact spot that's bad. You can see the below on how to start: -1. Testing RtcMemoryFixup - * To start, you'll need to add `rtcfx_exclude=00-FF` in boot-args. If after a reboot the RTC errors seems solved, this will tell you whether your CMOS errors are RTC related -2. Split 0x00-0xFF into 2 - * 0x00-0x7F and 0x80-0xFF - * write down the excluded range which fixes the RTC errors and proceed by splitting more into chunks - * e.g. `rtcfx_exclude=00-7F`fixes the RTC errors so you're gonna split it by half and don't consider more `rtcfx_exclude=80-FF` - * Test `rtcfx_exclude=00-7F` and `rtcfx_exclude=80-FF` - * Note you may also get a bad range of 7F-80, or even bad regions split into multiple sections(ex. 0x00-0x01 **and** 0x80-0x81) - * You can use `rtcfx_exclude=00-01,7F-80` to resolve this -3. After testing which regions is bad, shrink even more - * Assuming our bad region was within 0x80-0xFF, you'd next split that into 2: - * 0x80-0xBF and 0xC0-0xFF - * if you had multiple ranges that are bad -4. And you'll continue on with this pattern until you've narrowed down the bad region. Note that you will need to reboot each time to test if you're still getting CMOS/Safe-mode errors - * Also note that the final bad spot will usually be a range and not a singular spot. - * ie. `rtcfx_exclude=85-86` instead of one singular value - - +#### 1. Testing RtcMemoryFixup + +* To start, you'll need to add `rtcfx_exclude=00-FF` in boot-args. If after a reboot the RTC errors seems solved, this will tell you whether your CMOS errors are RTC related + +#### 2. Split 0x00-0xFF into 2 + +* 0x00-0x7F and 0x80-0xFF + * write down the excluded range which fixes the RTC errors and proceed by splitting more into chunks + * e.g. `rtcfx_exclude=00-7F`fixes the RTC errors so you're gonna split it by half and don't consider more `rtcfx_exclude=80-FF` +* Test `rtcfx_exclude=00-7F` and `rtcfx_exclude=80-FF` + * Note you may also get a bad range of 7F-80, or even bad regions split into multiple sections(ex. 0x00-0x01 **and** 0x80-0x81) + * You can use `rtcfx_exclude=00-01,7F-80` to resolve this + +#### 3. After testing which regions is bad, shrink even more + +* Assuming our bad region was within 0x80-0xFF, you'd next split that into 2: +* 0x80-0xBF and 0xC0-0xFF + * if you had multiple ranges that are bad + +#### 4. And you'll continue on with this pattern until you've narrowed down the bad region. Note that you will need to reboot each time to test if you're still getting CMOS/Safe-mode errors + +* Also note that the final bad spot will usually be a range and not a singular spot. +* ie. `rtcfx_exclude=85-86` instead of one singular value + **Pro tip**: To find a value in between 2 regions, I recommend first converting from hexadecimal to decimal, then run the below equation: -* `(x + y) / 2` +* `(x + y) / 2` Now lets try to use this with step 1 from earlier: @@ -81,14 +86,8 @@ For this, open up your config.plist and head to the `NVRAM -> Add` section. Here Next you'll want to add our bad RTC region as an array, so `rtcfx_exclude=85-86` will become `rtc-blacklist | Data | 8586`. This will also work with longer ranges such as 85-89 and such however with `rtc-blacklist` you must include every entry(ie. `<85 86 87 88 89>`). Remember to remove the boot-arg once you're set `rtc-blacklist` -Next ensure you have `NVRAM -> Block` also set as NVRAM variables will not be overwritten by OpenCore unless explicitly told so. +Next ensure you have `NVRAM -> Block` also set as NVRAM variables will not be overwritten by OpenCore unless explicitly told so. Once all this is done, you should have something similar to below: ![](../images/post-install/rtc-md/rtc-blacklist.png) - - - - - - diff --git a/multiboot/bootcamp.md b/multiboot/bootcamp.md index 8985e2aa..ee714cb3 100644 --- a/multiboot/bootcamp.md +++ b/multiboot/bootcamp.md @@ -1,7 +1,5 @@ # Installing and using BootCamp utilities - - So a neat feature of OpenCore is the ability to avoid the BIOS entirely and use Startup disk solely for multiboot. Problem comes in when we try to boot windows and have no way of setting the boot option back to macOS. That's where the BootCamp utilities come in. * Note: This guide will not cover the creation of the Windows installer, only the installation of BootCamp drivers. @@ -73,7 +71,7 @@ Once all is finished, you now have BootCamp switching! There should be a little * [Can't find Windows/BootCamp drive in picker](#cant-find-windowsbootcamp-drive-in-picker) * ["You can't change the startup disk to the selected disk" error](#you-cant-change-the-startup-disk-to-the-selected-disk-error) -* [Booting Windows results in BlueScreen or Linux crashes](#booting-windows-results-in-bluescreen-or-linux-crashes) +* [Booting Windows results in BlueScreen or Linux crashes](#booting-windows-results-in-bluescreen-or-Linux-crashes) * [Booting Windows error: `OCB: StartImage failed - Already started`](#booting-windows-error-ocb-startimage-failed---already-started) * [Windows Startup Disk can't see APFS drives](#windows-startup-disk-cant-see-apfs-drives) diff --git a/multiboot/bootstrap.md b/multiboot/bootstrap.md index 4a9303f3..d8a0c71e 100644 --- a/multiboot/bootstrap.md +++ b/multiboot/bootstrap.md @@ -1,7 +1,5 @@ # Using Bootstrap.efi - - So with OpenCore 0.5.8 and newer, we get a neat little file inside our EFI/OC/Bootstrap folder called Bootstrap.efi. What this allows us to do is add OpenCore to our motherboard's boot menu and prevent issues where either Windows or Linux try to overwrite the BOOTx64.efi file which can happen during updates and completely delete any way of booting OpenCore. ## Preparation diff --git a/scripts/linkcheck.py b/scripts/linkcheck.py new file mode 100644 index 00000000..cdcf3eff --- /dev/null +++ b/scripts/linkcheck.py @@ -0,0 +1,9 @@ +from pathlib import Path +import subprocess + +for i in [i for i in list(Path().resolve().glob("**/*.md")) if "node_modules" not in str(i.parent) and "_book" not in str(i.parent)]: + #bert = subprocess.run(['npx', 'markdown-link-check', '"' + str(i) + '"', '-c', '.markdownlinkcheck.json'], capture_output=True, shell=True, cwd=Path().resolve()) + bert = subprocess.run('npx markdown-link-check "' + str(i) + '"', stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True, cwd=Path().resolve()) + outpot = bert.stdout.decode().replace("\r", "").split("\n") + outpot = [i for i in outpot if ("FILE: " in i or " → Status: " in i) and " → Status: 429" not in i] + [print(i) for i in outpot] \ No newline at end of file diff --git a/scripts/sortDict.js b/scripts/sortDict.js new file mode 100644 index 00000000..8866ca08 --- /dev/null +++ b/scripts/sortDict.js @@ -0,0 +1,26 @@ +const fs = require("fs"); + +process.chdir(__dirname); + +console.log("Reading dictionary.txt"); +let dictionary = fs.readFileSync("../dictionary/dictionary.txt", { encoding: "UTF8" }) + .replace("\r", "").split("\n"); + +let ocDictionary = fs.readFileSync("../dictionary/opencorekeys.txt", { encoding: "UTF8" }) + .replace("\r", "").split("\n"); + +dictionary = dictionary.filter(string => string != ""); +ocDictionary = ocDictionary.filter(string => string != ""); + +dictionary = dictionary.filter((string, index) => dictionary.indexOf(string) == index); +ocDictionary = ocDictionary.filter((string, index) => ocDictionary.indexOf(string) == index); + +dictionary = dictionary.filter(string => !ocDictionary.includes(string)); + +console.log("Sorting..."); +dictionary.sort(); +ocDictionary.sort(); + +console.log("Writing dictionary.txt"); +fs.writeFileSync("../dictionary/dictionary.txt", dictionary.join("\n")); +fs.writeFileSync("../dictionary/opencorekeys.txt", ocDictionary.join("\n")); diff --git a/universal/audio.md b/universal/audio.md index 6a84eb4b..619eef86 100644 --- a/universal/audio.md +++ b/universal/audio.md @@ -1,9 +1,5 @@ # Fixing audio with AppleALC - - - - So to start, we'll assume you already have Lilu and AppleALC installed, if you're unsure if it's been loaded correctly you can run the following in terminal(This will also check if AppleHDA is loaded, as without this AppleALC has nothing to patch): ```sh @@ -215,7 +211,6 @@ For rare situations where you have 2 sounds cards(ex. onboard Realtek and an ext To get around this, we'll first need to identify the location of both our audio controllers. The easiest way is to run [gfxutil](https://github.com/acidanthera/gfxutil/releases) and search for the PCI IDs: - ```sh /path/to/gfxutil ``` @@ -232,13 +227,11 @@ From here, we can clearly see our PciRoot pathing is: PciRoot(0x32)/Pci(0x0,0x0)/Pci(0x0,0x0) ``` - * **Note**: This will assume you know both the Vendor and Device ID of the external sound card. For reference, these are the common Vendor IDs: * Creative Labs: `1102` * AsusTek: `1043` * **Note 2**: Your ACPI and PciRoot path will look different, so pay attention to **your** gfxutil output - Now that we have our PciRoot pathing, we can finally open up our config.plist and add our patch. Under DeviceProperties -> Add, you'll want to add your PciRoot(as a Dictionary) with the child called `external-audio`: @@ -246,8 +239,8 @@ Under DeviceProperties -> Add, you'll want to add your PciRoot(as a Dictionary) ``` DeviceProperties | --- > Add - | --- > PciRoot(0x32)/Pci(0x0,0x0)/Pci(0x0,0x0) - | ----> external-audio | Data | 01 + | --- > PciRoot(0x32)/Pci(0x0,0x0)/Pci(0x0,0x0) + | ----> external-audio | Data | 01 ``` ![](../images/post-install/audio-md/external-audio.png) diff --git a/universal/drm.md b/universal/drm.md index fde571d8..1e96ed16 100644 --- a/universal/drm.md +++ b/universal/drm.md @@ -1,9 +1,7 @@ # Fixing DRM support and iGPU performance - * **Note**: Safari 14 and macOS 11, Big Sur are currently unsupported by WhateverGreen's DRM patches. Safari 13 in Catalina and older are supported just fine however. - So with DRM, we have a couple things we need to mention: * DRM requires a supported dGPU @@ -137,7 +135,7 @@ Here's another example. This time, We have an Ryzen 3700X and an RX 480. Our con So how do we fix iGPU performance? Well by loading Apple's GuC (Graphics Micro Code). The main thing to note is that firmware loading is restricted to: -* Skylake and newer CPU with a [supported iGPU](https://dortania.github.io/GPU-Buyers-Guide/modern-gpus/intel-gpu) +* Skylake and newer CPU with a [supported iGPU](https://dortania.github.io/GPU-Buyers-Guide/modern-gpus/Intel-gpu) * **And** a recent chipset, 300-series or newer: Z390, B360, H370, H310, etc. (***not*** Z370, as it is actually 200-series) * Do note that even with recent chipsets, firmware loading is not guaranteed to work. If you experience a kernel panic or lots of graphics errors after trying this, it is probably because firmware loading is not supported on your setup. @@ -153,7 +151,7 @@ To enable firmware loading. ![Example of igfxfw injected into iGPU](../images/post-install/drm-md/igpu-path.png) -The best way to check is to monitor the iGPU's frequency is with either [Intel Power Gadget](https://software.intel.com/en-us/articles/intel-power-gadget) or checking the boot logs for Apple Scheduler references. Make sure you have the `igfxfw` property applied: +The best way to check is to monitor the iGPU's frequency is with either [Intel Power Gadget](https://software.Intel.com/en-us/articles/Intel-power-gadget) or checking the boot logs for Apple Scheduler references. Make sure you have the `igfxfw` property applied: ``` kernel: (AppleIntelCFLGraphics) [IGPU] Graphics Firmware Version: 2.14.0.0 diff --git a/universal/gpu-patches.md b/universal/gpu-patches.md index 8a72e497..110de656 100644 --- a/universal/gpu-patches.md +++ b/universal/gpu-patches.md @@ -1,7 +1,5 @@ # GPU Patching - - This little section is for those who need more than what is provided by simple framebuffer patching and WhateverGreen's auto-patches: * [Applying a fakeID for unsupported GPUs](https://dortania.github.io/Getting-Started-With-ACPI/Universal/spoof.html) diff --git a/universal/iservices.md b/universal/iservices.md index 1e539bea..a7d0849c 100644 --- a/universal/iservices.md +++ b/universal/iservices.md @@ -1,9 +1,5 @@ # Fixing iMessage and other services with OpenCore - - - - This page is for those having iMessage and other iServices issues, this is a very basic guide so will not go as in-depth into the issues as some other guides. This specific guide is a translation and reinterpretation of the AppleLife Guide on fixing iServices: [Как завести сервисы Apple - iMessage, FaceTime, iCloud](https://applelife.ru/posts/727913) **Note**: You and you alone are responsible for your AppleID, read the guide carefully and take full responsibility if you screw up. Dortania and other guides are not held accountable for what **you** do. @@ -158,6 +154,7 @@ And a final layer of precaution is to make a new AppleID to play with, this make Well mate, you've done it. You blacklisted your AppleID. The fix is simple but not pretty, **you MUST call [Apple](https://support.apple.com/en-us/HT201232)**. Otherwise, there is no proceeding besides using a new account. Adding a payment card before calling can help legitimize the account so it doesn't seem as much like a bot. ![](../images/post-install/iservices-md/blacklist.png) - * For Apple contacting, there are 2 methods - * Apple calls you: [Apple Support](https://getsupport.apple.com/). You must click on Apple ID and then select the iCloud, Facetime & Messages. Now, you should click on Talk to Apple Support Now and type your phone number - * You can contact Apple for support and service as well, look for your country in the list and then make a phone call: [Apple Support Phone Numbers](https://support.apple.com/HT201232) + +* For Apple contacting, there are 2 methods + * Apple calls you: [Apple Support](https://getsupport.apple.com/). You must click on Apple ID and then select the iCloud, Facetime & Messages. Now, you should click on Talk to Apple Support Now and type your phone number + * You can contact Apple for support and service as well, look for your country in the list and then make a phone call: [Apple Support Phone Numbers](https://support.apple.com/HT201232) diff --git a/universal/oc2hdd.md b/universal/oc2hdd.md index edbf850d..0ff9d17a 100644 --- a/universal/oc2hdd.md +++ b/universal/oc2hdd.md @@ -1,7 +1,5 @@ # Moving OpenCore from USB to macOS Drive - - ## Grabbing OpenCore off the USB So to start, we'll first want to grab OpenCore off of our installer. To do this, we'll be using a neat tool from CorpNewt called [MountEFI](https://github.com/corpnewt/MountEFI) diff --git a/universal/pm.md b/universal/pm.md index 38c1974f..469e211d 100644 --- a/universal/pm.md +++ b/universal/pm.md @@ -1,10 +1,8 @@ # Optimizing Power Management - - ## Enabling X86PlatformPlugin -So before we can fine tune power management to our liking, we need to first make sure Apple's XCPM core is loaded. Note that this is supported **only on Haswell and newer(with Ivy Bridge-E)**, consumer Sandy, Ivy Bridge and AMD CPUs should refer to the bottom of the guides: +So before we can fine tune power management to our liking, we need to first make sure Apple's XCPM core is loaded. Note that this is supported **only on Haswell and newer(with Ivy Bridge-E)**, consumer Sandy, Ivy Bridge and AMD CPUs should refer to the bottom of the guides: * [Sandy and Ivy Bridge Power Management](../universal/pm.md#sandy-and-ivy-bridge-power-management) * [AMD CPU Power Management](../universal/pm.md#amd-cpu-power-management) @@ -15,7 +13,7 @@ XCPM Present | Missing XCPM :-------------------------:|:-------------------------: ![](../images/post-install/pm-md/pm-working.png) | ![](../images/post-install/pm-md/pm-not-working.png) -As you can see from the left image, we have the X86PlatformPlugin attached meaning Apple's CPU Power Management Drivers are doing their thing(Note the CPU's name does not matter, CPU names come in many varitaions such as CP00, CPU0, PR00, etc. What matters is that AppleACPICPU attaches to it). If you get something like to the right image, then there's likely an issue. Make sure to check the following: +As you can see from the left image, we have the X86PlatformPlugin attached meaning Apple's CPU Power Management Drivers are doing their thing(Note the CPU's name does not matter, CPU names come in many variations such as CP00, CPU0, PR00, etc. What matters is that AppleACPICPU attaches to it). If you get something like to the right image, then there's likely an issue. Make sure to check the following: * SSDT-PLUG.**aml** is both present and enabled in your config.plist and EFI/OC/ACPI * If you're missing this, head to [Getting Started With ACPI](https://dortania.github.io/Getting-Started-With-ACPI) on how to make this @@ -46,7 +44,7 @@ XCPM does not natively support Haswell-E and Broadwell-E, this means we need to To start, we're gonna need a couple things: * X86PlatformPlugin loaded - * This means Sandy, Ivy Birdge and AMD CPUs are not supported + * This means Sandy, Ivy Bridge and AMD CPUs are not supported * [CPUFriend](https://github.com/acidanthera/CPUFriend/releases) * [Fewt's fork of CPUFriendFriend](https://github.com/fewtarius/CPUFriendFriend) * This fork has some additional features that can help both simplify the process and give use some better control @@ -61,7 +59,7 @@ When you first open up CPUFriendFriend, you'll be greeted with a prompt for choo To determine your LPM value, you can either: -* Look for the `TDP-down Frequency` on Intel's [ARK site](https://ark.intel.com/) +* Look for the `TDP-down Frequency` on Intel's [ARK site](https://ark.Intel.com/) * Note most CPUs do not have a listed value, so you'll need to determine yourself * Or choose recommended values: @@ -72,17 +70,16 @@ To determine your LPM value, you can either: | Haswell/Broadwell HEDT/Server(ie. X99) | 0D | Equivalent of 1300Mhz | | Skylake+ HEDT/Server(ie. X299) | 0C | Equivalent of 1200Mhz | - * **Note**: LFM value is only available on Broadwell and newer SMBIOS * **Note 2**: these values are not set in stone, each machine will have unique characteristics and so you'll need to experiment what works best for your hardware -For this example we'll be using the [i9 7920x](https://ark.intel.com/content/www/us/en/ark/products/126240/intel-core-i9-7920x-x-series-processor-16-5m-cache-up-to-4-30-ghz.html) which has a base clock of 2.9 GHz but no LFM, so we'll choose 1.3 GHz(ie. 1300Mhz) and work our way up/down until we find stability. +For this example we'll be using the [i9 7920x](https://ark.Intel.com/content/www/us/en/ark/products/126240/Intel-core-i9-7920x-x-series-processor-16-5m-cache-up-to-4-30-ghz.html) which has a base clock of 2.9 GHz but no LFM, so we'll choose 1.3 GHz(ie. 1300Mhz) and work our way up/down until we find stability. * Note that the LFM value is simply the CPU's multiplier, so you'll need to trim your value appropriately * ie. Divide by 100, then convert to hexadecimal ```sh -$ echo "obase=16; 13" | bc +echo "obase=16; 13" | bc ``` * Pay close attention we used 13 for 1.3Ghz and not 1.3 @@ -108,7 +105,6 @@ Next up is the Energy Performance Preference, EPP. This tells macOS how fast to This final entry is to help macOS out what kind of overall performance you'd like from your CPU. The general recommendation depends on your exact setup, and experimenting does help figure out what's best for you. - ### Cleaning up ![](../images/post-install/pm-md/done.png) @@ -131,7 +127,7 @@ What we'll need: * Ensure CpuPm and Cpu0Ist tables are **NOT** dropped * [ssdtPRGen](https://github.com/Piker-Alpha/ssdtPRGen.sh) -Initialling with OpenCore's setup in the Ivy Bridge section, we recommended users drop their CpuPm and Cpu0Ist to avoid any issues with AppleIntelCPUPowerManagement.kext. But dropping these tables have the adverse affect of breaking turbo boost in Windows. So to resolve this, we'll want to keep our OEM's table but we'll want to add a new table to supplement data only for macOS. So once we're done creating our CPU-PM table, we'll re-add our OEM's CPU SSDTs. +Initialing with OpenCore's setup in the Ivy Bridge section, we recommended users drop their CpuPm and Cpu0Ist to avoid any issues with AppleIntelCPUPowerManagement.kext. But dropping these tables have the adverse affect of breaking turbo boost in Windows. So to resolve this, we'll want to keep our OEM's table but we'll want to add a new table to supplement data only for macOS. So once we're done creating our CPU-PM table, we'll re-add our OEM's CPU SSDTs. To start, grab your config.plist then head to ACPI -> Delete and ensure both of these sections have `Enabled` set to YES: @@ -185,7 +181,7 @@ Finally, we can disable our previous ACPI -> Delete entries(`Enabled` set to NO) ### ssdtPRgen Troubleshooting -While ssdtPRgen tries to handle any incompatibility issues with your OEM's SSDT, you may find it still clashes on boot as your OEM has already declared certain devices or methods in sections like `_INI` or `_DSM`. +While ssdtPRgen tries to handle any incompatibility issues with your OEM's SSDT, you may find it still clashes on boot as your OEM has already declared certain devices or methods in sections like `_INI` or `_DSM`. If you find during boot up you get errors such as this one from SSDT-PM: diff --git a/universal/security.md b/universal/security.md index 22d6222e..75843ca3 100644 --- a/universal/security.md +++ b/universal/security.md @@ -1,11 +1,7 @@ # Security and FileVault - - So something that makes OpenCore truly special is how it's been built with security in mind which is quite rare especially in the Hackintosh community. Well here we'll be going through and setting up some of OpenCore's great Security features: - - * [**FileVault**](./security/filevault) * Apple's built-in drive encryption * [**Vault**](./security/vault) @@ -14,5 +10,3 @@ So something that makes OpenCore truly special is how it's been built with secur * OpenCore's drive policy, determines what types of disks show up in OpenCore's boot menu * [**Apple Secure Boot**](./security/applesecureboot) * Apple's variant of secure boot in the macOS kernel - - diff --git a/universal/security/applesecureboot.md b/universal/security/applesecureboot.md index 54a4e16b..c8d7cf66 100644 --- a/universal/security/applesecureboot.md +++ b/universal/security/applesecureboot.md @@ -3,7 +3,6 @@ * Note: DmgLoading, SecureBootModel and ApECID require [OpenCore 0.6.1](https://github.com/acidanthera/OpenCorePkg/releases) or newer * Note 2: macOS Big Sur requires OpenCore 0.6.3+ for proper Apple Secure Boot support - ## What is Apple Secure Boot * Information based off of [vit9696's thread](https://applelife.ru/posts/905541), [Apple's T2 docs](https://www.apple.com/euro/macbook-pro-13/docs/a/Apple_T2_Security_Chip_Overview.pdf) and [Osy's Secure Boot page](https://osy.gitbook.io/hac-mini-guide/details/secure-boot) @@ -64,18 +63,18 @@ Currently the following options for `Misc -> Security -> SecureBootModel` are su * Generally `Default` is more than adequate to use however if you plan to have use this with ApECID for full security, we recommend setting a proper value(ie. closest to your SMBIOS or versions of macOS you plan to boot) since the `Default` value is likely to be updated in the future. * `x86legacy` is not required for normal Mac models without T2's, any of the above values are supported. -* The list of cached drivers may be different, resulting in the need to change the list of Added or Forced kernel drivers. +* The list of cached drivers may be different, resulting in the need to change the list of Added or Forced kernel drivers. * ie. IO80211Family cannot be injected in this case, as it is already present in the kernelcache * Unsigned and several signed kernel drivers cannot be used * This includes Nvidia's Web Drivers in 10.13 -* System volume alterations on operating systems with sealing, like macOS 11, may result in the operating system being unbootable. +* System volume alterations on operating systems with sealing, like macOS 11, may result in the operating system being unbootable. * If you plan to disable macOS's APFS snapshots, please remember to disable SecureBootModel as well * Certain boot errors are more likely to be triggered with Secure Boot enabled that were previously not required * Commonly seen with certain APTIO IV systems where they may not require IgnoreInvalidFlexRatio and HashServices initially however Secure Boot does. * On older CPUs (ie. before Sandy Bridge) enabling Apple Secure Boot might cause slightly slower loading by up to 1 second -* Operating systems released before Apple Secure Boot landed (ie. macOS 10.12 or earlier) will still boot until UEFI Secure Boot is enabled. This is so, +* Operating systems released before Apple Secure Boot landed (ie. macOS 10.12 or earlier) will still boot until UEFI Secure Boot is enabled. This is so, * This is due to Apple Secure Boot assuming they are incompatible and will be handled by the firmware just like Microsoft Windows is -* Virtaul Machines will want to use `x86legacy` for Secure Boot support +* Virtual Machines will want to use `x86legacy` for Secure Boot support * Note using any other model will require `ForceSecureBootScheme` enabled ::: details Troubleshooting @@ -112,19 +111,19 @@ diskutil mount disk5s2 cd /System/Volumes/Preboot # Grab your UUID -ls - 46923F6E-968E-46E9-AC6D-9E6141DF52FD - CD844C38-1A25-48D5-9388-5D62AA46CFB8 +ls + 46923F6E-968E-46E9-AC6D-9E6141DF52FD + CD844C38-1A25-48D5-9388-5D62AA46CFB8 # If multiple show up(ie. you dual boot multiple versions of macOS), you will # need to determine which UUID is correct. # Easiest way to determine is printing the value of .disk_label.contentDetails # of each volume. cat ./46923F6E-968E-46E9-AC6D-9E6141DF52FD/System/Library/CoreServices/.disk_label.contentDetails - Big Sur HD% + Big Sur HD% cat ./CD844C38-1A25-48D5-9388-5D62AA46CFB8/System/Library/CoreServices/.disk_label.contentDetails - Catalina HD% + Catalina HD% # Next lets copy over the secure boot files, recovery will need different commands @@ -155,14 +154,12 @@ python3 -c 'import secrets; print(secrets.randbits(64))' With this unique 64-bit int, you can now enter it under Misc -> ApECID in your config.plist - However before setting ApECID, there's a few things we need to note: * Fresh installs with ApECID set to a non-zero value will require a network connection at install time for verification * SecureBootModel should have a defined value instead of `Default` to avoid issues if the value were to change in later OpenCore versions. * Pre-existing installs will need to use bless, for this you'll need to first reboot into recovery and run the following command(Replace Macintosh HD with your system's volume name): - ```sh bless bless --folder "/Volumes/Macintosh HD/System/Library/CoreServices" \ --bootefi --personalize @@ -171,9 +168,9 @@ However before setting ApECID, there's a few things we need to note: And something to note when reinstalling the OS is that you may receive "Unable to verify macOS" error message. To work around his issue, you'll want to allocate a dedicated RAM disk of 2 MBs for macOS personalization by entering the following commands in the macOS recovery terminal before starting the installation: ```sh -disk=$(hdiutil attach -nomount ram://4096) -diskutil erasevolume HFS+ SecureBoot $disk -diskutil unmount $disk -mkdir /var/tmp/OSPersonalizationTemp +disk=$(hdiutil attach -nomount ram://4096) +diskutil erasevolume HFS+ SecureBoot $disk +diskutil unmount $disk +mkdir /var/tmp/OSPersonalizationTemp diskutil mount -mountpoint /var/tmp/OSPersonalizationTemp $disk ``` diff --git a/universal/sleep.md b/universal/sleep.md index cda99db9..b3038c6a 100644 --- a/universal/sleep.md +++ b/universal/sleep.md @@ -1,7 +1,5 @@ # Fixing Sleep - - So to understand how to fix sleep issues in macOS, we need to first look at what contributes to sleep issues most of the time: * Incorrectly managed devices(most commonly PCIe based devices) @@ -15,7 +13,7 @@ The reason for this is when devices get an S3 call(or S0 for wake), the driver n * NVMe Drives And there are others that can cause sleep issues that aren't directly(or obviously) related to PCI/e: - + * CPU Power Management * Displays * NVRAM @@ -26,7 +24,7 @@ And there are others that can cause sleep issues that aren't directly(or obvious * TSC And something many people forget are over and under-clocks: - + * CPUs * AVX often breaks iGPUs and hurt overall stability * Bad RAM(Both overclocks and mismatched RAM) @@ -37,14 +35,13 @@ And something many people forget are over and under-clocks: ## Preparations - **In macOS**: Before we get in too deep, we'll want to first ready our system: ``` -sudo pmset autopoweroff 0 -sudo pmset powernap 0 +sudo pmset autopoweroff 0 +sudo pmset powernap 0 sudo pmset standby 0 sudo pmset proximitywake 0 ``` @@ -105,9 +102,9 @@ This guide also includes some other fixes than just mapping: With GPUs, it's fairly easy to know what might be causing issues. This being unsupported GPUs in macOS. By default, any GPU that doesn't have drivers already provided in the OS will run off very basic drivers known as VESA drivers. These provide minimal display output but also cause a big issue in that macOS doesn't actually know how to properly interact with these devices. To fix this, well need to either trick macOS into thinking it's a generic PCIe device(which it can better handle, ideal for desktops) or completely power off the card(on laptops, desktop dGPUs have issues powering down) * See here for more info: - * [Disabling desktop dGPUs](https://dortania.github.io/Getting-Started-With-ACPI/Desktops/desktop-disable) - * [Disabling laptop dGPUs](https://dortania.github.io/Getting-Started-With-ACPI/Laptops/laptop-disable) - + * [Disabling desktop dGPUs](https://dortania.github.io/Getting-Started-With-ACPI/Desktops/desktop-disable) + * [Disabling laptop dGPUs](https://dortania.github.io/Getting-Started-With-ACPI/Laptops/laptop-disable) + Special notes for iGPU users on 10.15.4 and newer: * iGPU wake is partially broken due to numerous hacks apple uses in AppleGraphicsPowerManagement.kext with real Macs, to get around this you'll likely need `igfxonln=1` to force all displays online. Obviously test first to make sure you have this issue. @@ -148,7 +145,6 @@ NICs(network Interface Controllers) are fairly easy to fix with sleep, it's main * Disable `Wake for network access` in macOS(SystemPreferences -> Power) * Seems to break on a lot of hacks - ### Fixing NVMe So macOS can be quite picky when it comes to NVMe drives, and there's also the issue that Apple's power management drivers are limited to Apple branded drives only. So the main things to do are: @@ -170,7 +166,7 @@ This guide is primarily for dGPU but works the exact same way with NVMe drives(a To verify you have working CPU Power Management, see the [Fixing Power Management](../universal/pm.md) page. And if not, then patch accordingly. -Also note that incorrect frequency vectors can result in wake issues, so either verify you're using the correct SMBIOS or adjust the frequency vectors of your current SMBIOS with CPUFrend. Tools like [one-key-cpufriend](https://github.com/stevezhengshiqi/one-key-cpufriend) are known for creating bad frequency vectors so be careful with tools not used by Dortania. +Also note that incorrect frequency vectors can result in wake issues, so either verify you're using the correct SMBIOS or adjust the frequency vectors of your current SMBIOS with CPUFriend. Tools like [one-key-cpufriend](https://github.com/stevezhengshiqi/one-key-cpufriend) are known for creating bad frequency vectors so be careful with tools not used by Dortania. A common kernel panic from wake would be: @@ -180,7 +176,7 @@ Sleep Wake failure in EFI **For AMD**: -Fret not, for their is still hope for you as well! [AMDRyzenCPUPowerManagement.kext](https://github.com/trulyspinach/SMCAMDProcessor) can add power management to Ryzen based CPUs. Installation and usage is explained on the repo's README.md +Fret not, for their is still hope for you as well! [AMDRyzenCPUPowerManagement.kext](https://github.com/trulyspinach/SMCAMDProcessor) can add power management to Ryzen based CPUs. Installation and usage is explained on the repo's README.md ## Other Culprits @@ -206,6 +202,7 @@ For the middle, macOS's lid wake detection can bit a bit broken and you may need ```sh sudo pmset lidwake 0 ``` + And set `lidewake 1` to re-enable it. The latter requires a bit more work. What we'll be doing is trying to nullify semi random key spams that happen on Skylake and newer based HPs though pop up in other OEMs as well. This will also assume that your keyboard is PS2 based and are running [VoodooPS2](https://github.com/acidanthera/VoodooPS2/releases). @@ -250,7 +247,7 @@ IRQ issues usually occur during bootups but some may notice that IRQ calls can b This will provide you with both SSDT-HPET.aml and `oc_patches.plist`, You will want to add the SSDT to EFI/OC/ACPI and add the ACPI patches into your config.plist from the oc_patches.plist ### Audio - + Unmanaged or incorrectly managed audio devices can also cause issues, either disable unused audio devices in your BIOS or verify they're working correctly here: * [Fixing Audio](../universal/audio.md) diff --git a/universal/spoof.md b/universal/spoof.md deleted file mode 100644 index f43b0b62..00000000 --- a/universal/spoof.md +++ /dev/null @@ -1,127 +0,0 @@ -# Disabling GPU - - - - - -So you need to hide your unsupported GPU? Well with OpenCore things are slightly different, specifically that we need to specify to which exact device we want to spoof. There are 3 ways we can do this: - -* Boot Flag - * Disables all GPUs except the iGPU -* DeviceProperties - * Disables GPU on a per-slot basis -* SSDT - * Disables GPU on a per-slot basis - -**CSM must be off in the BIOS for the spoofing to work correctly, especially on AMD CPU based systems.** - -### Boot Flag - -By far the simplest way, all you need to do is add the following boot-arg: - -`-wegnoegpu` - -Do note that this will disable all GPUs excluding the iGPU. - -### DeviceProperties Method - -Here is quite simple, find the PCI route with [gfxutil](https://github.com/acidanthera/gfxutil/releases) and then create a new DeviceProperties section with your spoof: - -``` -path/to/gfxutil -f GFX0 -``` - -And the output will result in something similar: - -``` -DevicePath = PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0) -``` - -With this, navigate towards `Root -> DeviceProperties -> Add` and add your PCI route with the following properties: - -| Key | Type | Value | -| :--- | :--- | :--- | -| name | data | 23646973706C6179 | -| IOName | string | \#display | -| class-code | data | FFFFFFFF | - -![](../images/extras/spoof-md/config-gpu.png) - -### SSDT Method - -There are many ways to find the path but generally, the easiest way is to get into Device Manager under windows and find the PCI path. - -Example of device path: - -`\_SB.PCI0.PEG0.PEGP` - - DefinitionBlock ("", "SSDT", 2, "hack", "spoof", 0x00000000) - { - External (_SB_.PCI0.PEG0.PEGP, DeviceObj) // (from opcode) - - Method (_SB.PCI0.PEG0.PEGP._DSM, 4, NotSerialized) // _DSM: Device-Specific Method - { - If (LOr (LNot (Arg2), LEqual (_OSI ("Darwin"), Zero))) - { - Return (Buffer (One) - { - 0x03 - }) - } - - Return (Package (0x0A) - { - "name", - Buffer (0x09) - { - "#display" - }, - - "IOName", - "#display", - "class-code", - Buffer (0x04) - { - 0xFF, 0xFF, 0xFF, 0xFF - }, - - "vendor-id", - Buffer (0x04) - { - 0xFF, 0xFF, 0x00, 0x00 - }, - - "device-id", - Buffer (0x04) - { - 0xFF, 0xFF, 0x00, 0x00 - } - }) - } - } - -A copy of this SSDT can be found here: [Spoof-SSDT.dsl](https://github.com/dortania/OpenCore-Install-Guide/blob/master/extra-files/Spoof-SSDT.dsl) You will need [MaciASL](https://github.com/acidanthera/MaciASL/releases) to compile this. Remember that `.aml` is assembled and `.dsl` is source code. You can compile with MaciASL by selecting File -> Save As -> ACPI Machine Language. - -Source: CorpNewt - -## Windows GPU Selection - -Depending on your setup, you may find that Windows renders games or applications using an undesired GPU. - -Many users only have two GPUs. Nvidia and the Intel HD/UHD IGPU. Since Nvidia no longer works on macOS, they may have the monitor plugged into the motherboards HDMI/DP connection for convenience. As a result, Windows will render all games and applications through the IGPU. You can reroute a specific game or application to a different GPU by going to: Settings > System > Display > Graphics settings - -![Credit to CorpNewt for image](../images/extras/spoof-md/corp-windows.png) - -The rendered game or application will have its buffer copied to the IGPU. Which is then displayed to you. This does come with a few downsides: - -- GSync will no longer work. -- Nvidia settings can no longer be opened. -- Decreased frame rate. -- Increased input latency. -- Refresh rate cap. - -If your motherboard only has an HDMI connector for the IGPU, the maximum refresh rate for spec 2.1 is [120Hz](https://www.hdmi.org/spec21Sub/EightK60_FourK120). This assumes your board, cable and monitor are of the same spec. This means your 144Hz monitor is only seeing a maximum of 120Hz as determined by the hardware. This limitation *does not* apply if your board has a DP connector for the IGPU. - -If you have more than two GPUs (AMD, Nvidia and Intel), this setting is limited. A monitor connected to the AMD GPU means Windows will only allow you to select the AMD GPU or the Intel IGPU. The Nvidia GPU will not show. - -Note: GSync and NV Settings requires the display to be connected to the GPU. As a recommendation, if you use both operating systems equally your best option is an HDMI or DP switch. diff --git a/universal/update.md b/universal/update.md index 0f14d6df..0b7f8516 100644 --- a/universal/update.md +++ b/universal/update.md @@ -1,9 +1,5 @@ # Updating OpenCore and macOS - - - - ## Updating OpenCore So the main things to note with updating OpenCore: @@ -16,23 +12,23 @@ So the main things to note with updating OpenCore: So the process goes as follows: -1. **Download the latest release of OpenCore** +### 1. **Download the latest release of OpenCore** * [OpenCorePkg](https://github.com/acidanthera/OpenCorePkg/releases) -2. **Mount your EFI** +### 2. **Mount your EFI** * So first, lets mount your hard drive's EFI and make a copy somewhere safe with [MountEFI](https://github.com/corpnewt/MountEFI). We won't be updating the drive's EFI at first, instead we'll be grabbing a spare USB to be our crash dummy. This allows us to keep a working copy of OpenCore in case our update goes south * For the USB, it must be formatted as GUID. Reason for this is that GUID will automatically create an EFI partition, though this will be hidden by default so you'll need to mount it with MountEFI. -![](../images/post-install/update-md/usb-erase.png) + ![](../images/post-install/update-md/usb-erase.png) * Now you can place your OpenCore EFI on the USB -![](../images/post-install/update-md/usb-folder.png) + ![](../images/post-install/update-md/usb-folder.png) -3. **Replace the OpenCore files with the ones you just downloaded** +### 3. **Replace the OpenCore files with the ones you just downloaded** * The important ones to update: @@ -44,7 +40,7 @@ So the process goes as follows: ![](../images/post-install/update-md/usb-folder-highlight.png) -4. **Compare your config.plist to that of the new Sample.plist** +### 4. **Compare your config.plist to that of the new Sample.plist** * With this, there's a couple ways to do this: @@ -55,9 +51,9 @@ So the process goes as follows: * Once you've made the adjustments and made sure you config is compliant with the newest release of OpenCore, make sure to double check your setting with the OpenCore Guide on what to set everything to, otherwise read the [Differences.pdf](https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Differences/Differences.pdf) if you want to get a bit more technical. -![](../images/post-install/update-md/oc-config-compare.png) + ![](../images/post-install/update-md/oc-config-compare.png) -4. **Boot!** +### 5. **Boot!** * Once everything's working with the dummy USB, you can mount the EFI and move it over to the hard drive's EFI partition. Remember to keep a copy of your old EFI in cases where OpenCore is acting funny down the road @@ -78,7 +74,7 @@ So the process goes as follows: * I've also provided a bit more of a detailed map of what's changed in macOS versions, see below: -**macOS Catalina** +**macOS Catalina**: * 10.15.0 * [Requires proper EC](https://dortania.github.io/Getting-Started-With-ACPI/) @@ -101,3 +97,14 @@ So the process goes as follows: * 10.15.5 * UHD 630's framebuffer broke for many, if you receive black screen you may need to swap from `07009B3E` to `00009B3E` * Comet Lake S no longer requires a CPU ID spoof +* 10.15.6 + * No change + * Requires all previous fixes for 10.15.5 +* 10.15.7 + * No change + * Requires all previous fixes for 10.15.5 + +**macOS Big Sur**: + +* 11.0.1 + * See here: [OpenCore and macOS 11: Big Sur](https://dortania.github.io/OpenCore-Install-Guide/extras/big-sur/) diff --git a/usb/amd-mapping/amd.md b/usb/amd-mapping/amd.md index d4d585dc..2bcef7e6 100644 --- a/usb/amd-mapping/amd.md +++ b/usb/amd-mapping/amd.md @@ -90,7 +90,7 @@ So what kind of data do we shove into this plist? Well, there are a couple of se > How do I know which ports are 2.0 and which are 3.0? -Well, the easiest way is grabbing a USB 2.0 and USB 3.0 device, then write down which ports are are what type from observing IOReg. +Well, the easiest way is grabbing a USB 2.0 and USB 3.0 device, then write down which ports are what type from observing IOReg. * **Remember**: USB 3.0 ports have dual personalities, so you **must** test both a 2.0 drive and 3.0 to know which ports are associated with it in IOReg. @@ -132,7 +132,7 @@ In this DSDT, we're missing HS02, HS03, HS04, HS05, etc. When this happens, we a An odd issue with some OEM's ACPI is that they never actually define or properly name the USB ports. And so when macOS's IOService starts scanning and building the ports, they're given a generic name. This makes it difficult to really know where your ports are. -To resolve this, we can simply add names with our USBmap.kext, this is thanks to us mathcing the USB map based off of the USB port's location instead of by name. +To resolve this, we can simply add names with our USBmap.kext, this is thanks to us matching the USB map based off of the USB port's location instead of by name. So before you USB map, you'll get something like this: @@ -162,7 +162,7 @@ Finally, grab IOreg and look for your USB controller: ![](../../images/post-install/usb-md/iopathmatch.png) -From here, pay very close attention to which actual device I selected. Specifically the child of of `XHC0@0,3` being `XHC0@61000000`, reason for this is that's our Root-hub(or what macOS uses to enumerate ports) The child with the same name is actually a root hub but does not concern us +From here, pay very close attention to which actual device I selected. Specifically the child of `XHC0@0,3` being `XHC0@61000000`, reason for this is that's our Root-hub(or what macOS uses to enumerate ports) The child with the same name is actually a root hub but does not concern us Now copy the `XHC0@61000000` entry and paste it back into the `IOPathMatch` entry in our USBmap.kext's info.plist, this should result in quite a long path name: diff --git a/usb/intel-mapping/intel.md b/usb/intel-mapping/intel.md index 52811616..9343e96f 100644 --- a/usb/intel-mapping/intel.md +++ b/usb/intel-mapping/intel.md @@ -4,7 +4,7 @@ Table of Contents: -* [Intel USB Mapping](#intel-usb-mapping) +* [Intel USB Mapping](#Intel-usb-mapping) So with the prerequisites out of the way, we can finally get to the meat of this guide. And now we get to finally read one of my favorite books before I go to bed each night: [The Advanced Configuration and Power Interface (ACPI) Specification!](https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf) @@ -34,7 +34,7 @@ Now open up USBmap.command and select `D. Discover Ports`: The interface for USBmap is quite simple and easy to grasp so won't go into detail here, the [README.md](https://github.com/corpnewt/USBMap) should do you well enough. The basic idea is insert a device, give it a name to remember the port by, remove and then try another port until you have a whole list of ports you want to keep. -* **Note**: USRx(ie. USR1, USR2) ports are not real USB ports, they're specifically [USBR ports](https://software.intel.com/content/www/us/en/develop/documentation/amt-developer-guide/top/storage-redirection.html) which macOS has no support for(and why real Macs don't have this). These can be excluded from your USB map. +* **Note**: USRx(ie. USR1, USR2) ports are not real USB ports, they're specifically [USBR ports](https://software.Intel.com/content/www/us/en/develop/documentation/amt-developer-guide/top/storage-redirection.html) which macOS has no support for(and why real Macs don't have this). These can be excluded from your USB map. Once you're done discovering your ports, select `Press Q then [enter] to stop` then head to `P. Edit Plist & Create SSDT/Kext` from the main menu. diff --git a/usb/manual/manual.md b/usb/manual/manual.md index dda268f7..20d1e958 100644 --- a/usb/manual/manual.md +++ b/usb/manual/manual.md @@ -1,6 +1,6 @@ # USB Mapping -So with the prerequisites out of the way, we can finally get to the meat of this guide. And now we get to finally read one of my favourite books before I go to bed each night: [The Advanced Configuration and Power Interface (ACPI) Specification!](https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf) +So with the prerequisites out of the way, we can finally get to the meat of this guide. And now we get to finally read one of my favorite books before I go to bed each night: [The Advanced Configuration and Power Interface (ACPI) Specification!](https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf) Now if you haven't read through this before(which I highly recommend you do, it's a thrilling tale), I'll point you to the meat of the USB situation: @@ -19,7 +19,6 @@ Here we're greeted with all the possible USB ports in ACPI: ## USB Mapping: The manual way - This section is for those who want to get down into the meats of their hackintosh, to really understand what it's doing and help if there's any issues with USBmap.py and other mapping tools. To start, we'll need a few things: * Installed version of macOS @@ -32,7 +31,7 @@ This section is for those who want to get down into the meats of their hackintos * [IORegistryExplorer.app](https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-302.zip) * To view the inner workings of macOS more easily * If you plan to use Discord for troubleshooting, [v2.1.0](https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-210.zip) is a bit easier on file size. -* [USBInjectAll]() +* [USBInjectAll](https://bitbucket.org/RehabMan/os-x-usb-inject-all/downloads/) * This is only required for older USB controllers like Broadwell and older, however some Coffee Lake systems may still require it * **Reminder** this kext does not work on AMD * [Sample-USB-Map.kext](https://github.com/dortania/OpenCore-Post-Install/blob/master/extra-files/Sample-USB-Map.kext.zip) @@ -51,7 +50,6 @@ For this example, lets try and map an Asus X299-E Strix board: ![](../../images/post-install/manual-md/initial-boot.png) - From the above image we can see 3 USB controllers: * PXSX(1, Top) @@ -64,7 +62,7 @@ Now I personally know which USB controllers match up with which physical ports, **Note**: The AppleUSBLegacyRoot entry is an entry that lists all active USB controllers and ports, these are not USB controllers themselves so you can outright ignore them. -**Note 2**: Keep in mind every motherboard model will have a unique set of port combos, controller types and names. So while our example uses PXSX, yours might have have the XHC0 or PTCP name. And quite common on older motherboards is that you may only have 1 controller, this is alright so don't stress about having the exact same setup as the example. +**Note 2**: Keep in mind every motherboard model will have a unique set of port combos, controller types and names. So while our example uses PXSX, yours might have the XHC0 or PTCP name. And quite common on older motherboards is that you may only have 1 controller, this is alright so don't stress about having the exact same setup as the example. Common names you can check: @@ -76,7 +74,7 @@ Common names you can check: * XHCI * XHCX * AS43 - * PTXH + * PTXH * Commonly associated with AMD Chipset controllers * PTCP * Found on AsRock X399 @@ -95,14 +93,12 @@ To start, I'm going to plug a USB device into my front USB 3.1(Type-A) and 3.2(T ![](../../images/post-install/manual-md/front-io-plugged.png) - Next lets look at IOReg, and we can see where our USB devices fell: | USB-C | USB-A | | :--- | :--- | | ![](../../images/post-install/manual-md/usb-c-test.png) | ![](../../images/post-install/manual-md/usb-a-test-3.png) | - Here we see a few things: * Front 3.2 Type-C is on the PXSX(2, middle) Controller @@ -125,14 +121,14 @@ We see that the USB 2.0 personality of our 3.0 port is `XHCI -> HS03`, now you s * Front Type-A: * HS03: 2.0 Personality * SS03: 3.0 Personality - + **Note**: If your USB ports show up as either AppleUSB20XHCIPort or AppleUSB30XHCIPort, you can still map however it will be a bit more difficult. Instead of writing down the names, pay very close attention to the `port` property on the right hand side: ![](../../images/post-install/manual-md/location-id.png) ### Creating a personal map -This is where we pull out out pen and paper, and start to write down which ports physically match up with which digital ports. An example of what your map can look like: +This is where we pull out pen and paper, and start to write down which ports physically match up with which digital ports. An example of what your map can look like: | Name Mapping | Property Mapping | | :--- | :--- | @@ -155,14 +151,13 @@ Next lets map our USB-C port, this is where it gets quite tricky as you may have | 9 | Type C connector - USB 2.0 and USB 3.0 with Switch | Flipping the device **does not** change the ACPI port | | 10 | Type C connector - USB 2.0 and USB 3.0 without Switch | Flipping the device **does** change the ACPI port. generally seen on 3.1/2 motherboard headers | -So when we map our USB-C header, we notice it occupies the SS01 port. But when we flip it, we actually populate it on the SS02 port. When this happens, you'll want to write this down for when we apply the port type. +So when we map our USB-C header, we notice it occupies the SS01 port. But when we flip it, we actually populate it on the SS02 port. When this happens, you'll want to write this down for when we apply the port type. * Note: All personalities from this port will be put under the Type 10 * Note 2: Not all USB-C headers will be Type 10, **double check yours** ![](../../images/post-install/manual-md/usb-c-test-2.png) - ### Continuing mapping Now that you have the basic idea, you'll want to go around with every USB port and map it out. This will take time, and don't forget to write it down. Your final diagram should look similar to this: @@ -185,7 +180,7 @@ Keep this in mind, as this plays into the Type 255 and getting certain services #### USRx Ports -When mapping, you may notice some extra ports left over, specifically USR1 and USR2. These ports are known as "USBR" ports, or more specifically [USB Redirection Ports](https://software.intel.com/content/www/us/en/develop/documentation/amt-developer-guide/top/storage-redirection.html). Use of these is for remote management but real Macs don't ship with USBR devices and so has no support for them OS-wise. You can actually ignore these entries in your USB map: +When mapping, you may notice some extra ports left over, specifically USR1 and USR2. These ports are known as "USBR" ports, or more specifically [USB Redirection Ports](https://software.Intel.com/content/www/us/en/develop/documentation/amt-developer-guide/top/storage-redirection.html). Use of these is for remote management but real Macs don't ship with USBR devices and so has no support for them OS-wise. You can actually ignore these entries in your USB map: ![](../../images/post-install/manual-md/usr.png) @@ -211,8 +206,6 @@ Next, open our newly downloaded SSDT with maciASL, you should be presented with Now, open IOReg and find the USB controller you want to reset(pay very close attention its the USB controller and not the child RHUB with the same name): - - If you look to the right side, you should see the `acpi-apth` property. Here we're going to need to translate it to something our SSDT can use: ```sh @@ -257,7 +250,6 @@ Scope (_SB.PC00.RP05.PXSX.RHUB) <- Renamed ![](../../images/post-install/manual-md/ssdt-rhub-fixed.png) - Once you've edited the SSDT to your USB controller's path, you can export it with `File -> SaveAs -> ACPI Machine Language Binary`: ![](../../images/post-install/manual-md/ssdt-save.png) @@ -266,13 +258,12 @@ Finally, remember to add this SSDT to both EFI/OC/ACPI and your config.plist und ## Creating our kext -Its the time you've all been waiting for, we finally get to create our USB map! +Its the time you've all been waiting for, we finally get to create our USB map! First off, we'll want to grab a sample USB map kext: * [Sample-USB-Map.kext](https://github.com/dortania/OpenCore-Post-Install/blob/master/extra-files/Sample-USB-Map.kext.zip) - Next right click the .kext, and select `Show Package Contents`. then drill down to the info.plist: | Show Contents | info.plist | @@ -372,15 +363,15 @@ And a reminder of all possible port types: | 10 | Type C connector - USB 2.0 and USB 3.0 without Switch | Flipping the device **does** change the ACPI port. generally seen on 3.1/2 motherboard headers | | 255 | Proprietary connector | For Internal USB ports like Bluetooth | -It should be coming full circle now, as you can see how our previous work with mapping out our ports works. +It should be coming full circle now, as you can see how our previous work with mapping out our ports works. #### Name -The name property is actually the name of the USB port's dictionary, and is used solely for house keeping. Keep in mind every USb port you want to use needs to have its own unique USB port dictionary. +The name property is actually the name of the USB port's dictionary, and is used solely for house keeping. Keep in mind every USB port you want to use needs to have its own unique USB port dictionary. -The name itself holds no value besides showing up in IOReg and so this can be whatever you like. To keep this sane, we use the name already given by our ACPI tables(in this case HS01) but the name can be any 4 character entry. However do not go over this 4 char limit, as unintended side effects can happen. +The name itself holds no value besides showing up in IOReg and so this can be whatever you like. To keep this sane, we use the name already given by our ACPI tables(in this case HS01) but the name can be any 4 character entry. However do not go over this 4 char limit, as unintended side effects can happen. -* Note: Those with AppleUSB20XHCIPort or AppleUSB30XHCIPort names for USB ports, you should choose a name easy to identify. On intel, this is HSxx for 2.0 personalities and SSxx for 3.0 personalities +* Note: Those with AppleUSB20XHCIPort or AppleUSB30XHCIPort names for USB ports, you should choose a name easy to identify. On Intel, this is HSxx for 2.0 personalities and SSxx for 3.0 personalities ![](../../images/post-install/manual-md/name.png) @@ -413,7 +404,7 @@ Once your saved your USB map's info.plist, remember to add the kext to both your Next, remove/disable: * USBInjectAll.kext(if you're using it) - * Reason for this is USBInjectAll actually breaks how Apple builds port maps. So while it's great for inital port mapping, it can break you final USB map + * Reason for this is USBInjectAll actually breaks how Apple builds port maps. So while it's great for initial port mapping, it can break you final USB map * XhciPortLimit(Under Kernel -> Quirks) * Now that we're finally under the 15 port limit, we no longer need this hacky fix @@ -421,7 +412,6 @@ Then reboot, and check IOReg one last time: ![](../../images/post-install/manual-md/finished.png) - Voila! As you can see, our USB map applied successfully! The main properties to verify are: @@ -429,6 +419,3 @@ The main properties to verify are: * Correct UsbConnector property on your USB ports * Comment applied(if injected) * Unused ports were removed - - - diff --git a/usb/misc/instant-wake.md b/usb/misc/instant-wake.md index 01c7e5a5..5d9af9cc 100644 --- a/usb/misc/instant-wake.md +++ b/usb/misc/instant-wake.md @@ -23,8 +23,6 @@ And generally you'll get results like these: * `Wake reason: RTC (Alarm)` * Generally caused by an app waking the system, quitting said app before you sleep should fix it - - **Do not use all these patches at once**, look through your DSDT and see what you have: | SSDT | ACPI Patch | Comments | diff --git a/usb/misc/keyboard.md b/usb/misc/keyboard.md index de7a8d4e..46e89e08 100644 --- a/usb/misc/keyboard.md +++ b/usb/misc/keyboard.md @@ -96,7 +96,6 @@ NVRAM |---boot-args | Sting | darkwake=514 ``` - The below is more for clarification for users who are already using darkwake or are looking into it, specifically clarifying what values no longer work: * `darkwake=8`: This hasn't been in the kernel since [Mavericks](https://opensource.apple.com/source/xnu/xnu-2422.115.4/iokit/Kernel/IOPMrootDomain.cpp.auto.html) diff --git a/usb/system-preparation.md b/usb/system-preparation.md index 66ced4c0..c13c4100 100644 --- a/usb/system-preparation.md +++ b/usb/system-preparation.md @@ -97,7 +97,7 @@ SMBIOS needing XHC1, EHC1 and EHC2 renames: * MacBookAir5,x and older * MacBookPro11,x and older -Now that we know what renames our SMBIOS need, we can next check the names of our USB controllers. +Now that we know what renames our SMBIOS need, we can next check the names of our USB controllers. ### Checking IOService @@ -106,6 +106,7 @@ Let's take XHC1 and execute the following command: ```sh ioreg -l -p IOService -w0 | grep -i XHC1 ``` + If you see this, you need a rename: | If you see this, you do not need a rename: :-------------------------:|:-------------------------: ![](../images/system-preperation-md/ioreg-name.png) | ![](../images/system-preperation-md/no-rename-needed.png) @@ -117,7 +118,7 @@ ioreg -l -p IOService -w0 | grep -i EHC1 ioreg -l -p IOService -w0 | grep -i EHC2 ``` -**If nothing returns(like with the right image)**, you don't need any renames. +**If nothing returns(like with the right image)**, you don't need any renames. **If one of the 3 entries return(like with the left image)**, you'll need a rename for whatever returns. @@ -130,7 +131,7 @@ If you're in the latter camp, you'll now want to add the needed ACPI renames to But now we must part into 2 sections, depending on which hardware you have: -* [Intel USB Mapping](../usb/intel-mapping/intel.md) +* [Intel USB Mapping](../usb/Intel-mapping/Intel.md) * A more automated process, Intel only however * [Manual USB Mapping](../usb/manual/manual.md) * More step by step process, and is the only way to map AMD and 3rd party USB controllers properly.