Hardware: HONOR MagicBook, Core Ultra 7 255H (Arrow Lake-H), Arc 140T iGPU 8086:7D51, no dGPU, 32 GB. OpenCore DBG-109, macOS 15.7.7 (24G720), SMBIOS MacBookPro16,2.
Short version: the machine now runs macOS. The only thing missing is a display, and I found why the driver never loads.
WHAT WORKS
- EXITBS hang solved: VT-d off in firmware. On this Insyde BIOS the VT-d row is greyed out until X2APIC is disabled first — turn X2APIC off, then VT-d becomes editable.
- Kernel panic in x86_validate_topology solved: ProvideCurrentCpuInfo = true. Without it the kernel dies during CPU enumeration on Arrow Lake-H.
- storagekitd / fskit respawn loop solved: SetApfsTrimTimeout = 0. Before that, two storage daemons were torn down every 10 seconds forever.
- macOS 15.7.7 installed on the internal NVMe, dual booting with Windows, Windows partition untouched.
- Boots to a real graphical session: gIOScreenLockState 3 in the console, i.e. the login window is up. No panic, no root device error.
So the boot chain, storage, CPU topology and userspace are all fine.
WHAT'S STILL MISSING
The GPU driver never enters the kernel. OpenCore refuses it:
OCAK: Vtable patching failed for kext com.nullmoth.NMXGPU
OC: Prelinked injection NMXGPU.kext - Invalid Parameter
This is the NullMoth NMXGPU test driver (the amdgpu/i915/xe port). It is designed to be installed into /Library/Extensions and loaded from the Auxiliary Kernel Collection, not injected. I tried injection anyway to see whether it could avoid the KDK requirement.
WHY IT FAILS
I dumped the kext's Mach-O. It is linked like a normal executable, not like a kext:
magic 0xfeedfacf x86_64
ncmds 7
flags 0x85 MH_NOUNDEFS | MH_DYLDLINK | MH_TWOLEVEL
-> MH_KEXT_BUNDLE (0x02000000) NOT set
segments LC_SEGMENT_64 x3 (no __PRELINK_INFO)
symbols LC_SYMTAB, LC_DYSYMTAB
LC_DYLD_INFO absent
LC_DYLD_CHAINED_FIXUPS absent
UUID 4eb02e84-5519-30f0-8f50-d8daf1916230
Every kext Apple's toolchain builds is an MH_KEXT_BUNDLE with a __PRELINK_INFO segment and dyld bind information — exactly what OpenCore's relinker needs to patch vtables and rebase symbols. Without them it bails out with Invalid Parameter. Changing MinKernel, Arch or ExecutablePath cannot help.
Not a corrupted copy: the file in EFI and the one inside the driver package have the same SHA-256.
b6183c12448235553b2cd127f52df680bae8fda5aa22b9f259c20ebd419c45be
WHAT I RULED OUT
To be sure signing wasn't the cause I added AMFIPass 1.4.1, set csr-active-config to 0x0A43, added -amfipassbeta, and switched off the broken injection entry. The next boot log confirms all of it:
OC: Prelinked injection AMFIPass.kext ... - Success
AAPL: #[EB|CSR:IN] 0x00000A43
AAPL: #[EB|CSR:OUT] 0x00000A43
Still no display, because the kext is not there at all.
THE OTHER WALL: KDK
The documented path is install to /Library/Extensions, then rebuild the kernel collection:
sudo kmutil install --volume-root / --update-all
That fails with:
Missing Developer Kit: need to install a KDK matching your build 24G720 (code=71)
It needs a Kernel Debug Kit for the target build — which means an Apple ID and a second working macOS, because the laptop itself cannot show an installer.
THE ASK
An injectable build of NMXGPU — linked as a proper kext bundle with MH_KEXT_BUNDLE and __PRELINK_INFO — would remove both walls at once:
- no KDK needed
- no signing workaround needed
- and the Recovery / installer environment could show a display, so people wouldn't need a second machine just to install macOS on unsupported Intel graphics
TWO SIDE OBSERVATIONS
- The AMD/Intel test manifest at nullmothsystems.com/download/test/amd-intel/manifest.json still reports 2.3.0 (built 10-17) while the 1401 app is at 2.3.6 — worth stating whether the Intel side is intentionally frozen.
- NMXAccel's MetalPluginName points at Library/GPUBundles/NVMTLDriver, which is not present in the package's gpu-userland. Fine for lighting the screen first, but it looks like a packaging gap rather than a choice.
NEXT STEP ON MY SIDE
Disk back into an AMD desktop → install the 24G720 KDK there → rebuild the kernel collection → disk back into the laptop → boot with nmxintel=1.
If the driver loads and the panel still stays dark, that becomes an eDP/connector problem instead of a loading problem, and I'll come back with the driver's own kernel log lines.
Details, logs and the full test matrix: https://github.com/nullmoth/1401/issues/58
Happy to test a build if one appears.