Omarchy on Googlebooks

[birkskyum]

Dell's XPS Googlebook and HP's Googlebook 14 use the same Snapdragon X Elite as the Windows laptops, but they don't start through UEFI. Their bootloader is Depthcharge, the one Chromebooks use, and it starts Android-format boot images. So Linux gets its hardware description from a device tree in the boot image, not from ACPI tables.

Where it stands (30 October). On the XPS Googlebook, whose Android device name is mica, Linux 7.2 with a device tree written for it starts from the unlocked bootloader's "Boot from external drive" menu, from an Android boot image on a USB drive. With the full Omarchy stack the GPU and the panel come up, but it doesn't reach the desktop yet. The logs stop when the audio DSP starts, and that's what is being worked on now. Neither the device tree nor an image is public yet.

Googlebook OS doesn't let the adb shell read its device tree or its firmware without root, so the stock system can't hand over its device tree. What still helps is each model's details, above all from the HP Googlebook 14, whose Android device name we don't know yet.

If you own one, this reads them without changing anything on the laptop. You need a second computer on the same Wi-Fi with Android's platform tools (brew install android-platform-tools on macOS, pacman -S android-tools on Arch).

1. On the Googlebook, open Settings, then About, and tap the build number seven times to turn on Developer options.
2. In Developer options, turn on Wireless debugging and choose Pair device with pairing code.
3. On the other computer, pair and connect with the address and code the Googlebook shows:

   adb pair <ip>:<pairing-port>
   adb connect <ip>:<port>

4. Print its details:

   adb shell 'for p in ro.product.model ro.product.device ro.product.board ro.build.fingerprint; do echo "$p=$(getprop $p)"; done; uname -a'

Post the output of step 4 here.

Please don't unlock the bootloader yet. It wipes the laptop, and there's no image to install on it yet.

[joshkerr]

Here's what my DELL XPS Googlebook reported:

ro.product.model=XPS Googlebook
ro.product.device=mica
ro.product.board=
ro.build.fingerprint=Dell/mica/mica:17/CL3B.260622.276.R5/16693588:user/release-keys
Linux localhost 6.12.81-android16-6-g08dd7534bf44-ab16287118-4k #1 SMP PREEMPT Tue Sep 8 10:57:08 UTC 2026 aarch64 Toybox

• Device: Dell XPS Googlebook, codename mica.
• Build: Android 17 (build CL3B.260622.276.R5), a signed retail user build.
• Kernel: 6.12.81 from Google's android16 kernel branch, 64-bit ARM (aarch64), using 4K memory pages.
• ro.product.board is empty.

The Googlebook's model is a Dell XPS Googlebook, and its chip is a Qualcomm Snapdragon X Elite (X1E80100).

Property	Value
ro.product.manufacturer	Dell
ro.product.model	XPS Googlebook
ro.soc.manufacturer	QTI (Qualcomm)
ro.soc.model	Snapdragon X Elite - X1E80100 - Qualcomm Oryon CPU
ro.board.platform	hamoa (Qualcomm's codename for this chip family)
ro.hardware	android-desktop
CPU cores	12× Qualcomm Oryon (implementer 0x51, part 0x001)

/proc/cpuinfo lists 12 cores, all Qualcomm Oryon (implementer 0x51, part 0x001). That matches the 12-core X1E80100.

ro.hardware.chipname is empty on this device, so the chip name only shows up in ro.soc.model.

[joshkerr]

Here's more from the same XPS Googlebook (mica), read from a plain adb shell with no root. The device tree's property files and /vendor/firmware are blocked, as you said. But node names, the sysfs links from each device to its bound driver, and lsmod can all be read, and together they tell you a lot about the board.

The stock kernel runs at EL2, not under Gunyah

• /dev/kvm exists, ro.boot.hypervisor.protected_vm.supported=1, virtualizationservice is running, and pvmfw is one of the A/B partitions. That's pKVM, which needs the kernel entered at EL2.
• The APSS watchdog (17410000) is bound to msm_watchdog, the SBSA watchdog (1c840000) has no driver, and the gh-watchdog driver is loaded with nothing bound to it.

That matches what mainline's arch/arm64/boot/dts/qcom/x1-el2.dtso sets up. Since your logs stop at the audio DSP, it may matter that this overlay is also where remoteproc_adsp gets iommus = <&apps_smmu 0x1000 0x80> (and remoteproc_cdsp gets <&apps_smmu 0x0c00 0x0>). Mainline needs those to start the DSPs from EL2. If your device tree doesn't have them yet, they may be worth trying. On the stock system the ADSP is 6800000.remoteproc-adsp on qcom_q6v5_pas, and the downstream adsp-loader starts it after boot.

Audio

• Four WSA884x speaker amps: two on the WSA SoundWire bus and two on WSA2, enumerated as …220 and …221 on each bus. That looks like the layout in mainline's x1-dell-thena.dtsi (Inspiron 14 Plus 7441 / Latitude 7455), which has two WSA8845 per bus at reg = <0 0> and <0 1>.
• No WCD938x/WCD939x headset codec is bound on any SoundWire bus. The modules are loaded, but nothing enumerated. That fits: the laptop has no headphone jack.
• The VA macro has pin groups for DMIC 0/1, 2/3, 4/5 and 6/7, plus a GPIO-switched regulator-dmic-en.
• The speaker enable pin groups are wsa_spkr_en01, wsa_spkr_en02, wsa_spkr_en1 and wsa_spkr_en2.
• The machine driver is canoe-asoc-snd, on the downstream SPF/AudioReach stack.

Board peripherals (controller address mapped to its mainline label)

Bus	Address	Driver on stock	Likely
i2c0 (b80000)	0x2c	i2c_hid_of	touchpad
i2c3 (b8c000)	0x08	ps883x_retimer	USB-C retimer
i2c5 (b94000)	0x4b, 0x4f	ptn3222	eUSB2 repeaters
i2c7 (b9c000)	0x08	ps883x_retimer	USB-C retimer
i2c8 (a80000)	0x10	i2c_hid_of	touchscreen (it has one)
i2c10 (a88000)	0x50	cr50_i2c	Google security chip
spi13 (a94000)	cs 0	cros-ec + cros-ec-keyb	ChromeOS EC, keyboard runs through it

The retimers and the touchscreen are where the XPS 13 9345 has them. The touchpad (i2c17 on the 9345) and the keyboard (hid-over-i2c on i2c0 on the 9345) are not. There's also a second cros-ec device, probably the fingerprint MCU, since there's an fpmcu-vcc-regulator node and the crosfp fingerprint HAL.

Other details:

• USB controllers: usb_2, usb_1_ss0, usb_1_ss1.
• PCIe: pcie6a and pcie4. The Wi-Fi driver is qca_cld3_kiwi_v2.
• Display: eDP on mdss_dp3; DP on mdss_dp0 and mdss_dp1.
• 16 GB RAM (ro.boot.ddr_size).
• Bootloader depthcharge-Google_Mica.16702.59.0/Google_Mica.16702.143.0, SKU LNF01-CAG000316-A1.

Still blocked without root: device tree property values, /sys/firmware/fdt, /vendor/firmware, the remoteproc firmware names, /proc/asound, and the I2C device names.

Commands, if an HP Googlebook 14 owner wants to post the same

Read-only, no root. This prints the I2C and SoundWire devices with their bound drivers, every platform device with its driver, /dev/kvm, the loaded modules, and the device tree node names.

adb shell '
for d in /sys/bus/i2c/devices/*-* /sys/bus/soundwire/devices/*; do l=$(readlink $d/driver); echo "$(basename $d) -> $(readlink -f $d) [${l##*/}]"; done
for d in /sys/bus/platform/devices/*; do l=$(readlink $d/driver); echo "$(basename $d) -> ${l##*/}"; done
ls -l /dev/kvm; lsmod
cd /sys/firmware/devicetree/base && find . -type d 2>/dev/null | sort' > googlebook.txt

I can run anything else that works without root.

[adenta]

Hey Josh,

Just shot you an email. I have gotten my device to boot and keyboard, mouse, screen, backlight, and Wi-Fi are all working!

Currently focused on the 4.5 RC, happy to trade notes.