[Installer] ASUS GU605MV (Meteor Lake, RTX 4060 dGPU-direct): builder output cannot reach the installer — and three rules that would help

This is not a "help me" report; it is a data point plus proposed builder rules. The machine is described in
nvidia-macos-driver#191-class hardware (RTX 4060 Laptop 10DE:28E0, internal eDP wired to the dGPU), but on a
Meteor Lake CPU and an ASUS/AMI firmware, so it is a different vendor and a different generation from the
HP unit in #191. Full background and the failing boot sequence: see
<nvidia-macos-driver#191 comment> (posted separately).

Machine

Where it goes wrong

The EFI produced for this machine never reaches userspace. Two distinct stages:

Stage 1 (fixed by hand): the firmware DSDT is dropped by Apple's ACPICA.

ACPI Exception: AE_NOT_FOUND, [DSDT] table load failed (20160930/tbxfload-289)
ACPI Error: 18 table load failures, 14 successful

Two firmware-side causes: (a) Apple's ACPICA (20160930) does not execute module-level code, so devices declared
inside a module-level If (...) never exist; (b) the DSDT contains Scope (_SB.PC00.XHCI.RHUB.HS07) where
HS07 only exists inside such an If, so the scope cannot resolve at load time — the 2016 ACPICA treats that as
fatal and throws away the whole table (ACPICA 2026 merely skips it).

Hand fix that took failures 18 → 3: ship a DSDT with the conditional blocks made unconditional (the build
already emits one, 435,063 vs 435,044 bytes, five If (One) wrappers), NOP out that 141-byte scope in place, and
rename GPI0._STA → XSTA for SSDT-GPI0. The remaining 3 failures are ASUS's own dead tables
(MtlP_Rvp, I2Pm_Rvp, St00Ssdt, all referencing a non-existent \_SB.PC00.I2C3 / SNDW) and are harmless.

Stage 2 (not fixed): silent hang after ACPI tables load.

CoreAnalyticsHub start completed
ACPI: FACP / DSDT 06A377 / SSDT ×21
ACPI Warning: Unsupported module-level executable opcode 0x70 …  (36 lines)
ACPI Error: 3 table load failures, 21 successful
pci (build 11:22:54 Jul 14 2025), flags 0xc3080
<silence — no AppleACPICPU line, no panic, CapsLock dead>

pci (build ...) is only IOPCIFamily's banner; the console continues past it. The silence starts after the ACPI
dump and before AppleACPICPU prints its first processor.

Proposed builder rules (the actionable part)

1. Don't use SSDT-PLUG-ALT on this firmware. It declares 48 CPU objects on top of the firmware's own 48
   ACPI0007 nodes (PR00..PR47), which produces an intel_startCPU page fault. A 98-byte SSDT-PLUG that only
   adds _DSM/plugin-type to \_SB.PR00 works.
2. Bake DSDT byte fixes into the file, not into ACPI → Patch. OpenCore applies ACPI → Patch before
   ACPI → Add, so TableSignature=DSDT patches never reach an injected DSDT.aml — the build's own renames
   silently do nothing. (This cost several hours here.)
3. Never replace _CRS. Firmware _CRS declares no memory window above 4 GB while both GPUs' BARs are above
   4 GB; a static replacement with a 32 GB window — with the bus range narrowed or unchanged — hangs PCI
   configuration on every boot. Leave the firmware method in place.

Also worth knowing: ResizeAppleGpuBars = 0 / ResizeGpuBars = -1 does work here (OpenCore log:
RBAR 2/3 supports 0x3FC0 … setting from 13 to 6, i.e. 8 GB → 64 MB), and Above 4G Decoding is effectively on
even though the BIOS exposes no toggle (the 4060's BAR1 is at 0x60_0000_0000).

What did not help (single-variable, real boots)

All 9 firmware CPU power SSDTs dropped (namespace then has no _PSS/_CST/_PDC/_PCT/_PPC at all) · all 83 _INI
renamed to XINI · all 170 _STA renamed to XSTA · com.apple.driver.AppleUSBXHCI blocked entirely ·
WhateverGreen removed · cpus=1 · npci=0x2000 · SetupVirtualMap true/false · BIOS HT/E-cores off.
None of them move the stop point.

Question

Can the 1401 build be taught (rule asus-mtl-dsdt?) to emit the If (One) DSDT plus the two byte fixes above?
That alone takes any ASUS Meteor Lake unit from "macOS refuses the firmware namespace" to "all tables load" —
which is the difference between a boot log with 18 cascading failures and one that only has the last wall left.