Linux Phone Porting

Linux Phone Porting

A debug iteration costs a build + flash + boot (5-10 min); blind fixes get refuted more often than they land. Follow this order strictly.

The chain drives itself; the operator owns the decisions. When a phase's exit condition is met, start the next phase's entry yourself: setup complete → evidence on the first symptom; evidence captured → the phase 2 sweep opens its ledger; ledger full → hypotheses ranked with falsifiers into phase 3's gate; gate passed → the cheapest decisive experiment, then verification, acceptance and cleanup; three refutations → back to phase 2, wider. Do not wait to be told the next step, and do not stop at a phase boundary to summarize — report compactly and continue. Ask, never guess, at the decision points that belong to the operator, and those are the only stops: unresolved target identity or an unspecified interface/session (phase 0 asks), a boot path the operator must complete (locked bootloader, missing payload demonstration — resume when done), the loop's refutation budget, anything that can destroy excluded userdata or otherwise unrecoverable state, physical hands, and pause/resume prerequisites. Everything else advances.

Every phase entry and command invocation refreshes the session's task list first. Before any work, replace the running todo/task list with the incoming unit's steps — one item per step of the phase or command about to run, first step marked in progress. A stale list from the previous unit masquerades as pending work and hides real progress; superseding it is part of starting the unit, not bookkeeping to defer.

Scope: mainline Linux bring-up on phones and tablets plus integration of the selected OS userspace — a method, not certification of any OS/device combination. The userspace need not be GNU/Linux; non-Linux kernels are out of scope.

0. Set up the port

Once, before the first flash. The stock system is the highest-authority research source for this board, and parts stop being readable once overwritten.

Establish the target (every later answer depends on it; every decision here is asked and user-confirmed — an existing repo, monorepo layer, staged OS image, prior context file or sibling device's choice near the project is a candidate to offer, not an answer; artifacts establish what is present, never what is wanted, and one target OS inferred from surrounding layout had to be superseded by the operator's actual selection):

• Exact device identity — marketing name, codename, SoC, regional/storage variant. Sibling variants of one name differ in panel, touch, modem; a fix researched against the wrong variant looks plausible and fails. Record sibling codenames — phase 2 enumerates their ports. On firmware-boot targets DMI/SMBIOS cannot even be trusted for the SoC generation: one family's DMI string appeared in no documentation while one marketing name spanned two SoC generations with zero portability (DT, patches, community tooling all generation-specific). Discriminate by the stock OS's CPU identity string plus per-core max frequency as tiebreaker, and verify later against the running system's board description; a "no port exists" sweep verdict must name the CPU generation it searched for, or it may be reporting the sibling's ecosystem — on one device all community port effort sat on the newer generation.
• Engineering stage — EVT/DVT/PVT, board identity, carrier/SKU, bootloader product + build fingerprints. Reconcile before choosing images: one presumed retail handset was an EVT board for a different product while Android reported user/release-keys. Build labels do not establish production hardware.
• Target OS/platform and integration contract — chosen release, required kernel lineage, startup/service manager, hardware-service interfaces, build/image/update model, evidence/control tools; verify against the target project's current docs. Linux-based ≠ mainline-compatible; a working Linux driver ≠ target-framework or application support.
• Target user interface/session — ask when unspecified; never assume. Prefer the platform's supported interface/session stack over replacing it during bring-up.
• Boot-model class — classify before anything else about boot; the class selects the write gate, the backup route and the board-authority artefact (boot-image DTB / ACPI tables / DT inside the vendor kernel image):
  • Retail-unlock — OEM unlock, boot images, A/B slots. Unlocked bootloader only — no unlocking steps; point at the OEM's instructions and resume when unlocked.
  • Exploit-booted — bootROM-vulnerable devices; no unlock state exists. Gate: a payload boot path demonstrated on this device; the payload environment is a candidate control channel and recovery path — prove both. No exploit-landing steps; point at the payload project's own instructions.
    • Session mechanics — every naive liveness signal false-positives. Enumeration shows the right VID:PID for a zombie session; the exploit tool's own verifier can print success without running its stage machine on a stale session; a session contaminated by dozens of failed races reads back as pwned while untrustworthy (one session burned ~3 h this way). Working gate: a USB node number different from the one recorded at last session close, a GETSTATUS-class control transfer answered within a short timeout (timeout = zombie), and the full stage trace in the exploit log — a success line with zero stages is the false-positive signature. Bound exploit attempts per session; after repeated failed races, re-enter clean DFU instead of continuing on the contaminated one.
    • The pwn exists only inside the live session. An idle payload session dies on its own; "pwned then later gone" means the session died — check what re-enumerated before theorizing a physical decay (one such theory was refuted in seconds by a raw descriptor read). Pre-stage everything downstream so exploit-success → payload-load is seconds, not minutes (one 25-minute grind was dead ~9 minutes later); record node + verified state at session close.
    • Success announces itself as USB re-enumeration to a payload-specific PID — the device leaves the exploit PID entirely, and different payload builds present different PIDs; watching the wrong PID reads as "loader silently does nothing" (one attempt wrongly concluded the whole approach dead). Record the expected PID map per build beside the udev rules; cover every chain stage's VID:PID up front (each stage re-enumerates). The uaccess tag can silently grant nothing (logind seat mismatch) — fall back to a deterministic group rule; and a newly installed rule does not apply to the already-plugged node, which is exactly the mid-chain node — replug or manual chgrp before the session continues. Interactive payload-console clients block forever without piped stdin: drive them as printf '…\n' | client.
    • Never diagnose device state from a host tool's parsed rendering of a USB string descriptor — read the raw descriptor with an oversized buffer. Host tools, and even the exploit suite itself, have read a truncated serial with the payload marker cut off, concluded "not pwned", and re-exploited an already-pwned session on every attempt; the misdiagnosis fed a physical "pwn decay" theory for hours before a raw-byte read retired it. The wrapper-corrupts-evidence rule extends into descriptor space, and the corrupting reader can be your own tool.
    • Mine a working project's boot scripts for the success signal and undocumented prerequisite steps — do not derive the flow from docs alone. A sibling project's flash script yielded steps no documentation mentioned (an explicit reset between exploit and payload load, missed by every doc-derived attempt). Pre-register the falsifier for the first tethered boot: one clean-session roll with a re-enumeration-poll timeout and named fallback flows.
    • Chain binaries get full provenance or the chain is unreproducible. Third-party CI-built and locally built payloads that no package manager provides: per-file origin (exact feed/zip), SHA-256, local build recipe with the pinned source revision; the tool environment defaults to the hashed copies via variables so no invocation silently picks up an untracked binary.
    • Entitlement-gated refusal is not absence. A readable retail OS may refuse its own diagnostic surfaces — an empty registry dump or a named storage-info failure proves the surface exists but is gated; the verdict is "unknown, evidence-backed", not "not exposed". Capture stdout and stderr as sibling files so refusals are first-class evidence, run every stock-side diagnostic before exploit work starts (the payload environment is the fallback surface and only exists after the chain works), and pre-register standing operational facts the stock OS already revealed — one end-of-life battery (cycle count + corroborating brown-out panic) became "expect spontaneous shutdowns, keep tethered, treat uncommanded power loss as routine" before any chain work; a capacity field returning a constant is a stub, not data.
  • Firmware-boot — UEFI or equivalent; lock state is often irrelevant to booting external media, but record it where the chain has one — some UEFI-lineage chains gate writes through their own unlock state and service tooling; where it gates writes, apply the retail-unlock gate to it. Gate: a demonstrated boot path. The board description may be ACPI tables, not a DTB.
    • Filesystem encryption is a phase 0 gate, before wipe/resize decisions. Record per-volume encryption status; the other OS can never read the recovery key for Linux and a resize of an encrypted volume fails until decryption fully completes (measured 10–60 min for a half-full 256 GB SSD). Record only that a key was exported and where — never the key. Record the wipe-vs-dual-boot decision and which partitions (e.g. factory recovery images) are intentionally forfeited before any destructive step.
    • The stock OS is the pre-install control channel. Its built-in ssh server replaces per-iteration operator hands: streaming harvests (driver/firmware stores, ACPI dumps) and even staging boot files onto the install medium, hashes verified host-side. The session's elevation follows the stock OS's own UAC configuration — know which you have. wmic-era tools are gone on current builds (use the OS's current management API). Do not route transfers through the install medium: its data partitions may be unreadable from the stock OS and its system partition may reject writes without elevation.
    • Harvest the Linux firmware before the wipe. On Windows-on-ARM targets the WLAN/BT/modem/DSP/GPU firmware lives in the driver store (System32/DriverStore/FileRepository) and is unobtainable afterwards — harvest filtered by SoC-number substring (one device: 99 package dirs, 726 MB / 1083 files), keep duplicate retained versions, file with dirlist + hashes + a README mapping each payload to its future firmware-path consumer, marked "reference only, not a restore source".
    • Harvest the ACPI board authority from the stock OS with the platform's dump/disassemble toolchain; if the toolchain mirrors are unreachable, the binaries ship inside GUI utilities. Disassemble the DSDT naming every SSDT so cross-table externals resolve. Then read absences as architecture: zero battery/AC method objects means the whole power path runs through an embedded controller on a bus the SoC dtsi may not even instantiate — and a mainline driver whose binding names this SoC may never have been tested on it: bindings text ≠ hardware validation.
    • Map physical connector → controller wiring from the stock OS before writing any DT node: with the device you will boot from plugged into the port you intend to use, walk the device's parent chain up to the first ACPI node — that instance names the owning controller (confirm its MMIO base in the DSDT). The same pass classifies unwired controllers: present-and-healthy-with-no-devices = dead on this board. One board's convention-based port guess cost two boot rounds before the stock-OS walk resolved the ports differently.
• Boot topology — A/B or not, slot layout. Decode slot state from the on-disk structure, not documented layouts (one SoC kept it in GPT partition-entry attribute bits, not the documented control partition). After a crash-loop, refill the tries-remaining budget before interpreting the next failure.
• Recovery — custom recovery installed? Convenience, not requirement.

Vendor A/B bank names do not establish seamless-update/slot/fallback semantics — establish the implementation before manipulating banks. Empty security properties = unknown, not unlocked. Same-SoC trees/firmware/signed programmers are candidates, not certified recovery paths; an unreleased prototype's only installed system may have no compatible replacement — preserve it, restorable backup before destructive experiments.

Raw-storage access without boot-chain control is a write/recovery route, not a boot path. A ROM-mode firehose (Qualcomm EDL-class) on a device whose vendor offers no unlock does not confer unlocked-like status: it can write partitions while the boot chain still verifies what it loads. The class gate is met only when a non-stock image is demonstrated to boot on this device through whatever chain achieves it — community "EDL ROMs" are precedent to verify, not proof. Once demonstrated, record the posture as retail-unlock-equivalent with the raw-storage route as the named recovery path; until then a permanently locked device stays out of scope for porting, and the available raw-storage channel is still recorded — it upgrades the backup and rescue posture for everything that follows (programmers are per-variant: prove the channel streams on this device before trusting it).

Back up every readable partition except userdata — a class that exposes no partitions is backed up through its demonstrated route (payload environment, preboot environment, full-storage image) with coverage recorded as it is:

• Userdata excluded: bulk, private — leave a DO-NOT-RESTORE note in the backup. Exclusion does not authorize its loss; before any operation that may wipe it, explain consequences + preservation options and obtain separate informed authorization.
• Device-unique partitions — back up, never publish. Modem NV/EFS, persist, calibration siblings carry IMEI, radio calibration, sensor trim; unreproducible; corruption leaves a phone that cannot register. Critical AND private.
• Private calibration stays in a protected runtime path. Validate provenance, length, integrity checks before use. Values must not enter source, DT, build inputs/outputs, arguments, logs or public reproductions (one audio integration kept them out of the build store and process args; a lens integration read them at runtime, not compiled in). Missing/invalid calibration blocks the operation — never borrow another handset's values or guess.
• Hash every image; record hashes beside the partition table. Only a hash answers "is the device still what I backed up."
• Verify restorable before the first risky flash, not after.
• Record what the backup route excludes by design, with counts and the size expectation. Unencrypted mobile-OS backups omit the credential store entirely and never include app binaries — a large-storage device yielding a few hundred megabytes and ~a thousand files is success, not truncation. A coverage record without the by-design exclusions gets a good backup re-diagnosed as failed.
• EDL is the fallback backup route when boot-based channels cannot read — prove the channel, don't assume it. A signed firehose programmer (OEM EDL package or custom-ROM bundle) grants raw storage; its rawprogram XML doubles as an independent partition-map cross-check. Programmers are per-variant; a mismatched one can configure cleanly and still not stream.
• Bulk dump loops abort at the first zero-byte or short read. A run whose partition-table read itself returned zero bytes still recorded ~50 void per-partition failures. Probe the smallest read (GPT) first; diagnose the loader/programmer instead of iterating a void list.

Research value of the backup:

• Stock board description — boot-image DTB, ACPI tables, or the DT carried inside the vendor kernel image, per boot-model class — board-specific configuration authority over a sibling SoC's dtsi once the variant/overlay is established; not proof of fitted silicon, physical wiring or measured voltages. Preserve conflicts until resolved.
• Firmware blobs + load order, vendor kernel cmdline + boot-image layout where the class has one (offsets, header version, args), exact kernel version string (uname -a / /proc/version — selects the right GPL OEM release in phase 2; vendors ship several, they differ), vendor configs (sensor/modem/HAL interfaces mainline must satisfy).

Check storage health before trusting device reports:

• Record the wear/lifetime report in phase 0 (UFS life-time %, eMMC health register). Storage is the classic misdiagnosis: I/O errors read as a dying drive; the wear % proved it healthy and one more stock-ROM flash cleared the fault. The % separates "hardware dying" from "software state bad" — opposite next steps.
• A media-failure verdict that would retire the device must survive re-probe in a later session: one flash region refused writes twice (cold power-off included), then passed 3/3 the next day against a full zero-error read scan. Absent wear fields = unknown; coarse values exclude nothing.

Inventory + harvest while the stock system is present:

• Inventory every component the stock system names — panel, touch, sensors, cameras, modem + RF config, WLAN/BT, charger + fuel gauge, audio — and compare against this variant's official spec sheets: find-docs for component docs, wigolo for web-found material (its cache matters across sessions); else plain web search. Sibling variants differ exactly here.
• Evidence level — declared / enumerated / driver-bound / exercised, no implied progression. A HAL name can reflect software ancestry, not silicon; installed firmware may cover unfitted components. One camera advertised 1080p30 in USB descriptors while Android exposed at most 1024×768 and 27 fps; no frames captured, so throughput was never measured.
• Readable retail beats a ROM image. On Android that is root: getprop, /proc/config.gz, mounted vendor/odm trees, HAL/sensor configs, calibration artefacts, factory field-test modes. Other retail OSes have their own readable surfaces — enumerate what this one exposes and harvest it through them. Privilege steps are the user's — no rooting or jailbreaking steps; resume when access exists.
• Record the newest community custom OS (on Android: custom ROM) as an optional development source: the most responsive OS ever run on one device was an unofficial recent-Android build, and its boot image shares the stock downstream lineage, so its DTB cross-checks the phase 0 extraction. A bundled EDL package also carries the signed programmer + rawprogram map.

Keep a persistent component–wiring–document inventory, seeded from stock, extended in phase 2, in the project's existing format. One research pack linked 134 component/subsystem records to 47 document records — not 134 fitted chips. Per component record:

Integrated functions are not separate packages; alternative populations are not extra fitted chips; a driver-family name need not equal the physical part (one controller shipped both 720×1280 and 720×1440 panel programs — the name alone did not select initialization). Keep unknowns unknown; an inventory is not permission to invent a BOM or blindly probe buses.

Working conventions. Resolve the device project root first. Multi-device reference layout (not a restructuring order):

kernel/<version>/     Clean upstream source + generic builder
soc/<vendor-soc>/     SoC-common patches, configuration, packages
os/<platform>/        Device-neutral OS integration and tools
devices/<model>/      Device assembly, patches, calibration, state

Shared bases never import device policy; device facts, private captures, per-device agent context stay with the device. Mark a shared kernel tree used for experiments as patched — never pristine upstream.

• Project layout. Everything large/private/device-derived lives under gitignored artifacts/ at the device project root: private/ (device-unique; partition backup first), firmware-harvest/ (blobs pending redaction), android/ (stock-ROM packages, rooted captures), debug-evidence/ (irreplaceable captures, preregistrations), reference/ (reading copies). Publishable firmware → sibling firmware-publishable/ repo with its own history, derived only after redacting device-unique identifiers. Device-local logs/: one subdir per boot/deploy + LATEST-* links. An artifacts/ README maps paths to class with hashes, acquisition, coverage — provenance, not a substitute for integrity checks.
• Publication hygiene runs at every boundary, not only upstream. Whatever leaves the project — an upstream payload, a published repo or install guide, a status report, an issue/PR/forum reply — is swept first for operator-supplied secrets (Wi-Fi SSIDs and passwords, accounts and app passwords, tokens) and device-unique identifiers (IMEI, serial and MAC addresses, board/asset ids, calibration values, private captures, local hostnames and addresses). Redact or generalize in the payload itself, then verify by scanning the exact bytes that leave the machine — a sweep run from memory misses the value it forgot.
• Prose holds no volatile numbers — the artifact does. Hand-copied hashes, counts and ratios drift the moment the next flash or run lands, and a stale hand-copied hash is worse than none: it reads as a mismatch and invites a pointless reflash (one project was bitten three times; one stale pair survived six sessions after being called out). Point at the authority — the verify tool, the ledger, the build file — and query it. The same goes for derived indexes: a convenience enumeration in prose that has gone stale is deleted rather than re-synced, because a wrong index is how a wrong patch gets quoted.
• Control channels. Before any flash, prove reachability through the target's available control/recovery tools + at least one post-boot channel into target Linux. adb, fastboot, USB-gadget Ethernet, serial/ACM, ssh are examples where supported, not individually mandatory. Record working channels, selectors, supported operations — a channel assumed but never tested is discovered missing mid-wedge. Provision missing host tools through the host OS's own package route — on declarative hosts via its shell/profile mechanism; on container/WSL setups, prove USB passthrough before a workflow depends on it. Missing a tool does not waive operation-level proof or recovery prerequisites.
• Bind every operation to the target. Record handset↔transport mapping; select the transport explicitly per command; re-establish after re-enumeration; verify product + slot immediately before writes. A second connected phone must never become an implicit target. The binding constrains the host too: a probe must never mutate host network config — one absent gadget MAC made a control script rewrite an unrelated USB Ethernet dock's IP settings. Inspect interface identity + route first; refuse ambiguous matches; host network setup is a separate explicit command on an owned, uniquely verified interface.
• Prove the operation, not just the connection. Record whether required operations are actually supported before building around them: one unlocked bootloader supported neither RAM boot nor partition fetch, stranding a built rescue image. Deeper: a firehose that connects, configures and advertises the full read set still truncated every streamed read to 16 bytes of a 17,408-byte request — stock tool and two custom drivers alike. Advertised commands ≠ working data path; self-test-read a known-content region and verify bytes before scripting bulk transfer.
• Note which recovery path is known to work.

Write into the project's agent context files: all work touching this device goes through this ruleset; no device action outside it. Existing backup? Confirm coverage + hashes still verify.

Keep the retail OS bootable for data gathering (Android in the founding port; same principle wherever the class retains one). Read a working vendor driver's probe/firmware sequence live next to a mainline failure; exercise hardware mainline cannot yet drive. Never conclude mainline behaviour from retail-OS behaviour without a cross-check.

1. Gather evidence from the live device first

Capture the failing run's full dmesg before changing anything. Enable debug knobs before reproducing — a second reproduction costs another boot. Keep them relevant and understood: do not arm unassessed probes indiscriminately, and never increase physical stress to compensate for unverified protection telemetry.

Evidence interpretation is kernel work: invoke linux-kernel-development if installed, else linux-kernel-crash-debug, else a subsystem kernel skill; else reason from sources + Documentation/. Do not stall.

Acquisition and claim boundaries

Per artifact record: origin, exact revision/build, acquisition method, coverage, access failures, integrity hashes. A running sysfs DT may include runtime fixups — not an untouched boot-image DTB (one capture: 2,740 property files preserved, 2,222 verified byte-identical, 518 redundant names accounted; all 2,839 manifest files passed — still not a restorable backup). A firmware path inventory does not establish load order.

Photographic identification: bind each observation to a named image/page/crop AND the photographed sample — not output order, not the target handset by assumption. One parallel-image association and one presumed manufacturer marking were withdrawn after original-byte inspection. Preserve uncertain transcriptions; public regional samples do not prove this handset's population.

Carry phase 0 evidence labels into findings. Record running vs deployed identities separately; service readiness ≠ end-to-end behaviour. Registered sound card + silent playback ≠ acoustic qualification; mark untested checks untested.

Evidence channels, roughly by reliability

• Live shell (network/USB) — cheapest; anything the device survives.
• Bootable retail OS (Android where retained) — boot deliberately when a question is best answered there; cross-check before transferring conclusions.
• pstore. Identify the active crash-record collector, its config and archive destination. Inspect the mounted kernel interface (/sys/fs/pstore/ where used) and any collector archive — when systemd-pstore.service has collected records its configured archive must be harvested too (one system moved everything to /var/lib/systemd/pstore/ early in boot). Merely running systemd proves nothing about collection; an empty kernel directory alone proves no absence of a crash. Console region is usually a single slot — copy to host first or the next crash overwrites it.
• ramoops. Lossy: DRAM charge retention decays unpowered — measured ~6.5 % of bits on one device, enough to fail ECC on zone headers and lose records — and warm reboots rot it too (tens of blocks). Decay follows the power cycle. Grep fuzzily. Let a wedged device log while the console zone holds, then power-cycle and back promptly; a 4 MiB zone absorbs hours of watchdog spam first — check zone size.
• Kernel ACM console (CONFIG_U_SERIAL_CONSOLE=y + console=ttyGS0) — the only channel that survives a wedge, but verify it survives the reporting context: payload is emitted inside panic() with IRQs off and other CPUs stopped; a workqueue-deferred console never prints. Test free with a crash injector (LKDTM /sys/kernel/debug/provoke-crash/DIRECT where present): synthetic lockup, exact geometry, no flash. A userspace getty yields zero bytes while still enumerating. Both config halves required.
• On compositor targets the screen is an evidence channel. A screenshot pulled over the demonstrated channel returned the live UI state in seconds, and a loopback VNC server reached through the existing ssh tunnel added touch/keyboard injection — no new network exposure. Read the panel instead of inferring UI state from logs; the UI is part of the runtime surface.

Rules that turn inference into measurement

• Confirm what is flashed by reading back — never notes or build logs. iflag=direct so the read doesn't perturb. Size-only comparisons prove nothing (boot images are padded). Hash the payload. But validate the readback method itself once against known content: on one host kernel iflag=direct against USB storage returned a deterministic wrong buffer for any freshly written image — the hazard that would have condemned good media. Verify install media cross-method (drop caches, buffered cmp device-vs-image, plus a hash of a file read back through a mount), and condemn hardware only on physical evidence — mid-write bus dropout, re-enumeration as a different identity-less device, disagreement across independent reads — never on a hash mismatch alone.
• Reading a debug interface can manufacture the symptom. Sampling DRM/GPU crash-state nodes during active submission synthesised fault/recovery lines that never occurred (five reads, five fault/recover pairs; none unobserved). Check whether your own observation produced the log line.
• Validate stimulus + observation path before interpreting silence. Confirm the actual register protocol, effective post-init state, physical receiver route and required clocks throughout sampling. The claim that unchanged camera TX-on/off status bytes proved a static bank is withdrawn: the TX-off control used the wrong protocol, stream startup rewrote the setting, and earlier silence measurements targeted the wrong PHY. Unchanged bytes prove neither latch nor transmitter failure; a sensor/top-level runtime reference does not retain per-PHY clocks through teardown.
• Capture a rejection's raw response before interpreting the mapped errno. A firmware EINVAL was ambiguous — wrong encoding or refused policy — until dynamic debug exposed well-formed words carrying explicit refusal. Opposite verdicts, opposite next steps. Classify every rejection: encoding / policy / not-found. Mirror: a clean negative is positive proof — a not-found from a correct lookup validates the encoding and kills a plan branch without touching the loader.
• A measurement racing an uncontrolled condition returns a plausible void number. One benchmark scored 55 in two seconds — the compositor held DRM master, every scene failed. The valid 132 → 485 comparison needed the compositor stopped for both runs. Name the voiding condition; verify it held every run.
• Control ownership through the whole measurement. One camera reopen failed EPIPE after another client changed the media graph; configure + capture under the clients' compatible lock passed a 90-frame burst without stopping audio. Establish which clients cooperate. For power cleanup, identify open owners before calling an active supply a leak: last-owner close/open/close measured votes 0→1→0; a restored camera monitor legitimately reopened the device.
• Measure controls on linear data, not enhanced previews. Fixed region + processing scale, account for black level and clipping, bracket with baselines for scene drift. Exposure doubling measured 1.990×/1.995× signal; 2×/4× gain 1.984×/3.957×; baseline drift <0.23%. Accepted writes and auto-contrasted images are not proof. Physical-unit calibration, per-frame delay, autofocus, color remain separate qualifications.
• Prove protection before increasing stress. Enable bits + successful init ≠ limiter intervention. Establish telemetry identity, units, update behavior, failure handling before using it to justify higher output. All five retained candidate temperature values in one investigation were zero; the OEM getter ignored the return code. Never heat/drive harder to compensate for missing observability. Keep output restricted when protection is unverified — one speaker path muted output and revoked access on provisioning loss rather than falling back unprotected. A read-only debug interface is not automatically harmless: an observer-enabled boot locked up, causation unresolved.
• Classify one-direction-dead USB networking by counters, not symptoms. Gadget still enumerated + host ARP failing is ambiguous: ping from the host while reading the device's interface TX/RX counters over a surviving channel — counters rising only inbound proved the device could receive but not transmit. Check the rootfs first, too: a read-only remount after a failed resume kills sshd and networking with identical outward silence.
• A host-side USB id proves neither the running OS nor a failed boot. One enumerated vendor id plus dead ssh was repeatedly logged as an "Android fallback" while the target OS was up and responsive; host-visible signals establish channel state only. Obtain OS identity through a working channel; until then record a channel failure, not a boot verdict.
• A session or compositor swap re-opens its layer's defaults. The previous session claimed the power key (screen lock); the new one claimed nothing, so the logind stock handler turned one short press into a clean shutdown — journal -b -1 shows the keypress, pstore stays empty: a shutdown masquerading as a crash. Config-variable errors can render as a near-invisible error banner instead of the UI, and autostarted input methods fail silently. After a session change verify: config loads clean (reload success), key/suspend handlers claimed, autostarts actually running, scale/orientation/idle behavior intact.
• Record rules you withdraw. Folklore goes stale with hardware revisions. Keep the overturned version next to the current one with what changed.
• Attribute arch-only crashes by running the same pinned revision on the other architecture. Same closure/revision crashing on x86_64 ⇒ upstream or packaging (miscompile class); running clean past the faulting constructor ⇒ port/display-stack specific. Strip variables before layer fixes: confirm the fault reproduces with no display stack (minimal platform), decode the core from its thread + file notes (a null vtable disassembly names the layer). Three single-layer fixes were refuted on one crash before the cross-arch run pointed at the build.
• Decompose the compositing tax before any "GPU is slow" conclusion. Matched-scene ladder, cheapest first: raw EGL surface → direct KMS (compositor stopped; the DRM-master voiding condition named and verified every run) → composited session. Check compositor CPU% to rule out starvation, A/B compositors, and verify direct-scanout engagement mechanically — compositor CPU time frozen while exactly one KMS plane is bound (it engages only for a single opaque fullscreen client with chrome hidden on some stacks). Perceived smoothness can be frame pacing, not throughput.
• Long multi-session hunts need infrastructure, not memory. Commit the smallest deterministic reproducer as a tool with a measured pass count; reconcile the incident-numbering ledger before comparing counts across sessions; pre-register predictions per experiment batch; and read back what the instrument actually received before trusting a control — one post-fix run whose gate parameter was silently dropped produced a withdrawn row (the printed received-range exposed it) and a corrected rerun reversed the conclusion. A sha256-pinned evidence manifest plus an offline replay tool that re-derives recorded metrics from the private captures closes the loop: drift is fatal, conflicts are the output.

Host-side gotchas

• timeout N ssh kills the local client only; the remote process keeps running — kill it explicitly.
• pgrep -f/pkill -f over that ssh path self-match their own remote shell — filter the matcher or match by PID.
• find needs -L when the start path is a symlink, or it returns silently empty.
• Any wrapper that rewrites output — token filters, pagers, formatters — corrupts evidence, sometimes inverting a test. Use the raw command for findings.
• A detached recovery unit (systemd-run) runs with a minimal PATH: one script's sleeps silently no-opped, it raced its own readiness check, and its reboot safety net fired on a false negative — destroying the state it existed to diagnose. Absolute paths; every step logged with timestamps; a destructive fallback gated on preconditions verified inside the same script.
• Verification harnesses: a missing answer is a FAIL, never a silent pass. Empty output, timeout or transport failure on a required probe = FAIL (or an explicitly modeled skip); exit nonzero when required evidence is missing; capture the producer's exit status before filtering (failed log acquisition is not a clean zero-match); set pipefail so a pipeline with a failing producer fails; bound cleanup so it preserves the original failure classification and reports its own uncertainty separately. Never kill by process-name pattern — a matcher can self-match or catch an unrelated process.

Operator hands are a step, not an assumption

• Authorization is scoped; pauses are binding. Record the permitted action, target, limits, pause/resume prerequisite. Inspect ≠ restart-service ≠ capture ≠ actuate ≠ reboot. A paused experiment stays paused until its prerequisite is satisfied and required operator authorization confirmed; only explicitly permitted remaining work may continue. Reachable transport and an unlimited iteration budget do not expand permission (one lens session allowed same-position lifecycle checks while optical movement stayed deferred). A higher-output exception expires with its named test, not tomorrow's default.
• Physical actions: name the exact action + direction, then verify via an observable signal — appearance (mount, re-enum, slot change) or disappearance (power-off, USB drop, silence). Disappearance is ambiguous: watch the drop as an event, or require done-confirmation + verified post-absence probe failure. Poll briefly; no signal within a bound ⇒ re-ask.
• Total channel loss after suspend/resume has three branches, not two. Host-side, live-phone-w

…(truncated)