Deep sleep on the Galaxy Book4 Edge: why it needed EL2
My daily laptop is a Samsung Galaxy Book4 Edge 14” (Snapdragon X Elite, X1E80100) running Arch Linux ARM and Omarchy. For weeks, closing the lid barely saved any power: suspend drew between about 1.7 and 3.8 W depending on the kernel, so a full battery was gone in a day or two. Windows on the same machine sleeps for days.
This is how it went from there to about 0.9 W, and why the answer turned out to be where Linux runs, not only what it runs.
The counters that tell the truth
Qualcomm SoCs keep sleep statistics in /sys/kernel/debug/qcom_stats. Three of them matter:
cxsd: the main chip power rail (CX) collapsedddr: memory in self-refreshaosd: the always-on subsystem asleep, the deepest state
If cxsd and ddr stay at 0 across a suspend, the SoC never really went to sleep, whatever the kernel log says. On this laptop they stayed at 0 every time.
What Windows asks for
The firmware’s ACPI tables describe the platform’s sleep states for Windows. The deepest one is called DRIPS, and it is reached only when every CPU cluster is in its deepest state. Translated into the PSCI call Linux would make, that is parameter 0x0200C354.
The device tree my kernel used had no system-level idle state at all, so Linux never asked the firmware for DRIPS. Adding it was easy. Getting the firmware to act on it was not.
EL1: the request goes nowhere
On these laptops the firmware starts Qualcomm’s hypervisor (Gunyah) at EL2 on every boot, and Linux runs under it at EL1. At EL1, with DRIPS in the device tree and the PDC wake-up controller in the right mode, the system power domain was entered once per suspend and simply held there. cxsd and ddr stayed at 0. The request reached the hypervisor and stopped.
I’m not the only one. A Surface Pro 11 owner measured 1.06 W with no CX collapse at EL1, and a Dell XPS 13 owner on the linux-arm-msm list zeroed every vote Linux holds at EL1 and still saw cxsd at 0.
EL2: Linux in the hypervisor’s seat
Windows doesn’t run Qualcomm’s hypervisor: it replaces it with Hyper-V through Microsoft’s Secure Launch (tcblaunch.exe), which the firmware accepts. slbounce uses the same mechanism to hand EL2 to Linux instead. My boot chain is now:
- a firmware boot entry that starts a UEFI Shell from the laptop’s own EFI partition
- qebspil, which starts the audio and compute DSPs (at EL1 the hypervisor does this)
- slbounce, with
tcblaunch.exetaken from the laptop’s own Windows install - GRUB, which boots the kernel at EL2
At EL2 the firmware stopped ignoring the request, but it bounced it straight back: millions of system-level entries per suspend, still no collapse. The pieces that got it over the line came mostly from x1e-sleep, which had reached full sleep on an ASUS Vivobook S15:
- The wake deadline. The firmware computes the next wake-up from the EL1 timers. At EL2 Linux uses different timers, so a small module (
el1tmr) writes the real next deadline into the EL1 physical timer before power-down. - Backports from Linux 7.3: the PDC pass-through series, and fixes for the audio (LPASS) macros and the Bluetooth UART, which kept clock and power votes through suspend.
- Votes nobody released: always-on panel supplies, and the audio VA/WSA macros holding their votes forever.
On 19 October the counters finally moved: CX collapse and DDR self-refresh for 97.5 to 99.9 % of each suspend. Since 20 October it is my daily setup, at about 0.9 W for the whole board.
What’s left
Other X1E laptops get to about 0.25 W. The SoC is now asleep almost the whole time, so the rest is board power outside it: regulators left on, the embedded controller, peripherals. That hunt is ongoing.
The bigger catch is that this needs EL2, and EL2 needs Microsoft’s tcblaunch.exe from a Windows install plus a kernel that starts the DSPs itself. A stock distribution boots at EL1 under Gunyah. Every report I’ve found so far reaches full collapse only at EL2, though I’ve asked the author of one Surface Pro 11 result whether theirs was at EL1.
Everything, including the patches, the boot scripts and the measurements, is in book4-edge-linux.
I did this work, and wrote this post, with the help of AI (mostly Claude Code). Every result here was measured on the laptop itself.