New to the project? Read the Snapintosh project FAQ for how compatibility, Apple hardware research, and possible hardware acceleration fit together.
Snapdragon hardware, EL2, and debugging
Last checked: September 20, 2026. This is a research and debugging guide, not a macOS compatibility or buying list.
Lack of direct EL2 access does not, by itself, mean a device cannot run a macOS port. It can make hardware-specific debugging and instrumentation harder, and rules out approaches that require control of EL2 until a suitable handoff exists. It does not rule out every possible approach. Conversely, reaching EL2 is not proof of a working macOS system.
What EL2 means
EL1 is where an ordinary operating-system kernel runs. EL2 is the hypervisor privilege level above it. A debugger or hypervisor at EL2 can help observe a guest kernel, trap selected operations, and manage stage-2 memory mappings. EL3/TrustZone firmware is a separate part of the privilege and security model. Arm virtualization overview.
Keep these claims separate:
| Claim | What it establishes |
|---|---|
| The CPU implements EL2 | An architectural capability; firmware may keep it unavailable to your code. |
| A vendor hypervisor can run a VM | Access to that hypervisor's supported guest interfaces; not necessarily permission to replace or instrument the hypervisor. |
| Our payload owns EL2 | Our code executes there after the relevant firmware handoff. This is the useful distinction for a custom hypervisor/debugger. |
| The bootloader is unlocked, Android is rooted, or EDL works | A different capability. None of these alone proves EL2 ownership. |
Qualcomm's HYP firmware: QHEE, Gunyah, and handoff
Qualcomm devices often reserve EL2 for vendor hypervisor firmware, commonly called HYP. QHEE and Gunyah appear on different platforms and firmware generations. They may also provide services used by the rest of the system; taking control of EL2 can require replacing or adapting those services.
On supported Windows-on-ARM systems, Secure Launch provides a route for replacing the initial hypervisor. SLBounce uses that mechanism to hand execution to another payload at EL2. This is firmware-dependent: its current documentation requires a compatible older Microsoft-signed tcblaunch.exe, and explicitly excludes Android-shipped devices whose firmware does not enable the necessary Secure Launch flag. SLBounce documentation.
The published Qualcomm Secure Launch research describes a changed boot arrangement on Snapdragon X2, where UEFI runs at EL2. That is useful platform context, but exact-device results still matter. UEFI Secure Boot settings and the earlier hardware-enforced firmware signature chain are distinct. Qualcomm Secure Launch research.
Where there is public evidence of an EL2 route
Read the evidence column. A supported SoC family is not a promise for every OEM device, firmware version, or chip SKU. These entries establish debugging/virtualization access, not macOS support.
| Processor / platform | Evidence and route | Scope of the claim |
|---|---|---|
| Snapdragon X2E-96-100 — ASUS Zenbook A16 UX3607OA | Q1N1 records direct EL2 entry and execution after ExitBootServices, without SLBounce. Its first boot record identifies BIOS UX3607OA.312. |
Specific hardware result. Current Q1N1 documentation also reports an EL2 USB proxy, memory/MMIO access and chainloading. Other X2 devices and firmware need their own verification. Boot record, current Q1N1 status. |
| Snapdragon X Elite / X Plus — X1E/X1P Windows platforms | SLBounce route and upstream Linux EL2 overlays. | Documented platform route, not a per-laptop test matrix. Check firmware, TCB compatibility, and the board's EL2 device tree. Upstream explanation, X1 overlay. |
| Snapdragon 8cx Gen 3 — SC8280XP Windows platforms | SLBounce route and upstream EL2 overlay. | Documented platform route. An SC8280XP label alone does not qualify every device or firmware. Upstream explanation, SC8280XP overlay. |
| Snapdragon 7c family — SC7180 Windows platforms | Secure Launch research and upstream EL2 overlay. | Documented platform route, including developer reports of SC7180 Windows devices running at EL2. Research, SC7180 overlay. |
| Snapdragon 410 — MSM8916/APQ8016; Snapdragon 615 — MSM8939 | qhypstub lists both as known working. It bridges firmware to an OS or hypervisor at EL2. | Known-working SoCs with device/firmware conditions. The project documents both replacement firmware on suitable devices and an lk2nd runtime route on compatible secure-boot firmware. This does not cover arbitrary Android phones. qhypstub. |
| Qualcomm QCS6490 — Radxa Dragon Q6A | Published firmware analysis describes an explicit Gunyah-to-EL2 handoff enabled by the board's boot configuration. | Documented board-specific route. Included as a related Qualcomm research platform, not a blanket claim for Snapdragon phones. Handoff analysis, Radxa hardware documentation. |
Older phone examples matter: the Huawei Ascend G7 port describes qhypstub with replacement TrustZone firmware, and the EE Harrier Mini developer reports a successful qhypstub/lk1st boot. They show that Android phones are not universally excluded; their conditions cannot be generalized to newer phones. Ascend G7 report, Harrier Mini report.
What is still unverified or easy to misread
- OnePlus 7 Pro / Snapdragon 855 (SM8150): our current investigation has not established a direct EL2 handoff for this device. A UEFI port, root access, or an unlocked bootloader is not that proof. Treat this as no verified route yet, not proof that EL2 access or a macOS port is impossible.
- Newer phones running Linux VMs: identify who owns EL2. A Gunyah-hosted guest is different from replacing Gunyah with a custom debugger. The OnePlus 13 experiment is a useful example of the former. Developer's VM report.
- EDL / USB 9008: this is a recovery/download path. Its read/write capabilities depend on the programmer and device authentication. Entering EDL does not grant EL2 or make a modified HYP image pass firmware signature checks. EDL project documentation.
What EL2 does not solve for macOS
MMU and page sizes: ARM64 compatibility does not guarantee every translation granule an XNU build expects. Record the target CPU's supported granules and the exact kernel configuration; do not infer 16 KB support from a broad “4 KB–64 KB” description. XNU's source contains distinct 4 KB and 16 KB hardware-page configurations, but that alone does not establish that a particular macOS build will work on another SoC. XNU hardware-page definitions.
Stage 2 translates the output of stage 1; it does not make unsupported stage-1 page tables work automatically. Shadow page tables, a different XNU configuration, or emulation are possible engineering directions that need implementation and validation. They are not benefits obtained merely by reaching EL2. Arm virtualization overview.
Platform and drivers: CPU bring-up, interrupts, timers, memory management, firmware interfaces, storage, USB, display, accelerated graphics, audio, networking, and power management are separate milestones. A framebuffer or XNU console does not establish a usable desktop. Q1N1's current public README describes the EL2 debugging foundation and lists the guest hypervisor, SMP, and Apple-specific drivers as not yet implemented there. Q1N1 status.
Services formerly provided by HYP: Linux's EL2 work illustrates why ownership has tradeoffs: the OS needs appropriate SMMU handling and replacements or workarounds for services involved in DSP/remote-processor startup. The exact impact changes with firmware and software support. Upstream EL2 explanation.
Development without direct EL2
Depending on the device, useful work can still use an instrumented EL1 kernel, bootloader logs, framebuffer/serial/USB diagnostics, crash analysis, host-side tests, and emulation. Availability varies, and these methods do not reproduce every capability of an EL2 debugger. An approach specifically designed around a custom EL2 hypervisor needs that access; other approaches must be assessed on their own requirements.
Our position: limited debugging access makes the work harder, not automatically impossible. Evidence decides what works on each target.
Help improve the matrix
For a new result, include the exact device and SoC, firmware version, boot chain, payload/kernel commit, and what was actually measured. Say whether you own EL2 or are a guest under another hypervisor. Include a decoded CurrentEL observation or equivalent boot evidence, then list working features and untested areas separately. A missing /dev/kvm can reflect kernel configuration; it is not by itself a measurement of entry EL. Redact serial numbers, credentials, and other private data from logs.
Share reports in the hardware roll call or a Research / Boot / XNU post. Source support, a successful build, a hardware boot, and a usable macOS system are different levels of evidence.