[b00t0x]

Prepare the 0.6.1 patch release. Reduce kernel stack usage in bootstrap, display power setup and accelerator dispatch by reusing display-state storage and separating installer calls. Move fatal diagnostic buffers to preallocated storage with a nonblocking ownership guard, and check generated stack frames during builds. DEBUG remains unoptimized; the fixes also apply to RELEASE.

Add an experimental eDP path for already supported mobile Display 13 GPUs, sharing panel setup with Tiger Lake. This adds no GPU IDs. Display 13 eDP has not been tested on physical hardware. Pair with WhateverXe Graphics 0.3.2 in b00t0x/WhateverXe-Graphics#6.

Includes commit 712c5d1 from #6: generated Compat dependency checks retain the 0.5.0 compatibility floor. This PR supersedes #6; its branch can be removed after this PR is merged.

Validation:

• DEBUG and RELEASE builds; 190 CPU/mock and exact-donor tests passed, including concurrent/reentrant scratch-storage checks and stack-budget regressions.
• Final commit 2ab88c5 passed G660/Tahoe DEBUG and RELEASE boot, dual-display visual checks, Metal compute/render, OpenGL, and H.264/HEVC hardware tests. No GPU recoveries or new crash reports.
• Earlier Tiger Lake laptop regression covered brightness/display wake and the accelerator-dispatch fix. The final additional storage revision was tested on G660; it was not rerun on the laptop.
• Fatal paths were verified offline; no live panic was induced. Individual and known direct-call stack measurements do not prove a whole-kernel maximum.

This PR is for review; no merge, tag or release publication is included.

[wjh3520]

First hardware data point for the experimental ADL-P internal eDP path, and it is blocked at the VBT panel identification step.

Hardware: ASUS Zenbook 14 Pro 2022 (N7401ZE), Core i7-12700H, iGPU 8086:46A6 (Alder Lake-P, Iris Xe 96EU, PCI rev 0x0C), internal 2880x1800 OLED on eDP DDI A, no MUX (all outputs go through the iGPU). macOS 15.8, WEX 0.6.1 DEBUG, WhateverXe Graphics installed, boot-args -allow3d -disablegfxfirmware -liludbg -wexdbg -igfxdvmt, iGPU properties framebuffer-patch-enable=01000000 + framebuffer-stolenmem=0000C003. BIOS offers no DVMT setting other than 64 MB.

Result: WEX does adopt the GPU. N97Admission = Yes, N97PhysicalIdentity = 0x46A68086, N97PhysicalMemoryLayout resolves to base 0x70800000, stolen 0x4000000 (64 MB), GTT 0x800000, aperture 0x10000000, so DVMT handling works. But the panel never leaves IONDRVFramebuffer at 19 MB, and:

N97NativeRoutingUnavailable = Yes
N97NativeStartAllowed       = No
WhateverXeFirmwarePorts     = {status=Valid, version=247, present=0x19, unmapped=0}
WhateverXeFirmwarePanel     = {valid=0, type=0, ddi=9, lowSwing=0, hobl=0}

N97NativeBootConnector, N97DisplayVersion and N97GGC are absent, matching the early return after N97NativeRoutingUnavailable is set in adlnBootstrap.

Connector facts are fine. Only one internal && dp port exists (DDI 0, type=0x1806, aux=0x40 = AUX A), so the multiple-internal-panel guard in panelFacts is not the cause:

DDI  type     dvo ddc aux   flags cap  preset
0    0x1806   10  3   0x40  0xC0  0x0  0     dp, INTERNAL, present
3    0x68C6   13  3   0x60  0xC0  0x3  0     dp, present
4    0x68C6   15  4   0x70  0xC0  0x3  0     dp, present

Root cause. Walking the VBT published in TGLVBT (8701 bytes, $VBT ALDERLAKE-P, BDB version 247, header 22, size 8652) with the panelFacts rules, every block it needs is present, correctly sized and not duplicated: 27 = 812 B (needs >= 212), 40 = 34 B, 43 = 305 B, 44 = 78 B (needs >= 56). The single failing condition is:

if(duplicate || !options || optionsSize<1 || options[0]>=16 ||
   !edp || edpSize<212 || (ports.version>=232 && (!power || powerSize<56)))return;

Block 40's payload begins ff 03 33 00 00 00 00 00, so options[0] = 0xFF. This OEM firmware does not populate an LFP panel type, and i915 treats 0xFF as "unset" and falls back to the default index instead of rejecting the block. Here the parse returns before p.valid = true, so nativePPS0() fails, display13Fixed() never sets w.panel, w.selected() stays 0, described() is false, supportedWiring() fails, and bootstrap takes the N97NativeRoutingUnavailable exit. The native framebuffer is then kept off by N97NativeStartAllowed = No, which is why the panel stays on IONDRVFramebuffer.

Since the docs require "one panel identified by VBT, PPS0 and PCH PWM0", a firmware that leaves the type unset cannot ever reach that path.

Suggestion: treat 0xFF as "not specified" and fall back to a default index (matching i915), or add an explicit override property (for example xelp-panel-type) so affected users can supply the index themselves. If index 0 is unsafe when the whole table is unpopulated, the override alone is enough for testing.

vbt.zip is attached; it contains vbt.bin, the 8701-byte VBT as published in TGLVBT (GitHub does not accept .bin directly). Happy to run any DEBUG build or extra collector against this machine if a candidate fix needs verification, and can provide full ioreg -l -w0 -r -c IOPCIDevice output on request.

Note this is not a complaint about the missing feature: internal display on ADL-H/P is explicitly on the roadmap, they just are not there yet. This is only meant to pin down the exact first blocking condition on real hardware.

vbt.zip

[zozado]

ADL-P (0x46A6 rev 0x0C, i5-1240P, Xiaomi Mi Book Pro 16 2022, subsystem 1d72) on macOS 15.8.2 (Build 24H232, xnu-11417.140.69.713.47~2): the whole Display13 bootstrap passes, but the Sequoia MMIO-UC routing fails on exactly ONE pinned fingerprint. 15 of 16 byte checks match on this build, so this may be a small per-servicing offset drift.

What passes on this machine (single boot, ioreg property evidence):

• IGPU WhateverXeDeviceSelection = {1, 0x46A68086, 0x0C, 0x46A68086, 5, 13, 6, 1} (AlderLakeP / XeLPD / ADLPMobile / admitted)
• WhateverXePhysicalGGC = 0xFEC1; fw-dvmt-preallocated-memory = 0x3C (60 MB); TGL VBT parsed ("ALDERLAKE-P"), firmware ports/records/checksum/panel present
• N97PhysicalIdentity 0x46a68086, N97PhysicalRevision 0x0C, N97Admission Yes, N97GTTopologyReady Yes, N97NativeEDRAM 0, N97NativeReservedGGTT Yes, N97NativePreflight Yes, N97NativeMapperAdmission {1,0,0,1}, WEXDisplay13BootReady Yes, TC boot ports all zero (no TC)
• Root: XELPDisplay13DPProbeAvailable Yes, XELPDisplay13TCProbeAvailable Yes, XELPSharedProbeAvailable Yes; WhateverXeWebKitIdentitySymbols Yes, WhateverXeDataAccess Yes

The failing stage (decoded TGLSequoiaMMIOGuard, 20 x u64):

"TGLSequoiaMMIOGuard" = <01000000000000000100000000000000000000104000000000000001000000000604070006040100010000000000000001000000000000000100000000000000010000000000000001000000000000000100000000000000010000000000000001000000000000000100000000000000010000000000000001000000000000000100000000000000010000000000000000000000000000000100000000000000806ccbd38dffffff0000000000000000>

idx	check	value
1	tglVM.enabled (verify bytes + verify-0x3FE0 pin)	1
2	tglVM.pciBAR	0x4010000000
3	BAR length	0x1000000
4	PAT (MSR 0x277)	0x1040600070406 (matches)
5/6/7	pmap_enter_options / IOProtectCacheMode / kernel_map present	1/1/1
8-15	frame, flags@0x159, args@0x35, protection@0x52, nonEPT@0xB8, create@0x1390, update@0x1030, protectFrame	all 1
16	protectCall fingerprint at _IOProtectCacheMode+0xCA	0 (the only mismatch)
17	kernel_map readable	1
18	tglKernelMap	0xffffff8dd3cb6c80
19	overall	0

Consequence chain: TGLMMIOStrongUCRouted No, TGLMMIOStrongUCPreflight No -> N97NativeKernelReady No, N97NativeStartAllowed No, N97NativeProbeBlocked Yes -> AppleIntelTGLGraphics/Framebuffer never attach (ioreg -rxc empty), IOAccelerator absent, system_profiler shows 35 MB placeholder VRAM and "No Kext Loaded", whole UI software-rendered and laggy.

Setup details: OPEN EXACTLY per README: SIP csr-active-config 03080000; boot-args include -allow3d -disablegfxfirmware -igfxdvmt; IGPU DeviceProperties AAPL,ig-platform-id 0x9A490000 + framebuffer-stolenmem 0x0000C003 patch, no device-id spoof (physical 46A6 kept per docs/device-selection.md); drivers 16.0.0 + bundles under /Library installed by WhateverXe Graphics pkg with AuxKC rebuild; WhateverXe DEBUG 0.6.1 + Lilu 1.7.2; WhateverGreen absent.

Question: under which exact xnu build were the 0.6.1 Sequoia fingerprints pinned? If pinning 24H232 is desired, the failing check is only the call-shaped bytes at protect+0xCA; a small window scan around +0xB0..0x110 (result recorded in evidence properties) would locate the real site on this servicing kernel. Happy to run any instrumented build and report the dumps. (Note: new issue creation appears restricted for non-collaborators here, so posting this under #7 - please retarget/delete the comment if you prefer a dedicated tracker.)