Debian port turns Snapdragon-powered Samsung Galaxy Book Go into a Linux daily driver

A developer has published a step-by-step account of running Debian sid on a Samsung Galaxy Book Go, the Snapdragon 7c Gen 2 laptop Samsung ships with Windows on ARM. According to the write-up on dev.to, a small collection of POSIX shell scripts and a single device tree patch were enough to turn a rough community draft into a machine that runs a daily desktop: kernel 7.2.9 with GNOME 50.5 on Wayland, GPU acceleration, Wi-Fi, Bluetooth, speakers, camera, battery and charging reporting, backlight, keyboard, touchpad, power button, and lid suspend all work. The hardware video decoder works in mpv, browsers decode video in software, and the author drafted the article on the laptop it describes.

Why the machine needed a port at all

The Galaxy Book Go has no upstream Linux support. Mainline Linux carries no device tree for it, and Debian's kernel ships only the Acer Aspire 1 tree for the same Qualcomm SC7180 chip. The community draft tree borrows Aspire 1 memory addresses and a keyboard interrupt that its own comment calls wrong.

ACPI is no escape route either, per the dev.to post: a generic ACPI kernel reboots the machine as soon as the SMMU driver loads, and without the SMMU there is no USB and no keyboard. So the laptop must boot with a device tree, and every missing node in that tree means a missing device. Samsung publishes no Linux driver pack for the machine; the only copy of the signed firmware the hardware needs is the factory Windows install.

Bring-up, one reboot at a time

Where a PC kernel discovers its hardware, this kernel knows only what the device tree tells it. Each device needs a tree node, Samsung's firmware, and a board fact, such as an interrupt or power pin, read out of the Windows side. The Aspire 1 configuration served as a starting guess, and four values borrowed from it — keyboard interrupt, display bridge interrupt, audio memory region and speaker data line — were all wrong on this board.

Every guess was tested with a reboot. The author's journal logged 26 boots across the two-day bring-up on 11 and 12 October 2026, plus UEFI shell boots that left no journal entries. Risky changes went in as one-time boots selected with grub-reboot, so a black screen cost a single power cycle rather than an unbootable machine. The scripts and the device tree patch are collected in a GitHub repository named linux-arm-adventures.

From installer to working desktop

The guide's prerequisites tell the story: a Galaxy Book Go (NP340XLA or NP345XLA) with Secure Boot off, a Debian 13 installer stick carrying the community device tree, a USB-C hub with a USB keyboard and Ethernet adapter because USB boot is unreliable plugged straight into the port, the Windows DriverStore directory copied off before Windows was wiped, and a second machine for the SSH rescue path.

Three fixes stand out. First, the installer's stock GRUB menu had no devicetree line, so the installed kernel booted through ACPI and the machine reset — the installed system's journal was empty because it had never booted. A GRUB generator script adds per-kernel entries for normal, safe (without GPU or DSP drivers) and debug boots, each pointing at the device tree. Second, GNOME initially ignored the internal keyboard: the hid-over-i2c device reports a stray axis, udev tagged it as a tablet pad, and a udev rule is needed to clear the tags — and it must match the input0 node, not only the event device, because libinput reads the parent's tags too. Third, five Samsung-signed firmware files, covering the GPU zap shader, modem DSP, Wi-Fi, video codec and audio DSP, exist only in the Windows driver store. Since a bad firmware file can reset a Qualcomm SoC on every boot, each one was staged and tested for a single boot before installation. The modem came up under ath10k_snoc, the video decoder and encoder bound, and the GPU initialised as FD618, letting gnome-shell leave software rendering. The audio DSP initially failed on the Aspire 1 memory region; the guide's later steps address it.

The author also shows where the hardware strains: the laptop has 3.4 GiB of usable memory, and 1.3 GiB sat in swap while a browser, GNOME and a native arm64 coding assistant ran together.

Why it matters

This port is a useful signal for Linux-on-ARM hardware support. It illustrates the current reality of ARM laptops: discovery depends on per-board device trees rather than generic enumeration, vendor firmware lives only inside a Windows install, and even two boards sharing the same SoC differ in interrupts and memory maps. It also shows the gap is closable by individuals — a community draft, a handful of scripts and one patch reached daily-driver status, with a careful methodology (staged firmware, one-shot boot entries) that others can reuse on similar Snapdragon hardware. The remaining limits, software-only browser video decoding and tight memory headroom, mark where work is still needed.