Start here

This site documents gbook: bringing mainline Linux up on the Dell XPS Googlebook, a Snapdragon X Elite (X1E80100) ChromeOS laptop whose board name is mica (ChromeOS firmware branch firmware-bluey-16702.B). Everything here is exported from the project’s working repository at a release tag and rebuilt per release; the dates on each page are the dates the facts were read or measured.

Two public ports exist for this machine. The Nura (postmarketOS) port by Anton Bambura installs through pmbootstrap and is the way to get a packaged system today. gbook builds its own kernel image for the ChromeOS kernel partition and a Debian rootfs on a USB stick, and documents the parts the other record leaves open: the ChromeOS boot path (depthcharge, FIT, EL2), the SCMI mailbox stall and the decision it led to, the sound card’s SoundWire wake fix, and a status matrix with a line of evidence for every row.

Where to look:

• Status: what works, where it works, what is upstream, with evidence for every row.
• The guide: How mica boots Linux, SCMI over the CPUCP mailbox, Sound on mica, the device tree compared with the Nura port.
• How-to: Boot a gbook image, with the recovery steps first.
• Reference: Device tree, Local patches, Kernel configuration, Glossary, Releases.
• Decisions, Research and Evidence: the records behind the claims.

There is no image to download yet: the recipes are documented and the public repository holds no binaries. The two released images so far are described on the Releases page by their tag messages.

Nothing on this site has been sent upstream. The project holds its kernel and device-tree submissions until its milestone M5 (decision 0010); four local patches are listed by their status lines only until then.

A warning: this is experimental work on a device whose firmware can refuse to boot an unsigned image or need a recovery stick to return to stock. Read the recovery decisions (0001, 0002) before touching developer mode.

Licence: prose CC BY-SA 4.0, tooling MIT, device tree BSD-3-Clause, patches GPL-2.0-only (details).

About this build

Generated by scripts/export-public.sh from the gbook repository at v2026.11.05-21-gf05400b on 2026-11-05 4:42 PM EST. Files exported: 85, plus the generated pages. Links to files that stay private are plain text. Rebuilt once per release tag; nothing between tags is published.

Licence

gbook: mainline Linux on the Dell XPS Googlebook (mica)
Copyright (c) 2026 m3

This tree carries work under four licences. A file's path says which one applies; the texts are in LICENSES/.

1. Prose: every Markdown file and the site rendered from them.
   Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0): LICENSES/CC-BY-SA-4.0.txt.
   Attribution: "m3, gbook", with a link to this site.

2. Tooling: gate.sh, book.toml, the workflow under .github/, the kernel configuration fragments
   (src/kernel/*.config) and the build-script headers quoted under src/scripts/.
   The MIT License: LICENSES/MIT.txt.

3. Device tree sources (src/dts/*.dts, src/dts/*.fixups): BSD-3-Clause, as their SPDX headers state,
   with the copyright lines they carry (Qualcomm, Aleksandrs Vinarskis, and this project's additions).
   LICENSES/BSD-3-Clause.txt.

4. Kernel patches (src/kernel/patches/*.patch): GPL-2.0-only, as Linux kernel code. Each patch names
   its author; the FROMLIST ones are copies of patches posted to the kernel lists by their authors.
   LICENSES/GPL-2.0-only.txt.

Vendor firmware is not in this tree: src/kernel/firmware.sha256 lists hashes only.

Texts: CC BY-SA 4.0, MIT, BSD-3-Clause, GPL-2.0-only.

How mica boots Linux

The Dell XPS Googlebook does not boot like other Snapdragon X laptops. There is no Qualcomm ABL (Android Bootloader) and no UEFI: the machine runs ChromeOS firmware, and Linux gets in through the door that firmware already has for self-signed kernels (boot-path note, “Answer” and “Route C”). Sources: the boot-path note, the FIT packaging note, the EL2 handoff note, ADR 0001 and ADR 0003.

The firmware stack

The firmware is coreboot plus the depthcharge bootloader, with Android boot support added on top; vboot (verified boot) sets the rules depthcharge enforces about what may run (boot-path note, “Answer”). The firmware build carries no hypervisor image at all, no Gunyah and no QHEE (EL2 handoff note, “1. Firmware chain”, also the table’s source).

Developer mode is the “unlock”

Google’s “Unlock bootloader” menu item is ChromeOS developer mode under a new label, and Android’s “OEM unlocking” switch is the vboot flag that withholds developer boot until it is on. The Chromebook USB-boot settings are preset: in normal mode the firmware turns external boot on and signed-only boot off (boot-path note, “2. Unlock = developer mode”).

“Self-signed” is precise: developer mode takes the keyblock on its hash, but the kernel body must still verify against the keyblock’s own key, so the image is signed with a self-consistent key pair, by convention the public vboot developer keys (boot-path note, “2. Unlock = developer mode”; FIT packaging note, “4. Dev keys”).

The recovery gates come first

Unlocking wipes the device, and nobody had shown that Google’s recovery media restores an unlocked unit or relocks the bootloader. So no unlock happens until Gate 1 passes: recovery media made and booted to the recovery screen, the key combination recorded, the recovery image and build saved, the fingerprint and bootloader version recorded, and the data the next phase needs backed up. The owner does those steps by hand; agents never unlock, flash or enter recovery (ADR 0001, “Context” and “Decision”). On 2026-11-02 Gate 1 passed: Device Recovery Utility media reached the recovery screen and served the installed build. The public recovery zip alone had not passed it, because its build 16471258 is older than the installed 16560795 and anti-rollback might refuse it (ADR 0001, “Update 2026-10-21” and “Update 2026-11-02”).

The route: a FIT image on a ChromeOS kernel partition

vboot treats a GPT entry as bootable when its type is the ChromeOS kernel GUID fe3a2a5d-4f32-41a7-b725-accc3285a309; depthcharge loads the body into its kernel buffer and boots it as a FIT, U-Boot’s Flattened Image Tree (boot-path note, “Route A”). ADR 0003 chose that route on a USB stick: the stock SSD is never written during boot tests, and a bad image falls back to the next partition or the menu, not a brick (ADR 0003, “Decision”, “Consequences”).

The partition holds a vboot kernel blob: a 64 KiB vblock followed by a FIT with one kernel, one device tree blob (DTB) and one ramdisk. mkdepthcharge from depthcharge-tools builds and signs it in one command, wrapping mkimage and vbutil_kernel with the developer keys (FIT packaging note, “Answer” and “1. mkdepthcharge for a custom board”). The firmware’s rules (same note, “2. Compression and the 256 MiB limit”):

The first-boot image is 256 MiB and holds a 128 MiB KERN-A, rewritten whole for every attempt; since milestone M3 the rootfs is partition 2 of the same stick, from 256 MiB on (ADR 0003, “Update 2026-10-21 (first-boot details)”; ADR 0012, decision 3).

Configuration matching. depthcharge prefers google,mica-rev<board>-sku<sku> down to a plain google,mica, ranks each FIT configuration by its best match, and boots /configurations/default when nothing matches (boot-path note, “Route A”). A DTB whose root compatible holds google,mica matches any board-id and sku-id, and the default is a safety net and a trap, since a wrong DTB still boots (FIT packaging note, “Answer”, step 6). On 2026-11-02 the coreboot table reported board-id 3 and no sku-id (first boot, “Result”).

Partition attributes. vboot keeps priority, tries and successful bits in each entry’s GPT attributes: it picks the highest priority above zero and spends a try on each boot of an entry whose successful bit is clear (FIT packaging note, “5. Partition type and attributes”). The project writes cgpt add -t kernel -S 0 -T 3 -P 15, three tries then fall back. pmbootstrap’s -S 1 -T 5 -P 10 is for an installed system: with successful already set, tries are ignored and a kernel that panics is picked again on every boot (same note, “Answer”, step 5).

Entering at EL2

depthcharge jumps to the kernel with a plain branch, no eret, so Linux starts at EL2 with no hypervisor underneath (EL2 handoff note, “Answer”). On 2026-11-02 the first boot logged CPU: All CPU(s) started at EL2 (first boot, “Result”).

Mainline’s hamoa.dtsi assumes Gunyah owns some hardware, so the FIT carries x1e80100-google-mica-el2.dtb: the mica DTS with the kernel’s x1-el2.dtso overlay applied. The overlay enables the Qualcomm APSS watchdog and the PCIe SMMU (the system IOMMU), maps the PCIe controllers onto that SMMU, disables the generic SBSA watchdog, the GPU zap shader and the IRIS video block, and adds iommus to the ADSP and CDSP remote processors (ADR 0003, “Update 2026-10-21 (first-boot details)”; EL2 handoff note, “2. What x1-el2.dtso changes”). Overlays cannot delete properties, so mica’s differences live in the fixups file: it removes those remoteproc iommus again, because the stock mica tree has none, and with them the PAS (peripheral authentication service) driver asks TrustZone for a resource table that mica’s TrustZone refuses with -EIO, leaving the ADSP offline (attempt 2026-11-02-4; fixups header; dts README, “EL2 overlay” row).

The command line and the console

mkdepthcharge prepends kern_guid=%U to the stored command line; at boot depthcharge replaces %U with the kernel partition’s PARTUUID in lowercase, appends cros_secure and writes the result into /chosen/bootargs. The rest is console=ttyMSM0,115200n8 earlycon=qcom_geni,0x894000; the UART address was spelled out because the draft DTS then lacked /chosen/stdout-path, which a bare earlycon needs; the DTS gained it on 2026-10-21 (FIT packaging note, “3. Kernel command line”; dts README, “Console” row).

The console is read through Closed Case Debugging (CCD): with the Google Security Chip (GSC) still locked, a SuzyQ cable exposes the AP (application processor) and EC (embedded controller) consoles, read-only here, though Google’s documentation warns that the AP console is disabled on production devices (ADR 0006, “Context” and “Decision”; boot-path note, “5. Closed Case Debugging”). On 2026-11-02 the AP console carried kernel output only from 0.67 s on, once ttyMSM0 probed; the full log came from ramoops, read back on the next stock boot (first boot, “Channels”).

What the initramfs does

The FIT’s ramdisk holds /init, which finds the block device whose PARTUUID equals kern_guid, takes that device’s parent disk, and requires the disk’s partition 2 to carry the label gbook-root. It mounts that partition on /newroot, moves /dev, /proc and /sys over, and runs switch_root into the Debian rootfs; without it, or on a failed mount, it falls back to capture-and-reboot (ADR 0012, decision 4; the M3 rootfs note, “4.2”). The rootfs path has worked on the device since the 2026-11-04 attempts (status, “Rootfs from USB”).

Since 2026-11-05 /init also enforces “the stock drive is never written”: right after the stick is identified, it sets every other block device read-only at the block layer with blockdev --setro; an unknown GUID locks nothing. It is advisory (root can undo it) and was untested on the device when recorded (ADR 0003, “Update 2026-11-05”).

What this page does not cover

The Nura postmarketOS port installs through pmbootstrap and is the way to get a packaged system today: Dell XPS Googlebook (google-mica). There is no image to download from this site: the recipes are documented in the notes above, and the public repository holds no binaries.

SCMI over the CPUCP mailbox, and why PSCI cpuidle is off

On mica the three CPU clusters take their performance levels from a firmware core, and mainline talks to it with the System Control and Management Interface (SCMI) over a mailbox. That path stalled on most boots, and the board device tree now turns Power State Coordination Interface (PSCI) cpuidle off because of it. The evidence is in the SCMI research note and the recon note, which number boot attempts per day as 2026-11-03-N, shortened to -N below; the decisions are ADR 0008 and ADR 0009.

What SCMI does on this SoC

The mailbox is the CPUSS Control Processor (CPUCP) mailbox controller, qcom,x1e80100-cpucp-mbox, a doorbell between the application processor and the CPUCP (the pinned kernel’s binding, qcom,cpucp-mbox.yaml). The SCMI node uses mailbox channels 0 and 2 with shared memory in SRAM, and each CPU takes its perf domain from scmi_dvfs; the stock tree drives the same block the same way (recon note, “Why”). Up to attempt -7 the mailbox driver was a module and the initramfs loads none, so firmware:scmi deferred forever. With QCOM_CPUCP_MBOX=y (attempt -8), SCMI bound at 0.358 s, read Firmware version 0x20000, and scmi-cpufreq came up on all three clusters, 710.4 MHz to 3417.6 MHz under schedutil (recon note, “Result: pass”). Status lists it as works.

What failed

The next boot, attempt -9, had the same SCMI configuration and failed. From 0.437 s the log shows ten timed out in resp lines about 36 ms apart (the 30 ms default timeout rounded up to jiffies at 250 Hz), then replies for requests the kernel had already dropped: Message for 7 type 0 is not expected!. The version query was among the timeouts, so the base protocol read Firmware version 0x0, and scmi-cpufreq probed with -110 and never retried (research note, section 1). The note reads this as a slow CPUCP, not lost interrupts, since other messages in the same window succeeded (inference). Every upstream x1e80100 SCMI and CPUCP fix was already in the pinned kernel (research note, “Summary”, section 2).

A version of 0x0 carries a hazard. The quirk that forces the fast channel for PERF_LEVEL_GET is declared for Qualcomm firmware from 0x20000 up; with the version unread it stays off, and the driver falls back to the regular message that Sibi Sankar (Qualcomm) said crashes this firmware when idle states are enabled (research note, “Summary” item 5 and section 4, the review thread).

Cold boot versus warm reset

The embedded controller’s console separates cold starts (G3->S5) from warm resets out of running stock Android. On 2026-11-03 SCMI worked in both cold boots and failed in every warm reset; the same image failed warm (-11) and worked cold (-12). The recon note’s inference is that the stock kernel leaves the CPUCP in a state that survives a warm reset, so stock is powered off before every attempt (recon note, “Update: cold boot vs warm reset”, 5:25 PM ET). By 5:59 PM ET three cold starts had given one -110, one run of timeouts and one pass, so a cold start is no guarantee either (recon note, “Update: cold starts fail too”).

Measuring the replies

The research note recommended measuring first, then sizing arm,max-rx-timeout-ms from the measured latency (“Ranked recommendation”). On attempt -22 the trace showed the base protocol’s discovery messages taking 23 to 36 ms each; the implementation-version message took 36.0 ms, which the 30 ms default misses, leaving the version 0x0. Other replies took 155 to 222 ms, four requests timed out at 250 ms (one message twice), and the boot still came up (recon note, “Update: reply latency per message”).

When the CPUCP answers, it answers in milliseconds; on a bad boot single messages wait up to a second or never come, and the window only absorbs that (recon note, “Update: 1000 ms window”). The board DTS carries arm,max-rx-timeout-ms = <1000> on /firmware/scmi. No stock node has it, so the DT README lists it as unverified.

The stall

With cpuidle.off=1 every reply came within 0.1 ms on 3 of 3 cold starts (recon note, “Update: cpuidle.off=1 A/B”). With arm,no-completion-irq (polling) and idle states on, the CPUCP freed the shared-memory channel within 0.1 ms of every request, 3 of 3: the CPUCP is not slow, the completion interrupt is. In interrupt mode every boot counted one mailbox interrupt per reply, all on CPU 0, stalled boots included: the interrupts arrive, late (recon note, “Update: arm,no-completion-irq A/B”).

The wake trace on -32 shows what CPU 0 did during one 534 ms stall: it entered cpuidle state1 (the PSCI retention state cluster_c4) and left it 26694 times, about every 20 µs, while taking only three interrupts. The stall ended when the arch_timer, a Private Peripheral Interrupt (PPI), ran; 6 µs later the mailbox interrupt was taken (recon note, “Update: the wake trace”). The idle counters on -33 showed PSCI refusing the system-level composite state about 598000 times in 95 s (“Update: idle counters”). Removing every domain idle state gave 3 of 3 clean boots (“Update: no PSCI domain idle states”), but two later boots on that tree stalled with zero refusals and CPU 0’s loop at 130000 to 156000 entries (“Update: ADR 0008 is not enough”). A diagnostic kernel patch then routed the mailbox’s Shared Peripheral Interrupt (SPI) to CPU 1: the loop moved with it (CPU 1 at 134862 entries, CPU 0 at 6131) and the reply stalled for 872 ms (“Update: the stall follows the interrupt’s CPU”). The reading, marked inference in every source, is that a core in PSCI retention is woken by a pending SPI but does not take it until a PPI runs.

The A/B tests

The counts are the recon note’s own tally lines (scripts/attempt.sh tally reads machine-recorded boot health; a “clean” boot has no timeout and every reply under 100 ms: status, “What clean means”).

At ten boots, no PSCI cpuidle against domain states present is a one-sided Fisher p of 0.0015; against ADR 0008’s DT it is 0.051 (same section). ADR 0009 later records 0 of 17 (“Update 2026-11-04 (11:24 AM ET)”), the count status carries today.

Two decisions

ADR 0008 (accepted 2026-11-03) deleted the cluster and system domain-idle-states from the board DTS and kept per-CPU retention. The 2026-11-04 boots above showed the stall did not need the composite states, and the ADR was superseded the same day (ADR 0008, “Status” and “Update 2026-11-04”).

ADR 0009 (accepted 2026-11-04) deletes cluster_c4 from cpu_pd0 to cpu_pd11 instead. With no idle state on any CPU, cpuidle-psci does not load and every core idles in WFI, as under cpuidle.off=1; the cluster and system states return to stock, since nothing requests them; the 1000 ms window stays (ADR 0009, “Decision”). Attempt 2026-11-04-4 confirmed it: no cpuidle driver, 78 replies within 0.1 ms, cpufreq on all three clusters (ADR 0009, “Update 2026-11-04 (12:57 AM ET)”). Both ADRs are deliberate deviations from the stock tree under ADR 0004, recorded in the DT README.

What it costs: no core enters PSCI retention and no cluster or the SoC powers down when idle, so idle power is higher by an amount that has not been measured (ADR 0009, “Consequences”). Status lists CPU idle as partial for that reason; the measurement is parked until a battery-only session, because the debug cable powers the bench (status, “CPU idle” and “Idle power”). An s2idle round trip completes on this DT, in WFI, but which low-power state the SoC reaches is unmeasured (ADR 0009, “Update 2026-11-04 (5:01 AM ET)”).

What is still open

• Why a core in retention does not take a pending SPI until a PPI runs: the GIC’s wake path or the PSCI firmware (ADR 0009, “Consequences”).
• Whether the CPUCP also answers within 0.1 ms when every core sleeps: untested (recon note, “Update: what -29 shows and does not”).
• A warm reset from stock now works, 1 of 1, but with the window and ADR 0009 both in place, so which change fixed it is not separated (status, “SCMI after a warm reset from stock”, inference).
• The 1000 ms window stays unverified (recon note, “Update: 1000 ms window”).

A report on the mechanism is drafted. It is held, not sent: under ADR 0010 nothing goes to a mailing list before milestone M5, and the owner reviews and sends it then (ADR 0009, “Update 2026-11-04 (10:07 AM ET)”).

Sound on mica

How the speakers and microphones of the Dell XPS Googlebook (board mica) came to work on mainline Linux. Status lists “Speakers” and “Microphones” as works on the released image v2026.11.05; the Nura port’s wiki lists Audio as Broken as of its 2026-10-31 edit (https://wiki.nura.eco/wiki/Dell_XPS_Googlebook_(google-mica)). Sources: the audio recon note, the DT README, the audio fragment, the patch list. The owner’s hearing reports, with their times, are the evidence that sound came out; the register reads say why.

The hardware

The card is Qualcomm’s qcom,x1e80100-sndcard, model X1E80100-Dell-XPS-13-9345, on the Low Power Audio Subsystem (LPASS). Four WSA8845 smart amplifiers (Qualcomm’s WSA family) sit on two MIPI SoundWire buses, two per bus; four digital microphones (DMICs) hang off the voice-activation (VA) macro. The audio DSP’s topology file loads at the card’s probe, and Debian’s ALSA Use Case Manager (UCM) profile for the XPS 13 9345 resolves through a link the rootfs adds (audio recon note, “Result”).

(audio recon note, “What the boots proved about the mapping”; DT README, “What changed from the 9345”, row “Audio”)

Where the mapping came from

The node was modelled on the Lenovo Yoga Slim 7x tree at the pinned commit a804c57, then checked against the stock ChromeOS tree from the public recovery image: the SoundWire masters and codecs, the shutdown pins, L15B, the VA macro and the DMIC pins trace to the stock base tree, the microphone rail to the stock board overlay. It booted as a TEST IMAGE from 2026-11-04, moved into the board DTS on 2026-11-05 and was proven on the base image over three clean cold boots. One deviation: stock drives the shutdown pins high when active; mica starts them low, the Yoga’s way, and the codec driver’s reset-gpios releases them; all four play that way (DT README, row “Audio”).

The two kernel options that blocked the card

The initramfs loads no modules, so the audio fragment builds in every driver the node needs; all were =m in the arm64 defconfig (audio fragment, header). Two were not obvious. The WSA884x driver asks the reset framework for its shutdown pin; the reset core turns reset-gpios into an auxiliary reset-gpio device and defers the codec until that device’s driver, CONFIG_RESET_GPIO, binds. With it built in (kernel #31) the reset-gpio devices deferred in turn: TLMM 204 and 205 are each shared by two codecs, and the kernel’s shared-GPIO support routes such a pin through a proxy chip that only CONFIG_GPIO_SHARED_PROXY registers. Both are =y since kernel #32, and the card bound on attempt 2026-11-04-28. A distribution kernel loads both as modules, so the Yoga never showed this (audio recon note, “The two blockers, both kernel options”).

The first sound, and the wake problem

The speaker test on boot -28 (2026-11-04, 11:51 PM EST): the owner heard two sounds, one louder and one lower, and the spoken names gave “Front Right” and “Rear Right”; after some minutes, nothing. The masters’ enumerator registers showed one enumerated slot per bus (unique id 1) and a slave stuck at device number 0. The note’s reading (inferred): the right-side units played, the id-0 pair never enumerated, and every re-enumeration after a clock stop failed the same way (audio recon note, “The speaker test”).

The debug boot (2026-11-05, 12:25 AM EST) showed all four amplifiers enumerating at boot, with the unique ids the DT says. The exit from clock stop lost them: after the SoundWire masters runtime-suspend, each wake races the hardware enumerator against the attach interrupts, bus by bus, and which bus wins is chance: both on the first wake, neither on the first tone, one on the second; the owner heard nothing at either tone. With the masters’ runtime power management forced on, both buses re-enumerated and the owner heard “front left, front right, rear right, rear left” (audio recon note, “The debug boot”). A udev rule forcing the masters on was rejected: its own write is the first wake, and on that boot (1:01 AM EST) one bus lost the race and stayed lost (audio recon note, “The udev-rule boot”).

The fix: two local patches, one of them the fix

Both patches carry the same first line, quoted because the files stay unpublished until milestone M5 and the patch list gives them by status line only:

Status: LOCAL gbook (ours; not sent: upstream hold until M5), checked 2026-11-05

Patch 0010 re-arms a stalled SoundWire enumerator in Qualcomm’s master driver (audio recon note, “The udev-rule boot”). Patch 0011 sets clk_stop_mode1 on the WSA884x codec, so every resume of the masters runs the full reset-and-init sequence that has enumerated at every boot, instead of the bare clock restart (audio recon note, “The patch boot, revision 3 and patch 0011”).

With both (kernel #35, 1:34 AM EST) three wakes came back whole, where two earlier revisions of 0010 alone had lost a bus on the first; the owner heard all the beeps each time (same section). The rule-free boot (2:05 AM EST) met the ticket’s bar, a tone after ten minutes idle included (audio recon note, “The rule-free boot”). The 0011-alone boot (kernel #36, 12:32 PM EST) set 0010 aside and every wake came back whole; the owner heard tone 1, tone 2 and the four names twice (12:30 and 12:32 PM EST). So 0011 carries the fix; the owner decided at 12:38 PM EST that 0010 stays until the M5 patch review and is then dropped (audio recon note, “The 0011-alone boot”). The released v2026.11.05 is kernel #35, with both (status, “Speakers”).

The microphones

The capture test (2026-11-05, 9:26 AM EST) enabled UCM’s Speaker and Mic, recorded ten seconds from capture device 3 while the owner spoke, and played the file back through the speakers. The owner heard their own voice. The file, measured on the build host, varies second by second on both channels; the journal has no VA macro, DMIC or LPASS line for the capture. So the mic rail and the DMIC clock work as described (audio recon note, “The capture test”).

Boot by boot

(audio recon note, “Result” through “The 0011-alone boot”)

What is unverified

Audio values the DT README marks as not traced to the stock tree (DT README, “Unverified (check at first boot)”):

• vdd-io-supply L12B on the four codecs: not in the stock codec nodes; every a804c57 X1E80100 board uses it.
• qcom,dmic-sample-rate = <4800000>: the Yoga’s; stock sets only the clock divider 16.
• The 3.3 V EN_PP3300_MIC as vdd-micb-supply: the Yoga’s is a 1.8 V LDO; the stock rail is always-on, so a wrong binding is harmless.
• Which physical unit each UCM prefix (WooferLeft, TweeterLeft, WooferRight, TweeterRight) drives: stock calls swr0’s pair SpkrLeft/SpkrRight and swr3’s Spkr2Left/Spkr2Right; open.

What is left

A read FIFO underflow burst on every wake and two Parity error detected lines remain open; they did not stop playback (audio recon note, “The debug boot”). PipeWire and WirePlumber are not yet in the rootfs; a per-card WirePlumber drop-in is a recorded proposal for when they are (SteamOS on ARM research note, “What gbook could adopt”).

The device tree, compared with the Nura port

Two public device trees describe mica, and both carry the same compatible string, "google,mica", "qcom,x1e80100". This page says how gbook’s tree was built, what the other one does differently, and what the two authors would have to settle before either goes upstream. The comparison was made on 2026-11-05, 2:37 PM EST by compiling both sources against the same pinned kernel tree (torvalds a804c57) and diffing the compiled trees node by node; facts about the other tree are structural (which nodes exist and are enabled, which properties are deleted), not quotations of its text.

gbook’s tree in one paragraph

x1e80100-google-mica.dts starts from mainline’s Dell XPS 13 9345 file, the closest X1E80100 laptop, and changes every board-specific pin to what the stock ChromeOS tree says (the DT README, “What changed from the 9345”). The stock tree is extracted from Google’s public recovery image for this model, so each change cites a line in it; a value with no stock counterpart is listed as unverified (“Unverified (check at first boot)”). The first-boot tree adds a framebuffer reservation at the stock splash address and is built as the board DTB plus mainline’s x1-el2.dtso overlay, followed by mica-el2.fixups, two property deletions that an overlay cannot express (“First-boot additions”). Every enabled node binds since 2026-11-04 (the unbound-nodes note).

The other tree

Anton Bambura’s x1e80100-bluey-mica.dts (authored 2026-10-19, in his kernel tree for the postmarketOS-based Nura port; pmaports merge request 9856 “google-bluey: new device”, merged 2026-11-03) names the board "Google Mica" and includes the same two SoC files, hamoa.dtsi and hamoa-pmics.dtsi. It compiles against a804c57 once one binding header his tree carries is stubbed (a camera orientation header not in the pinned tree), with three dtc warnings about thermal zones that use the PMIC’s ADC as a sensor without a sensor-cells property at this commit. Compiled, the two trees have 1,466 and 1,451 nodes; 1,383 and 1,366 of them are enabled.

What each tree enables that the other does not

The 47 nodes only gbook enables and the 34 only the port enables are counted from the compiled trees; pin-state subnodes make up most of both lists.

Where the two trees make the same choice

• Both enter the kernel at EL2 and both drop the iommus property from the ADSP and CDSP remoteproc nodes. gbook does it with the fixups file after applying mainline’s EL2 overlay; the port folds the overlay’s changes into the source (its commit message says it includes the x1-el2.dtso changes except those two properties, which make the firmware fail to load). The reason gbook recorded on 2026-11-02: with iommus set the driver asks TrustZone for a resource table and mica’s TrustZone answers with an error (the fixups).
• Both load the ADSP and CDSP from the stock firmware. gbook names the stock split files (adsp.mdt and adsp_dtb.mdt) under a lowercase qcom/x1e80100/google/mica/ path and ships hashes only (firmware.sha256, ADR 0005); the port names single .mbn files under a capitalised path and redistributes them in a firmware package. The two paths differ in case, so a rootfs built for one tree will not find the other’s firmware without a symlink (inferred).
• Both keep the console on uart21 and the Bluetooth UART on uart14, and both drive the ChromeOS EC over spi13 with the keyboard matrix behind it.

Where they differ in substance

Whether the port’s machine shows the SCMI stall gbook measured is unknown here: its tree does not change the SCMI timeout or the idle states, and no report either way was found (inferred from the tree alone).

What this means for upstream

One compatible string can have only one board file in mainline. gbook holds every submission until its milestone M5 (ADR 0010); the project’s owner intends to write to the port’s author before then to coordinate a single google,mica tree and to offer the sound description and the SoundWire wake fix. Until that conversation, this page is the diff. The DT README’s “Before sending upstream” list (the binding entry, the block order, the attribution header) applies to whichever tree goes first.

Boot a gbook image on mica

A how-to for one boot attempt of a gbook kernel image from a USB stick, written from the project’s own runbook with the host-specific tooling left out. It assumes you have an image: the build recipe is documented (How mica boots Linux, the kernel configuration and patch pages) and the build scripts are published with a later release. No image download exists yet.

Roles in the project: a person does every key press, every unlock and every write to a stick; an agent builds, checks and reads consoles (ADR 0001). If you are alone, you are both.

Before the first attempt (once)

1. Prove the way back first. Make a Google recovery stick for this model with the ChromeOS recovery tool, boot it once with the recovery keys (Esc + Refresh (F2) + Power) and confirm you reach its screen, then label it and never rewrite it. The project calls this Gate 1; nothing else happens before it passes (ADR 0001).
2. Back up what you care about on the machine. Developer mode wipes user data.
3. Unlock the bootloader on your own responsibility. On this model the steps are Google’s: turn on OEM unlocking in the system’s Developer options, hold Esc + Refresh (F2) + Power to reach the recovery screen, then Advanced options, Unlock bootloader. The firmware screen reads “Bootloader is unlocked” from then on, and self-signed kernels boot from an external drive without further settings (the boot-path note, chromeos-boot-path.md, “Unlock = developer mode”).
4. A second stick for images: USB 3, 4 GB or more, used for nothing else. Keep it visibly different from the recovery stick; the project once put the recovery stick in by mistake and Google recovery ran.
5. Optional but useful: a SuzyQ debug cable in the left port gives the AP console (ADR 0006). Without it the panel and, once Wi-Fi is up, the network log are the only channels.

Write the stick

1. Write the whole image to the stick’s block device with dd, addressing the stick by its stable device path (for example under /dev/disk/by-id/), never by a letter that can change. The image is a complete disk of 256 MiB: a GPT with a 128 MiB ChromeOS kernel partition holding the signed FIT, and, on the same stick from 256 MiB on, a second partition for a rootfs when one is used (ADR 0003).
2. Read the stick back and compare it with the image before you unplug it. Every rewrite also resets the kernel partition’s tries counter: depthcharge spends one try per boot, and the image sets 15.
3. Power the stick off or eject it cleanly, then carry it straight to the laptop.

Boot

1. Power the laptop off. Check: image stick in the right port, no charger, no hub, lid open. Battery at half or more.
2. Power on with no keys held. On the “bootloader is unlocked” screen choose Boot from external drive.
3. Never press the recovery keys with the image stick in. Recovery mode scans the stick for a Google-signed kernel, rejects the developer-signed one and marks the kernel partition bad; the stick then needs a rewrite (the project lost two boots to this on 2026-11-03).
4. If you see “Recovering your device”, the recovery stick is in. Interrupt nothing. It reinstalls the same build and leaves developer mode on; a cut firmware update can brick the device.
5. The first lines appear on the AP console at about 0.6 s and on the panel once the display driver is up. The initramfs prints GBOOK: status lines; with a rootfs on the stick it hands over to it, otherwise it reboots after its sweep. Pull the stick as soon as it reboots so the next boot is stock; with the stick still in, the firmware waits on its boot screen.
6. SCMI needs a cold boot. After a warm reset from stock the CPUCP answers late or not at all and cpufreq fails, so power the machine off before each attempt (SCMI over the CPUCP mailbox).

If nothing appears

Back to stock

Esc + Refresh + Power with the recovery stick in the right port, then “Use USB drive or SD card”. It erases the disk and installs the build the stick carries. The project’s own return-to-stock plan, including the untested probes with a spare SSD, is in the M4 recovery matrix.

Feature status

As of 2026-11-05, 1:57 PM EST. Kernel: torvalds a804c57 plus kernel/patches/0001-0011. Board DTS: dts/x1e80100-google-mica.dts. The default state is “untested”. Every row cites the recon note it rests on, or “none” when no note covers it.

This is the feature matrix of ADR 0010: the milestones note, recommendation 2, which the owner adopted on 2026-11-04 (“all a” to its section 5). Asahi and Nura publish their feature tables the same way.

Patch numbers: 0008 and 0009 here are the PCIe GDSC and PCIe PHY GDSC retention patches. Both numbers named other patches before the rule against reusing numbers. 0008 was a GENI I2C timing test (commit 16a2828, attempt 2026-11-04-2), and 0009 was the IRQ-to-CPU-1 diagnostic (commit cee735d, attempt 2026-11-04-3, deleted by ADR 0009). Recon notes about those two attempts mean the old patches.

Legend

• State: works, partial, broken or untested. A parked row keeps its state, and its note says “parked until ” (ADR 0010, update 2026-11-04).
• Where it works:
  • mainline at a804c57: the driver is unchanged;
  • + patch NNNN: a local patch in kernel/patches/;
  • board DTS: needs the mica device tree;
  • config fragment (name): kernel/<name>.config builds the driver in, because the initramfs loads no modules.
  • These combine as needed; — means it works nowhere yet. In the Upstream column, — means there is nothing to report.
• Upstream: what mainline or linux-firmware already has, and what gbook would have to send.
  • “mica DTS not sent” covers both the board DTS and the google,mica binding (dts/README.md, “Before sending upstream”).
  • The patch words follow ChromiumOS, with LOCAL in place of its CHROMIUM: FROMLIST means posted to a list but not merged, and LOCAL means carried here and not sent.
  • Nothing is sent before M5.
• Evidence: the dated recon note, plus the attempt id where the note gives one. “none” means no note covers the feature.
• Note: kept short. inference marks a judgement call, such as the choice of state.

Boot and consoles

SoC: power, clocks, SCMI/cpufreq, idle, suspend

Storage and buses: USB, Type-C, PCIe, NVMe

Network: Wi-Fi, Bluetooth

Display and GPU

Input and EC

Security

Remoteprocs

Multimedia

Power

Userspace

Milestone M2: where it stands

M2 is done (2026-11-04, 12:38 PM ET): all four criteria are met. Criterion 1 is met by the unbound= proxy, and the s2idle row’s boots ran on test images.

M2 is “board on the console” in ADR 0010, from the milestones note, section 4. The ADR’s bar has four criteria:

1. every enabled DT node binds;
2. the M2 rows read works: USB host, Type-C, PCIe enumeration, Wi-Fi, eDP + backlight, GPU probe, EC keyboard, touchpad, TPM, SCMI cpufreq and the s2idle round trip;
3. every other row reads works or partial, or is parked with a note;
4. one base image (no debug command-line or DT extras) has 3 clean cold boots by scripts/attempt.sh tally.

Under criterion 3, rootfs, Mesa and the audio state are also M3 criteria in the ladder (section 4).

Counts (checked by scripts/status_check.py): 55 rows: 36 works, 5 partial, 3 broken, 11 untested; 14 parked. The line above is the one scripts/check.sh compares with the tables (retro-8/06), so it changes with them.

Criterion 4, read-only from dumps/firstboot/attempts.tsv (gitignored), at 11:24 AM ET:

$ scripts/attempt.sh tally '^2026-11-04-12$'
group 1 /^2026-11-04-12$/: attempts=1 health=1 boots=3 known=3 stalled=0 clean=3 unknown=0 max=0.1-0.1ms
  2026-11-04-12 0/3

• The base image: packaged with no command-line or DT extras; attempt.sh verify recorded “base image: no command-line or DT extras” and image sha256 2f08fb87463eeac6. All three boots started cold (EC G3->S5).
• What “clean” means: in tally, “clean” is an SCMI verdict: no timeout, and every reply under 100 ms (scripts/boot_health.py). It does not judge the whole boot.
• Before 2026-11-04-12 the only row with 0008 + 0009 was 2026-11-04-11, a test image (gbook.suspend=1).
• Next: M3, userspace from USB (a rootfs with Mesa, ADR 0010).

dts

x1e80100-google-mica.dts is the mainline device tree for the Dell XPS Googlebook (mica). Draft, never booted (2026-10-21). Booted since 2026-11-02; each feature’s state is in docs/status.md.

• Experiments: device-tree diagnostics go in diag/ as .dtsi fragments, built on top with GBOOK_DTS_EXTRA, not into this file (2026-11-03).
• Base: forked from arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts at torvalds/linux a804c5742bff224d4cb4d25dd383554d598be32b. The first commit is the unmodified copy, so git log -p shows every mica change. The SoC dtsi at that pin is hamoa.dtsi (with hamoa-pmics.dtsi), not x1e80100.dtsi.
• Board changes: from the stock Googlebook OS tree (stock-dtb.md), mapped to mainline labels in 9345-dts-diff.md. The stock tree is two files: dumps/recovery-16471258/dtbo/entry00-base.dts (the SoC) and entry01-overlay.dts (the board: regulators, the sound card’s overrides, thermal trips). Search both; a value “not in the stock tree” was found in the overlay on 2026-11-04 (retro-12/01).
• Compatible: "google,mica", "qcom,x1e80100", so depthcharge’s FIT matcher (google,mica-rev*-sku* down to google,mica) picks it.

Build and check

scripts/setup-toolchain.sh   # once: sparse kernel checkout at a804c57 + dtschema venv + schema, in ~/.cache/gbook
scripts/build-dtb.sh ~/.cache/gbook/linux-a804c57 dts/x1e80100-google-mica.dts /tmp/mica.dtb   # cpp + dtc, Kbuild W=0
~/.cache/gbook/venv-dtschema/bin/dt-validate -s ~/.cache/gbook/schema-a804c57.json /tmp/mica.dtb
# first-boot DTB: the same base plus the pinned x1-el2.dtbo, applied with fdtoverlay like Kbuild's -dtbs targets
scripts/build-dtb.sh ~/.cache/gbook/linux-a804c57 dts/x1e80100-google-mica.dts /tmp/mica-el2.dtb \
  ~/.cache/gbook/linux-a804c57/arch/arm64/boot/dts/qcom/x1-el2.dtso

scripts/check.sh builds and validates both DTBs, and also fails when the keymap drifts from stock. When the google,mica binding lands, remove its allowance in check.sh.

State 2026-10-21:

• Build: no warnings.
• dt-validate: one finding. google,mica is not yet in Documentation/devicetree/bindings/arm/qcom.yaml; upstreaming needs that binding patch. The unmodified 9345 validates clean with the same schema.
• The keymap in the built DTB is identical to stock (119 entries).
• Every board-specific TLMM pin in the built DTB traces to the stock tree. A programmatic check compared the decompiled DTB with the stock overlay and base. The only other pins are SoC-level states from hamoa.dtsi (QUP UARTs, LPASS) and the PCIe clkreq pins the stock base also sets. No 9345-only pin survived.

What changed from the 9345

Kept from the 9345 and confirmed in the stock tree: retimers and all six rail GPIOs; USB-C orientation GPIOs 121 and 123; eDP 3.3 V on TLMM 70 and HPD on 119; NVMe 3.3 V on TLMM 18; PCIe4 (146-148) and PCIe6a (152-154); Wi-Fi 3.3 V on TLMM 214, WLAN 117, BT 116; uart14 BT; uart21 debug.

First-boot additions

Decided 2026-10-21 (What goes into the first-boot DTB), in the tree since 2026-11-02:

• reserved-memory: framebuffer@e4800000, reg = <0x0 0xe4800000 0x0 0x2200000>, no-map. The address comes from the stock splash_region, the size from coreboot’s reservation.
• The first-boot DTB is x1e80100-google-mica-el2.dtb = this DTB + x1-el2.dtbo from the pinned kernel. scripts/build-dtb.sh and check.sh build and validate both. 2026-11-02: both build with no warnings, both give only the google,mica dt-validate finding, and the -el2 DTB keeps compatible = "google,mica". The reservation overlaps no hamoa.dtsi region (nearest: tags_mem1, ending at 0xe36a0000).

Unverified (check at first boot)

• The left/right labels on the USB-C connectors (copied from the 9345). 2026-11-03: swapped on mica. connector@0 (retimer on i2c3, usb_1_ss0, mdss_dp0) is the left port, connector@1 (i2c7, usb_1_ss1, mdss_dp1) the right one (dp-2026-11-03.md).
• usb_2_hsphy supplies (from other hamoa boards; the stock overlay does not set them).
• usb_mp QMP PHYs: stock disables both, and this draft keeps the 9345’s enabled ones so usb_mp probes.
• The panel model (edp-panel probes it over AUX) and the PWM period.
• The edp_bl_en pin config on PMC8380-3 GPIO 4 (function = "normal", from the T14s; stock has no pin state for it).
• Through the EC, no DT node needed (2026-11-03, attempt -14): keyboard backlight (chromeos::kbd_backlight), fan RPM (cros_ec hwmon).
• Audio (2026-11-05, moved from dts/diag/sound.dtsi): vdd-io-supply L12B on the four codecs (not in the stock codec nodes; every a804c57 x1e80100 board uses it); qcom,dmic-sample-rate = <4800000> (the Yoga’s; stock sets only the clock divider 16); the 3.3 V EN_PP3300_MIC as the VA macro’s vdd-micb-supply (the Yoga’s is a 1.8 V LDO; the stock rail is always-on, so a wrong consumer binding is harmless); which physical unit each prefix (WooferLeft, TweeterLeft, WooferRight, TweeterRight, the UCM profile’s names) drives: stock calls swr0’s pair SpkrLeft/SpkrRight and swr3’s Spkr2Left/Spkr2Right. The speakers play (ticket 16, 2026-11-05). 9:26 AM EST 2026-11-05: capture passed (the owner heard the recording played back, audio-2026-11-04.md, “The capture test”), so the DMIC rate and the mic rail work as written; the values stay the Yoga’s where stock has no counterpart, and the unit-to-prefix question stays open.
• Not described yet: EC PWM, Glowbar, ambient-light sensor (the 9345 file has no sound node at this commit; mica’s is above), camera (USB), fingerprint (USB).

Before sending upstream

• Add google,mica to Documentation/devicetree/bindings/arm/qcom.yaml (x1e80100 boards).
• Reorder the &label blocks alphabetically, as qcom reviewers expect. They are left in place here so the diff against the 9345 copy stays readable.
• Replace the copied 9345 copyright header with the right attribution for a derived file.

Source files

x1e80100-google-mica.dts (the board DTS) and mica-el2.fixups (the differences from mainline’s x1-el2.dtso), as exported.

Kernel configuration fragments

Merged onto the arm64 defconfig in name order after mica-firstboot.config (scripts/build-kernel.sh). A # require: line must end =y in the result; a # forbid-y: line must not. Each fragment’s own header follows. Also here: firmware.sha256 (hashes of the vendor firmware the initramfs stages; the blobs are not redistributed), dt-gaps.txt and known-failures.txt.

mica-adsp.config

Phase 3, ADSP: boot the audio DSP so pmic_glink (Type-C orientation and mode, battery) can come up.
Source: the USB run (docs/recon/usb-2026-11-02.md): pmic-glink stayed deferred with "failed to initialize pdr".
Firmware: the stock modem_a partition's image/adsp.mdt + .bNN and adsp_dtb.mdt + .bNN (build
ADSP.HT.5.9.c5-00032.4-HAMOA-1), packed into the initramfs from ~/.cache/gbook/firmware (ADR 0005: not in git).
The remoteproc driver for qcom,x1e80100-adsp-pas and its helpers (all =m in defconfig at a804c57).
require: REMOTEPROC
require: RPMSG_QCOM_GLINK
require: QCOM_SMEM
require: QCOM_SMP2P
require: QCOM_AOSS_QMP
require: QCOM_IPCC
require: QCOM_PDR_HELPERS
require: QCOM_QMI_HELPERS
require: FW_LOADER

mica-audio.config

M3, audio (ticket 10, 2026-11-04): the sound card of the board DTS (dts/diag/sound.dtsi until 2026-11-05; 4x WSA8845 on swr0 and swr3, 4 DMICs on
the VA macro, the ADSP's APM and PRM services over GPR). scripts/dt-kconfig-map.py on the sound -el2 DTB,
2026-11-04: every driver below was =m, and the initramfs loads no modules. The topology
qcom/x1e80100/X1E80100-Dell-XPS-13-9345-tplg.bin is requested at the card's component probe
(sound/soc/qcom/qdsp6/topology.c:1422, q6apm.c q6apm_audio_probe), so scripts/stage-firmware.sh puts it in the
initramfs. Firmware-side: the stock ADSP (adsp.mdt) must offer the "avs/audio" protection domain; QCOM_PD_MAPPER
and QCOM_PDR_HELPERS are =y already (pmic_glink uses them).
require: SND_SOC_QDSP6_COMMON
require: SND_SOC_QDSP6_APM
require: SND_SOC_QDSP6_APM_DAI
require: SND_SOC_QDSP6_APM_LPASS_DAI
require: SND_SOC_QDSP6_PRM
require: SND_SOC_QDSP6_PRM_LPASS_CLOCKS
require: SND_SOC_QCOM_COMMON
require: SND_SOC_QCOM_SDW
require: SND_SOC_TOPOLOGY
require: SND_SOC_LPASS_MACRO_COMMON
require: REGMAP_SOUNDWIRE
require: QCOM_PDR_HELPERS
require: QCOM_PD_MAPPER
require: RPMSG_QCOM_GLINK_SMEM

mica-bt.config

M2, Bluetooth (owner, 2026-11-04 park round: "test"): the WCN7850's Bluetooth on uart14 (dts: &uart14 { bluetooth {
compatible = "qcom,wcn7850-bt" } }). scripts/dt-kconfig-map.py names BT_HCIUART (=m in arm64 defconfig) for it, so
the node never bound. hci_uart's QCA protocol (BT_HCIUART_QCA, already =y) probes it over serdev, powers it through
the WCN power sequencer (pwrseq-qcom-wcn) and, when the core powers the new controller on, downloads
qca/hmtbtfw<rom>.tlv and an NVM file chosen by board id (btqca.c:825-827, 919-921, qca_get_nvm_name_by_board at
a804c57); scripts/stage-firmware.sh stages all five hmtnv20.* candidates. No userspace (no BlueZ): the controller
is set up, then the core powers it off again; nothing scans or pairs.
require: BT_HCIUART_SERDEV
require: BT_HCIUART_QCA
require: SERIAL_DEV_BUS
require: SERIAL_QCOM_GENI
require: POWER_SEQUENCING_QCOM_WCN

mica-console.config

The owner's view on the Googlebook's own panel (2026-11-03): /init mirrors a readable status page to tty1 (fbcon on
the eDP panel; the kernel console stays on the serial port, console=ttyMSM0). The default 8x16 font gives 320x100
characters on the 2560x1600 13.4" panel, too small to read at arm's length; Terminus 16x32 gives 160x50
(lib/fonts/Kconfig:126-134). The command line selects it with fbcon=font:TER16x32 (scripts/package-in-container.sh).
require: FRAMEBUFFER_CONSOLE
require: DRM_FBDEV_EMULATION
require: VT_CONSOLE

mica-debug.config

Event tracing for the boot captures (owner round 2026-11-03: 1a), docs/research/debug-tools.md option 1.
arm64 defconfig:1970 sets "# CONFIG_FTRACE is not set", so the kernel had no tracefs and no trace events. The command
line (scripts/package-in-container.sh) arms scmi, i2c and qcom_geni_i2c events with trace_event= from start_kernel;
/init saves a filtered copy into the netlog. ENABLE_DEFAULT_TRACERS selects TRACING, which selects EVENT_TRACING,
RING_BUFFER and TRACEPOINTS (kernel/trace/Kconfig:179-188, :588-591). No function tracer.
require: EVENT_TRACING
require: TRACEPOINTS

mica-display.config

Phase 3, display: msm DRM drives the eDP panel, so the panel stays lit after the regulator core's unused-supply
cleanup. Source: attempt 2026-11-03-3 (docs/recon/wifi-2026-11-03.md): "VREG_EDP_3P3: disabling" at about 33 s,
because only simpledrm drives the screen and nothing claims the panel supply. The mica DTS already describes the
path (&mdss, &mdss_dp3 with an edp-panel on its aux-bus, &mdss_dp3_phy, pwm-backlight); every driver on it is =m
in defconfig at a804c57 and the initramfs loads no modules.
The GPU is left out: the command line carries msm.skip_gpu=1 (scripts/package-in-container.sh), because the GPU
would join the MDSS component match (drivers/gpu/drm/msm/msm_drv.c:1076-1086) and wait on gpucc.
MDSS/DPU/DP (drivers/gpu/drm/msm/Kconfig:3). Sub-options DPU, DP and KMS_FBDEV default to y.
require: DRM
require: DRM_MSM_DPU
require: DRM_MSM_DP
require: DRM_MSM_KMS_FBDEV
require: DRM_FBDEV_EMULATION
require: PWM
require: REGULATOR_FIXED_VOLTAGE
require: DRM_AUX_HPD_BRIDGE

mica-ec.config

Phase 3, EC: the ChromeOS EC on spi13, its keyboard and its children (owner round 2026-11-03: 1a 2a).
Source: every boot on 2026-11-03 (10 in dumps/firstboot/2026-11-03-netlog.txt) logs 77 lines of
"sync_state() pending due to a94000.spi" and not one cros_ec line. a94000 is spi13 (hamoa.dtsi:1905), the bus of
cros_ec ec@0 in dts/x1e80100-google-mica.dts. Its driver (qcom,geni-spi, drivers/spi/Kconfig:1013) is =m in arm64
defconfig, and the initramfs loads no modules, so the EC and cros-ec-keyb never probed.
The EC's children are MFD cells that cros_ec_dev adds per EC feature (drivers/mfd/cros_ec_dev.c:106-153):
cros-keyboard-leds for EC_FEATURE_PWM_KEYB ("chromeos::kbd_backlight", cros_kbd_led_backlight.c:201), the EC LEDs,
and the cros_ec hwmon (fan RPM, temperatures; SENSORS_CROS_EC is already =y).
require: CROS_EC
require: CROS_EC_SPI
require: CROS_EC_PROTO
require: MFD_CROS_EC_DEV
require: KEYBOARD_CROS_EC
require: SENSORS_CROS_EC
forbid-y: CROS_EC_TYPEC
forbid-y: CROS_EC_UCSI

mica-firstboot.config

First-boot config fragment for mica, merged onto arm64 defconfig at torvalds/linux a804c57:
  scripts/kconfig/merge_config.sh -m arch/arm64/configs/defconfig kernel/mica-firstboot.config
  make ARCH=arm64 LLVM=1 olddefconfig
Decided in .scratch/phase-2-first-boot/issues/06-kernel-tree.md (inputs: tickets 04 and 05).
Boot arguments are not set here; they go on the mkdepthcharge command line (ticket 08).

scripts/check.sh checks offline that every CONFIG_ line and every "# require:" symbol exists in a804c57 Kconfig.
After the merge, the build fails unless all of them are =y.
Silent-boot channel 1: the failed boot's printk in depthcharge's ramoops region (defconfig: PSTORE_RAM=m).
require: SERIAL_QCOM_GENI
require: SERIAL_QCOM_GENI_CONSOLE
require: QCOM_GENI_SE
require: PINCTRL_MSM
require: PINCTRL_X1E80100
require: QCOM_PDC
require: COMMON_CLK_QCOM
require: CLK_X1E80100_GCC
require: QCOM_RPMH
require: QCOM_COMMAND_DB
require: QCOM_CLK_RPMH
require: QCOM_RPMHPD
require: INTERCONNECT
require: INTERCONNECT_QCOM
require: INTERCONNECT_QCOM_X1E80100
require: ARM_SMMU
require: ARM_SMMU_QCOM
require: ARM_PSCI_FW
require: ARM_PSCI_CPUIDLE
require: ARM_PSCI_CPUIDLE_DOMAIN

mica-gpu.config

Phase 3, GPU: the Adreno X1-85 (gpu@3d00000, qcom,adreno-43050c01) with its GMU (gmu@3d6a000).
Source: attempt 2026-11-03-4 (docs/recon/display-2026-11-03.md): 3da0000.iommu (the GPU SMMU) stayed deferred on
"supplier 3d90000.clock-controller not ready", and the display only bound because the command line carried
msm.skip_gpu=1. scripts/dt-kconfig-map.py on the mica-el2 DTB: gpucc is the one GPU-path driver still =m.
The command line now carries msm.separate_gpu_kms=1 instead (drivers/gpu/drm/msm/msm_drv.c:57-66,1082;
adreno_device.c:275), so the GPU gets its own DRM device and a GPU failure cannot take the display with it.
Firmware: qcom/gen70500_sqe.fw and qcom/gen70500_gmu.bin (a6xx_catalog.c:1573-1577), loaded on the first open of
the GPU's DRM device (msm_drv.c msm_open -> load_gpu), staged by scripts/stage-firmware.sh from
linux-firmware-qcom 20260916-1. The zap shader is disabled by x1-el2.dtso, so a6xx_gpu.c:1507-1516 writes
SECVID_TRUST_CNTL directly and warns "Zap shader not enabled".
The GPU clock controller (drivers/clk/qcom/Kconfig:278): GDSCs and clocks for the GPU, GMU and adreno_smmu.
require: DRM_MSM
require: ARM_SMMU
require: ARM_SMMU_QCOM
require: PM_DEVFREQ
require: DEVFREQ_GOV_SIMPLE_ONDEMAND
require: PM_OPP
require: QCOM_LLCC

mica-pcie.config

Phase 3, PCIe: bring up both PCIe controllers and enumerate their devices.
Source: every boot so far left pcie@1bf8000 and pcie@1c08000 deferred ("Failed to parse Root Port: -517");
scripts/dt-kconfig-map.py on the mica-el2 DTB shows their suppliers are =m in defconfig at a804c57.

Safety: the NVMe slot holds the stock SSD, which is never written (ADR 0003, ticket 07). BLK_DEV_NVME stays =m
(not loaded), so enumeration reads PCI config space only and no NVMe command reaches the SSD.
QMP PCIe PHYs: gen4x4 phy@1bfc000 (pcie@1bf8000) and gen3x2 phy@1c0e000 (pcie@1c08000). Their menu parent
PHY_QCOM_QMP is already =y in mica-usb.config.
forbid-y: BLK_DEV_NVME
require: PCIE_QCOM
require: PCIEPORTBUS
require: PCI_MSI
require: POWER_SEQUENCING
require: PCI_PWRCTRL
require: PCI_PWRCTRL_PWRSEQ

mica-pmdebug.config

Suspend debugging (2026-11-04, ADR 0009's suspend test): attempts 2026-11-04-5 to -8 reset the AP about 0.7 s after
the s2idle wake. With patch 0008 the PCIe GDSC warning is gone and the kernel prints nothing before the reset, so
/init (gbook.suspend=1) turns on /sys/power/pm_print_times and pm_debug_messages: every device's suspend and resume
callback is logged as "calling <cb> @ <pid>, parent: <dev>" before it runs (drivers/base/power/main.c:227-241 at
a804c57), and the last such line before the reset names the device. Both files exist only with PM_SLEEP_DEBUG
(kernel/power/main.c:644, a def_bool on PM_DEBUG && PM_SLEEP, kernel/power/Kconfig:257-259).
require: PM_SLEEP_DEBUG

mica-rootfs.config

M3, the rootfs (ADR 0012, decision 6; .scratch/m3-rootfs ticket 01). systemd v262's README ("REQUIREMENTS") says
userspace firmware loading "is not supported and should be disabled in the kernel"; arm64 defconfig sets
FW_LOADER_USER_HELPER=y (built config, read 2026-11-04). Off here; firmware still loads from the filesystem
(Documentation/driver-api/firmware/fw_search_path.rst at a804c57). USB Attached SCSI for the rootfs stick: the stick
ran bulk-only so far (USB_UAS not set); UAS falls back to bulk-only for devices that lack it.
CONFIG_FW_LOADER_USER_HELPER is not set
forbid-y: FW_LOADER_USER_HELPER

mica-scmi.config

Phase 3, SCMI: CPU performance domains (cpufreq) through the CPUCP mailbox.
Source: every boot up to attempt 2026-11-03-7 left "firmware:scmi: supplier 17430000.mailbox not ready", then
"arm-scmi: failed to setup channels": the mailbox driver for qcom,x1e80100-cpucp-mbox
(drivers/mailbox/qcom-cpucp-mbox.c:205, Kconfig:343) is =m in defconfig, and the initramfs loads no modules.
The stock tree drives the same block: cpucp@18830000 (qcom,cpucp-v2) with reg 0x17430000 + 0x18830000, scmi mboxes
<cpucp 0 cpucp 2>, shmem at 0x18b4e000 (entry00-base.dts:384-402, :908-926, :10534-10540; stock also lists a vendor protocol@80 that hamoa.dtsi has not), as hamoa.dtsi does.
The CPUs take their "perf" power domain from scmi_dvfs (hamoa.dtsi:78-79 and the other cpu nodes).
require: MAILBOX
require: ARM_SCMI_PROTOCOL
require: ARM_SCMI_TRANSPORT_MAILBOX
require: ARM_SCMI_PERF_DOMAIN
require: ARM_SCMI_CPUFREQ
require: DEBUG_FS

mica-sync.config

Phase 3, the last never-bound devices (handoff 2026-11-03 item 3; kernel/dt-gaps.txt "sync_state lead").
Source: attempt -26 left unbound=6: four bandwidth-monitor PMUs (pmu@24091000 qcom,sc7280-llcc-bwmon;
pmu@240b3400/@240b5400/@240b6400 qcom,sdm845-bwmon), videocc@aaf0000 and camcc@ade0000, all =m in defconfig while
the initramfs loads no modules (scripts/dt-kconfig-map.py at a804c57). An unbound interconnect consumer keeps the
providers from sync_state() and their boot-time votes in place (the crypto node did, Omarchy 2210); whether these
do is what the boot shows. Kconfig at a804c57: QCOM_ICC_BWMON drivers/soc/qcom/Kconfig:266 (selects PM_OPP,
REGMAP_MMIO), SM_VIDEOCC_8550 drivers/clk/qcom/Kconfig:1981 (covers X1E80100), CLK_X1E80100_CAMCC :247.
require: QCOM_ICC_BWMON
require: SM_VIDEOCC_8550
require: CLK_X1E80100_CAMCC

mica-touch.config

Phase 3, touch: the I2C HID touchpad and touchscreen (owner 2026-11-03, after the retro's DT gap check).
Source: scripts/dt-kconfig-map.py --gaps listed "hid-over-i2c  I2C_HID_OF=m  touchscreen@10,touchpad@2c": the
OF glue for hid-over-i2c (drivers/hid/i2c-hid/Kconfig:25, selects I2C_HID_CORE) is =m in arm64 defconfig, and the
initramfs loads no modules, so neither node has ever bound. Nodes: touchpad@2c on i2c0 (descriptor 0x20, TLMM 3)
and touchscreen@10 (LG SW42101M, descriptor 0x0, TLMM 51) in dts/x1e80100-google-mica.dts.
HID_MULTITOUCH: a precision touchpad and a touchscreen report as multitouch; hid-generic would see a mouse at best.
require: I2C_HID
require: HID_GENERIC
require: INPUT_EVDEV
require: I2C_QCOM_GENI

mica-tpm.config

Phase 3, TPM: the Ti50 GSC's TPM on I2C (owner 2026-11-03, after the retro's DT gap check).
Source: scripts/dt-kconfig-map.py --gaps listed "google,cr50  TCG_TIS_I2C_CR50=m  tpm@50": the driver
(drivers/char/tpm/Kconfig:116) is =m in arm64 defconfig, so tpm@50 has never bound. It knows the Ti50 by its
DID/VID ("ti50 DT" / "ti50 OT", tpm_tis_i2c_cr50.c:693-702) and prints "<name> TPM 2.0 (i2c 0x50 irq N id 0x..)".
TPM traffic: probe sends startup/self-test and capability reads (tpm_chip_register); reboot sends
TPM2_Shutdown(CLEAR) (tpm-chip.c:272), as any Linux kernel with a TPM does. No NV or key writes.
require: TCG_TPM
require: HW_RANDOM_TPM
forbid-y: TCG_TPM2_HMAC

mica-usb.config

Phase 3, USB: build the whole USB chain in, so the module-free initramfs can use it.
Merged after kernel/mica-firstboot.config by scripts/build-kernel.sh.
Source: the first boot (docs/recon/firstboot-2026-11-02.md): all four dwc3 controllers stayed deferred
("failed to register DWC3 Core") because every PHY, repeater, retimer and I2C driver below was =m in defconfig
at a804c57 and no module was loaded. Each line maps a compatible in x1e80100-google-mica-el2.dtb to its driver.
I2C buses that carry the PS8830 retimers and PTN3222 redrivers (qcom,geni-i2c).
require: USB_DWC3
require: USB_DWC3_QCOM
require: USB_XHCI_HCD
require: USB_XHCI_PLATFORM
require: USB_STORAGE
require: USB_HID
require: USB_ROLE_SWITCH
require: SPMI_MSM_PMIC_ARB
require: MFD_SPMI_PMIC

Local kernel patches

Applied by the build onto torvalds a804c57 in name order. Line 1 of each file is its status (the ChromiumOS words, LOCAL for CHROMIUM: decision 0007). The four LOCAL gbook patches stay unpublished until milestone M5 (decision 0010); their status lines are listed.

Build scripts

The header of each build script in the private repository, as of this build. The scripts themselves run on the project’s build host and are not published yet (their paths and listeners are specific to it).

setup-toolchain.sh

Set up the DTS toolchain outside the repo (idempotent): a sparse torvalds/linux checkout at the pinned commit
(DTS sources, bindings, every Kconfig file and the arm64 defconfig), a dtschema venv, and the processed binding schema.
  scripts/setup-toolchain.sh            -> $GBOOK_TOOLS (default ~/.cache/gbook)
  PYTHON=python3.14 scripts/setup-toolchain.sh   (the macOS host: bare python3 is 3.15 there)
  GBOOK_FULL=1 scripts/setup-toolchain.sh        (the build host: the whole tree, for scripts/build-kernel.sh; ~1.5 GB)
Then: scripts/build-dtb.sh ~/.cache/gbook/linux-<short> dts/x1e80100-google-mica.dts /tmp/mica.dtb
      ~/.cache/gbook/venv-dtschema/bin/dt-validate -s ~/.cache/gbook/schema-<short>.json /tmp/mica.dtb
The commit is the one the mica DTS was forked from (ADR 0004); change both together.

build-dtb.sh

Compile a board DTS against a mainline kernel tree the way Kbuild does (cpp, then dtc), without building a kernel.
  scripts/build-dtb.sh <kernel-tree> <file.dts> [out.dtb] [extra.dtsi ...] [overlay.dtso ...] [fixes.fixups ...]
A .dtsi is a diagnostic built on top of the board DTS (a wrapper #includes the DTS, then each .dtsi in order), so an
experiment from dts/diag/ never edits the stock-traceable DTS (retro 2026-11-03; GBOOK_DTS_EXTRA in package-image.sh).
With overlays, out.dtb is the base with each overlay applied by fdtoverlay, as Kbuild builds "-dtbs" targets
(scripts/Makefile.dtbs), e.g. the first-boot DTB:
  scripts/build-dtb.sh <tree> dts/x1e80100-google-mica.dts /tmp/mica-el2.dtb <tree>/arch/arm64/boot/dts/qcom/x1-el2.dtso \
    dts/mica-el2.fixups
A .fixups file lists "delete-property <label> <property>" lines (labels from /__symbols__), applied with fdtput
after the overlays, because overlays cannot delete properties.
The kernel tree only needs arch/arm64/boot/dts/qcom, include/dt-bindings and scripts/dtc/include-prefixes
(a sparse checkout is enough). The DTS may live outside the tree: its own directory is searched first.
Preprocesses with $CC -E like Kbuild (Apple's cpp wrapper misparses -o). Prints dtc warnings; exits non-zero on any error.

build-kernel.sh

Build the mica kernel Image on the build host: arm64 defconfig at the pinned commit + every kernel/*.config fragment
(mica-firstboot.config first, then the rest in name order),
clang/lld (LLVM=1), out of tree. Image only: no modules, no in-tree dtbs (scripts/build-dtb.sh builds the DTB).
  GBOOK_FULL=1 scripts/setup-toolchain.sh     # once: the full kernel tree
  scripts/build-kernel.sh [kernel-tree] [out-dir]
Defaults: $GBOOK_TOOLS/linux-a804c57 and $GBOOK_TOOLS/build-a804c57 (GBOOK_TOOLS defaults to ~/.cache/gbook).
Applies kernel/patches/*.patch first (ADR 0007; the kernel release then ends in -dirty).
Writes <out-dir>/localversion-gbook (gbook_localversion below), so the release names the gbook commit too: it reads
like 7.3.0-gbook-g6934235-ga804c5742bff-dirty (a release keeps that form: ADR 0011 maps the hash to its tag).
Fails if any CONFIG_ line or "# require:" symbol of any fragment is not =y after the merge (ticket 06), or if any
"# forbid-y:" symbol is =y (safety rails, e.g. the NVMe driver near the stock SSD).
Needs clang, ld.lld, make, flex, bison, bc, perl and openssl headers.

package-image.sh

Package the first-boot image on the build host: stage Image, the -el2 DTB and /init, then run scripts/package-in-container.sh
in the digest-pinned Debian sid container through pkexec (the owner stays out of the docker group, ticket 06).
  scripts/build-kernel.sh && scripts/package-image.sh
Output: $GBOOK_TOOLS/out/{mica-usb.img,mica.kpart,manifest.txt,...} (GBOOK_TOOLS defaults to ~/.cache/gbook).
Firmware: scripts/stage-firmware.sh rebuilds $GBOOK_TOOLS/firmware (stock modem_a + the build host's linux-firmware, never in
git: ADR 0005) and checks it against kernel/firmware.sha256; the tree goes into the initramfs at /lib/firmware.
Wi-Fi: ~/.local/state/gbook/wifi.conf (owner-written wpa_supplicant network block), if present, goes in as
/etc/wpa_supplicant.conf.
Writes nothing to a USB drive; the owner does that with pkexec dd (ticket 13).

build-rootfs.sh

Build the M3 rootfs (ADR 0012; .scratch/m3-rootfs ticket 03): Debian sid arm64 from one snapshot.debian.org
timestamp, mmdebstrap in the digest-pinned container of scripts/package-image.sh, run rootless with podman
(retro-8/05). Output in $GBOOK_TOOLS/rootfs (GBOOK_TOOLS defaults to ~/.cache/gbook), never in git:
  out/rootfs.ext4     the ROOT image (GBOOK_ROOTFS_SIZE, default 4G; label gbook-root), from out/rootfs.tar
  out/lock.txt        every installed package as pkg:arch=version, sorted (the lock list)
  out/manifest.txt    snapshot, SOURCE_DATE_EPOCH, container digest, tool versions, counts and sha256s
  out/mmdebstrap.log  the build log; cache/ keeps every .deb (snapshot answered 503/504 on 2026-11-04)
  scripts/build-rootfs.sh [YYYYMMDDTHHMMSSZ]      (default: today 00:00 UTC; ticket 02 sized 20261104T000000Z)
  GBOOK_ROOTFS_MIRROR=http://deb.debian.org/debian   while snapshot.debian.org is down: the manifest then says snapshot=none
                                                     and requested_snapshot=<ts>, so release tooling (ticket 12) sees it
  GBOOK_ROOTFS_OFFLINE=1   rebuild from cache/ alone, pinned to the previous out/lock.txt (no network for packages)
The manifest's lock_changed= line counts lock.txt lines that differ from the previous build's (kept as lock.prev.txt).
Mode (ADR 0012, decision 9): the container runs mmdebstrap inside its own user namespace (unshare --map-root-user
--map-auto, the substance of mmdebstrap's unshare mode; as container root mmdebstrap would skip the namespace and
fail to mount, 2026-11-04). GBOOK_ROOTFS_MODE=sysadmin instead adds SYS_ADMIN to the rootless container and runs
mmdebstrap's root mode directly: a capability inside podman's user namespace, not on the host.
Writes nothing to a USB drive; the owner writes ROOT (ticket 11).

stage-firmware.sh

Rebuild the initramfs firmware tree $GBOOK_TOOLS/firmware (default ~/.cache/gbook/firmware) from its two sources,
and check every file against kernel/firmware.sha256 (hashes only in git; the blobs never are: ADR 0005).
  scripts/stage-firmware.sh                 stage and check; fails on any hash change or missing file
  scripts/stage-firmware.sh --update        stage and rewrite kernel/firmware.sha256 (after a deliberate change)
  scripts/stage-firmware.sh board2 [regex]  list board-2.bin entry names matching regex (e.g. 'subsystem-vendor=105b')
Sources:
  stock  = the recovery-stick copy's modem_a partition (dumps/gate1/), read with scripts/fat_ls.py, no mount
  distro = the build host's linux-firmware-atheros and wireless-regdb packages (/usr/lib/firmware), zstd-decompressed
  pkg    = files from an Arch package the build host does not install (linux-firmware-qcom: the Adreno X1-85 GPU firmware and
           the Dell XPS 13 9345 audio topology),
           downloaded once into $GBOOK_TOOLS/pkgs, signature-checked against pacman's keyring, extracted, never
           installed. The version matches the distro linux-firmware packages (20260916-1).
package-image.sh copies the staged tree into the initramfs at /lib/firmware.

mkpatch.sh

Assemble a local kernel patch (ADR 0007) from the edited kernel tree, then restore the tree (retro-15/02: three
revisions of patch 0010 were 40-line heredocs each, and a prose "Status:" line failed check 34 once).
  scripts/mkpatch.sh <NNNN-slug> --subject '<text>' --notes <file> [--body <file>] [--status '<WORD> <reference>']
                     [--assisted-by <id>] [--tree <dir>] [--out <file>]
Edit the files in the tree first (its HEAD is the pin). The patch is the tree's diff of its modified tracked files:
  line 1   Status: <status>, checked <today>        default: LOCAL gbook (ours; not sent: upstream hold until M5)
  prose    the notes file: why, evidence, what it changes (gbook's block before the mail header)
  mail     From 0000…, From: the gbook repo's git identity, Date: now (date -R), Subject: [PATCH] <subject>,
           the body file (or the subject alone), Assisted-by: <id> (default Claude), ---, diffstat, diff
Then the touched files go back to HEAD, so the tree stays what build-kernel.sh expects (it applies every patch itself).
--out names the file (default kernel/patches/<NNNN-slug>.patch; a new number takes the next unused one, check 34).

release-draft.sh

Draft a release's annotated tag message (ADR 0011 and its 2026-11-04 update; .scratch/m3-rootfs ticket 12). Checks the
release bar first, prints the message, writes it to $GBOOK_TOOLS/out/tag-<version>.txt and names the owner's git tag
command. Tags nothing: the owner tags (CLAUDE.md, "Git").
  scripts/release-draft.sh <milestone> <attempt id regex> [vYYYY.0M.0D[.MICRO]]   (default version: today's date)
The bar (ADR 0011): one base image, 3 clean cold boots. "clean" is scripts/attempt.sh tally's SCMI verdict over the
rows the regex selects (anchor it: '^2026-11-04-12$'); "cold" is each row's start column (boot_start.py, the row's first
boot); "base image" is what attempt.sh stick last read back from the stick. The rootfs must be pinned by date
(manifest snapshot=, not none: a GBOOK_ROOTFS_MIRROR build is not release material).
The rootfs on the stick's partition 2 must be that manifest's (attempt.sh root-verify's record, retro-9/01).
check.sh 46 runs the two checks alone: release-draft.sh --self-check <tally line> <starts> <stick file> <manifest> [<root file>].

Project glossary

mica

The Googlebook’s Android device codename (ro.product.device, read over adb 2026-10-20).

bluey

The ChromeOS reference baseboard for Qualcomm X1 devices in coreboot (src/mainboard/google/bluey); mica is one of its variants. Firmware branch firmware-bluey-16702.B.

Hamoa

Qualcomm’s platform name for the X1E80100 family; mainline Linux renamed x1e80100 device-tree files to hamoa.

Tributo

Codename of the Dell XPS 13 9345, the Windows sibling whose mainline device tree (x1e80100-dell-xps13-9345.dts, compatible dell,xps13-9345) is the starting point for this one.

Stock DT

The device tree Googlebook OS boots with: an LZ4-compressed vendor base DTB plus board and keyboard overlays in the dtbo_a partition (dtb_a is empty). It is used only as a hardware map (ADR 0004).

Recovery image

Google’s public mica-user/16471258/recovery.zip: one 19 GB GPT disk image. Build 16471258 is older than the installed 16560795.

Stock OS

Googlebook OS (codename Aluminium): Android 17 with a desktop shell, as shipped. Phase 1 reads it without changing it.

Stock drive and spare drive

The stock drive is the M.2 2230 SSD the laptop shipped with; it stays untouched in a drawer during experiments. The spare drive is a second 2230 SSD that takes every experiment (ADR 0002).

Gate

The condition that ends a phase. Work from the next phase does not start until its gate passes. Gate 1 = a proven way back to stock. Gate 2 = a mainline kernel’s own Linux version line, captured from the AP console, the panel or the ramoops readback.

Milestone

A named rung between the gates, M0 to M7 (ADR 0010), each with a “done when” bar. M0 and M1 coincide with Gates 1 and 2, M4 with Gate 3 and M6 with Gate 4. M5 (upstream-ready) ends the upstream hold. Per-feature state lives in docs/status.md.

Attempt

One boot of one image, with an ID YYYY-MM-DD-N and a row in the gitignored dumps/firstboot/attempts.tsv (scripts/attempt.sh). Repeat boots of the same image are added to its row.

Base image and test image

A base image is packaged with no debug command-line or DT extras. A test image has some (for example gbook.suspend=1). scripts/attempt.sh stick names which one the stick holds. Only a base image can become a release.

Release and version

A release is a base image with 3 clean cold boots by scripts/attempt.sh tally, which the owner would hand on. Its version is a CalVer annotated tag vYYYY.0M.0D[.MICRO] on the commit that built it (ADR 0011). A version names an image, and an attempt names one boot of it. uname -r carries the gbook commit it was built from, for example -gbook-g6934235 (+ for a tree with changes). A released image keeps that form, and its tag message maps the hash to the version.

Patch status

The first line of a kernel/patches/ file: Status: LOCAL, FROMLIST, FROMGIT or UPSTREAM, plus a reference (ChromiumOS’s words, with LOCAL for its CHROMIUM; ADR 0007 update). Patch numbers are never reused.

Recovery media

A USB drive (32 GB+) written by Google’s Device Recovery Utility Chrome extension; it reinstalls stock OS from the firmware recovery screen (Esc + F2, then Power, per Google’s Googlebook article; Esc + Refresh is the Chromebook combo).

Developer mode

ChromeOS firmware state that allows booting non-Google-signed kernels. On mica the recovery screen calls it “Unlock bootloader” / “Bootloader is unlocked”; it needs OEM unlocking turned on in Android first.

Kernel partition and FIT

A GPT partition of the ChromeOS-kernel type holding a vboot-signed image. On Arm the payload is a FIT (Flattened Image Tree): kernel plus one or more device trees, picked by compatible (google,mica-rev*-sku*).

ALink

Google’s USB bridge cable or dongle that depthcharge’s fastboot looks for as USB host; a Prolific PL27A1 also works. Without one, firmware fastboot runs over TCP via a USB-Ethernet adapter.

ABL

Qualcomm’s Android Bootloader, which loads Android boot images and speaks fastboot. mica does not use it (it boots through depthcharge, found 2026-10-21); kept here because the older plan assumed it.

RAM boot

fastboot boot <image>: boots an image once from memory without writing it to storage. mica’s depthcharge fastboot does not implement it; booting from a USB drive replaces it.

GSC

Google Security Chip on the board in place of a Windows TPM; on mica it is a Ti50 (coreboot TPM_GOOGLE_TI50). On Chromebooks it provides CCD.

CCD

Closed Case Debugging: UART consoles for the main processor and the EC over USB-C through the GSC, without opening the case. mica has it: CCD is Locked, with AP and EC console reads allowed Always (gsctool -a -I, 2026-10-21).

SuzyQ

The USB-C debug cable (here the Fyra Labs SuzyQ Board) that exposes CCD consoles to a second computer. On mica it works in the left port. the build host sees Ti50 18d1:5066, with ttys for the GSC shell, AP (uart21), EC and FPMCU.

EC

Embedded controller: battery, fans, keyboard, lid, Glowbar, LEDs. On mica it is a ChromeOS EC (Zephyr, Nuvoton NPCX9) over SPI, so mainline cros_ec drivers are the starting point; its mica overlay is partly private.

DTS and DTB

Device tree source and its compiled blob: the hardware description the kernel boots with on Arm.

GSI and DSU

Generic System Image, an AOSP system image for any Treble device; Dynamic System Updates boots one from new partitions without touching stock. The cheapest test after unlocking.

ROOT

The kernel stick’s partition 2, GPT name gbook-root, 8 GiB from sector 524288, declared by every KERN-A image’s GPT (ADR 0012, decision 3). The owner writes rootfs.ext4 to it; /init finds it as partition 2 of the disk that holds the kern_guid partition.

M3 rootfs

The Debian sid arm64 root filesystem of milestone M3, built by scripts/build-rootfs.sh from rootfs/packages.txt with mmdebstrap in the pinned container; rootfs/customize.sh adds its units. gbook-m3 is its capture service (GBOOK: m3-<key>= lines, a second netlog transfer); gbook-cage runs Ghostty under cage as user gbook.

mica (ssh host)

the build host’s ssh mica entry: the booted M3 rootfs at the Wi-Fi lease, key-only, user gbook with sudo (ADR 0012 update 2026-11-04). Reads are free; writes need the owner; one connection attempt per boot.

Releases

One entry per annotated tag vYYYY.0M.0D[.MICRO] (decision 0011); the tag message is the release note.

v2026.11.05

v2026.11.05: M3

Milestone: M3 (ADR 0010)
Kernel base: torvalds a804c57 (v7.3 + 1703, the 7.4 merge window; ADR 0011)
Kernel release: 7.3.0-gbook-2026.11.04-35-g7c6a1aa-ga804c5742bff-dirty (uname -r; build 69edd54 of gbook)
Local patches (kernel/patches/, ADR 0007):
  0001-drm-panel-edp-add-lgd-0x0804.patch: LOCAL gbook (not sent: the EDID gives only part of the model name), checked 2026-11-04
  0002-drm-msm-a6xx-cxpd-device-link-stateless.patch: FROMLIST [RFT 1/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-1-6e33e6aa9b4f@oss.qualcomm.com>; v2 has it as 2/8 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below); checked 2026-11-04
  0003-drm-msm-centralize-standalone-drm-check.patch: FROMLIST [RFT 2/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-2-6e33e6aa9b4f@oss.qualcomm.com>; dropped in v2 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below); checked 2026-11-04
  0004-drm-msm-adreno-fix-drvdata-typecast.patch: FROMLIST [RFT 3/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-3-6e33e6aa9b4f@oss.qualcomm.com>; v2 has it as 1/8 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below); checked 2026-11-04
  0005-drm-msm-component-model-for-standalone-gpu.patch: FROMLIST [RFT 4/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-4-6e33e6aa9b4f@oss.qualcomm.com>; v2 has it as 5/8 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below); checked 2026-11-04
  0006-drm-msm-attach-a-driver-to-the-gmu.patch: FROMLIST [RFT 5/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-5-6e33e6aa9b4f@oss.qualcomm.com>; v2 has it as 6/8 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below), ported to v7.2.8 by Brandon Williams; checked 2026-11-04
  0007-drm-msm-gmu-optional-and-lock-init.patch: LOCAL Brandon Williams via Omarchy (third-party fix-up on 0002-0006), https://github.com/omacom/omarchy-pkgs/tree/master/pkgbuilds/linux-omarchy-aarch64, checked 2026-11-04
  0008-clk-qcom-gcc-x1e80100-pcie-gdsc-retention.patch: FROMLIST [6/7] (Krishna Chaitanya Chundru) <20260102-pci_gdsc_fix-v1-6-b17ed3d175bc@oss.qualcomm.com>, changes requested on linux-arm-msm patchwork; regenerated against a804c57; checked 2026-11-04
  0009-clk-qcom-gcc-x1e80100-pcie-phy-gdsc-retention.patch: LOCAL gbook (ours; not sent: upstream hold until M5), checked 2026-11-04
  0010-soundwire-qcom-rearm-enumerator-after-clock-stop.patch: LOCAL gbook (ours; not sent: upstream hold until M5), checked 2026-11-05
  0011-asoc-wsa884x-clk-stop-mode1.patch: LOCAL gbook (ours; not sent: upstream hold until M5), checked 2026-11-05
KERN-A image sha256 (attempt.sh stick): bc62c69ecf560525
Rootfs image sha256: 6fea12f2dc824f63947e7251fafd31ae799f44ea6c5e40056ebaddba0f72ac56
Rootfs snapshot: 20261104T000000Z (snapshot.debian.org); lock list sha256 12f96fa08768262e228319783831fa28bd229d9e821b2b5bdfd8be2d02cc1388; 321 packages
Proof (attempt.sh tally '^2026-11-05-5$'): group 1 /^2026-11-05-5$/: attempts=1 health=1 boots=3 known=3 stalled=0 clean=3 unknown=0 max=0.1-0.1ms
Attempts: 2026-11-05-5; start: cold
Changes since v2026.11.04: 45 commit(s)
  69edd54 Release bar met for v2026.11.05: base image bc62c69e (sound node in the board DTS), 3 clean cold boots, the names heard on each
  e4820b0 Audio: the capture test passes (the owner heard the recording played back); Microphones: works; boot 7 added to 2026-11-05-4
  9d120a5 Audio: the sound node moves from dts/diag/sound.dtsi into the board DTS (mapping and unverified values in dts/README.md)
  176058d Retro 15: check.sh -q, mkpatch.sh, localversion on the kernel's inputs, watch replaces and wait-rootfs, attempt lifecycle in CLAUDE.md, audio-state --names
  b9c6ca2 Audio: ticket 16 closed (the owner heard the idle tone and the four names); Speakers works; README resume line
  b93bd13 Audio: the rule-free boot meets ticket 16's bar (tones a minute apart, after 10 minutes idle, the four names)
  86d6fd2 Ticket 16: tone 3 of boot -4 has no hearing report; audio-state.sh's masters label is stale
  e7c2791 Audio: the udev rule leaves the rootfs (patches 0011 and 0010 fix the wakes); check 45 now refuses it; status row for the speakers
  9a61e0b Audio: boot 2026-11-05-4 recorded, patch 0011 with 0010 revision 3 passes the first bar (three wakes whole)
  c08dc60 Audio: boot 2026-11-05-3 recorded (revision 2 sees the stall, the re-arm does not clear it)
  7c6a1aa Audio: patch 0010 revision 3 (a wedged enumerator gets a controller reset and init) and patch 0011 (wsa884x clk_stop_mode1)
  ed3af1e Audio: boot 2026-11-05-2 recorded (patch 0010 revision 1 did not fire); ideas #29 and #30 on the task list
  d4c3b68 Audio: patch 0010 revision 2, a delayed check re-arms the enumerator while a peripheral sits at device 0 (ticket 16)
  22ffd5c Audio: the udev rule is not a workaround (its write is the first wake, bus 1 lost it); attempt 2026-11-05-2 opened for patch 0010
  50d16d2 Research sources: CodeLinaro through its GitLab API, patchwork and GitHub commits API for upstream-fix reads
  4921d2f Audio: ticket 16 comment, recon Next and log row for patch 0010 and the udev-rule rootfs build
  50ac603 Audio: local patch 0010, re-arm the SoundWire enumerator when re-enumeration stalls after clock stop (ticket 16)
  ffb7273 Retro 14: recon.sh stock-kmsg, audio-state UCM path and masters runtime PM, sdw status caveat, Next pruned
  f9b770d Audio: all four speakers play with the SoundWire masters kept clocked (boot 2026-11-05-1); udev workaround, ticket 16 fix shape
  c23ab29 Retro 13: gaps check reads reset-gpios and shared GPIOs; audio-state, swrm_enum, mica-ssh; one watch at a time
  dbfd2ef Research: ASoC and SoundWire debugging tools (ticket 16 reads)
  7f9fe97 Audio: speaker test, the left amplifiers never enumerate (ticket 16); ssh user joins audio
  9b8fc6b Audio: the sound card binds (attempts 2026-11-04-26 to -28)
  c613c1d mica-audio.config: GPIO_SHARED_PROXY=y (the shared reset pins, attempt -27)
  e8c45c0 mica-audio.config: RESET_GPIO=y (the codecs deferred on their reset-gpios, attempt -26)
  afca45f Retro 12: stock tree is two files, + kernel release refused at the bar, navigation lines
  a7d9d52 Log: the audio offline part; attempts row 2026-11-04-26
  c80b1a3 sound.dtsi: the DMIC supply from the stock overlay (EN_PP3300_MIC, TLMM 69)
  7f5199a Audio attempt, offline part (M3 ticket 10)
  7072998 Log: retro 11 done but ticket 03 (RTK.md, owner); README next line
  752eb8b Retro-11 tickets 02, 04, 05 and retro-9 07: journal group, tally pending row, Evidence column, the ssh block
  a71c205 watch: classify the EC power sequence (retro-11/01)
  ca9cb6f Retro 11: five tickets for the rootfs-side session
  4ec4dae Docs: the EC's G3->S5 after power-down is soft-off; Ghostty's 38 s marked inferred
  e085d11 Log: boot -25 powered off over ssh
  8079c55 Docs: the rootfs side measured, m3-end at 48.7 s (attempt 2026-11-04-25)
  e6d0e06 rootfs: cage at boot, polled cage read, joined channel handed over (task #26)
  82549ae Recon: the rootfs side of boot 2026-11-04-24, by the journal
  54d6e82 Log: the fast-sweep boot powered off over ssh
  a5ab9d2 Docs: the fast-sweep boot is still up; times from logged anchors
  ... and 5 more

v2026.11.04

v2026.11.04: M3

Milestone: M3 (ADR 0010)
Kernel base: torvalds a804c57 (v7.3 + 1703, the 7.4 merge window; ADR 0011)
Kernel release: 7.3.0-gbook-g82c43ed-ga804c5742bff-dirty (uname -r; build 506159b of gbook)
Local patches (kernel/patches/, ADR 0007):
  0001-drm-panel-edp-add-lgd-0x0804.patch: LOCAL gbook (not sent: the EDID gives only part of the model name), checked 2026-11-04
  0002-drm-msm-a6xx-cxpd-device-link-stateless.patch: FROMLIST [RFT 1/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-1-6e33e6aa9b4f@oss.qualcomm.com>; v2 has it as 2/8 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below); checked 2026-11-04
  0003-drm-msm-centralize-standalone-drm-check.patch: FROMLIST [RFT 2/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-2-6e33e6aa9b4f@oss.qualcomm.com>; dropped in v2 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below); checked 2026-11-04
  0004-drm-msm-adreno-fix-drvdata-typecast.patch: FROMLIST [RFT 3/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-3-6e33e6aa9b4f@oss.qualcomm.com>; v2 has it as 1/8 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below); checked 2026-11-04
  0005-drm-msm-component-model-for-standalone-gpu.patch: FROMLIST [RFT 4/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-4-6e33e6aa9b4f@oss.qualcomm.com>; v2 has it as 5/8 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below); checked 2026-11-04
  0006-drm-msm-attach-a-driver-to-the-gmu.patch: FROMLIST [RFT 5/5] of "drm/msm: Attach a driver to GMU" v1 (Akhil P Oommen) <20260513-gmu-sync-state-fix-v1-5-6e33e6aa9b4f@oss.qualcomm.com>; v2 has it as 6/8 <20261030-gmu-sync-state-fix-v2-0-89d3082d97af@oss.qualcomm.com>; copy: Omarchy linux-omarchy-aarch64 (below), ported to v7.2.8 by Brandon Williams; checked 2026-11-04
  0007-drm-msm-gmu-optional-and-lock-init.patch: LOCAL Brandon Williams via Omarchy (third-party fix-up on 0002-0006), https://github.com/omacom/omarchy-pkgs/tree/master/pkgbuilds/linux-omarchy-aarch64, checked 2026-11-04
  0008-clk-qcom-gcc-x1e80100-pcie-gdsc-retention.patch: FROMLIST [6/7] (Krishna Chaitanya Chundru) <20260102-pci_gdsc_fix-v1-6-b17ed3d175bc@oss.qualcomm.com>, changes requested on linux-arm-msm patchwork; regenerated against a804c57; checked 2026-11-04
  0009-clk-qcom-gcc-x1e80100-pcie-phy-gdsc-retention.patch: LOCAL gbook (ours; not sent: upstream hold until M5), checked 2026-11-04
KERN-A image sha256 (attempt.sh stick): 9673d6d782ef4cdb
Rootfs image sha256: 4b0e2e027c0b2d74699eaa907a0eaca8597504a9eab6caec394b28c6f15c5d3c
Rootfs snapshot: 20261104T000000Z (snapshot.debian.org); lock list sha256 12f96fa08768262e228319783831fa28bd229d9e821b2b5bdfd8be2d02cc1388; 321 packages
Proof (attempt.sh tally '^2026-11-04-2[123]$'): group 1 /^2026-11-04-2[123]$/: attempts=3 health=3 boots=3 known=3 stalled=0 clean=3 unknown=0 max=0.1-0.1ms
Attempts: 2026-11-04-21 2026-11-04-22 2026-11-04-23; start: cold,cold,cold
Changes since the first commit (first release): 256 commit(s)
  506159b M3 release bar met: snapshot rootfs on ROOT, 3 clean cold boots; release-draft.sh fixes
  0d297ff Log: the snapshot-pinned release rootfs built (20261104T000000Z, 321 packages)
  07885c4 Retro-9/01: ROOT write and read-back as attempt.sh root-cmd and root-verify
  8b5181a Docs: README resume, docs index, glossary and ADR 0010 updated for the first ROOT boots
  4f59c59 Retro-9/02 resolved: udiskie honours the sticks' no-automount hint
  584702c Retro 9: tickets for the ROOT-boot session's tooling gaps
  d21096d Third ROOT boot: ssh from the build host, the netlog with the journal, Vulkan
  6fe07af M3 ticket 13: sshd for the build host in the rootfs, keys handed over at boot
  575493b Research: how the build host reaches the booted rootfs (sshd, reverse ssh, journal, USB gadget)
  e11ae23 The rootfs boots from USB: Mesa on the GPU, Wi-Fi in userspace, Ghostty
  b9514cc Ticket 09: note the terminfo symlink for the next rebuild
  a2dee5a M3 ticket 12: release-draft.sh checks the bar and drafts the tag message
  879a770 M3 ticket 09: Ghostty under cage in the rootfs
  1e0ebb5 M3 ticket 07: the rootfs's units and the M3 captures
  d8123c7 Rootfs: offline mode from the .deb cache, and byte-identical builds
  5e3956f M3 ticket 08: Ghostty 1.4.0 built for arm64 by cross compilation
  ebd263f Research: pinned, reproducible rootfs builds when snapshot throttles
  acfbcf4 M3 ticket 05: /init finds ROOT and switch_roots into it
  be3091b Portable checks and an honest manifest for a non-snapshot rootfs build
  98a9391 M3 ticket 03: build-rootfs.sh builds the rootfs reproducibly
  e95ebd4 Retro-7/08 resolved: stick boot tries counted and raised to 15
  61258b6 Retro-8/01 resolved: watch and verify say when a console tty is gone
  d2e8a94 Retro-8/04 resolved: known parked failures collapse in watch
  a9a53d4 Retro-8/06 resolved: a format check for docs/status.md
  4cf4b78 Retro-7/07 resolved: check 32 reads every added markdown line
  f9e2532 Retro-8/05 resolved: rootless podman for the rootfs sizing
  80064c8 Retro 8: tickets for the M2 bench session's tooling gaps
  148a2d7 M3 tickets 04 and 06 verified on attempt 2026-11-04-17
  82c43ed M3 tickets 04 and 06: ROOT in every image's GPT; one netlog sender
  d573942 M3 ticket 02: size the rootfs (1.45 GiB installed, 303 packages)
  f2bac5a M3 ticket 01 resolved: build #28 has FW_LOADER_USER_HELPER off, USB_UAS on
  f5cb508 M3 plan: ADR 0012 (Debian sid rootfs on the stick), 12 tickets
  139bcdc docs/research/sources.md: where the evidence comes from, how to read it
  ca3c851 Research: the M3 rootfs (Debian sid now, Omarchy aarch64 at M4)
  ce13a86 Milestone M2 reached; deep suspend resets the AP and is parked
  b97066c Keyboard wake from s2idle: partial (1 of 2), via the EC interrupt
  cfe5ed6 Bluetooth works (2026-11-04-14); capture the s2idle wake IRQ
  635448d Bluetooth for M2: mica-bt.config, QCA firmware, /init capture
  8ebbda3 /init suspend modes: key (wake by key, 120 s safety alarm) and deep
  48fc483 M2 park round: 16 rows parked, 3 tests left (wake, deep, Bluetooth)
  ... and 216 more

Decisions

Architecture decision records, Nygard’s shape (status, context, decision, consequences) with dated updates.

• 1. No bootloader unlock until a way back to stock is proven
• 2. Experiment on a spare M.2 2230 SSD; keep the stock drive intact
• 3. First boot through a ChromeOS kernel partition on external storage
• 4. Mainline device tree forked from the XPS 13 9345; stock tree as hardware map only
• 5. Vendor content and per-unit identifiers stay out of git; extraction stays reproducible
• 6. Debug console through GSC CCD and a SuzyQ, read-only while CCD is locked
• 7. Local kernel patches live in kernel/patches/ and apply at build time
• 8. The board DTS removes the PSCI domain idle states (cluster cl4/cl5, system ss3)
• 9. No PSCI cpuidle on mica: the per-CPU domains lose cluster_c4
• 10. Milestones M0 to M7, a feature status table, and the upstream hold ends at M5
• 11. Versions: CalVer tags for released images, the gbook version in uname -r
• 12. M3 rootfs: Debian sid from a snapshot, on the stick’s partition 2, entered by switch_root
• Decisions

1. No bootloader unlock until a way back to stock is proven

Status

Accepted (from the project log, 2026-10-17; recorded as an ADR 2026-10-21)

Context

Unlocking the bootloader wipes all data and disables device security (Google Help). The device is new and the only one the owner has. Dell’s Service Manual (Rev. A00, pages 65-66) documents USB recovery media from Google’s Device Recovery Utility, but nobody has shown that it restores a device that was unlocked, that has a blank or foreign SSD, or that it lets the bootloader be relocked. Google may serve only the latest image, so anti-rollback could block an older build.

Decision

Phase 2 (unlock) starts only after Gate 1 passes:

• recovery media made and tested to reach the recovery screen,
• the working recovery key combo recorded,
• the recovery image and its build number saved,
• build fingerprint and bootloader version recorded,
• device-specific data that Phase 2 needs is backed up or dumped.

Agents never unlock, flash or enter recovery or fastboot; the owner does those steps by hand.

Consequences

Phase 1 stays on the stock OS, read-only over adb, which slows the start but keeps the device returnable. The spare-SSD approach (ADR 0002) reduces risk further but does not replace this gate, because the bootloader state lives in firmware, not on the SSD.

Update 2026-10-21

• Google’s recovery image for mica is public: mica-user/16471258/recovery.zip (downloaded to dumps/, sha256 in stock-dtb.md). Its build CL3B.260622.273.R1/16471258 (AVB rollback index 1339) is older than the installed CL3B.260622.276.R2/16560795. Whether anti-rollback accepts it is unknown, so it does not pass Gate 1 by itself.
• Unlocking is ChromeOS developer mode (ADR 0003). “Lock bootloader” on the developer screen returns to normal mode. Whether that restores verified boot without a reinstall is still untested.
• Still required for Gate 1: Device Recovery Utility media made and booted to the recovery screen, and the build it serves compared with the installed one.

Update 2026-10-21 (recovery steps)

Google’s Recover your Googlebook (read 2026-10-21) documents:

• Media: recovery media from the Device Recovery Utility in Chrome on a Chromebook, Windows or Mac. Linux is not listed. The drive is 32 GB or more and gets erased.
• Recovery mode: Esc + F2, then Power. Esc + Refresh in Dell’s Service Manual is the Chromebook combo.
• Recovery erases: recovering “permanently erases everything”.

For Gate 1, the owner stops at the recovery screen and does not select Use USB drive. The checklist lives in Pass Gate 1.

Update 2026-11-02 (Gate 1 passed)

Device Recovery Utility media reaches the recovery screen with Esc + F2, and serves CL3B.260622.276.R2/16560795, the installed build (rollback index 1339). A full copy of the stick is in dumps/gate1/. Details: Pass Gate 1. The relock test runs on unlock day, before any Linux boot (unlock-day ticket).

2. Experiment on a spare M.2 2230 SSD; keep the stock drive intact

Status

Accepted (from the project log, 2026-10-17; recorded as an ADR 2026-10-21)

Context

Dell’s Setup and Specifications guide (Rev. A00) lists one M.2 2230 PCIe Gen4 x4 NVMe slot, and the Service Manual reaches the SSD right after the base cover (4 Torx T5 screws). The SSD is a field-replaceable part. Dell names “Google Qualified” drives, so an unlisted drive may or may not be accepted.

Decision

All Linux experiments run on a second 2230 SSD. The stock drive comes out and stays in a drawer. Before any internal work: disconnect the battery-cable bracket and hold power for 20 s (Service Manual).

Consequences

• Returning to stock is a drive swap, as long as the bootloader and firmware state allow it (see ADR 0001).
• Open, testable questions: does the firmware accept an unlisted drive; does a cloned stock drive boot (tells whether the drive is bound to the device); do recovery and fastboot live in the 32 MB firmware flash (a blank drive answers that, since fastbootd lives on the SSD).
• Opening the case may matter for warranty; the owner decides when.

Update 2026-10-21

The stock internal disk (from the recovery image’s GPT, stock-dtb.md) mixes ChromeOS KERN-A/B and ROOT-B with Android A/B partitions (boot_* use the ChromeOS-kernel type GUID). The first Linux boot goes on external or spare storage (ADR 0003). Nothing in that plan needs the stock drive.

Update 2026-10-21 (first boot)

Owner decision (boot media and port hookup):

• First boot: Phase 2 runs from a dedicated USB stick in the right USB-C port, on battery.
• Spare SSD: deferred to Phase 3, when Linux needs persistent storage.
• Stock SSD: for Phase 2 it stays installed rather than in a drawer, and it is never written (ADR 0003). It is the fallback boot, and the stock OS on it reads back a failed boot’s ramoops through dropbox.

The rest of this decision applies once Phase 3 starts.

3. First boot through a ChromeOS kernel partition on external storage

Status

Accepted 2026-10-21. Supersedes the log’s original Phase 2 plan (fastboot boot of an Android boot image, then Mu-Silicium as a fallback).

Context

The original plan assumed Qualcomm ABL and Android fastboot. Recon and source research showed otherwise (recon, chromeos-boot-path.md):

• The bootloader is ChromeOS depthcharge (Google_Mica.16702.*, branch firmware-bluey-16702.B).
• Google’s “Unlock bootloader” is vboot developer mode. After the transition, the firmware enables external boot and fastboot, and it boots self-signed kernels.
• depthcharge’s fastboot has no boot command, so there is no RAM boot. It runs only through an ALink or PL27A1 bridge, or over TCP via a USB-Ethernet adapter.
• vboot accepts ChromeOS-type kernel partitions (FIT image: kernel plus DTBs) and Android vbmeta partitions. depthcharge picks a FIT configuration by compatible, down to google,mica.

Decision

The first Linux boot uses a ChromeOS kernel partition (GUID fe3a2a5d-…) on a USB drive or the spare SSD:

• Image: a FIT image with the mainline Image, the mica DTB and an initramfs, signed with the public vboot developer keys.
• Build: depthcharge-tools with a [boards/custom/mica] section.
• Boot: from the “Boot from external drive” menu.

The Android GKI route (modified boot/vendor_boot/dtbo) and RW_LEGACY alternate firmware are fallbacks, not the plan.

Consequences

• The stock SSD and its Android partitions are never written during first-boot tests.
• No special cable is needed. The SuzyQ on the left port gives the AP console (ADR 0006).
• Partition attributes (priority, tries, successful) decide what boots. A bad image falls back to the next partition or the menu, not to a brick.
• postmarketOS’s trogdor recipe (deviceinfo_generate_depthcharge_image, cgpt) applies almost directly.
• Still to confirm on the device: the board-id/sku-id DT match, and whether depthcharge leaves a framebuffer.

Update 2026-10-21

Source research answered both items under “Still to confirm on the device”, pending a live boot:

• DT match: not a blocker. A DTB whose root compatible holds google,mica matches any board-id and sku-id, and a single-DTB FIT keeps a default config that boots even without a match. depthcharge prints the real ids on the AP console (fit-packaging.md).
• Framebuffer: depthcharge adds no simple-framebuffer node. coreboot’s scan-out at 0xE4800000 stays live, and mainline can use it through COREBOOT_FRAMEBUFFER and simpledrm only if the DTS reserves that region no-map (silent-boot-observation.md).
• Exception level: the kernel starts at EL2 with no hypervisor, so the DTB needs the x1-el2.dtso changes (el2-handoff.md).

Update 2026-10-21 (first-boot details)

Decided on the first-boot map:

• Image: a 256 MiB image holding only KERN-A (128 MiB), cgpt add -i 1 -t kernel -S 0 -T 3 -P 15. It is rewritten whole for every attempt, which resets vboot’s tries (Iteration loop).
• Hookup: a dedicated USB stick in the right USB-C port, on battery, with the SuzyQ on the left. The owner writes the stick with pkexec dd (Boot media and port hookup).
• Firmware fastboot over TCP is ruled out: it writes only the single fixed disk, the stock SSD (depthcharge 694eabf src/fastboot/disk.c:40-44).
• DTB: the FIT carries x1e80100-google-mica-el2.dtb, because the kernel enters at EL2 with no hypervisor (EL2 handoff).

Update 2026-11-05 (12:20 PM EST): the stock drive locked read-only from /init

“The stock drive is never written” is now enforced mechanically for the Linux side of a boot: /init’s lock_stock() (task #36, after the Steam Frame initramfs’s blockdev_ro hook, re-implemented from its description in steamos-arm.md) runs right after the stick is identified by its kern_guid partition and sets every other block device, whole disks and partitions, read-only at the block layer (blockdev --setro); ram, loop, zram and dm devices are skipped, and an unknown GUID locks nothing (locking the stick blindly would break ROOT). The capture GBOOK: lock-ro= names what was locked, none: only the stick (sda) while the NVMe driver stays # forbid-y, or skipped: with the reason. It is advisory against mistakes: a root process can --setrw. check.sh 58 drives it on a synthetic /sys/class/block with a fake blockdev. Untested on the device until the next boot.

4. Mainline device tree forked from the XPS 13 9345; stock tree as hardware map only

Status

Accepted 2026-10-21.

Context

• No mica DTS exists anywhere: not in mainline, not in the ChromiumOS 6.12 kernels, not on lore.
• The stock DT is a Qualcomm vendor tree: an LZ4 base plus overlays in dtbo_a, with sde, qupv3_seN and qcom,… properties. Mainline cannot boot it.
• The 9345 is a close match: address-by-address comparison (9345-dts-diff.md) shows mica reuses its retimer block, touchscreen, PCIe, eDP and uart21 debug console. The parts that differ are ChromeOS ones: cros-ec, Ti50, QSPI flash, a USB fingerprint MCU.

Decision

• dts/x1e80100-google-mica.dts starts as an unmodified copy of mainline x1e80100-dell-xps13-9345.dts at a pinned commit (torvalds a804c57), committed alone. Mica’s changes go in later commits, so the diff is the record.
• compatible = "google,mica", "qcom,x1e80100".
• The stock tree is used only as a hardware map: buses, addresses, GPIOs, regulators, keymap. Every board-specific pin must trace to it. Anything copied from the 9345 without a stock match is marked “unverified”.
• Checks before a commit counts: scripts/build-dtb.sh with no warnings, and dt-validate with no findings beyond the pending google,mica binding.

Consequences

• Upstreaming later needs a qcom.yaml binding patch, alphabetical node order and correct attribution.
• Mainline changes to the 9345 file should be followed by re-basing onto a newer pinned commit.
• Missing pieces (keyboard backlight, Glowbar, ALS, fans, audio, camera) get added once something boots.

Update 2026-10-21

• EL2 changes come from mainline’s x1-el2.dtso, applied at build time (x1e80100-google-mica-el2.dtb), the way mainline builds every x1 board. The DTS stays the plain board file (What goes into the first-boot DTB).
• One board fact traces to firmware source rather than the stock tree. The framebuffer reservation’s address matches the stock splash_region (0xe4800000). Its size, 0x2200000, comes from coreboot’s memlayout.ld; stock uses 0x21c0000 with no no-map.
• /chosen/stdout-path = "serial0:115200n8" is now in the DTS, traced to the stock base (commit 709212e).

5. Vendor content and per-unit identifiers stay out of git; extraction stays reproducible

Status

Accepted 2026-10-21. It records rules that CLAUDE.md has applied since the scaffold.

Context

• Vendor blobs: the work needs Google’s and Dell’s binaries (the recovery image, the stock DTB, and the DSP and GPU firmware), and they are not ours to redistribute.
• Identifiers: recon output is meant for public channels (#aarch64-laptops, linux-arm-msm), but adb, the GSC and the recovery image all expose per-unit identifiers (serials, chip IDs, MACs, pcr0).
• Remote: the repo is private on the private remote today and may become public.

Decision

• dumps/ is gitignored. It holds downloads and extractions (recovery zip and image, partitions, stock DTBs, firmware). *.img, *.bin, *.mbn, *.elf, *.dtb and .firecrawl/ are gitignored too.
• Commit derived facts, not blobs: hashes, sizes, node maps, addresses, keymaps as text, and source URLs.
• Extraction is scripted from public inputs (scripts/extract-stock-dtb.sh from the public recovery URL), so anyone can reproduce it.
• Redaction happens before writing, for anything committed: scripts/recon.sh redacts serial numbers, boot ids and MACs. GSC console captures leave out the Ti50 serial, chip ID and pcr0.

Consequences

• A fresh clone cannot boot anything without running the extraction scripts first.
• Before any push, check: git ls-files | rg '^dumps/' must be empty, and no serial-like strings in docs/.

Update 2026-11-05, 2:08 PM EST: the public export

The identifier list grows for publication (public-writeup.md, “Build round”; task #39). LAN addresses are redacted at source like serials (commit bf34583: ADR 0012 and two recon notes). Host, user and remote names and the owner’s mail domain stay in this private repo’s text and are substituted when scripts/export-public.sh builds the public tree; that script holds the name list, and site/gate.sh (which ships with the export) holds only the generic classes (MACs, serials, chip IDs, RFC 1918 addresses). Check 61 runs the export and the gate before every commit.

6. Debug console through GSC CCD and a SuzyQ, read-only while CCD is locked

Status

Accepted 2026-10-21.

Context

First boot needs a console that works before display or USB drivers do. Tested 2026-10-21 (ccd-gsc.md):

• A Fyra Labs SuzyQ in the Googlebook’s left USB-C port exposes the Ti50 as 18d1:5066, with Shell, AP, EC and FPMCU consoles.
• ccdstate shows UARTAP+TX: the AP UART is bridged both ways while CCD is Locked.
• The stock and mainline DTs both name uart21 (0x894000) as serial0.
• Opening CCD (gsctool -a -o plus power-button presses) needs developer mode, and it changes GSC state.

Decision

• Kernel console: uart21 is the first-boot console: stdout-path = "serial0:115200n8", console=ttyMSM0,115200. the build host reads it through the SuzyQ’s AP console.
• Read only: agents run the SuzyQ consoles read-only. Before reading, run stty raw -echo on the tty so nothing echoes back. On the GSC shell, agents send only read-only commands (version, ccdstate, help). Never ccd open/unlock/reset, wp, reboot or any flash command.
• Opening CCD (for a full AP flash backup over raiden_debug_spi) is an owner decision. It happens after unlocking and gets its own ADR.
• the build host access: the uaccess udev rule /etc/udev/rules.d/70-ti50-ccd.rules (owner choice over joining uucp).

Consequences

• The left USB-C port is taken by the SuzyQ during bring-up. Boot media and power go through the right port (a hub with PD pass-through) or the spare SSD.
• If the AP console stays silent under Linux, the fallbacks are ramoops (depthcharge always reserves it) and the panel.

Update 2026-10-21

• The DTS has the console now: it sets stdout-path = "serial0:115200n8" (commit 709212e).
• Read-only still applies with our own kernel: the first-boot initramfs prints its captures, then reboots, and has no shell (Initramfs contents and pass criteria).
• Logs: raw AP-console logs go to dumps/firstboot/.
• Second channel: when the console is silent, the stock OS’s dropbox SYSTEM_LAST_KMSG holds the failed boot’s last 64 KiB (stock pstore).

7. Local kernel patches live in kernel/patches/ and apply at build time

Status

Accepted 2026-11-03 (owner, “1a 2a 3b”).

Context

• Until now the first-boot kernel was torvalds a804c57 plus config fragments only (kernel/*.config).
• The first change that needs kernel source is a panel-edp entry for the mica panel (LGD 0x0804): without it the driver warns and uses fallback timings (panel-edp.c:755-772).
• The kernel tree lives outside the repo (~/.cache/gbook/linux-a804c57, set up by scripts/setup-toolchain.sh), and the DTS scripts and check.sh read the same tree.

Decision

• Patches are files in git: kernel/patches/NNNN-<topic>.patch, unified diffs against the pinned commit, each with a header saying what it changes, its source and whether it went upstream. Name order is apply order.
• scripts/build-kernel.sh applies them before every build: it restores the files the patches touch from the pinned commit, fails if the tree has any other change, then runs git apply on each patch. The patches stay applied after the build, so the kernel release ends in -dirty.
• check.sh check 20 fails when a patch no longer applies (or reverts) cleanly against the tree.
• Upstream is a separate decision per patch. The first one (0001, panel-edp) stays local: the EDID gives only part of the model name (“LP134WQ…”), and an upstream entry needs the full name.

Consequences

• The pinned tree is no longer pristine after a build; git -C ~/.cache/gbook/linux-a804c57 status shows the patched files. Running build-kernel.sh again is safe, and any foreign edit stops it.
• Moving the pin (ADR 0004) means re-checking every patch; check 20 shows which ones break.

Update 2026-11-04 (10:07 AM ET): a status line on every patch, and numbers are never reused

Owner: “all a” to question 5 of milestones-versioning.md, section 5.

• Line 1 of every patch reads Status: <WORD> <reference>. The words are ChromiumOS’s patch-tagging words, with LOCAL in place of its CHROMIUM and no BACKPORT (a modified copy says so in its reference):

  • LOCAL <who>: carried downstream and not posted to a list (gbook’s own, or a third party’s downstream fix-up);
  • FROMLIST <list reference>: posted to a list, not in a maintainer tree when checked;
  • FROMGIT <tree> <branch>: in a maintainer or -next tree, not in mainline;
  • UPSTREAM <tag or commit>: in mainline, a backport onto the pin.

  A lore Message-ID goes in the reference when one is known, and the line says “not recorded” otherwise. The free-text header below the line stays. git apply ignores everything before the first diff, so check 20 is unaffected.

• A patch number is never reused. A deleted patch’s number is retired, and the next patch takes the next unused number. Two numbers were reused before this rule:

  • 0008 first named a GENI I2C timing patch (16a2828) and now names the PCIe GDSC patch;
  • 0009 first named the IRQ-to-CPU-1 diagnostic (cee735d, deleted by ADR 0009) and now names the PCIe PHY GDSC patch.

  The new patches arrived on 2026-11-04 (5272658 at 4:07 AM ET and ddecbd8 at 4:47 AM ET). A log entry older than those commits that says “0008” or “0009” means the old patch.

• check.sh check 34 enforces both rules. It allows exactly those two old reuses.

8. The board DTS removes the PSCI domain idle states (cluster cl4/cl5, system ss3)

Status

Superseded 2026-11-04 by ADR 0009 (owner round 4): the stall does not need the domain states; the board DTS now drops the per-CPU cluster_c4 instead and keeps the domain states as stock.

Accepted 2026-11-03 (owner, grilling round 2: “yes” to all four). A deliberate deviation from the stock tree (ADR 0004).

Context

• On mica the CPUCP’s SCMI replies stalled for 0.5 to 1 s on most cold boots, with a timeout now and then. That needed the local arm,max-rx-timeout-ms = <1000> to come up at all (scmi-2026-11-03.md, attempts -20 to -26).
• A/B boots, all cold, interrupt mode unless noted:
  • Without cluster_cl5 (-27) or without domain_ss3 (-30): both still stalled.
  • No stalls: cpuidle.off=1 (-28), polling with arm,no-completion-irq (-29), and no domain idle states at all (-34). Each was 3 of 3, with replies within 0.1 to 4 ms.
  • With the domain states present: 8 of 11 boots stalled.
• The wake trace (-32): during a stall, CPU 0, which takes the mailbox interrupt, left the PSCI ret state every ~20 µs without taking any interrupt.
• The counters (-33): PSCI in OS-initiated mode refused the composite ss3 request about 598000 times in 95 s, from the last CPU of clusters 1 and 2, and genpd retried each time.
• The stock tree has the same four states and topology (entry00-base.dts: cluster_pd0-2 with cl4 and cl5, system_pd with system_ss3). Stock runs Qualcomm’s own cpuidle and SCMI stacks, so its behaviour does not carry over (inference).

Decision

• x1e80100-google-mica.dts deletes domain-idle-states from cluster_pd0, cluster_pd1, cluster_pd2 and system_pd. The per-CPU domains keep cluster_c4, so CPUs still enter PSCI retention.
• The 1000 ms SCMI window stays as a safety net. It costs nothing on a fast boot and is still marked unverified.
• Polling stays a diagnostic. arm,no-completion-irq is not in the board DTS: the binding describes hardware without a completion interrupt, and mica has one.
• Upstream waits. A report draft lives in scmi-cpucp-stall-report.md, and sending it is a separate owner decision after the suspend test.

Consequences

• The clusters and the SoC never power down when idle, so idle power is higher. How much has not been measured.
• Suspend is untested either way. It is the trigger to revisit this ADR, together with a firmware update or an upstream fix. The finer cut, keeping cl4 and dropping cl5 and ss3, was not tested.
• Why the firmware refuses the composite states, and how that delays the interrupt to CPU 0, is still open.
• dts/README.md lists the change under “Changes” as a deviation, citing this ADR.

Update 2026-11-04 (12:26 AM ET): not a complete fix

Attempts 2026-11-04-1 and -2 stalled on this board DTS (max replies 1019.2 ms with 2 timeouts, then 652.0 ms): 2 of 6 cold boots without domain idle states, against 8 of 11 with them. Both stalled boots show CPU 0’s state1 loop (130000-156000 entries by the early read, against 4700-19000 on clean boots) with 0 PSCI refusals, so the stall does not need the composite states (scmi-2026-11-03.md, “ADR 0008 is not enough”). The decision is open again: keep, revert or replace this change. The 1000 ms window keeps every boot working either way.

9. No PSCI cpuidle on mica: the per-CPU domains lose cluster_c4

Status

Accepted 2026-11-04 (owner, grilling round 4: “yes” to all four). Supersedes ADR 0008. A deliberate deviation from the stock tree (ADR 0004).

Context

The evidence is in scmi-2026-11-03.md, attempts -27 to 2026-11-04-3.

• The symptom: SCMI replies from the CPUCP stalled for 0.5 to 1 s, with an occasional timeout, on most cold boots. The 1000 ms window kept every boot working.
• No stalls: with plain WFI (cpuidle.off=1, -28) and with polling (arm,no-completion-irq, -29), 0 of 3 each. Polled replies take 0.1 ms, so the CPUCP answers fast.
• During a stall (-32), the core that takes the reply’s SPI leaves the PSCI ret state (cluster_c4, arm,psci-suspend-param 0x4) about every 20 µs. It takes IPIs but not the SPI, until a timer PPI runs.
• The stall follows the interrupt’s CPU (2026-11-04-3, kernel/patches/0009 routing SPI 28 to CPU 1): CPU 1 looped (134862 state1 entries) and the reply stalled for 872 ms, while CPU 0 stayed normal.
• The domain states are not the cause. Removing the cluster and system states (ADR 0008) still left 2 of 6 cold boots stalling. The PSCI refusals of ss3 (-33) ran alongside the stall.
• Other SPIs stalled too: GENI I2C timeouts on -30, and a loop with no SCMI pending on -32 (inference).
• Mainline gives no per-CPU way out. irqaffinity= always keeps the boot CPU (kernel/irq/irqdesc.c:36). A CPU without idle states makes cpuidle-psci fail for every CPU (cpuidle-psci.c:399-401, :437-447 at a804c57).

Decision

• x1e80100-google-mica.dts deletes domain-idle-states (cluster_c4) from cpu_pd0 to cpu_pd11. cpuidle-psci then does not load, and every core idles in WFI, as with cpuidle.off=1.
• The cluster and system domain states stay as stock. Without cpuidle-psci nothing requests them, so ADR 0008’s deletions are reverted.
• The 1000 ms SCMI window stays as a safety net and is still marked unverified.
• kernel/patches/0009 (the IRQ-to-CPU-1 diagnostic) is deleted. The idle-counter and wake-trace tooling stays.
• The upstream report is rewritten around this mechanism in scmi-cpucp-stall-report.md and is not sent. Sending is a separate owner decision after the suspend test.

Consequences

• No core enters PSCI retention, and no cluster or the SoC powers down when idle. Idle power is higher; how much has not been measured.
• s2idle uses cpuidle states, so suspend will not reach PSCI low-power states with this DT (inference). The suspend test is the trigger to revisit, together with a firmware update or an upstream answer.
• Why a core in ret does not take a pending SPI is open: the GIC’s wake path, or the PSCI firmware. That is the report’s question.

Update 2026-11-04 (12:57 AM ET): confirmed on the board DTS

Attempt 2026-11-04-4 booted this DT (kernel #21). There was no cpuidle driver, SCMI replied within 0.1 ms (78 of 78, 0 timeouts), and cpufreq came up on all three clusters. With -28, plain WFI is 4 of 4 cold boots without a stall.

Update 2026-11-04 (2:31 AM ET): the tally

scripts/attempt.sh tally (scmi-2026-11-03.md, “the counts from attempt.sh tally”): domain states present 7 of 10 stalled against no PSCI cpuidle 0 of 4 (p = 0.035); ADR 0008’s DT 3 of 7 against 0 of 4 (p = 0.21, not significant alone). The decision stands on the mechanism plus the first comparison. More boots on this DT will sharpen the count; record now adds each one to the table.

Update 2026-11-04 (4:40 AM ET): the suspend test, and the tally at ten boots

The suspend test ran: six cold boots, 2026-11-04-5 to -10 (suspend-2026-11-04.md). s2idle entry and the RTC wake work. The resume resets the SoC every time, in the PCIe controllers’ noirq resume: first the PCIe GDSCs (fixed by local patch 0008, from an upstream series), then the NVMe endpoint behind PCIe 6a (link kept) and PCIe 4’s host re-init (link shut down). The failure comes before any idle state matters, so the test neither confirms nor refutes this ADR’s suspend cost (inference). The revisit stays open until a resume completes.

Those boots also added to the count (scripts/attempt.sh tally with group 2 '^2026-11-03-28$|^2026-11-04-([4-9]|10)$'; kernels #21 to #23 and the no-PCIe-6a diagnostic DT, none of which touches the SCMI probe). No PSCI cpuidle: 0 of 10 stalled. Against domain states present, 7 of 10: p = 0.0015. Against ADR 0008’s DT, 3 of 7: p = 0.051.

Update 2026-11-04 (5:01 AM ET): a complete suspend round trip, and the count against ADR 0008

With local patches 0008 and 0009 (the PCIe GDSCs and the PCIe PHY GDSCs to retention), attempt 2026-11-04-11 completed an s2idle round trip on this DT (suspend-2026-11-04.md, newest update). The CPUs had no cpuidle driver, so s2idle ran in WFI. Whether the SoC reached a low-power state, and at what power, is not measured. The revisit trigger is met, and the suspend cost of this ADR is still the open question. Measuring it needs a power reading that is not charge current.

Count: console boot #11 adds one more clean boot to -10. Group 2 is now '^2026-11-03-28$|^2026-11-04-([4-9]|1[01])$': 0 of 12 stalled. That is p = 0.0007 against domain states present (7 of 10), and p = 0.036 against ADR 0008’s DT (3 of 7), now under 0.05.

Update 2026-11-04 (5:13 AM ET): suspend 3 of 3, the count at 14

Two more boots of -11’s image completed the round trip too: 3 of 3 (suspend-2026-11-04.md). All were clean for SCMI. The same group 2 regex now gives 0 of 14 stalled: p = 0.0003 against domain states present, and p = 0.026 against ADR 0008’s DT.

Update 2026-11-04 (10:07 AM ET): when the report is sent

The “Decision” line that made sending scmi-cpucp-stall-report.md an owner decision after the suspend test is superseded by ADR 0010. The report waits for milestone M5, like the binding and DTS. The owner reviews and sends it, and an agent never does.

This ADR’s “patch 0009” is the deleted IRQ-to-CPU-1 diagnostic (cee735d). Today’s kernel/patches/0009 is a different patch, the PCIe PHY GDSCs, added before numbers were retired (ADR 0007 update).

Update 2026-11-04 (11:24 AM ET): the first base image, and the count at 17

Attempt 2026-11-04-12 is the first base image on this DT with patches 0008 and 0009: kernel #26, no command-line or DT extras. It had 3 cold boots, all clean for SCMI. scripts/attempt.sh tally with group 2 '^2026-11-03-28$|^2026-11-04-([4-9]|1[0-2])$' gives boots=17 known=17 stalled=0 clean=17: no PSCI cpuidle has 0 of 17 stalled.

10. Milestones M0 to M7, a feature status table, and the upstream hold ends at M5

Status

Accepted 2026-11-04 (owner: “all a” to the open questions 1, 7 and 9 of milestones-versioning.md, section 5). Supersedes the line in ADR 0009 “Decision” that made sending the stall report an owner decision after the suspend test.

Context

• The phases and gates (README “Phases and gates”) mark four big steps. Phase 3, from first boot to a daily-drivable install, is a long stretch with no checkpoint in between. Progress was tracked as prose in README “Resume here”.
• Comparable projects track progress per feature and per stage (research note, section 1):
  • Asahi’s feature-support tables have a column saying where each feature lives (upstream release, downstream, WIP).
  • postmarketOS (now Nura) puts devices into categories with entry criteria.
  • The XPS 13 9345’s first upstream DTS went in with the EC, speakers, mics and camera not working, and it listed what worked and what did not.
• The kernel’s process documents favour posting early (3.Early-stage.rst, 5.Posting.rst at the pin). A board DTS needs a documented compatible (bindings submitting-patches.rst item 7), must pass dtbs_check with no new warnings, and must pass dt-check-style in relaxed mode (maintainer-soc.rst) (research note, section 3).
• AI agents must not add Signed-off-by and must never send anything themselves (coding-assistants.rst:34 at the pin). 207 of the repo’s 210 commits had a Claude co-author trailer (git log, 2026-11-04).
• On 2026-11-04 the owner put upstream sends (the SCMI stall report, patch 0009) on hold “until the project progresses further”.

Decision

• The milestone ladder. Each rung fits inside the phases and gates:

  M	Name	Phase / gate	Done when
  M0	Way back to stock	Phase 1, Gate 1	recovery media reach the recovery screen and relock is tested (ADR 0001)
  M1	First light	Phase 2, Gate 2	our Linux version line on the AP console, the panel or the readback
  M2	Board on the console	Phase 3	every enabled DT node binds; the M2 rows of docs/status.md read works; every other row is works, or partial or parked with a note; one base image has 3 clean cold boots by scripts/attempt.sh tally
  M3	Userspace from USB	Phase 3	a rootfs from USB with Mesa on the GPU and Wi-Fi in userspace; the audio state is known; the first release tag (ADR 0011)
  M4	Daily-drivable	Phase 3, Gate 3	installed on the spare SSD (ADR 0002), with dual-boot or a documented return to stock
  M5	Upstream-ready	Phase 4 entry	the google,mica binding and the DTS, rebased on the qcom tree, pass dt_binding_check, dtbs_check (no new warnings), relaxed dt-check-style and checkpatch.pl; a Working / Not working list is written; every local patch has its status line; the owner has reviewed and signed off every patch
  M6	Upstream	Phase 4, Gate 4	the binding and DTS are applied to the qcom tree, then reach a mainline release
  M7	In a distribution (optional)	after Phase 4	a Nura testing device package, or an Ubuntu Concept entry

  The M2 rows are: USB host, Type-C, PCIe enumeration, Wi-Fi, eDP and backlight, GPU probe, EC keyboard, touchpad, TPM, SCMI cpufreq and an s2idle round trip. A base image is one with no debug command-line or DT extras: its scripts/attempt.sh stick first line reads base image.

• docs/status.md is the feature matrix. It has one row per feature and four state words: works, partial, broken, untested. Untested is the default. Each row says where the feature works (mainline at the pin, a local patch, the board DTS, a config fragment), what upstream has or what gbook would have to send, and the recon note behind it. README “Resume here” points to it. Its prose stays as the owner’s dated record.

• The upstream hold ends at M5. Nothing goes to a list before then. At M5 the binding and DTS go out first as a [PATCH RFC] series, following the kernel’s own versioning (ADR 0011). The stall report and patch 0009 wait for the same bar. The owner reviews, signs and sends every patch. An agent never adds Signed-off-by and never sends.

• The research note’s other rider is the owner’s call. It suggests a recon post in #aarch64-laptops before M5 (Phase 1 list in the project log). That post is the owner’s to make, and an agent does not post.

Consequences

• Progress has a name between the gates: “M2 nearly done” says more than “Phase 3”.
• docs/status.md has to be kept current. A recon note that changes a feature’s state also changes its row.
• M5 can run in parallel with M3 and M4, because it is about the binding and DTS, not userspace.
• What blocks M5 today (inference, research note section 3): the unverified arm,max-rx-timeout-ms, ADR 0009’s deleted idle states, the merge-window pin, and the panel entry that lacks the full model name.

Update 2026-11-04 (11:37 AM ET): parking untested rows

Owner, park round (“yes” to all recommendations). A parked row in docs/status.md keeps its state (untested, partial or broken), and its note says “parked until ”. M2’s third criterion counts a parked row as settled. The first round parked 16 rows:

• NVMe I/O until the spare SSD (M4);
• the left port’s USB 3 and DP until a session without the SuzyQ;
• idle and suspend power until a battery-only session;
• audio, camera, fingerprint, the rootfs and Mesa until M3;
• the lid switch, ambient-light sensor and Glowbar until a stock-tree or EC lead;
• the crypto engine until upstream drops BROKEN.

Three rows stay open for M2: wake from s2idle by a key or the power button, deep suspend, and Bluetooth.

Update 2026-11-04 (12:38 PM ET): M2 reached

All four criteria of M2 are met (docs/status.md, “Milestone M2”):

• every enabled DT node binds, by the unbound= proxy;
• the twelve M2 rows work; the backlight was set and read back in 3 of 3 base-image boots;
• every other row works, is partial, or is parked: Bluetooth works (2026-11-04-14), keyboard wake from s2idle is partial (-15), deep suspend failed and is parked (-16), and 16 rows were parked in the park round;
• the base image 2026-11-04-12 has 3 clean cold boots (tally).

The next milestone is M3, userspace from USB. Its first base image that passes the release bar gets the first tag (ADR 0011).

Update 2026-11-04 (7:11 PM ET): M3’s technical criteria have evidence; the release is pending

Three ROOT boots on 2026-11-04 (attempts -18 to -20; rootfs-2026-11-04.md): a rootfs from USB with Mesa on the GPU (eglinfo, kmscube, cage and vkcube on the Adreno X1-85), Wi-Fi in userspace (the supplicant and networkd carried the netlog), and the audio state known (aplay -l: no sound card; the attempt is ticket 10). The status rows “Rootfs from USB” and “Mesa (freedreno)” read works. M3 closes with the first release tag (ADR 0011): a snapshot-pinned rootfs build, 3 clean cold boots of one base image, and the owner’s tag drafted by scripts/release-draft.sh.

Update 2026-11-04 (8:39 PM EST): M3 reached, first release v2026.11.04

The release bar was met the same evening: the rootfs rebuilt from snapshot 20261104T000000Z (321 packages, 4b0e2e027c0b2d74…), written to ROOT and read back equal (attempt.sh root-cmd, root-verify), then three clean cold boots of base image 9673d6d782ef4cdb (attempts -21 to -23, tally clean=3 stalled=0; rootfs-2026-11-04.md, “Release boots”). The owner tagged v2026.11.04 from scripts/release-draft.sh’s message and pushed it to the private remote. M3 is passed. The upstream hold stays until M5; the next milestone is M4, daily-drivable (Gate 3).

11. Versions: CalVer tags for released images, the gbook version in uname -r

Status

Accepted 2026-11-04 (owner: “all a” to the open questions 2, 3, 4, 6 and 8 of milestones-versioning.md, section 5). Question 5 (patch status lines) is an update to ADR 0007.

Context

• Several things change at different rates: the repo (every commit), the boot image (every package-image.sh), the kernel base (a re-pin), the local patches, and the boots themselves. Each boot has an attempt ID YYYY-MM-DD-N in attempts.tsv. The repo has no tags. An image is identified only by its kernel banner (release plus UTS #N).
• SemVer requires a declared public API (semver.org 2.0.0, item 1), and gbook has none. CalVer suits projects whose releases are driven by external changes (calver.org, “When to use CalVer?”). Here those changes are the mainline base and the milestones.
• Annotated git tags “are meant for release” (git-tag(1)), and git describe reads only annotated tags by default.
• scripts/setlocalversion at the pin appends the contents of localversion* files in the object and source dirs to the release. init/Kconfig caps the release at 64 characters.
• The pin a804c57 is a 7.4 merge-window commit, 1703 commits after v7.3 and before v7.4-rc1 (GitHub compare API, research note section 2).

Decision

• A release is a base image with 3 clean cold boots. A base image has no debug command-line or DT extras (scripts/attempt.sh stick reads base image). The 3 boots of one image hash are counted by scripts/attempt.sh tally, and the image is one the owner would hand on. Every other image is an experiment, named only by its attempt IDs.

• A release gets an annotated tag vYYYY.0M.0D[.MICRO] (CalVer, e.g. v2026.11.20; .1 for a second release the same day). The tag goes on the gbook commit that built the image, after its 3 boots. The image must have been built from a clean tree (no + in its uname -r). No SemVer.

• The tag message is the release note until a tagged image first leaves the build host. From then on, CHANGELOG.md in Keep a Changelog 1.1.0 form is the release note. The message contains:

  • the milestone;
  • the kernel base (a804c57, “v7.3 + 1703, 7.4 merge window”) and the kernel release from uname -r;
  • each local patch with its status line;
  • the image sha256 as scripts/attempt.sh stick prints it;
  • the attempt IDs and the tally line that proved it;
  • what changed since the last tag.

• uname -r names the gbook state. scripts/build-kernel.sh writes localversion-gbook into the build directory (the O= dir, never the source tree). Its gbook_localversion() gives the exact rules, and check 35 tests them:

  • -gbook- plus git describe against the nearest annotated v[0-9]* tag, without the v (-gbook-2026.11.20-3-g1a2b3c4);
  • -gbook-g<hash> before the first tag;
  • a trailing + when the tree differs from the commit (changed tracked files, or untracked ones that are not ignored).

  Today that reads 7.3.0-gbook-g6934235-ga804c5742bff-dirty. The kernel tree’s own -dirty (the applied patches, ADR 0007) stays. A released image keeps the -gbook-g<hash> it was built with, because the tag comes after its boots. The tag message maps that hash to the version, and a rebuild at the tag would be a new, unproven image. The kernel column of attempts.tsv already records the release, so each attempt names its gbook commit, and no new column is needed.

• Upstream series use the kernel’s scheme only. That means [PATCH RFC], then [PATCH vN], with the per-version changelog below --- and git format-patch --base (submitting-patches.rst at the pin). A gbook version never appears in a patch subject.

• The pin moves onto a mainline release tag. The next re-pin is onto v7.4 (or the release current then), after M3 and before M5 in any case (ADR 0010). After that, the pin moves at most once per mainline release. Each re-pin re-checks every local patch (check 20) and the DTS, and the first base image on the new pin needs its own 3 clean cold boots before it can be released.

Consequences

• No tag exists on 2026-11-04. The image on the stick is a test image (gbook.suspend=1 no_console_suspend), and no base image with patches 0008 and 0009 has 3 clean cold boots yet.
• Every gbook commit changes the kernel release, so a rebuild relinks the version objects. The UTS #N keeps counting builds as before.
• The release grows by about 20 to 33 characters (worst case -gbook-2026.11.04.1-12-g1234567+), which stays under the 64-character cap.
• A tool to cut a release (check the tally, compose the tag message) is not needed until M3. It is left for then.
• Verified on 2026-11-04: build #25 (kernel Image 52734464 bytes) reads 7.3.0-gbook-g8493ab4+-ga804c5742bff-dirty in include/config/kernel.release, and scripts/image_uts.sh reads the same release from the Image banner. The + was an uncommitted log edit at build time.
• The v7.4 re-pin replaces patches 0002 to 0007. Their series has a v2 (2026-10-30) that drops 0003 and adds four patches, and torvalds master’s cf27afc3bd6e (“drm/msm: default separate_gpu_kms to auto selection”) conflicts with 0002, 0003 and 0005 to 0007 (patch-status lookup, 2026-11-04). The status lines of ADR 0007’s update record both.

Update 2026-11-04 (2:03 PM ET): a release names the rootfs too

Owner, M3 round (“yes” to question 10 of m3-rootfs.md). From M3 on, a release is two artifacts: the KERN-A image and the rootfs image (ADR 0012). The tag message adds the rootfs image’s sha256, its snapshot.debian.org timestamp and the hash of its lock list, next to the KERN-A image hash that scripts/attempt.sh stick prints.

Update 2026-11-04 (8:39 PM EST): the first release, v2026.11.04

Tagged by the owner from scripts/release-draft.sh M3 '^2026-11-04-2[123]$' at commit 506159b: kernel 7.3.0-gbook-g82c43ed-ga804c5742bff-dirty (patches 0001 to 0009), KERN-A image 9673d6d782ef4cdb, rootfs 4b0e2e027c0b2d74… from snapshot 20261104T000000Z (lock 12f96fa08768262e…, 321 packages), 3 clean cold boots. Two things the first real run taught the tool: the Attempts line must come from attempts.tsv (tally lists every id on one line), and git log -n 40 rather than | head, which ended the script by SIGPIPE under pipefail before the owner’s tag line. The tag also records the rootfs read back from the stick (attempt.sh root-verify, retro-9/01): release-draft.sh refuses a stick whose ROOT is not the manifest’s rootfs.

Update 2026-11-05 (9:54 AM EST): the second release, v2026.11.05

Tagged by the owner from scripts/release-draft.sh M3 '^2026-11-05-5$' at commit 69edd54: kernel 7.3.0-gbook-2026.11.04-35-g7c6a1aa-ga804c5742bff-dirty (patches 0001 to 0011; the two new ones, 0010 and 0011, keep the four speakers through the SoundWire masters’ runtime PM wakes), KERN-A image bc62c69ecf560525 (the sound node in the board DTS, no extras), a rootfs from the same snapshot and lock as v2026.11.04‘s (20261104T000000Z, lock 12f96fa08768262e…, 321 packages), rebuilt 2026-11-05 as 6fea12f2… (the audio group, the m3-swrm capture; the udev rule tried that night never shipped), 3 clean cold boots (attempt 2026-11-05-5), the four spoken channel names heard on each boot and the microphones’ capture heard played back. The AP console was absent for the three boots (the SuzyQ was unplugged on the build host’s side); the bar’s evidence is the netlog, which attempt.sh tally reads. The draft ran once before the final docs commit and again on it, so the tag file names the tagged commit: run it last.

12. M3 rootfs: Debian sid from a snapshot, on the stick’s partition 2, entered by switch_root

Status

Accepted 2026-11-04 (owner: “yes” to the ten open questions of m3-rootfs.md, section 5). Nothing in it has run on mica yet; section 4 of the note is inference until the first rootfs boot.

Context

• M3 (ADR 0010) needs a rootfs from USB with Mesa on the GPU and Wi-Fi in userspace, a known audio state, and the first release tag (ADR 0011).
• Mesa does not separate the candidates: X1-85 support landed in Mesa 24.2 (MR !30249, merged 2024-07-18), and every candidate ships 26.x. Ghostty 1.4 arm64 exists only in Omarchy’s aarch64 repo (research note, sections 1-2).
• The packaging already runs in a digest-pinned Debian sid container, and Debian can be pinned to one snapshot.debian.org timestamp. Omarchy aarch64 has no dated pin, and its install path is UEFI-only.
• Everything the kernel needs is built in, and uname -r changes with every gbook commit (ADR 0011).

Decision

1. Debian sid arm64, built by mmdebstrap in the pinned container from one snapshot.debian.org timestamp, with a lock list and a local .deb cache. Omarchy aarch64 (Arch Linux ARM base) is revisited at M4.
2. Ghostty 1.4.0 is built from its signed source tarball (Zig, as Omarchy’s PKGBUILD does). If that fails, M3 goes without Ghostty until M4.
3. ROOT is partition 2 of the same stick, from 256 MiB on. Every image’s GPT declares it, so the per-attempt 256 MiB dd, verify and gpt stay as they are. The owner writes ROOT only when the rootfs changes.
4. /init finds ROOT next to the booted kernel partition: the partition whose PARTUUID equals kern_guid, its disk’s partition 2, which must be labelled gbook-root. It mounts it, then switch_roots. No ROOT, or a failed mount, runs today’s capture-and-reboot path. The command line does not change.
5. The Wi-Fi network block and the stock ADSP/CDSP firmware stay in the initramfs. /init copies them to the new root’s /run/gbook/ before the hand-off. The rootfs image carries no secret, no vendor blob and no identifier (ADR 0005).
6. Every driver stays built in. New needs get kernel/*.config fragments. The rootfs ships no /lib/modules. kernel/mica-rootfs.config turns FW_LOADER_USER_HELPER off, as systemd’s README asks.
7. Audio gets one test attempt: the 9345’s sound node as a dts/diag/ overlay (unverified per ADR 0004), a kernel/mica-audio.config, and Debian’s 9345 topology and UCM. Either outcome is the “known state”.
8. No getty on the AP console, no sshd, nothing listening. The panel runs Ghostty under cage as an unprivileged user.
9. The container build tries mmdebstrap’s unshare or fakechroot mode first, and --cap-add SYS_ADMIN only if those fail.
10. A release names both images. See the ADR 0011 update of the same date.

Consequences

• The rootfs keeps the netlog format and listener: one shared sender script serves /init and the rootfs. A base rootfs sends after its checks and then stays up.
• The first rootfs boot must check two assumptions: that firmware lookups after switch_root resolve against the new root, and that the GPU’s first open there finds gen70500_*. If either fails, the stock files or the command line change, and this ADR gets an update.
• wpa_supplicant@wlan0 needs a drop-in to read /run/gbook/.
• The work is tracked in .scratch/m3-rootfs/.

Update 2026-11-04 (3:08 PM ET): how decision 9 came out

scripts/build-rootfs.sh runs the pinned container rootless with podman (retro-8/05), not through pkexec docker. Inside it, mmdebstrap’s own unshare mode does not apply: as container root it skips the user namespace, and container root cannot mount without SYS_ADMIN (probe, 2026-11-04). The script makes the same namespace by hand (unshare --map-root-user --map-auto --mount --pid --fork, a subuid range for root) and runs mmdebstrap’s root mode inside it; podman’s --security-opt unmask=ALL lets that namespace mount /proc (“Mount too revealing” otherwise). The arm64 essential set built this way in 32 s under qemu binfmt. fakechroot was not tried: mmdebstrap(1) says the mode fails with a different libc inside the chroot than outside, which a foreign-architecture chroot is. GBOOK_ROOTFS_MODE=sysadmin keeps the third option (--cap-add SYS_ADMIN, a capability inside podman’s user namespace only, never on the host).

Update 2026-11-04 (3:52 PM ET): the reproducibility contract, and throttling

From rootfs-pinning.md (recommendations 1, 4 and 7), after the first builds of ticket 03:

• Two builds of one snapshot timestamp must agree on lock.txt and the rootfs.tar sha256. The rootfs.ext4 sha256 is expected to agree only between builds with the same e2fsprogs version, which the manifest records: the container installs its tools from live sid at build time. The first two builds agreed on all three.
• The answer to snapshot.debian.org’s throttling is the .deb cache plus an offline flat repository (GBOOK_ROOTFS_OFFLINE=1, pinned to the previous lock.txt), not a mirror switch: Debian publishes no limit figures, snapshot-cloudflare.debian.org fronts the same backend (live headers, inference), and no third-party snapshot mirror resolved on 2026-11-04. A build on another mirror (GBOOK_ROOTFS_MIRROR) says snapshot=none in its manifest and is not release material (ADR 0011).

Update 2026-11-04 (6:38 PM ET): decisions 5 and 8 change, sshd for the build host

Owner (“yes” to the ranked options after the second ROOT boot; rootfs-access.md, recommendations 1 and 2). The rootfs runs sshd, key-only, for the build host alone (AllowUsers gbook@<the build host's LAN address>, PermitRootLogin no, no passwords), and gbook has sudo for the agent’s reads and unit restarts; writes on the device still need the owner’s word, as everywhere. The image stays free of keys: the host key and the build host’s authorized key travel in the initramfs (~/.local/state/gbook/ssh, packaged like the Wi-Fi block) and /init copies them to /run/gbook/; ssh.service has ConditionPathExists on the host key, Debian’s baked host keys are removed from the image, and sshd-keygen is masked (an empty machine-id is no first boot, so it would never run, and must not write keys to ROOT). The AP console stays read-only (ADR 0006); the gettys stay masked. The boot journal also travels as a section of the rootfs’s netlog, so a Wi-Fi failure still leaves the journal on the stick and a working boot sends it.

Research notes

Where the evidence comes from and how to read each source (blocked sites and their mirrors, the APIs that work): sources.md.

One file per topic, each claim with its source and the date it was read.

Done:

• chromeos-boot-path.md (2026-10-21): how Linux can boot through mica’s depthcharge, fastboot, CCD, recovery image

• stock-dtb.md (2026-10-21): the stock DT extracted from the recovery image, its hashes and board devices

• ccd-gsc.md (2026-10-21): SuzyQ on the left port, console map, GSC version and ccdstate, EC log

• 9345-dts-diff.md (2026-10-21): node-by-node against mainline 9345; AP console uart21; what to copy and what to replace

• el2-handoff.md (2026-10-21): depthcharge enters the kernel at EL2 with no Gunyah; build the mica DTB with x1-el2.dtso

• fit-packaging.md (2026-10-21): mkdepthcharge FIT + dev-key signing for mica, 256 MiB limit, cmdline, cgpt attributes, FIT matching, offline checks, tools on Arch

• console-kernel-config.md (2026-10-21): built-in drivers and boot arguments for a console-only first boot on uart21, earlycon limits, Image size, jhovold/jglathe/Ubuntu Concept configs

• silent-boot-observation.md (2026-10-21): if the AP console is silent: depthcharge ramoops and its readback, the coreboot framebuffer, EC console, firmware log, LED codes, ccdstate

• scmi-cpucp-timeouts.md (2026-11-03): intermittent SCMI timed out in resp and scmi-cpufreq -110 at boot; upstream fixes (all in the pin), the FastChannel quirk hazard on 0x0 firmware version, arm,max-rx-timeout-ms, measure-first plan

• milestones-versioning.md (2026-11-04): a milestone ladder M0-M7 over the gates, CalVer image tags, kernel [PATCH vN] rules and patch status words, when the upstream hold could end (AI agents may not add Signed-off-by); 9 open questions for the owner

• m3-rootfs.md (2026-11-04): which rootfs for M3 (Debian sid, Arch Linux ARM + Omarchy, Ubuntu, Fedora, postmarketOS: Mesa for the X1-85, Ghostty 1.4, our kernel, pinning) and how it boots: ROOT on the same stick, /init finds it by kern_guid, switch_root; 10 open questions for the owner

• debug-tools.md (2026-11-03): the per-boot debug tools: SCMI and I2C trace events, dyndbg, what each boot carries and how attempt.sh trace reads it

• rootfs-pinning.md (2026-11-04): pinning and reproducing the M3 rootfs when snapshot.debian.org throttles

• rootfs-access.md (2026-11-04): reaching the booted rootfs from the build host without a secret in the image (keys in the initramfs, journal upload, ssh)

• asoc-debug-tools.md (2026-11-04): ASoC, SoundWire and audioreach debugging tools; the downstream driver’s enumerator handling (ticket 16)

• scmi-cpucp-stall-report.md (2026-11-04): DRAFT report for linux-arm-msm on the PSCI-retention stall, not sent (M5 hold)

• steamos-arm.md (2026-11-05): what Valve published for the Steam Frame (no ARM SteamOS tree; package repos, repair image, the Deckard DTS, kernel commits through GitHub), five adoption candidates and the owner’s decisions

• m4-recovery-matrix.md (2026-11-05): Valve’s five recovery rows mapped onto mica’s vboot and recovery-stick mechanisms, each labelled proven or inference; the three owner probes that close M4’s return to stock; the slot-policy question

• public-writeup.md (2026-11-05): publishing gbook as a guide: the repo inventory and identifier exposure, Nura and aarch64-laptops conventions, Diátaxis, licences, venues with versions, a redaction gate; finds Anton Bambura’s public Nura port of mica (DTS 2026-10-19, same compatible)

• cloudflare.md (2026-11-05): which Cloudflare products fit the chosen GitHub Pages setup: a DNS-only CNAME and the challenge TXT now, Web Analytics by snippet, R2 or GitHub Releases for the artefacts at the first release that has them, token permission names; Pages, Workers, Turnstile, Tunnel and rate limiting skipped with reasons; 6 open questions for the owner

Reading upstream (learned 2026-11-03, scmi-cpucp-timeouts.md):

• lore.kernel.org, patchwork and git.kernel.org sit behind a bot check (Anubis). Read threads on lkml.rescloud.iu.edu or lists.infradead.org/pipermail, keep the lore Message-ID, and read torvalds master on the GitHub mirror.
• The owner’s web clippings in ~/code/obsidian/the build host/Clippings/ may already hold the thread (the X1E CPUFreq series was there).

Queued:

• fcc-p212g.md: FCC filings for regulatory model P212G (internal photos, chip markings, SSD placement)

Sources: where the evidence comes from, and how to read it

Compiled 2026-11-04, 1:59 PM ET from the research and recon notes, and from the 2026-11-04 session’s lookups. This is an index: each claim lives in the note that cites it (last column), and a new finding goes there, not here. Primary sources only. News coverage of the Googlebook exists in recon notes, but it is never the authority for a claim (CLAUDE.md, “Docs conventions”).

How to read them

By topic

Keeping it current

• A new research or recon note that relies on a new kind of source adds one row here, in the same commit.
• A source that becomes blocked, or a new way round, is recorded in “How to read them”, with the date.

How Linux can boot on mica’s depthcharge firmware

Researched 2026-10-21 from firmware source, Google’s docs and a live read of the device. Nothing was changed on the device.

Answer

The Googlebook boots through ChromeOS firmware: coreboot plus the depthcharge bootloader, with Android boot support added on top. Qualcomm ABL is not involved. That changes the plan:

1. “Unlock bootloader” is ChromeOS developer mode with new labels. Once unlocked, the firmware boots from external drives and accepts self-signed kernels by default. No crossystem step is needed.
2. The best first-boot route is a ChromeOS kernel partition on a USB drive. It holds a FIT image (kernel plus device trees), signed with the public developer keys. postmarketOS and depthcharge-tools already boot Qualcomm Chromebooks this way. The stock drive stays untouched.
3. Firmware fastboot has no boot command, so the planned fastboot boot RAM-boot test cannot work. Fastboot is also reachable only through a bridge cable (ALink or Prolific PL27A1) or over TCP via a USB-Ethernet adapter. That explains the “specialized cables” report.
4. Nobody has a device tree for mica. Mainline has hamoa/x1e80100 boards, including the XPS 13 9345, but no Chrome-firmware X1 board. Writing that device tree is the core work, as expected.
5. Closed Case Debugging exists. GSC consoles are readable while CCD stays locked, so a SuzyQ should give EC (and possibly AP) logs before anything is unlocked.

Items marked inference below are reasoned from source, not tested on the device.

Sources and revisions

Correction 2026-10-21: e62d095 is not v0.6.2. It is the main head, 107 commits after the tag (git ls-remote reads refs/tags/v0.6.2^{} = 95d17c444ae3a9dec1c51ead6301ed04777314b9). The citations below point at e62d095. Found by the FIT packaging research (docs/research/fit-packaging.md on branch research/fit-packaging).

Repos: https://chromium.googlesource.com/chromiumos/platform/depthcharge, …/platform/vboot_reference, …/third_party/coreboot, …/platform/ec, https://github.com/alpernebbi/depthcharge-tools, https://gitlab.postmarketos.org/postmarketOS/pmaports. These are branch heads read on 2026-10-21. The exact commits behind the device’s Google_Mica.16702.59.0/Google_Mica.16702.143.0 build are not public. Local copies are in .firecrawl/ (gitignored).

1. What mica is

config.mica also sets DRIVER_SOC_X1P42100=y. That is the name of the depthcharge SoC driver for the whole X1 family. coreboot builds mica as Hamoa, and the device reports X1E80100.

Internal disk, live read 2026-10-21 (recon): ChromeOS KERN-A, KERN-B and ROOT-B sit next to Android A/B partitions: boot, init_boot, vendor_boot, dtb, dtbo, vbmeta, pvmfw and super.

2. Unlock = developer mode

• The menu item. depthcharge src/vboot/ui/screens.c:765 (16702.B): the Advanced options item .name = "Unlock bootloader" targets UI_SCREEN_RECOVERY_TO_DEV (“Transition to developer mode”). Once unlocked, the screen reads “Bootloader is unlocked”. Its menu offers Lock bootloader, Boot from internal disk, Boot from external drive (:1801), Select alternate bootloader and Advanced options (which holds “Bootloader fastboot”).
• The OEM unlocking toggle. Android’s switch in Developer options maps to the NV bit VB2_NV_OEM_LOCK. While that bit is set, vboot withholds DEV_BOOT_ALLOWED (vboot firmware/2lib/2misc.c ~600-613). The firmware then shows “Booting with an unlocked bootloader is disabled… enable OEM unlocking in Developer options”. This matches Google’s steps: turn on OEM unlocking, then Esc + F2 + Power, then Advanced options > Unlock bootloader.
• Defaults are already set. vboot 2misc.c:296-303: while in normal mode, the firmware presets DEV_BOOT_EXTERNAL=1 and DEV_ENABLE_FASTBOOT=1, and clears DEV_BOOT_SIGNED_ONLY. That is the trogdor crossystem dev_boot_usb=1 dev_boot_signed_only=0 step, done ahead of time. This matters because Googlebook OS has no crossystem (live read: not on PATH).
• Self-signed kernels boot. vb2_need_kernel_verification is false in dev mode unless FWMP or dev_boot_signed_only says otherwise (2misc.c ~821-837). On the ChromeOS path, a keyblock whose signature fails is still accepted on its hash (2load_kernel.c ~163-253). The body must still match the keyblock’s own key, so the kernel must be self-signed, not unsigned. The public dev keys (/usr/share/vboot/devkeys) work.

3. Boot routes after unlocking

Route A: ChromeOS kernel partition with a FIT image (recommended)

vboot treats a GPT entry as bootable when its type is the ChromeOS kernel GUID fe3a2a5d-4f32-41a7-b725-accc3285a309 or the Android vbmeta GUID (cgptlib_internal.c, 2load_kernel.c:696-733). For ChromeOS entries, depthcharge loads the body to KERNEL_START and boots it as a FIT (src/arch/arm/fit.c:57-68).

FIT image rules (verified in source):

• Compression: none, lzma, lz4 or legacy-lz4 only (src/boot/fit.c:291-311). The arm64 Image magic is checked (boot64.c:188), so a gzip Image.gz fails.
• Device-tree choice: depthcharge ranks each FIT configuration’s compatible against google,mica-rev<board>-sku<sku>, then google,mica-rev<board>, google,mica-sku<sku> and google,mica (fit.c:49-102, name from coreboot’s MAINBOARD_PART_NUMBER “Mica”). With no match it boots /configurations/default. The ordering is documented in the kernel’s Documentation/arch/arm/google/chromebook-boot-flow.rst.
• What depthcharge writes into the DT:
  • /chosen: bootargs, kaslr-seed and rng-seed.
  • Memory: replaces every memory node with one /memory from coreboot’s map and adds /reserved-memory regions (dt_update.c).
  • Ramdisk: linux,initrd-start/end.
  • /firmware/coreboot (with board-id, sku-id, fw-config), /firmware/chromeos, ramoops, LPDDR info and the pKVM pvmfw and DRNG reservations.
  • bluey’s cpumap_fixup.c also marks defective CPU cores status = "fail" based on SoC ID.

Tooling: depthcharge-tools mkdepthcharge wraps mkimage and vbutil_kernel and signs with the dev keys. Its boards.ini has no mica entry; a custom section is needed (inference: values from config.mica):

[boards/custom/mica]
arch = arm64
codename = custom-mica
dt-compatible = google,mica(-rev\d+)?(-sku\d+)?
image-format = fit
image-start-address = 0xC7800000
image-max-size = 256 MiB

Correction 2026-10-21: this section is incomplete. [boards/arm64] in boards.ini at e62d095 (lines 3514-3521) sets boots-lz4-kernel, boots-lzma-kernel and loads-fit-ramdisk = True. Per the FIT packaging research, a custom board section does not pick these up, so without them depthchargectl build patches the initramfs into the DTB, pads the kernel and tries only an uncompressed kernel. Add these three lines to the section:

loads-fit-ramdisk = True
boots-lz4-kernel = True
boots-lzma-kernel = True

A plain dt-compatible = google,mica is enough: depthcharge-tools extends it to the -rev/-sku pattern itself.

Disk layout, per the pmbootstrap precedent (pmb/install/partition.py:105-203): a ChromeOS-kernel partition with cgpt add -t kernel -S 1 -T 5 -P 10, holding the signed image, plus a root partition. depthcharge-tools adds kern_guid=%U, which the firmware expands to the partition’s PARTUUID, so root=PARTUUID=%U/PARTNROFF=1 finds the next partition.

Route B: modified Android GKI boot image

vboot’s Android path (2load_android_kernel.c:320-468) verifies boot, init_boot, vendor_boot, pvmfw and dtbo with AVB. In dev mode, verification errors are allowed and the boot state turns orange. The DT comes from the dtbo partition’s table (android_dtboimg.c). The kernel command line comes only from vendor_boot. Inference: if no dtbo base entry matches, depthcharge falls back to a FIT inside the boot image. This route overwrites stock partitions, so it ranks below Route A.

Route C: alternate firmware payload (RW_LEGACY)

coreboot’s chromeos.fmd has an RW_LEGACY region outside write-protected RO. depthcharge runs payloads listed in altfw/list when DEV_BOOT_ALTFW is allowed (payload.c, screens.c:2041-2063). This is how a UEFI payload (EDK2 or U-Boot) could boot generic distro images. It needs flashrom with root to write RW_LEGACY, plus an arm64 Hamoa payload that nobody has built. This is a later option, not the first boot.

4. Firmware fastboot

• Commands (src/fastboot/cmd.c, 16702.B): continue, upload, download, erase, flash, getvar, oem cmdline|bootconfig add/del/set, oem logs, oem read/write-ufs-descriptor, oem set-successful, oem set-priority, oem sha256, reboot[-…], set_active and snapshot-update. main adds only fetch. There is no boot, no flashing unlock and no oem unlock.
• Transport (fastboot.c:241-261, usb.c:16-28): depthcharge is the USB host. It looks for a Prolific PL27A1 (067b:27a7) or a Google ALink cable or dongle (18d1:506d/506e/506f/5084), then falls back to TCP port 5554 over DHCP with ASIX, r8152 or smsc95xx USB-Ethernet adapters. bluey registers no USB device-mode controller, so a plain USB-C cable to a PC cannot reach it.
• Present in production? It is linked in only with CONFIG_FASTBOOT_IN_PROD, which the depthcharge ebuild sets when use avb. Inference (strong): mica needs AVB for Android boot, so fastboot is present. The board overlay is private.
• Use here: flash with no allow-list and oem set-priority/set-successful can install and select a kernel partition, given a USB-Ethernet adapter on a DHCP network. That makes it an optional install path, not a RAM boot. Android’s userspace fastbootd (reboot-fastboot) is separate.

5. Closed Case Debugging

Live read 2026-10-21 (gsctool -a -I runs as the adb shell user): CCD Locked, no password. The Always capabilities are:

• UartGscRxAPTx (read the AP console)
• UartGscRxECTx (read the EC console)
• UartGscRxFpmcuTx
• FlashRead
• UnlockNoReboot and UnlockNoShortPP

FlashAP, FlashEC, OverrideWP and OpenNoDevMode are IfOpened, and AllowUnverifiedRo is Never. GSC firmware: RO 2.0.119, RW 0.33.291.

From docs/case_closed_debugging_gsc.md (EC cr50_stab):

• Consoles: the doc says Ti50 enumerates as 18d1:504a. On mica it is 18d1:5066, and Linux exposes the consoles as ttys (ccd-gsc.md), so usb_console is not needed. usb_console -d 18d1:504a -i 1 gives the AP console and -i 2 the EC console.
• Opening CCD: needs developer mode, then gsctool -a -o and repeated power-button presses over about 5 minutes. Opening wipes dev mode.
• Flashing over CCD: flashrom -p raiden_debug_spi:target=AP works once CCD is open (FlashAP).
• Caveat: “the AP console itself is disabled for production devices”. So the AP UART may carry nothing, even though the capability allows it.

FlashRead is not a flash dump. The same doc’s capability table says it allows “dumping a hash of the AP or EC flash”. A full AP flash backup over raiden_debug_spi still needs CCD opened, and opening needs developer mode.

Inference: with the Fyra SuzyQ on the debug-accessory port, the EC console (and maybe firmware logs) can be read now, with no unlock. A flash hash could also be taken now, to compare against later.

6. Recovery image (Gate 1)

https://dl.google.com/device/recovery/mica-user/16471258/recovery.zip answered HEAD with 200, 7,601,764,157 bytes, Last-Modified 2026-10-05 15:44 GMT [11:44 EDT] (found via cros.tech/googlebook/mica, not downloaded). Saving it covers the log’s “save a copy of the recovery image” item, with one problem: its build number 16471258 is older than the installed build 16560795 (fingerprint …/CL3B.260622.276.R2/16560795). Anti-rollback may refuse it. Before relying on it for Gate 1, check the build inside the zip and whether the Device Recovery Utility serves a newer image than this static URL. It should also contain the stock dtb, dtbo and vendor_boot images, which means the vendor device tree and firmware without unlocking (inference: check the zip’s layout).

7. Proposed path

Status 2026-10-21: step 1 is done. The recovery zip is extracted (stock-dtb.md) and the EC and GSC consoles were read (ccd-gsc.md). The DTS for step 3 is drafted (dts/). Recorded as ADR 0003.

1. Before unlock: save the recovery zip (check the build-number question in section 6) and extract the stock DTB, dtbo and firmware. Read the EC console (and the AP console, if live) with the SuzyQ.
2. Unlock (owner, after Gate 1): OEM unlocking, Esc + F2 + Power, Unlock bootloader.
3. First boot (Route A):
   • Build a mainline kernel with a google,mica DTS: start from x1e80100-dell-xps13-9345.dts and use the stock DTB as the hardware map.
   • Package it with mkdepthcharge and dev keys onto a USB drive’s ChromeOS-kernel partition.
   • Choose Boot from external drive.
4. Console: CCD AP/EC UART if live. Otherwise ramoops (depthcharge always reserves it) read back on the next stock boot, or the panel through mdss once the DTS is good enough.

Not found

• Any mica or bluey device tree (mainline, chromeos-6.12, the 16702.B kernel branch, lore linux-arm-msm).
• Public board overlays for bluey or mica (to confirm use avb), and the exact firmware build commits.
• Which physical USB-C port is the debug-accessory port: the left one works (tested 2026-10-21); the right is untested.
• Any public report of Linux or another non-Android OS running on a Googlebook. AskUbuntu 1570130 (2026-10-07) is unanswered.
• Board-id and sku-id values (still unknown): /proc/device-tree reads are denied to adb shell. They are in /firmware/coreboot once booted, or in the stock DTB.

mica’s stock device tree

Extracted 2026-10-21 on the build host from Google’s public recovery image. The device was not touched. The DTBs themselves stay in dumps/ (gitignored, vendor content). This note keeps how to reproduce them, their hashes and what they show.

Source

Reproduce: scripts/extract-stock-dtb.sh dumps/recovery-16471258/recovery.zip. It needs unzip, sfdisk, lz4 and dtc, and uses scripts/dtbo_split.py.

Partition table (from the image’s GPT)

The image is a full internal-disk layout: 38 partitions, with A/B pairs for most Android partitions. _b twins are left out below; each has the same size and type as its _a partition. Only vbmeta_b carries attributes, GUID:48,49,50,51,56 (priority 15, successful). The live device boots slot _b (ro.boot.slot_suffix, recon). Read with sfdisk -d.

Points that matter for the boot path (chromeos-boot-path.md):

• boot_a/b use the ChromeOS-kernel type GUID (fe3a2a5d-…).
• vbmeta_a/b use the Android vbmeta GUID (88434509-…). vboot loads Android kernels through it.
• KERN-A (1 sector), KERN-B (a 4 MiB squashfs) and ROOT-B are typed as plain Linux data, so vboot does not treat them as kernels.

Where the DT lives

• dtb_a (2 MB) is all zeros.
• dtbo_a is an Android DT table (magic d7b7ab1e, version 1, 3 entries of 32 bytes). Each entry is an LZ4 frame (04 22 4d 18), not a raw DTB.
• That matches depthcharge’s Android path, which builds the DT from the dtbo table (boot path, route B).

dtbo_a.img sha256: a94f74e2b9360351a94618699f5e9362984f41a68ac37e16efb81e5cf01d06ba. The table fields probably encode board-id and SKU ranges for depthcharge’s matcher (android_dtboimg.c). The decoding is not checked yet.

What it shows

The base is a Qualcomm vendor tree, not mainline. It has 608 compatible properties (257 distinct). Some match mainline bindings: qcom,x1e80100-gcc, -dispcc, -adsp-pas, -cdsp-pas, -pcie, qcom,pmic-glink. Display is downstream (qcom,sde-kms, sde_* labels), and buses use downstream labels (qupv3_seN_i2c). Remoteproc firmware names are bare (adsp.mdt, cdsp.mdt), loaded from /vendor/firmware. So it is a hardware map (buses, addresses, GPIOs, regulators) for writing a mainline DTS, not something to boot as is.

Board devices in overlay 1 (bus label as in the stock tree):

The overlay also targets display (mdss_*, sde_edp, sde_dp, sde_dp1, eDP HPD on tlmm 119), the battery charger, the USB multiport PHYs, reserved memory (a splash region, and a pKVM protected region for the GIC ITS at 0x17040000), and it disables seven apps_rsc_drv2 children.

Against the XPS 13 9345 (first pass)

• The 9345 uses parade,ps8830 retimers too. Mica’s two retimers sit on different buses, and mica has no USB4/Thunderbolt in Dell’s spec (10 Gbps). Compare the 9345’s ps8830 nodes and its USB4 nodes.
• The 9345 has a Dell EC (dell-xps-ec work); mica replaces it with google,cros-ec-spi and google,cros-ec-keyb. Battery and charging go through pmic-glink on both.
• The 9345’s TPM is not a GSC; mica adds google,cr50 on I2C.
• Camera: the 9345’s camera is the SoC camera-subsystem work in Linaro’s tree (project log); mica’s is USB (MAINBOARD_HAS_CAMERA_VIA_USB, pp3300-ucam rail), so likely plain UVC.

Follow-up (2026-10-21): the node-by-node comparison is 9345-dts-diff.md, and the draft DTS built from it is in dts/.

Closed Case Debugging on mica with the SuzyQ

Tested 2026-10-21 on the build host with a Fyra Labs SuzyQ Board. CCD stayed Locked, nothing was opened or flashed, and the only commands sent to the GSC were version and ccdstate. Per-unit identifiers (the Ti50 USB serial number, chip ID and pcr0) are left out.

Hookup that works

• The SuzyQ’s USB-C plug goes into the Googlebook’s left USB-C port. The board’s own USB-C socket goes to the build host with a data cable. The board is only a pass-through; it needs both connections at once (Fyra docs: “The SuzyQ USB-C connector goes into the CCD port … You must provide a USB cable that can carry data”).
• It enumerated in the first orientation tried. The other orientation and the right port were not tested.
• the build host sees 18d1:5066 Google Inc. Ti50. Linux’s usb_serial_simple (“google converter”) creates the ttys. Note the ID: the GSC doc names 18d1:504a, but this Ti50 reports 5066.

Use /dev/serial/by-id/usb-Google_Inc._Ti50_*-if0N-port0 instead of the ttyUSBN numbers, which can change.

the build host access

The ttys are root:uucp 0660 by default. Since 2026-10-21, /etc/udev/rules.d/70-ti50-ccd.rules tags SUBSYSTEM=="tty" with ATTRS{idVendor}=="18d1" and ATTRS{idProduct}=="5066" as uaccess, so the active desktop session gets an ACL. It sorts before systemd’s 73-seat-late.rules, which applies the tag. Check with getfacl /dev/ttyUSB0. To undo, delete the file.

Reading safely

Turn off local echo first, or the tty line discipline echoes received bytes back into the console:

stty -F /dev/ttyUSB2 raw -echo -echoe -echok -echoctl -echoke
timeout 60 cat /dev/ttyUSB2          # EC: passive
printf 'ccdstate\r' > /dev/ttyUSB0   # GSC: one command, read the reply from a cat already running on ttyUSB0

What it showed

GSC version:

• RO: A 0.0.113, B 2.0.119 (active).
• RW: A 0.33.270, B 0.33.291 (active), ti50a_common_mp-16604.B:v0.0.151-54d5cc09, built 2026-06-11.
• This matches gsctool -a -f from adb (RO 2.0.119 / RW 0.33.291).

GSC ccdstate:

gsctool -a -I from adb shows CCD Locked with UartGscRxAPTx, UartGscRxECTx and UartGscRxFpmcuTx allowed Always. UartGscTxAPRx shows Y Always too, which explains UARTAP+TX.

EC console (Zephyr logging), charger test:

I: ADSP: Charging from USB0
I: ADSP: Charging from USB1

The EC reports charge-port changes coming from the SoC’s ADSP. That fits the stock DT’s pmic-glink and UCSI connectors: on Linux, battery and USB-C state go through the ADSP, as on other X1 laptops, and the EC is told.

What it means for bring-up

• A console for the first boot exists. The AP UART is bridged both ways while CCD is locked. A mainline kernel booted with console=ttyMSM0,115200 (or the right GENI UART) should print to ttyUSB1. Which GENI serial engine is wired to the GSC is still to be found in the stock DT (inference to test).
• The EC console shows charge and power events during experiments, with no unlock needed.
• Still locked: FlashAP, FlashEC, OverrideWP and GscFullConsole need CCD opened. Opening needs developer mode, gsctool -a -o and power-button presses (boot path, section 5).

Open

• The right port and the other plug orientation (does CCD work only on the left port, which matches coreboot’s single DAP_USE_SMB1?).
• Whether depthcharge prints to the AP UART during boot. A reboot while ttyUSB1 is being read would show it. That is a harmless test, but it reboots the owner’s device, so it needs the owner’s OK.

mica vs the mainline XPS 13 9345 device tree

Compared 2026-10-21. Both trees were read on the build host; the device was not touched.

• Mainline: arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts with hamoa.dtsi and hamoa-pmics.dtsi, torvalds/linux a804c5742bff224d4cb4d25dd383554d598be32b.
• Stock: the base DTB and board overlay from recovery build 16471258 (stock-dtb.md, overlay 1 sha256 ae86b730…).

Stock labels use Qualcomm’s vendor names (qupv3_seN_i2c). Each was matched to its mainline label by node address through the base DTB’s __symbols__ (for example qupv3_se0_i2c = i2c@b80000 = mainline &i2c0). GPIO numbers below are decimal; the stock overlay writes them in hex.

Answer

mica is a close derivative of the 9345 board. The USB-C retimer block (both PS8830s, all six power-rail GPIOs, both reset GPIOs), the touchscreen, the touchpad interrupt line, the PTN3222 reset, Wi-Fi enable, the NVMe and Wi-Fi PCIe controllers, the eDP controller and the debug UART all match the 9345 exactly. The changes cluster in a few places:

1. ChromeOS parts replace Dell parts: a cros-ec on SPI (keyboard, and probably lid and battery events), a Ti50 TPM on I2C, the AP firmware flash on QSPI, a USB fingerprint MCU.
2. Touchpad moved: it now sits on i2c0, where the 9345 has its I2C keyboard. The interrupt line is the same.
3. Backlight is PWM (PMK8550 PWM). The 9345’s panel node has no PWM.
4. eUSB2 repeaters: two PTN3222 on i2c5 (0x4f, 0x4b) where the 9345 has one on i2c9 (0x4f).
5. Audio: the WCD938x headset codec is disabled. Speakers use the WSA macros, plus 4 DMICs.

So the bring-up DTS should be #include the 9345’s board choices where they match, and replace the keyboard, EC, backlight and repeater sections. Inference: the 9345 DTS can be copied as the starting file, not merely used as reference.

AP console: uart21

Inference (strong): the GSC’s AP console (ttyUSB1 on the build host, ccd-gsc.md) is wired to uart21. A mainline kernel with &uart21 { status = "okay"; }, stdout-path = "serial0:115200n8" and console=ttyMSM0,115200 should print there. It is the first thing to check at first boot.

Node by node

Not compared yet: the camera (USB per coreboot, so probably UVC on usb_mp or usb_2), the ambient-light sensor, the Glowbar, the lid switch, and the two fans. None of them appear in the board overlay. Inference: they sit behind the EC or on USB.

Plan for dts/x1e80100-google-mica.dts

Status 2026-10-21: done as a draft (dts/x1e80100-google-mica.dts, ADR 0004). Two changes from this plan: the QSPI flash was left out because mainline hamoa has no QSPI node, and the touchpad reset is held by pinctrl because generic hid-over-i2c has no reset property. The dts/README.md table supersedes this list.

1. Copy x1e80100-dell-xps13-9345.dts at a804c57. Set compatible = "google,mica", "qcom,x1e80100" so depthcharge’s FIT match (google,mica…) selects it, and set the model.
2. Keep the matching blocks: uart21, uart14 with BT, pcie4 with Wi-Fi, pcie6a with NVMe, both retimers and their rails, the touchscreen, mdss_dp0/1/3, usb_1_ss0/ss1, smb2360_0/1, the remoteprocs.
3. Replace:
   • i2c0 keyboard → the touchpad (from i2c17);
   • drop the Dell EC;
   • add &spi13 { cros_ec: ec@0 { compatible = "google,cros-ec-spi"; … } } with cros-ec-keyb (keymap from overlays 1 and 2);
   • add &i2c10 tpm@50 google,cr50;
   • i2c9 PTN3222 → i2c5 at 0x4f and 0x4b, and enable usb_2;
   • backlight → pwm-backlight on the PMK8550 PWM.
4. Start minimal for the first boot: UART, NVMe or USB storage, simple-framebuffer if depthcharge leaves one (unknown), then add the rest.
5. Firmware names: the stock tree loads bare adsp.mdt and cdsp.mdt from /vendor/firmware. Mainline expects qcom/x1e80100/<vendor>/<board>/…; this needs a qcom/x1e80100/google/mica/ path and the blobs pulled from vendor in super.

Caveats

• The stock tree is a vendor tree. Only addresses, GPIOs, I2C addresses and regulators carry over. Property names (qcom,…) generally do not.
• parade,ps8830 appears in the stock DT while coreboot selects MAINBOARD_HAS_PS8820_RETIMER. The Linux driver binding may cover both. Check drivers/usb/typec/mux/ps883x.c before the first USB-C test.
• The 9345 mainline DTS was read at one commit. Recheck against the tag the kernel is built from.

Exception level at kernel entry on mica, and x1-el2.dtso

Researched 2026-10-21 from firmware and kernel source at pinned commits, the stock DT extracted from the recovery image, and the existing recon. The device was not touched. Resolves ticket 02.

Answer

1. mica’s firmware enters Linux at EL2. coreboot asks BL31 (TF-A) to start the payload at EL2. depthcharge (built on libpayload) runs at EL2 and jumps to the kernel with a plain branch, with no eret. The Android and the FIT routes both use that same jump. The bluey firmware has no Gunyah or other Qualcomm hypervisor: on the application cores it starts only BL31 (EL3), QTEE (secure EL1) and depthcharge. AOP, CPUCP, SHRM and ADSP-lite firmware go to other processors. On stock, EL2 belongs to the Android kernel’s pKVM (kvm-arm.mode=protected).
2. Apply x1-el2.dtso. Either build x1e80100-google-mica-el2.dtb from mica.dtb + x1-el2.dtbo (the way the Makefile does it for the 9345), or put the same changes in the mica DTS directly, as the sc7180/sc7280 Chromebook trees do. mica has no Gunyah variant, so the plain-EL1 DTB has nothing to boot on. The overlay applies cleanly to the current draft and passes dt-validate (section 5).
3. What breaks without it (inference from the overlay’s comments and the drivers):
   • First-boot risk: sbsa_watchdog stays enabled. Its comment says it “is implemented in software in Gunyah and can’t be used when running in EL2”. If CONFIG_ARM_SBSA_WATCHDOG probes a watchdog that does not exist, the result is unknown. Separately, apss_watchdog (the real hardware watchdog) stays reserved.
   • As soon as NVMe or Wi-Fi is on: pcie_smmu stays reserved and pcie4/pcie6a get no iommu-map. Under Gunyah, firmware programs that SMMU; at EL2 nobody does.
   • Phase 3: the GPU tries to load a zap shader through PAS, IRIS tries PAS boot (broken at EL2, per commit c0f045e), and the ADSP/CDSP lack the iommus that the PAS driver needs to map their firmware.
4. Applying it wrongly means applying it under a hypervisor that owns the PCIe SMMU and APSS watchdog. Linux would then fight that hypervisor for both. That cannot happen on this firmware.

1. Firmware chain: who runs at which EL

Sources: ChromiumOS coreboot firmware-bluey-16702.B at ff3258d575b0ddf4ba0514a2cd03c6a1936dba69 and depthcharge firmware-bluey-16702.B at 694eabf646855067acd51935059c3191436ccc79 (pinned in chromeos-boot-path.md). Read 2026-10-21.

No hypervisor image in the bluey build. src/soc/qualcomm/x1p42100/Makefile.mk:88-431 lists every Qualcomm blob put into CBFS: QcLib, DCB, pre-DDR DTB, CPR, QUP firmware, AOP, CPUCP, ADSP-lite, SHRM, the QTEE configs tzoem_cfg/tzqti_cfg, the access-control configs tzac_cfg/hypac_cfg, APDP and ramdump. TF-A (bl31) and QTEE (secure_os) come from the arch Kconfig. No hypervisor image (hyp.mbn, Gunyah, QHEE) is there. src/soc/qualcomm/x1p42100/soc.c:115-147 loads the four configs, then preloads bl31 and secure_os, and nothing else.

DRAM map agrees. src/soc/qualcomm/x1p42100/memlayout.ld:267-268 puts coreboot’s own post-RAM stack at 0x80000000. On Windows-firmware boards, mainline reserves that address as gunyah_hyp_mem (hamoa.dtsi:482-485 at a804c57). TZ is at 0xD8000000, with BL31 right after it (:293-294). Inference: the mainline gunyah_hyp_mem reservation wastes 8 MiB on mica and does no harm.

Stock agrees. Recon 2026-10-21 (recon-2026-10-21.md rows 19 and 21):

• the command line has kvm-arm.mode=protected and id_aa64mmfr1.vh=0, plus kvm-arm.protected_modules= with pkvm-smc-filter.ko and qcom_smmu_v2_v3_dispatcher.ko;
• ro.boot.hypervisor.protected_vm.supported=1.

Protected KVM installs its hypervisor at EL2 from the kernel, and the kernel can only do that if it was entered at EL2. depthcharge also loads pvmfw and adds its reserved-memory node for pKVM (src/arch/arm/fit.c:79-97, CONFIG_ANDROID_PVMFW=y in configs/config.mica). Inference: on stock, pKVM plus its Qualcomm SMMU and SMC modules fill the role that Gunyah fills on Windows laptops.

Linux allows either level: “The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order to have access to the virtualisation extensions), or in EL1.” (Documentation/arch/arm64/booting.rst:174-175 at a804c57)

2. What x1-el2.dtso changes, and why

File: arch/arm64/boot/dts/qcom/x1-el2.dtso at torvalds/linux a804c5742bff. History read through the GitHub commits API for that path on 2026-10-21 (four commits):

The whole overlay (x1-el2.dtso:10-69):

• apss_watchdog okay;
• gpu_zap_shader disabled (“linux can zap the gpu on it’s own”);
• iris disabled;
• pcie3, pcie4, pcie5, pcie6a get iommu-map onto pcie_smmu (stream bases 0x30000, 0x40000, 0x50000, 0x60000);
• pcie3 and pcie5 also get msi-map onto gic_its (“ITS emulation in Gunyah is broken”);
• pcie_smmu okay;
• the remoteproc iommus above;
• sbsa_watchdog disabled.

The mainline defaults it overrides are in hamoa.dtsi (a804c57):

• pcie_smmu is status = "reserved"; /* Controlled by Gunyah. */ (:8520-8532);
• apss_watchdog is "reserved"; /* Reserved by Gunyah */ (:8560-8566);
• sbsa_watchdog has no status, so it is enabled (:8777-8782);
• pcie4 and pcie6a already have msi-map (:3721, :3441), so mica’s two PCIe controllers have MSIs either way.

The Makefile builds x1e80100-dell-xps13-9345-el2.dtb := x1e80100-dell-xps13-9345.dtb x1-el2.dtbo (:440-441). That is the board mica’s DTS is drafted from (ADR 0004).

3. Chromebook precedent: Qualcomm Chrome trees carry the same changes

Older Qualcomm Chromebooks boot the same way: coreboot, TF-A and depthcharge, with no QHEE. Their mainline trees already contain what the WoA EL2 overlays add:

• sc7180-el2.dtso:15: “Venus can be used in EL2 if booted similarly to ChromeOS devices”. Commit 0d95f64be417 (2025-05-03): WoA sc7180 “includes QHEE hypervisor”, hence EL1.
• sc7180-trogdor.dtsi:44 /delete-node/ &gpu_zap_shader; and :45 /delete-node/ &hyp_mem;; :1005-1008 adds video-firmware { iommus = … } to Venus. That is the same zap and video change sc7180-el2.dtso makes.
• sc7280-chrome-common.dtsi:3-9 (“memory protections put into place by the Chrome bootloader … different than … Qualcomm’s typical bootloader”) deletes gpu_zap_shader and hyp_mem (:23-24) and sets &watchdog { status = "okay"; } (:143-145). In the base tree that watchdog is status = "reserved"; /* Owned by Gunyah hyp */ (kodiak.dtsi:6918-6923).

Inference: mica’s bluey firmware is the same design one generation later, so it needs the same DT treatment. For X1 that treatment is already packaged as x1-el2.dtso.

4. Against the stock mica tree

Derived facts from the recovery-image base DTB (dumps/recovery-16471258/dtbo/entry00-base.dts, gitignored; reproduce with scripts/extract-stock-dtb.sh, see stock-dtb.md). Line numbers refer to that decompiled file.

Counter-signals, and why the overlay is still right:

• hypac_cfg. coreboot loads a “hyp access-control” config (hyp_ac_config.elf, Makefile.mk:371-376, soc.c:135-138). Which component reads it is not public. Nothing besides BL33 is ever entered at EL2 (section 1), so it does not mean there is a hypervisor. Inference: QTEE or TF-A applies it as a policy.
• Stock enables the SBSA watchdog. That cuts against the overlay’s comment that Gunyah emulates it. The stock tree is a Qualcomm vendor base, and enabling a node does not show anything exists at 0x1c840000. Disabling it is safe either way. Leaving it enabled is the only one of the two choices that can go wrong at first boot.
• Stock keeps a zap-shader node. ChromeOS precedent goes the other way (section 3: trogdor and chrome-common delete it). Inference: the stock node serves Android’s pKVM and vendor-driver path, not mainline’s. adreno_gpu.c:49-52 at a804c57 treats a missing or disabled zap-shader as “zap not available” (-ENODEV). It then takes the zap-less path. The overlay’s own comment says that path works at EL2: “linux can zap the gpu on it’s own” (x1-el2.dtso:14).

5. Check: the overlay applied to the draft DTS

Run 2026-10-21 on the build host in a scratch directory (nothing committed):

1. scripts/build-dtb.sh compiles with dtc -@ (line 17), so the base keeps __symbols__.
2. dtc -@ -I dts -O dtb x1-el2.dtso and fdtoverlay -i mica.dtb -o mica-el2.dtb x1-el2.dtbo applied with no errors.
3. dt-validate -s schema-a804c57.json mica-el2.dtb reported only the known pending google,mica root-compatible finding, the one scripts/check.sh already allows.
4. fdtget before → after:
   • iommu@15400000: reserved → okay;
   • watchdog@17410000: reserved → okay;
   • watchdog@1c840000: (enabled) → disabled;
   • video-codec@aa00000: okay → disabled;
   • pcie@1c08000 iommu-map = 0 <pcie_smmu> 0x40000 0x10000;
   • pcie@1bf8000 = … 0x60000 0x10000.

The draft dts/x1e80100-google-mica.dts sets &gpu_zap_shader { firmware-name } (:748-750) and &iris { status = "okay" } (:959-962), following the 9345. The overlay disables both, which is intended at EL2.

Packaging note for the FIT ticket: depthcharge can apply overlays itself. A FIT configuration’s fdt property may list a base followed by overlays (src/boot/fit.c:115-134, :177-178), applied with dt_apply_overlay() (:464-479). The configuration also needs a compatible (:261-263). Applying it at build time is simpler and matches the kernel Makefile.

Watchdog left armed by firmware? coreboot’s common Qualcomm watchdog.c (src/soc/qualcomm/common/watchdog.c:10-16, linked in romstage at x1p42100/Makefile.mk:34) only reads the AOSS reset status to record a tombstone. It does not arm a watchdog. Inference: a kernel without apss_watchdog will not be reset by a firmware-armed watchdog. The depthcharge watchdog code was not read (only part of depthcharge is cached).

Not found

• TF-A’s Qualcomm platform code that reads bl33_ep_info.spsr. coreboot uses a prebuilt BL31 plus libqtisec.a (Makefile.mk:99-104). That BL31 honours the requested EL2 is inferred from the stock pKVM evidence; its source was not read.
• Who reads hypac_cfg, and what policy it applies.
• What is at 0x1c840000 on mica, and whether the SBSA watchdog exists there without Gunyah.
• Whether mica’s QTEE supports the PAS resource-table SCM call. With iommus present, qcom_q6v5_pas.c takes that path (:862 has_iommu, :475-500 qcom_pas_get_rsc_table(), :927 use_tzmem). It decides whether ADSP/CDSP boot at EL2 (Phase 3).
• The state firmware leaves the PCIe SMMU in (enabled, bypass or abort) when Linux leaves it alone, which decides how NVMe fails without the overlay.
• Anything on exception levels in chromebook-boot-flow.rst. At a804c57 (Documentation/arch/arm/google/chromebook-boot-flow.rst) it covers FIT compatible matching only.
• A boot log showing CPU: All CPU(s) started at EL2. It would confirm this answer, and the first boot (or ramoops) will show it.
• The full depthcharge tree at 694eabf: only the files under .firecrawl/src-depthcharge-… were read.

Packaging and signing a mica FIT, and checking it offline

Researched 2026-10-21 on the build host from upstream source at pinned commits, distro package metadata and a read of the stock dtbo table in dumps/ (read only). The Googlebook was not touched. Nothing was installed. Items marked inference are reasoned from source, not tested.

Ticket: 03-fit-packaging. Decision context: ADR 0003, chromeos-boot-path.md.

Answer

A mica kernel partition is a vboot kernel blob (64 KiB vblock + body) whose body is a FIT with one kernel, one DTB and one ramdisk. mkdepthcharge builds it in one command. Everything except the actual boot can be checked on the build host.

Step list

1. Tools. Run the toolchain in a Debian sid container (all four packages are official there), or install extra/uboot-tools plus AUR vboot-utils and run depthcharge-tools from a git checkout (see 8). Docker is active on the build host, but the owner is not in the docker group (live read 2026-10-21), so the container runs through pkexec:

   pkexec docker run --rm -it -v /home/the owner/.cache/gbook/out:/out debian:sid bash
   # inside:
   apt-get update && apt-get install -y depthcharge-tools vboot-kernel-utils vboot-utils cgpt u-boot-tools device-tree-compiler
   sha256sum /usr/share/vboot/devkeys/{kernel.keyblock,kernel_data_key.vbprivk,kernel_subkey.vbpubk}
   

   The three hashes must equal the pinned tests/devkeys values in 4.

2. Inputs.

   • Image: the plain arm64 Image, not Image.gz. depthcharge checks the arm64 magic 0x644d5241 after its own decompression step and knows only none/lz4/lzma.
   • mica.dtb: from scripts/build-dtb.sh. Its root compatible must contain the exact string google,mica. The current draft does: google,mica qcom,x1e80100 (live read of the built DTB, 2026-10-21).
   • initramfs.cpio.gz: any cpio the kernel can unpack. Gzip inside the cpio is fine. FIT-level ramdisk compression must be none, and mkimage writes none.

3. Build and sign (keys default to /usr/share/vboot/devkeys):

   mkdepthcharge -o /out/mica.kpart --tmpdir /out/mkdc-tmp -v \
     -A arm64 --format fit -C none \
     -c "console=ttyMSM0,115200n8 earlycon=qcom_geni,0x894000 ignore_loglevel" \
     -d /out/Image -i /out/initramfs.cpio.gz -b /out/mica.dtb
   

   • mkdepthcharge prepends kern_guid=%U, so the stored cmdline is kern_guid=%U console=ttyMSM0,115200n8 earlycon=qcom_geni,0x894000 ignore_loglevel.
   • At boot depthcharge replaces %U with the kernel partition’s PARTUUID (lowercase) and appends cros_secure. It also appends cpufreq.default_governor=powersave, but only when booting with no battery.
   • It runs mkimage -f auto -A arm64 -T kernel -O linux -C none -n … -i initramfs -b mica.dtb -d Image, then fdtput … type kernel_noload, then vbutil_kernel --version 1 --arch aarch64 --vmlinuz depthcharge.fit --config kernel.args --bootloader empty.bin --keyblock … --signprivate … --pack, then vbutil_kernel --verify.
   • --tmpdir keeps depthcharge.fit for the checks below.
   • Leave out root= for the first boot. The initramfs is the whole userspace.
   • --kernel-start is not needed. On arm64 it only feeds the 32-bit initramfs hacks, which stay off.

4. Offline checks (all on the build host, no device):

   fdtget mica.dtb / compatible                      # contains google,mica
   dumpimage -l mkdc-tmp/depthcharge.fit             # kernel-1, fdt-1, ramdisk-1, conf-1
   fdtget mkdc-tmp/depthcharge.fit /configurations default        # conf-1 (one DTB keeps the default)
   fdtget mkdc-tmp/depthcharge.fit /images/fdt-1 compression      # none
   fdtget mkdc-tmp/depthcharge.fit /images/kernel-1 compression   # none | lz4 | lzma
   fdtget mkdc-tmp/depthcharge.fit /images/kernel-1 data-size     # must FAIL: data is embedded, not external
   vbutil_kernel --verify mica.kpart --signpubkey /usr/share/vboot/devkeys/kernel_subkey.vbpubk --verbose
   vbutil_kernel --verify mica.kpart                 # hash-only path, same as dev-mode firmware
   futility show mica.kpart
   stat -c %s mica.kpart                             # body must be <= 0x10000000 (256 MiB)
   

   Expected --verify output: keyblock flags 23 (0x17), “Body verification succeeded”, and a Config that echoes the cmdline with a literal %U.

5. Disk (build as a file on the build host, then copy it to the USB drive as an owner step):

   truncate -s 2G mica-usb.img
   cgpt create mica-usb.img
   cgpt boot -p mica-usb.img                         # protective MBR, for Linux later
   cgpt add -i 1 -t kernel -b 8192 -s 262144 -l KERN-A -S 0 -T 3 -P 15 mica-usb.img   # 128 MiB
   cgpt add -i 2 -t data -b 270336 -s 3923935 -l ROOT mica-usb.img   # optional rootfs for later; fits the 2 GiB file
   dd if=mica.kpart of=mica-usb.img bs=512 seek=8192 conv=notrunc
   cgpt show mica-usb.img
   cgpt show -i 1 -P mica-usb.img; cgpt show -i 1 -T mica-usb.img; cgpt show -i 1 -S mica-usb.img
   

   • -t kernel gives type fe3a2a5d-4f32-41a7-b725-accc3285a309.
   • -S 0 -T 3 -P 15 means “try three times, then fall back”. vboot spends a try on each attempt while successful is 0.
   • pmbootstrap’s -S 1 -T 5 -P 10 is for an installed system. With successful=1 the tries count is ignored, so a kernel that panics is picked again on every boot.
   • Sizes are in device blocks. The numbers above assume 512-byte sectors.

6. FIT matching is not a blocker. depthcharge prefers google,mica-rev<R>-sku<S>, then google,mica-rev<R>, google,mica-sku<S> and google,mica. A DTB whose root compatible holds google,mica matches whatever board-id and sku-id the EC reports. With one DTB, mkdepthcharge also keeps default = "conf-1", which boots even with no match. That is a safety net, and a trap: a wrong DTB still boots.

What cannot be checked offline:

• depthcharge’s own config choice. There is no upstream unit test for fit.c at 694eabf; the logic is small enough to check by reading.
• The real board-id and sku-id.
• Whether depthcharge’s DT fixups (dt_apply_fixups) succeed on a mainline-shaped DT.
• Whether earlycon prints anything.

On the AP console, depthcharge prints Compat preference: … and Choosing best match … (fit.c:384-387, 439-440), which reveals board-id and sku-id on the first boot.

Follow-ups for other files (not edited here):

• chromeos-boot-path.md labels e62d095 as depthcharge-tools v0.6.2. It is v0.6.2-107-ge62d095 (2026-10-19); the tag is 95d17c4 (2023-06-30).
• Its draft [boards/custom/mica] section lacks loads-fit-ramdisk, boots-lz4-kernel and boots-lzma-kernel. See 1.
• The draft DTS has no /chosen/stdout-path (fdtget → FDT_ERR_NOTFOUND, 2026-10-21), so a bare earlycon would do nothing. Hence the explicit earlycon=qcom_geni,0x894000 above.

Update 2026-10-21: all three follow-ups are applied on main in commit 709212e: dated corrections in chromeos-boot-path.md, and /chosen/stdout-path in the DTS.

Sources and revisions

All read 2026-10-21. Paths below are relative to each repo. Line numbers refer to these commits.

1. mkdepthcharge for a custom board

mkdepthcharge is board-agnostic. It takes the arch, format, compression, cmdline, keys and files (depthcharge_tools/mkdepthcharge.py:597-978). For fit it runs:

• mkimage -f auto -A <arch> -T kernel -O linux -C <compress> -n <name> [-i initramfs] -b <dtb>… -d <vmlinuz> (:1190-1202);
• fdtput <fit> <kernel node> type kernel_noload (:1214-1219);
• fdtput -d /configurations default, only when there is more than one DTB (:1221-1227);
• vbutil_kernel --version <n> --arch <vboot arch> --vmlinuz <fit> --config <cmdline file> --bootloader <512-byte empty file> --keyblock … --signprivate … --pack <out> (:1240-1250), then vbutil_kernel --verify (:1401-1410).

For arm64 the vboot arch string is aarch64 (utils/platform.py:536-545), which futility maps to ARCH_ARM (vboot futility/cmd_vbutil_kernel.c:290-291). --kernel-start is used only by the --patch-dtbs and --pad-vmlinuz hacks (mkdepthcharge.py:1059-1188). The manual says arm64 depthcharge decompresses the kernel to a safe place itself, so the hacks are for 32-bit boards (mkdepthcharge.rst:151-169).

The board section only matters for depthchargectl build/check. boards.ini tells users to add “fully specified sections with a unique codename” (depthcharge_tools/boards.ini:7-29). Sections inherit only from their /-separated parents (utils/collections.py:11-42). So [boards/custom/mica] inherits nothing from [boards/arm64] (boards.ini:3514-3521, which sets boots-lz4-kernel, boots-lzma-kernel and loads-fit-ramdisk).

Those keys default to False (depthchargectl/__init__.py:123-137). With loads-fit-ramdisk False, depthchargectl build turns on patch_dtbs (_build.py:549). That adds /chosen/linux,initrd-* to the DTB and pads the kernel. Without the two boots-* keys, only none compression is tried (_build.py:434-442).

A complete section:

[depthchargectl]
board = custom-mica

[boards/custom/mica]
arch = arm64
codename = custom-mica
name = Dell XPS Googlebook (mica, custom)
dt-compatible = google,mica
image-format = fit
image-max-size = 256 MiB
image-start-address = 0xC7800000
loads-fit-ramdisk = True
boots-lz4-kernel = True
boots-lzma-kernel = True

• A plain dt-compatible = google,mica is extended to google,mica(-rev\d+)?(-sku\d+)? automatically (utils/string.py:112-131). It is used only to pick DTBs from an fdtdir (_build.py:238-292).
• image-start-address is informational on arm64 (see above).
• image-max-size makes depthchargectl build reject a too-large image (_build.py:589).

Version differences. e62d095 is 107 commits past the v0.6.2 tag. For a one-DTB FIT build, the relevant code is the same in both, apart from the new default removal for multi-DTB FITs (git diff v0.6.2 e62d095 -- depthcharge_tools/mkdepthcharge.py).

Precedent.

• pmaports trogdor: deviceinfo_depthcharge_board="qc7180", deviceinfo_depthcharge_compression="lzma", a 128 MiB kpart at sector 8192 (device/community/device-google-trogdor/deviceinfo:21-34).
• boot-deploy runs depthchargectl build --root none --board … --kernel … --kernel-cmdline … --initramfs … --fdtdir … --compress … --output … (boot-deploy-functions.sh:1078-1108).

2. Compression and the 256 MiB limit

Allowed formats.

• depthcharge reads a FIT image node’s compression as none, lzma or lz4. Anything else is invalid (src/boot/fit.c:140-165), and decompression supports exactly those (:291-311).
• mkdepthcharge offers none, lz4 and lzma and passes -C none explicitly, because mkimage otherwise assumes gzip (mkdepthcharge.py:685-699, 993-1003).
• The FDT image node must be none when the config has no compatible (fit.c:254-259), and mkimage writes none for every -b file (U-Boot tools/fit_image.c:392-393).
• The FIT ramdisk must be none (fit.c:484-488); a ramdisk node with no compression property counts as none (fit.c:143).

Embedded data only. depthcharge reads only the data property (fit.c:149-151). A FIT built with external data (mkimage -E) would load empty images. mkimage -f auto embeds the data (fit_image.c:368).

Kernel placement.

• depthcharge partly decompresses the kernel to read the arm64 header, checks magic 0x644d5241 (boot64.c:44, 178-192) and takes image_size from it (:194-197).
• It picks a KASLR slot outside [min(BASE_ADDRESS, KERNEL_START, FIT_FDT_ADDR), 4 GiB) (boot64.c:129-133) and decompresses or copies the kernel there (:199-210).
• So the decompressed kernel never has to fit the 256 MiB buffer. Only the packed body does.

The 256 MiB limit.

• config.mica sets CONFIG_KERNEL_START=0xC7800000 and CONFIG_KERNEL_SIZE=0x10000000.
• The linker script turns those into _kernel_start/_kernel_end (src/image/depthcharge.ldscript.S:38-39), and vboot gets kernel_buffer_size = _kernel_end - _kernel_start (src/vboot/stages.c:162-163).
• vboot rejects a body larger than the buffer (“Kernel body doesn’t fit in memory”, vboot firmware/2lib/2load_kernel.c:389-392). It requires the body to start within the first 64 KiB of the partition (:378-382; futility’s default --pad is 65536, cmd_vbutil_kernel.c:33).
• The body is roundup(FIT, 4K) + 4 KiB cmdline + 4 KiB params + roundup(bootloader, 4K) (futility/vb1_helper.c:668-685, sizes in futility/kernel_blob.h:15-21). So the FIT may be up to about 256 MiB − 12 KiB.
• The partition must hold 64 KiB + body.

The DT limit. The flattened DT after depthcharge’s edits must fit the 8 MiB FDT buffer at 0xDA800000 (depthcharge.ldscript.S:40-41, src/arch/arm/fit.c:105-111). The draft DTB is 215,695 bytes.

Ramdisk placement. The ramdisk stays inside the FIT in the kernel buffer, below 4 GiB, as fit_add_ramdisk assumes (fit.c:335-348).

Choice.

• Inference: use -C none for the first boot. It has the fewest moving parts, and an arm64 Image plus a small initramfs is far below 256 MiB.
• lz4 is the fallback if USB read time or partition size matters. lzma is the slowest to decompress in firmware.
• depthchargectl itself tries none, then lz4, then lzma, and keeps the first that fits (_build.py:434-442, 562-597).

3. Kernel command line

• Storage. mkdepthcharge writes the cmdline to a file for vbutil_kernel --config. An empty cmdline becomes --, because vbutil_kernel rejects an empty one (mkdepthcharge.py:876-881). The config slot is 4096 bytes including the NUL (kernel_blob.h:15, vb1_helper.c:73-75).
• kern_guid=%U. mkdepthcharge prepends it unless --no-kern-guid is given (mkdepthcharge.py:885-905, mkdepthcharge.rst:236-249).
• %U expansion.
  • vboot copies the chosen entry’s unique GUID into params->partition_guid (2load_kernel.c:761-762).
  • depthcharge passes it to commandline_subst (src/vboot/stages.c:307-312), which replaces each %U with the GUID in lowercase (src/boot/commandline.c:79-85).
  • It then appends every queued parameter with a leading space (:94-98):
    • cros_secure on the ChromeOS path (src/vboot/boot_info.c:56);
    • cpufreq.default_governor=powersave only when board_boot_in_no_battery_mode() (src/board/bluey/board.c:161-163).
  • The result goes into /chosen/bootargs (src/boot/dt_update.c:38). The working buffer is 2 × 4096 bytes (stages.c:293, src/vboot/boot_info.h:43).
• root=PARTUUID=%U/PARTNROFF=1. The kernel resolves this form itself (block/early-lookup.c:41-61, 226-246 at a804c57). It matters only when the kernel mounts root, that is with no initramfs /init.
  • Inference: an initramfs’s own init would have to parse PARTNROFF itself.
  • For the first boot, leave root= out. Keep kern_guid=%U: pmOS’s boot-deploy uses it to find the partition to write the next image to (boot-deploy-functions.sh:1121-1144).
• Console.
  • uart21 is serial@894000 (arch/arm64/boot/dts/qcom/hamoa.dtsi:1296-1298 at a804c57). The draft DTS sets compatible = "qcom,geni-debug-uart" on it and serial0 = &uart21.
  • The GENI driver registers earlycon qcom_geni for that compatible and names its ttys ttyMSM (drivers/tty/serial/qcom_geni_serial.c:1755, 1769, 1785).
  • earlycon=qcom_geni,<addr> “must already be setup and configured” (Documentation/admin-guide/ kernel-parameters.txt:1515-1519). Bare earlycon uses /chosen/stdout-path (:1398-1403), which the draft DTS lacks.
  • So: console=ttyMSM0,115200n8 earlycon=qcom_geni,0x894000.
  • Inference: if the firmware leaves uart21’s clocks off, earlycon stays silent while ttyMSM0 still works once the driver probes. The kernel needs CONFIG_SERIAL_QCOM_GENI_CONSOLE=y.

4. Dev keys

• What vboot checks in developer mode.

  • need_keyblock_valid is false (2load_kernel.c:143; chromeos-boot-path.md section 2).
  • When the keyblock signature fails against mica’s kernel subkey, vboot accepts the keyblock on its SHA-512 hash (:164-181).
  • Keyblock flag mismatches only clear keyblock_valid (:184-211).
  • The body must still verify against the keyblock’s own data key (:433-438).
  • So any self-consistent key pair boots. The public dev keys are the convention.

• Where they come from. vboot_reference ships them in tests/devkeys/. make install copies them to /usr/share/vboot/devkeys (Makefile:30, 448-453). At 34fbbe6, sha256:

  File	sha256
  kernel.keyblock	ca2feab9d94eae768fea8616e52cda6cb5576b3d45cd8f7f8af0ce14cb9ce252
  kernel_data_key.vbprivk	bc9e707a86e55a93f423e7bcdae4a25fd470b868e53829b91bbe2ccfbc6da27b
  kernel_subkey.vbpubk	36b9c5fa6f5d0432b9acbe8e2b7da2e602162a87a425575c6d7ba975a0440708

  • kernel.keyblock decodes to header 2.1, size 1208 bytes and flags 0x17 = DEVELOPER_0 | DEVELOPER_1 | RECOVERY_0 | MINIOS_0 (offsets from firmware/2lib/include/2struct.h:371-418, read on the build host 2026-10-21). That matches KERNEL_KEYBLOCK_MODE (scripts/keygeneration/common.sh:87) and passes in dev mode without recovery and without miniOS.
  • key.versions says kernel key version 1 and kernel version 1. mkdepthcharge’s default --tpm-kernel-version is 1 (mkdepthcharge.py:966-978). Rollback checks do not apply when need_keyblock_valid is false (2load_kernel.c:313-323).

• On the build host. mkdepthcharge searches, in order:

  • --keydir, or the directories of any given key;
  • /etc/depthcharge-tools;
  • /usr/share/vboot/devkeys;
  • /usr/local/share/vboot/devkeys (utils/platform.py:166-198, mkdepthcharge.rst:257-268).

  Sources:

  • AUR vboot-utils copies tests/devkeys to /usr/share/vboot/devkeys (its PKGBUILD package()).
  • Debian’s vboot-kernel-utils ships the same file names there (packages.debian.org sid file list, read 2026-10-21).
  • With no install at all, --keydir <vboot_reference checkout>/tests/devkeys works.

  Check any copy against the table above.

5. Partition type and attributes

• Type. vboot boots GPT entries whose type is the ChromeOS kernel GUID fe3a2a5d-4f32-41a7-b725-accc3285a309 or the Android vbmeta GUID (firmware/include/gpt.h:46-47, firmware/lib/cgptlib/cgptlib_internal.c:157-170). cgpt’s alias for the first is kernel (cgpt/cgpt_common.c:653); data is Linux data (:656).
• Attribute bits. Priority sits in bits 48-51, tries in 52-55 and successful in 56 (cgptlib_internal.h:40-53). cgpt add -S/-T/-P set them (cgpt/cmd_add.c:16-33). cgpt show -i N -S|-T|-P|-A reads them back (cgpt/cmd_show.c:19-41).
• Selection.
  • GptNextKernelEntry skips entries with neither successful nor tries, and picks the highest priority > 0 (firmware/lib/cgptlib/cgptlib.c:44-120).
  • A booted entry with successful=0 gets a try deducted (2load_kernel.c:768-779). With successful=1, tries are ignored (cgptlib.c:135-144).
  • A failing entry is marked bad and the next one is tried (2load_kernel.c:742-743).
• Precedent. pmbootstrap uses cgpt add -i <kernel> -t kernel -b <start> -s <size> -l pmOS_kernel -S 1 -T 5 -P 10, then an efi boot partition and a data root (pmb/install/partition.py:107-204). It writes the image with dd (pmb/install/_install.py:651-663).
• First-boot recommendation. Use -S 0 -T 3 -P 15 instead (inference from the selection code). That matches ADR 0003’s “a bad image falls back”. depthchargectl’s bless --oneshot sets successful=0, tries=1 and the highest priority (depthchargectl.rst:247-252).
• Stock disk, for contrast (stock-dtb.md). The stock boot_a has the ChromeOS-kernel type but holds a plain Android boot image (magic ANDROID! at offset 0, read 2026-10-21) and has priority 0. So vboot’s ChromeOS path never picks it, and the Android path goes through vbmeta.

6. FIT configuration matching, and what the stock dtbo table says

The match list.

• depthcharge builds the compatibles from coreboot’s mainboard part string, lowercased with _ → - (src/boot/fit.c:49-102). For mica that string is "Mica" (coreboot src/mainboard/google/bluey/Kconfig:317-325 at ff3258d).
• The list is google,mica-rev<board_id>-sku<sku_id>, google,mica-rev<board_id>, google,mica-sku<sku_id> and google,mica. Entries whose id is undefined are skipped (fit.c:80-101).
• Nothing in the bluey board code adds compatibles: fit_add_compat is called only from fit.c.
• The ordering is documented in Documentation/arch/arm/google/chromebook-boot-flow.rst:21-49.

How a config is ranked.

• Each FIT config is ranked by the best (lowest-index) list entry that equals any of its compatible strings (fit.c:228-289; exact string match). The best-ranked config wins; with no match, /configurations/default boots (fit.c:436-449).
• mkimage -f auto writes conf-N { kernel, fdt, loadables, ramdisk } with no compatible (fit_image.c:482-531).
• So depthcharge takes the “legacy FIT” branch and reads the first compatible property of the DTB’s root node. That requires an uncompressed FDT and no overlays (fit.c:248-274).
• The draft DTB’s root compatible = "google,mica", "qcom,x1e80100" therefore matches rank 3 on any board-id and sku-id.

Where board-id and sku-id come from.

• mica selects MAINBOARD_HAS_CHROME_EC (bluey Kconfig:79-92), which selects EC_GOOGLE_CHROMEEC (:282-287).
• So coreboot reads board_id from the EC board version and sku_id from the EC’s SKU (bluey/boardid.c:21-24, 41-42).
• The values are not public. depthcharge prints them on the AP console (fit.c:384-387) and writes them to /firmware/coreboot in the booted DT (chromeos-boot-path.md section 3).

Stock dtbo table (dumps/recovery-16471258/parts/dtbo_a.img, header and entries decoded 2026-10-21; version 1, 3 entries of 32 bytes). depthcharge parses v1 entries as dt_size, dt_offset, id, rev, flags, custom[3] (src/boot/android_dt_table.h:43-53). It treats rev as min_rev = rev & 0xffff, max_rev = rev >> 16; 0..0xffff means “any” (android_dtboimg.c:82-92). custom[0] & 0xff == 0 makes custom[1] a SKU, where 0xffffffff means any (:139-145, 228-229, 259-263). Compression is flags & 0xf (android_dt_table.h:35-41).

• id is unused (0) and only echoed as an index. The table does not encode a SKU at all.
• The only board-id information is that the keyboard-matrix overlay applies to board revisions 1-15.
• Inference: production mica reports a board_id between 1 and 15, and rev 0 (early proto) boards had a different keyboard. The real value stays unknown until the first boot.
• The mainline DTB does not depend on it, as shown above. A rev- or sku-specific DTB can be added later with google,mica-rev<N> compatibles.

7. What can be verified offline

Cannot be exercised without the device:

• depthcharge’s FIT selection. tests/boot/ at 694eabf has tests for android_mte, bootconfig, commandline, memchipinfo and payload, but none for fit (gitiles tree listing, 2026-10-21). The %U substitution does have tests/boot/commandline-test.c.
• The real board-id and sku-id.
• depthcharge’s DT fixups on a mainline DT. dt_apply_fixups failing aborts the boot (src/arch/arm/fit.c:99-100).
• Console output.

8. Installing the tools on Arch

Sources: pacman -Si/-Ss/-Q on the build host; AUR RPC /rpc/v5/search and the PKGBUILDs at aur.archlinux.org (read 2026-10-21); qa.debian.org/madison.php and packages.debian.org file lists (read 2026-10-21). Debian sid depthcharge-tools depends on cgpt, vboot-kernel-utils, vboot-utils, u-boot-tools, device-tree-compiler, lz4, xz-utils, zstd and others.

AUR packages.

• AUR vboot-utils builds release-R154-16805.B and runs make install … MINIMAL=1, then copies tests/devkeys. It depends on AUR cbfstool and chromeos-flashrom-git, which is heavy for three binaries.
• AUR depthcharge-tools builds the 2023 v0.6.2 tag with python setup.py. It declares only python as a dependency, so mkimage, vbutil_kernel and fdtput must come from elsewhere.

Options, in order of preference.

1. Container. pkexec docker run … debian:sid with the packages in the Answer. No host install, all official packages. vboot is R156 rather than the firmware’s branch.
   • Inference: the keyblock and preamble formats (2.1/2.2) have not changed between them, and --verify uses the same verification code the firmware links.
   • A pinned image digest or a Dockerfile in scripts/ would make it reproducible (not done here).
2. Arch host. pacman -S uboot-tools, AUR vboot-utils, and depthcharge-tools run from the pinned checkout.
   • For example PYTHONPATH=<checkout> python3 -m depthcharge_tools.mkdepthcharge …; the module has a __main__ guard (mkdepthcharge.py:1415). Inference: untested.
   • That needs an owner OK for the installs.
3. Scratch build. Build futil and cgpt from the vboot_reference checkout at 34fbbe6 (Makefile:360-361 defines futil). Inference: untested; it needs OpenSSL and libuuid headers.

Not found

• Board-id and sku-id values. Neither public source nor the stock dtbo reveals them; only the keyboard overlay’s board_id range 1-15. The EC console’s cbi command would show them, but sending it needs the owner’s OK under ADR 0006.
• A depthcharge unit test for fit.c at 694eabf, so FIT selection can only be checked by reading the code.
• Whether dt_apply_fixups, including bluey’s CPU-map fixup, succeeds on a mainline-shaped DT. The fixup source was not located under src/board/bluey/ at 694eabf.
• Whether depthcharge leaves uart21 clocked, so that earlycon=qcom_geni prints before the GENI driver probes.
• Measured image sizes. There is no mica kernel build yet, so the 256 MiB margin is not measured.
• A tested run of the container or AUR route on the build host. Nothing was installed for this note.

Console-only kernel config and boot arguments for the first mica boot

Researched 2026-10-21 for ticket 04. Sources were read on the build host. Nothing was built, and the Googlebook was not touched. Items marked inference are reasoned from source, not tested.

Answer

Derive the config with plain make defconfig. Do not trim it. At torvalds a804c57 the arm64 defconfig already builds in every driver on uart21’s supplier chain. An arm64 defconfig Image is about 50 MiB, so the 256 MiB KERNEL_SIZE gives no reason to trim. After make defconfig, check the list below in .config before building, so that a later tree or fragment cannot quietly switch one of them to =m.

Must be =y (built in). These are needed for ttyMSM0 on uart21 with no initramfs and no module loading:

Three entries are missing from the defconfig file only because their Kconfig default (ARCH_QCOM) already makes them y: PINCTRL_MSM, PINCTRL_X1E80100 and QCOM_GENI_SE. Do not “fix” the file by adding them. No firmware file is needed. coreboot loads the UART protocol into QUP2 SE5, and the kernel loads GENI firmware only when the SE reports no protocol.

Boot arguments (they go into the vbutil_kernel --config command line, which depthcharge writes to /chosen/bootargs. defconfig sets no CONFIG_CMDLINE):

console=ttyMSM0,115200n8 earlycon=qcom_geni,0x894000 clk_ignore_unused pd_ignore_unused

Optional for the first attempt: ignore_loglevel, and keep_bootcon (it keeps earlycon after ttyMSM0 takes over, so lines print twice). root= and init= belong to the FIT/initramfs tickets.

• Use the explicit earlycon=qcom_geni,0x894000. A bare earlycon reads /chosen/stdout-path, and dts/x1e80100-google-mica.dts has no /chosen node yet. hamoa.dtsi:34 is chosen { };, and the 9345 file sets none either. ADR 0006 records stdout-path = "serial0:115200n8" as decided, so the DTS needs that line. That is a DTS-ticket item; this note does not edit the DTS. Update 2026-10-21: the DTS now sets stdout-path = "serial0:115200n8" (commit 709212e).
• Earlycon does not wait for clocks. It registers from early_param before any driver probes, and its setup writes only SE registers. It sets no clock, pinmux, interconnect, OPP or baud rate. So it prints only if firmware left SE5 clocked, loaded with UART firmware, pinmuxed and running at 115200. coreboot always loads the UART firmware, but it sets the baud divider and pinmux only when its own serial console is built in. Whether mica’s production firmware does that is not known (see “Not found”).
• ttyMSM0 does not depend on firmware state. The real console sets its own clocks, pins and 115200 baud when it probes. That happens once the chain above is up, and printk then replays the log buffer.
• clk_ignore_unused pd_ignore_unused: the stock Googlebook kernel boots with both, and so does Ubuntu Concept’s x1e GRUB config. They are not needed for ttyMSM0 itself, because the driver claims its clocks when it probes. They matter in the failure case: if the real driver never probes, clk_disable_unused would gate the QUP clocks at late_initcall_sync (they carry no CLK_IGNORE_UNUSED) and silence the earlycon (inference).

Image size against KERNEL_SIZE. KernelCI’s arm64 defconfig build of mainline b88c841d (v7.3-rc6+, clang-21, 2026-10-11) gives:

• Image: 52,271,616 bytes (49.9 MiB);
• header image_size: 53,084,160 bytes (50.6 MiB);
• Image.gz: 14.6 MiB.

depthcharge’s kernel buffer is KERNEL_SIZE = 256 MiB. It holds the whole loaded body: the FIT with its kernel, DTB and any ramdisk. An uncompressed Image uses about a fifth of it. That build is close to a804c57, not a804c57 itself.

Other trees, as facts for the kernel-tree decision:

Both Ubuntu-based configs load the GENI serial driver from an initramfs. So a first boot without an initramfs would print nothing on ttyMSM0 from them, and earlycon would be missing too (inference). For a console-only first boot, use defconfig or johan_defconfig, or add SERIAL_QCOM_GENI=y to one of the Ubuntu configs.

Sources and revisions

The kernel files came from raw.githubusercontent.com/torvalds/linux/<commit>/…, because the local sparse checkout holds only DTS and bindings. The Ubuntu trees were read from shallow sparse clones. Paths below without a repo prefix are in torvalds/linux at a804c57.

Evidence

1. The probe chain from uart21 to its suppliers (DT)

• uart21: serial@894000 (hamoa.dtsi:1296-1318):
  • clocks = <&gcc GCC_QUPV3_WRAP2_S5_CLK>;
  • interconnects on clk_virt (MASTER_QUP_CORE_2), gem_noc and config_noc (SLAVE_QUP_2);
  • power-domains = <&rpmhpd RPMHPD_CX> and operating-points-v2 = <&qup_opp_table_100mhz>, whose OPPs require rpmhpd_opp_low_svs/svs (:671-681);
  • pinctrl-0 = <&qup_uart21_default>: gpio86 TX and gpio87 RX, function qup2_se5 (:6726-6737).
• mica sets compatible = "qcom,geni-debug-uart" and serial0 = &uart21 (dts/x1e80100-google-mica.dts:32,1552-1555). That is the same as the 9345, CRD and devkit.
• The parent qupv3_2: geniqup@8c0000 (hamoa.dtsi:847-862) has the clocks GCC_QUPV3_WRAP_2_M_AHB_CLK and _S_AHB_CLK, and iommus = <&apps_smmu 0x423 0x0>.
• gcc (:759-807) has power-domains = <&rpmhpd RPMHPD_CX> (:804).
• apps_rsc: rsc@17500000 (:8575-8607) has power-domains = <&system_pd> (:8591). Its children are apps_bcm_voter, rpmhcc and rpmhpd.
• system_pd is a child of psci { compatible = "arm,psci-1.0"; } (:377-474).
• cmd-db is a reserved-memory node (:517-518).
• tlmm (:6095-6108) has wakeup-parent = <&pdc>.

Code that turns these links into hard dependencies:

• The wrapper probe gets its clocks, then devm_of_platform_populate(). The UART child exists only after that (drivers/soc/qcom/qcom-geni-se.c:1603-1650).
• geni_se_resources_init() gets the se clock, the OPP table and the interconnect paths (qcom-geni-se.c:1196-1226, geni_icc_get at :1220). The serial probe calls it through resources_init (drivers/tty/serial/qcom_geni_serial.c:1921).
• TLMM returns -EPROBE_DEFER while the PDC wakeup domain is missing (drivers/pinctrl/qcom/pinctrl-msm.c:1471-1477).
• A missing PM-domain provider sends genpd to driver_deferred_probe_check_state() (drivers/pmdomain/core.c:3362-3383). That defers, then returns -ETIMEDOUT once deferred_probe_timeout expires (drivers/base/dd.c:285-298). The default is 10 s when MODULES=y (drivers/base/Kconfig:76-79). rpmh-rsc uses pdev->dev.pm_domain (drivers/soc/qcom/rpmh-rsc.c:1124-1128). So without the PSCI domain driver, apps_rsc never probes. The domain driver matches arm,psci-1.0 and registers at core_initcall (drivers/cpuidle/cpuidle-psci-domain.c:126,192).
• Init order when everything is built in: the RPMh core and the x1e interconnect at core_initcall (rpmh-rsc.c:1177, drivers/interconnect/qcom/x1e80100.c:1915), TLMM at arch_initcall (pinctrl-x1e80100.c:1866), GCC at subsys_initcall (gcc-x1e80100.c:7506), and the GENI wrapper as a module init (qcom-geni-se.c:1689).
• Inference: QCOM_SCM (selected by PINCTRL_MSM and ARM_SMMU_QCOM), AOSS QMP and IPCC are not on this chain.

2. Kconfig and defconfig

• SERIAL_QCOM_GENI is a tristate that depends on QCOM_GENI_SE. SERIAL_QCOM_GENI_CONSOLE is a bool that selects SERIAL_EARLYCON (drivers/tty/serial/Kconfig:915-929).
• The qcom,geni-debug-uart match entry exists only with the console option (qcom_geni_serial.c:2191-2199).
• The earlycon is OF_EARLYCON_DECLARE(qcom_geni, "qcom,geni-debug-uart", …) (:1755-1756).
• Inference: with the driver =m, the earlycon table entry sits in the module and is never seen at early boot.
• Defaults:
  • QCOM_GENI_SE, QCOM_COMMAND_DB and QCOM_RPMH: default ARCH_QCOM (drivers/soc/qcom/Kconfig:30-43,155-158).
  • PINCTRL_MSM: default ARCH_QCOM. The SoC drivers sit inside if PINCTRL_MSM, and PINCTRL_X1E80100 has default ARCH_QCOM (drivers/pinctrl/qcom/Kconfig:2-17, Kconfig.msm:2,582-591).
  • CLK_X1E80100_GCC and QCOM_CLK_RPMH: default ARCH_QCOM (drivers/clk/qcom/Kconfig:267-276,416-419).
  • QCOM_RPMHPD has no default (drivers/pmdomain/qcom/Kconfig:20-26). Neither does INTERCONNECT_QCOM_X1E80100 (drivers/interconnect/qcom/Kconfig:461-469), ARM_SMMU (drivers/iommu/arm/Kconfig:3-15) or QCOM_PDC (drivers/irqchip/Kconfig:523-529).
  • ARM_SMMU_QCOM is def_tristate y and depends on ARCH_QCOM (drivers/iommu/arm/Kconfig:53-59).
  • ARM_PSCI_FW is selected by ARM64 (arch/arm64/Kconfig:110). ARM_PSCI_CPUIDLE_DOMAIN is a bool with default y (drivers/cpuidle/Kconfig.arm:17-44).

• arch/arm64/configs/defconfig sets: ARCH_QCOM=y :69, ARM_PSCI_CPUIDLE=y :95, MODULES=y :127, SERIAL_QCOM_GENI(_CONSOLE)=y :585-586, COMMON_CLK_QCOM=y :1472, CLK_X1E80100_GCC=y :1487, QCOM_CLK_RPMH=y :1496, ARM_SMMU=y :1617, QCOM_COMMAND_DB/GENI_SE=y :1654-1655, QCOM_RPMH=y :1660, QCOM_RPMHPD=y :1678, QCOM_PDC=y :1746, INTERCONNECT(_QCOM)=y :1865/:1871, INTERCONNECT_QCOM_X1E80100=y

  1901. It has no CONFIG_CMDLINE line.

• Also in defconfig, outside the console chain: CROS_EC=y and CROS_EC_SPI=y :1427-1430, TCG_TIS_I2C_CR50=m :611, BLK_DEV_NVME=m :309, PSTORE_RAM=m :1928. PSTORE_RAM matters for the ramoops fallback in ADR 0006, which the observation ticket covers.

3. Earlycon and console mechanics

• earlycon= with no options takes the console from stdout-path. qcom_geni,<addr> starts a polled console; “the serial port must already be setup and configured. Options are not yet supported” (Documentation/admin-guide/kernel-parameters.txt:1398-1402,1515-1518).
• Parsing:
  • setup_earlycon() tries names with an empty compatible first, then qcom_geni (drivers/tty/serial/earlycon.c:176-214).
  • 0x<addr> parses as MMIO (drivers/tty/serial/serial_core.c:2175-2176).
  • The register page goes through the fixmap (earlycon.c:39-48; FIX_EARLYCON_MEM is def_bool y, arch/arm64/Kconfig:364-365).
  • The parameter is an early_param (earlycon.c:242).
• A bare earlycon on a DT boot with ACPI support goes through early_init_dt_scan_chosen_stdout(). That returns -ENOENT without stdout-path (earlycon.c:223-241, arch/arm64/kernel/acpi.c:231-233, drivers/of/fdt.c:950-969). arm64 selects ACPI_SPCR_TABLE when ACPI is on (arch/arm64/Kconfig:12), and defconfig has ACPI=y (:116).
• qcom_geni_serial_earlycon_setup() (qcom_geni_serial.c:1702-1754):
  • It returns -ENXIO unless the SE already reports the UART protocol.
  • It writes only packing, FIFO and frame registers in the SE. It touches no clock, pinctrl, ICC or baud divider.
• The real console:
  • It is named ttyMSM, and its index comes from the serial alias (:1768-1787, :1895-1897).
  • Only index 0 is valid (GENI_UART_CONS_PORTS 1 at :88, check at :1615).
  • Setup defaults to 115200 and parses console= options (:1605-1649).
• If the SE has no protocol, the driver tries geni_load_se_firmware() (:1358-1367). That needs a firmware-name property on the wrapper (qcom-geni-se.c:1565-1567), which hamoa.dtsi does not set.
• Boot consoles are dropped when the preferred real console registers, unless keep_bootcon (kernel/printk/printk.c:3868-3878,4211-4220).

4. What firmware leaves on SE5 (coreboot ff3258d)

• UART_FOR_CONSOLE defaults to 21 (src/soc/qualcomm/x1p42100/Kconfig:80-82). That is QUP2 SE5, the same engine as Linux uart21.
• load_qc_se_firmware_late() loads UART firmware into QUPV3_2_SE5 “even if coreboot’s serial output is disabled” when CONSOLE_SERIAL is off (src/mainboard/google/bluey/mainboard.c:290-297). It runs from mainboard_late_init (:320-322).
• qupv3_se_fw_load_and_init() loads the firmware and sets up the SE (src/soc/qualcomm/common/qupv3_config.c:14-80).
• The baud divider (from XO), the TX/RX pinmux and the watermarks are set only in uart_init() (src/soc/qualcomm/common/qupv3_uart.c:47-90). That is coreboot’s serial-console path.
• qupv3_fw_init() turns on all QUP clocks (qupv3_config.c:255-262). Where bluey calls it was not traced.

Inference: with production firmware (serial console presumably off), the SE reports UART, so earlycon registers. Whether its output appears at 115200 depends on divider and pinmux state that coreboot does not set. The real ttyMSM0 console does not depend on any of this.

5. clk_ignore_unused and pd_ignore_unused

• Both are documented as debug/development aids that “should not be needed on a platform with proper driver support” (kernel-parameters.txt:788-798,5279-5283).
• Their code: clk_disable_unused() runs at late_initcall_sync (drivers/clk/clk.c:1580-1627), and genpd_power_off_unused() also at late_initcall_sync (drivers/pmdomain/core.c:1356-1387).
• The QUP clocks have no CLK_IGNORE_UNUSED. gcc_qupv3_wrap2_s5_clk has only CLK_SET_RATE_PARENT (gcc-x1e80100.c:4900-4912). The wrapper AHB clocks are at :5014-5035.
• Who passes them:
  • Stock Googlebook kernel: its live /proc/cmdline contains clk_ignore_unused pd_ignore_unused (recon, /proc/cmdline row).
  • Ubuntu Concept x1e: grub.d/ubuntu-x1e-settings.cfg sets GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX} clk_ignore_unused pd_ignore_unused cma=128M efi=noruntime", both at c38933d0 and on ubuntu/resolute @ d4002829. The resolute copy also sets GRUB_BADRAM. The repo log has “Add efi=noruntime as recommended by jhovold” (2025-08-12).
  • Inference: efi=noruntime and the GRUB_BADRAM workaround are for UEFI boots, so they do not apply to a depthcharge DT boot.

6. Image size and depthcharge limits

• config.mica: KERNEL_START=0xC7800000, KERNEL_SIZE=0x10000000, KERNEL_FIT_FDT_ADDR=0xDA800000, BASE_ADDRESS=0xDB000000.
• The ldscript defines _kernel_end = CONFIG_KERNEL_START + CONFIG_KERNEL_SIZE (src/image/depthcharge.ldscript.S:38-39).
• vboot loads into kernel_buffer = _kernel_start, size _kernel_end - _kernel_start (src/vboot/stages.c:161-162). So 256 MiB bounds the loaded partition body.
• boot_arm_linux() reads the arm64 header and needs a contiguous free range of header image_size bytes. It picks a KASLR slot outside [min(BASE_ADDRESS, KERNEL_START, FDT_ADDR), 4 GiB) and reserved memory, then decompresses into it (src/arch/arm/boot64.c:113-210). The Image therefore runs from RAM above 4 GiB (or below 0xC7800000), not from the 256 MiB buffer.
• FIT compression: none, lz4 or lzma (chromeos-boot-path.md).
• Measurement (2026-10-21): KernelCI node 6acbaef4a3f195e1aa6556c8, defconfig, clang-21, artifact files.kernelci.org/kbuild-clang-21-arm64-mainline-6acbaef4a3f195e1aa6556c8/Image.gz, created 2026-10-11 11:44 EDT [15:44 UTC]. Results:
  • Image.gz: 15,284,553 bytes;
  • Image: 52,271,616 bytes;
  • header text_offset: 0;
  • header image_size: 53,084,160;
  • magic ARM\x64.

7. Other trees

jhovold:

• johan_defconfig @ a9cd6cda sets:
  • CPU_IDLE=y :47, ARM_PSCI_CPUIDLE=y :48;
  • SERIAL_QCOM_GENI(_CONSOLE)=y :177-178, PINCTRL_MSM/X1E80100=y :188-190;
  • COMMON_CLK_QCOM=y :316, QCOM_CLK_RPMH=y :321, ARM_SMMU=y :335;
  • QCOM_COMMAND_DB/GENI_SE/RPMH/RPMHPD/PDC=y :348-363, INTERCONNECT_QCOM_X1E80100=y :381;
  • GCC by default;
  • PCIE_QCOM=m :115, BLK_DEV_NVME=m :129.
• It has no ACPI line, and ACPI defaults to y only on x86 (drivers/acpi/Kconfig:9-17).
• Branch head commits: “johan_defconfig: add custom config” and “arm64: defconfig: build Qualcomm PCIe driver as a module”.
• GitHub API, 2026-10-21: the newest wip/x1e80100-* branch is 6.16 (head 2025-07-28), and the repo was last pushed 2025-09-19. kernel.org johan/linux.git only has master at 6.5-rc6.

jglathe:

• debian/debian.env is DEBIAN=debian.qcom-x1e, and rebuild.sh runs dpkg-buildpackage.
• debian.qcom-x1e/config/annotations sets:
  • SERIAL_QCOM_GENI m :10798, console y :10799;
  • CLK_X1E80100_GCC y :2359, PINCTRL_MSM/X1E80100 y :8781/:8973;
  • INTERCONNECT_QCOM_X1E80100 y :5729, ARM_SMMU y :1396, PSCI cpuidle y :1360-1361;
  • QCOM_RPMH/RPMHPD y :9297-9298, QCOM_PDC y :9280;
  • EFI_ZBOOT y :168, CMDLINE "console=ttyAMA0" :2384, DEBUG_INFO_NONE y :3171;
  • BLK_DEV_NVME m :51, PCIE_QCOM y :8421;
  • CROS_EC_SPI m :2859, TCG_TIS_I2C_CR50 m :12233, EC_QCOM_HAMOA n :4046.
• Its dev-build arch/arm64/configs/ubuntu_x1e_defconfig (used by devbuildconfig.sh) also has SERIAL_QCOM_GENI=m :2290 and CMDLINE="console=ttyAMA0" :130.

Ubuntu Concept:

• debian.qcom-x1e/config/annotations @ d997b73b (header FLAVOUR: arm64-qcom-x1e) sets:
  • SERIAL_QCOM_GENI m :10416, console y :10417;
  • CLK_X1E80100_GCC y :2139, PINCTRL_X1E80100 y :8625;
  • INTERCONNECT_QCOM_X1E80100 y :5471, ARM_SMMU y :1203, PSCI cpuidle y :1169-1170;
  • QCOM_RPMH/RPMHPD y :8940-8941, QCOM_PDC y :8922;
  • ACPI y :502, EFI_ZBOOT y :156, CMDLINE "console=ttyAMA0" :2161;
  • BLK_DEV_NVME m :48, PCIE_QCOM y :8144, PHY_QCOM_QMP_PCIE y :8340.
• resolute-x1e @ ba0042b4 builds from debian.master (generic arm64), where these are m: CLK_X1E80100_GCC :3033, PINCTRL_X1E80100 :10897 and INTERCONNECT_QCOM_X1E80100 :7167.
• With a CONFIG_CMDLINE set, the bootloader’s command line still wins under the default CMDLINE_FROM_BOOTLOADER (inference, from Kconfig defaults; not read for this note).

Not found

• mica firmware serial state. Whether mica’s production coreboot is built with CONSOLE_SERIAL is unknown. So is whether depthcharge or anything after coreboot leaves SE5’s divider, pinmux and clocks usable. Without that, nobody can say whether earlycon output will be readable at 115200. A read of ttyUSB1 across a reboot answers it (silent-boot observation ticket). Where bluey calls qupv3_fw_init() was not traced.
• No stdout-path in the mica DTS. dts/x1e80100-google-mica.dts has no /chosen/stdout-path, although ADR 0006 decided serial0:115200n8. That belongs to a DTS change, not this ticket.
• No Image built from a804c57 itself. The closest public measurement is b88c841d (v7.3-rc6+). A defconfig build of the chosen tree should record its own Image size.
• No current jhovold x1e tree past 6.16 on GitHub or kernel.org as of 2026-10-21.
• Launchpad cgit for the Ubuntu Concept kernel repos returns HTTP 403 for log/tree pages. Branch heads came from code.launchpad.net ref pages, and the configs from shallow clones.
• Interconnect lookup when the x1e provider is a module. of_icc_get()’s behaviour was not read; the “defers” claim in the table rests on the DT link plus fw_devlink, inference.

Observing a silent first boot on mica

Researched 2026-10-21 from firmware and kernel source at pinned commits, AOSP source, and the stock DT already extracted from the recovery image (stock-dtb.md). Nothing was run on the Googlebook and no SuzyQ tty was opened. Items marked inference are reasoned from source, not tested on the device.

Ticket: 05-silent-boot-observation.

Answer

If the AP console (uart21 through the SuzyQ -if01) stays silent, these channels show how far the kernel got. They are ranked by how much they tell and how little they need from the new kernel.

1. ramoops: the kernel log of the failed boot, read on the next boot. This is the best channel.
   • depthcharge always adds /reserved-memory/ramoops (compatible = "ramoops") on mica. The buffer is the coreboot CBMEM entry RAMOOPS, 1 MiB by default, and it sits in CBMEM just below 0x866C0000.
   • The exact address is decided at boot, not fixed in source. Inference: it lies between 0x85F80000 and 0x866C0000.
   • Layout: 256 KiB console, 128 KiB ftrace, 128 KiB pmsg and two 256 KiB dump records. max-reason = 2 (oops and panic).
   • Mainline a804c57 picks the node up unchanged. The kernel needs CONFIG_PSTORE=y, CONFIG_PSTORE_CONSOLE=y and CONFIG_PSTORE_RAM=y built in. arm64 defconfig has PSTORE_RAM=m and no PSTORE_CONSOLE.
   • What to read: console-ramoops-0 holds every printk of the previous boot, up to the hang. A dmesg-ramoops-N record appears only after an oops or panic.
   • Readback:
     • (a) Stock OS, after the next boot: adb shell cat /sys/fs/pstore/console-ramoops-0. adb bugreport also carries it as “LAST KMSG”. AOSP grants the shell user both the file mode and the SELinux rule. Inference to test: the stock kernel has pstore enabled.
     • (b) The next mainline boot: /sys/fs/pstore/.
     • Update 2026-10-21 (live read): on stock build 16560795, /sys/fs/pstore is denied to adb shell, so (a) as written fails. adb shell dumpsys dropbox --print SYSTEM_LAST_KMSG returns the last 64 KiB instead (stock pstore ticket).
   • Conditions:
     • DRAM must survive the reset. Let the kernel reboot itself (panic=5, plus softlockup_panic=1 or hung_task_panic=1 for hangs). Do not hold the power button: that is an EC power-off.
     • The next boot must run the same firmware.
2. The panel, through the firmware framebuffer.
   • coreboot brings up eDP and draws its splash into a 32 bpp linear framebuffer at 0xE4800000 (region size 0x2200000). It reports that framebuffer in the coreboot table.
   • depthcharge adds no simple-framebuffer node and does not reserve the region. At handoff it clears the screen to black. bluey registers no display driver, so depthcharge has no way to stop the scan-out. Inference: the panel is still scanning out when the kernel starts.
   • Mainline can use it with COREBOOT_TABLE, COREBOOT_FRAMEBUFFER, DRM_SIMPLEDRM and fbcon. The driver registers a simple-framebuffer device from the coreboot table, so no width, height or stride needs to go into the DTS.
   • The DTS must add a no-map reservation for 0xE4800000+0x2200000; the stock overlay does the same with its cont_splash_region. Without it simpledrm cannot probe: arm64 ioremap refuses memory in the linear map.
     • Correction 2026-10-21: the stock splash_region (entry01-overlay.dts:40-42) has the same address, but its size is 0x21c0000 and it has no no-map. The first-boot DTB uses coreboot’s 0x2200000 with no-map (decision).
   • Keep the lid open: coreboot skips display init when the lid is closed.
   • Inference: add clk_ignore_unused pd_ignore_unused, and do not let the DT turn off the eDP rails, or the kernel cuts the display’s clocks and power.
3. EC console (SuzyQ -if02), passive.
   • It logs every AP power-state change (power state N = S0…) and AP resets (AP_RST_L transitions). It also logs POWER_GOOD loss and the 8 s long-press power-off.
   • It does not log kernel progress. Host-command tracing is off by default and cannot be turned on through a read-only console.
   • Use it as a heartbeat: a kernel that reaches panic=5, or an initramfs that runs reboot -f or poweroff -f on purpose, shows up as a reset or an S0→S5 transition.
4. Firmware log of the previous boot (/sys/firmware/log).
   • coreboot’s CBMEM console keeps appending across warm reboots. The next boot’s log therefore holds the failed boot’s firmware lines, including depthcharge’s Choosing best match … and jumping to kernel.
   • It proves depthcharge picked our FIT configuration and jumped. It holds no kernel output.
   • It is readable on a mainline boot with COREBOOT_MEMCONSOLE. adb shell on the stock OS is denied (recon).
5. Glowbar / service-LED codes: firmware stage only.
   • 4,3 matches coreboot’s mica-only LCD check, MAINBOARD_LCD_FAIL_DETECT. When eDP EDID/DPCD read or link training fails in coreboot, it sends the EC lightbar sequence 101 (inference that 101 is the 4,3 pattern).
   • 3,5 is the EC’s power-on timeout. Inference: it is the POWER_GOOD not seen in time path.
   • A ramdump pattern (sequence 55) exists, but mainline leaves Qualcomm download mode off.
   • None of these reports kernel progress. The pattern table is in the EC’s private module.
6. GSC ccdstate: coarse. The AP: line says whether the AP is powered and out of reset. In cr50 source it follows TPM_RST_L; Ti50 is closed (inference that Ti50 behaves the same). It cannot tell a hung kernel from a running one. Its output also prints pcr0, which must be redacted before anything is saved.

For the runbook (inference, for the console-config and failure-playbook tickets):

• Kernel config: PSTORE, PSTORE_CONSOLE, PSTORE_RAM, COREBOOT_FIRMWARE (the menu that gates the next three), COREBOOT_TABLE, COREBOOT_MEMCONSOLE, COREBOOT_FRAMEBUFFER, DRM_SIMPLEDRM and FRAMEBUFFER_CONSOLE, all =y.
• Command line: panic=5 softlockup_panic=1, plus clk_ignore_unused pd_ignore_unused while the framebuffer is the display.
• DTS: a no-map region at 0xE4800000.
• After a silent boot: watch the EC console for the reset, let the device fall through to the stock OS, and run adb shell cat /sys/fs/pstore/console-ramoops-0.
  • Pull the USB drive first, or make sure the internal disk is the default: another mainline boot overwrites the zone.
  • Read it before any further reboot: the stock kernel’s own log replaces it on the next boot.

Sources and revisions