Resuscitation
v2.2.0.125

• Device codename: hammerhead, vendor lg.
• Target OS: postmarketOS, edge channel (see the scope decision's OS-choice rationale).
• Goal for this device: a headless/telemetry node, not a phone UI — so a minimal or no graphical user interface is preferred over a full desktop session.

• A Linux host machine (physical or VM) to run pmbootstrap; native Windows and WSL are both reported as troublesome for this step, a plain Linux install is the reliable option.
• A USB cable and adb~/~fastboot on the host.
• The device fully backed up: unlocking the bootloader wipes all data.

1. On the device, enable Developer Options, then enable "USB debugging". Look for "OEM unlocking" too, but do not treat its absence as a blocker: on a real unit (Android 6.0.1, checked in both French and English) this toggle does not appear at all. This matches other Nexus 5 owners' reports for Android 6 — the device predates the newer bootloader-security model that hard-gates fastboot behind that toggle on later devices (5X, 6P); on the Nexus 5's older bootloader either the toggle doesn't apply or doesn't render, but it does not block the unlock command below.
2. Reboot to the bootloader (power off, then hold Volume Down and press Power), connect the USB cable, and on the host run: fastboot oem unlock — the old-style command; the Nexus 5 does not use the newer fastboot flashing unlock syntax some later devices require. fastboot's own help text may not even list oem unlock as recognised; run it anyway. Confirm the prompt on the device itself using the volume buttons to choose and the power button to select.
3. Behaviour after confirming the unlock varies by unit: the postmarketOS wiki describes the device returning automatically to the Fastboot Mode screen, but a real unit has instead rebooted into Android's setup wizard (userdata was wiped, so Android treats it as factory-fresh, which resets Developer Options and its toggles with it). Either outcome is fine and needs no special handling: the bootloader-unlock state is a firmware-level flag that persists independently of anything on the Android/userdata side, and every remaining step below is a plain fastboot command — fastboot mode does not depend on Developer Options or USB debugging at all (that setting only gates adb access from a running Android OS). There is no need to complete the setup wizard or re-enable Developer Options/USB debugging: just power off and re-enter the bootloader (Volume Down + Power) and continue directly with the next step.
4. On the host, install pmbootstrap and run pmbootstrap init, selecting vendor lg, device codename hammerhead, the edge channel, and the console UI (headless, no graphical environment) rather than a full desktop, per the telemetry-node goal above. When asked about using systemd as the init system: answer never (i.e. use OpenRC). systemd stalls at first boot on this device; every actual working reference found for this device used OpenRC, and postmarketOS's own current status shows systemd support as recent (merged into edge January 2025) with an acknowledged, still-being-reworked USB-gadget-handling story on mainline devices — see ResearchJournal.org for the full reasoning. Not yet re-verified with OpenRC; correct this note again once it is.
5. Run pmbootstrap install with no flag (current pmbootstrap has no --no-fde flag: no full-disk encryption is now the default behaviour, flipped from an earlier opt-out model to an opt-in one — add --fde only if full-disk encryption is actually wanted). This is the step that builds the rootfs/ kernel images in a local chroot on the host — it downloads packages, and interactively prompts to set a login password for the account named during init. Nothing exists to flash before this step runs.
6. With the device back in fastboot mode, run the flasher commands in the order pmbootstrap install itself prints at the end of its own output ("FLASHING INFORMATION" block) for the current build. On the version used here, that order is: pmbootstrap flasher flash_lk2nd first (pmbootstrap's own message: "Your device supports and may even require flashing lk2nd. You should flash it before flashing anything else."), then pmbootstrap flasher flash_rootfs, then pmbootstrap flasher flash_kernel. This resolves the earlier discrepancy noted in ResearchJournal.org: an older install transcript for this device didn't surface the lk2nd message at all, but the current tool version does, confirming the postmarketOS wiki's original claim. lk2nd boots the kernel from the rootfs's own /boot, not from a separately-flashed boot partition — do not flash the boot partition directly.
7. Reboot. SSH is enabled by default: once booted, log in as the username chosen during pmbootstrap init with the password set during install, over the USB network interface pmOS brings up (ssh <user>@172.16.42.1 is the standard address for this).

Device-specific quirk to check during step 4: hammerhead shipped in two variants with different DDR vendors (Elpida and another); if flashing fails with an "Unknown chunk type" error, the bootloader itself likely needs updating first to a current factory image before retrying.

Confirmed against a real unit, on the fresh system used to reach the milestone above.

ip a                          # find the interface (e.g. enx<mac>);
                               # no "inet" line means no IP yet
sudo dhclient enx<mac>         # try this first

sudo ip addr add 172.16.42.2/24 dev enx<mac>

sudo apk update              # refresh the package index
sudo apk add <package>       # install
sudo apk search <name>       # search

Full method and physical-test evidence in ResearchJournal.org's "Sensor inventory complete" entry; this is the reference summary for whoever builds the MQTT publisher next.

Working (all under /sys/bus/iio/devices/ unless noted):

• iio:device0 (apds9930) — ambient light (in_illuminance0_input) + proximity (in_proximity0_raw).
• iio:device1 (mpu6515) — accelerometer (in_accel_{x,y,z}_raw) + gyroscope (in_anglvel_{x,y,z}_raw).
• iio:device4 (bmp280) — barometric pressure (in_pressure_raw~/~_scale) + temperature (in_temp_raw~/~_scale).
• iio:device5 (unnamed, AK8963-class) — magnetometer (in_magn_{x,y,z}_raw).
• iio:device2~/~iio:device3 (PM8941 PMIC ADC channels) — exist, but are read-only power-management measurement channels (voltage/temperature-type telemetry for the PMIC's own internal use), not user sensors and not a power-control mechanism — ADC means Analog-to-Digital Converter, a reading-only capability, not an actuation path. Not telemetry candidates. (See FutureResearch.org's external-power item for the actual question this was raised alongside: a genuine software power-control path, if one exists on this PMIC, would be a different mechanism entirely and hasn't been looked for.)

Not working, with reasons (not just absence):

• GPS/GNSS: no /dev/gnss*, no /dev/modem, no modem/QMI/rpmsg activity in dmesg at all. Matches a known postmarketOS bug ("lg-hammerhead: modem not working" — the modem crashes during ofono initialization); GPS runs through this same modem's QMI Location Interface on Qualcomm platforms, so this is a real software-stack limitation for this device, not a separate GPS-chip fault.
• Camera: no /dev/video* at all. Not investigated further — Qualcomm camera ISPs are historically hard to mainline, an unimplemented camera on a community port is unsurprising, and it's outside Concept.org's actual goal (sensor telemetry, not imaging).
• On-device audio playback/recording: not implemented (documented upstream, not separately re-tested here); a Bluetooth audio device is the known workaround. Irrelevant to the telemetry goal.

Full investigation and reasoning in ResearchJournal.org's corresponding entry; this is the reference summary.

Poweroff does not work — poweroff, poweroff -f, and reboot are all indistinguishable: every one of them just cycles the device back into the OS. Investigated rather than assumed: ruled out a watchdog-timeout bug (no watchdog driver active at all), ruled out a missing lk2nd boot-menu timeout (/boot/extlinux/extlinux.conf is already correctly configured), and found no restart/poweroff driver activity anywhere in dmesg. Cross-checked against masneyb/nexus-5-upstream's own exhaustive, patch-by-patch account of every component mainlined for this device: it documents dozens of fixes down to minor bugs, and contains zero mentions of poweroff/restart/~pshold~ anywhere. Conclusion: proper poweroff was most likely never implemented for this device's mainline port at all, not a bug to hunt down — a pattern also seen on several other community-mainlined phones (Redmi 2, Samsung Galaxy S3 mini, Nokia N900, Motorola Droid 4). Not being pursued as a fix: real kernel development work, outside this project's scope. The only reliable way to actually cut power is physical: Volume-Down+Power into the bootloader, then select "Power off" there.

Powering back on from a genuine cold poweroff needs "Start" selected manually in the bootloader — the power button alone does not resume it, even though extlinux.conf's own timeout~/ ~default are correctly set. Plausible (not confirmed) explanation: this may be intentional lk2nd behaviour distinguishing a true cold power-on from a warm OS-triggered restart, rather than a bug.

Neither of these blocks testing dudhya-sensord — that only needs the phone booted and reachable, not powered off. Worth revisiting for an eventual vehicle deployment, where the better design may be surviving abrupt ignition-cut power (robust filesystem, maybe a small buffer capacitor) rather than relying on a graceful shutdown command at all.

The phone hosts its own MQTT broker (see ResearchJournal.org for the design rationale) and publishes its confirmed-working sensors to it, as the first step toward being a self-contained network hub for in-vehicle deployment. Source: dudhya-sensord.c. Confirmed running on the physical unit itself (see "Open items" below).

mosquitto_pub -h localhost -t 'dudhya/nexus5/status/get' -m ''
mosquitto_sub -h localhost -t 'dudhya/nexus5/status' -C 1

make dist

scp dudhya-VERSION.tar.gz <user>@172.16.42.1:~/

tar xzf dudhya-VERSION.tar.gz
cd dudhya-*/

sudo apk add build-base autoconf automake mosquitto-dev

sudo apk add mosquitto

sudo rc-update add mosquitto default
sudo rc-service mosquitto start

./bootstrap
./configure
make
sudo mkdir -p /etc/dudhya
sudo cp sensord.conf.example /etc/dudhya/sensord.conf
# edit /etc/dudhya/sensord.conf if the defaults (device_name=nexus5,
# rate_hz=1.0, broker_host=localhost, broker_port=1883) need changing

sudo ./dudhya-sensord --calibrate-accel /etc/dudhya/sensord.conf

sudo cp dudhya-sensord /usr/local/bin/
sudo cp dudhya-sensord.openrc /etc/init.d/dudhya-sensord
sudo chmod +x /etc/init.d/dudhya-sensord
sudo rc-update add dudhya-sensord default
sudo rc-service dudhya-sensord start

mosquitto_sub -h localhost -t 'dudhya/#' -v

Switches between station and access-point mode, not concurrent operation — concurrent use would need checking this chip/driver's actual supported interface combinations (a separate question from the plain mode-capability check already done via iw list), and switching covers the project's actual need without that extra verification step. Not yet run against the physical unit — see "Open items" below.

sudo apk add hostapd hostapd-openrc dnsmasq wpa_supplicant wpa_supplicant-openrc

sudo dudhya-wifi-mode station
sudo dudhya-wifi-mode ap

Automates the manual steps in "Post-boot: internet access and package management" above and their WiFi-radio equivalent, as a matched pair of scripts — one for the host, one for the device — covering both connection types dudhya devices support. cable mode confirmed working against the physical unit — see below. radio mode's own interface-detection logic is also confirmed correct, but an actual package operation over radio stalls whenever the device's own AP is active — see the WiFi section's own "Open items" for this same, accepted driver- level limitation, not a Provisioning-script bug.

sudo dudhya-host-connect cable
sudo dudhya-host-connect radio

sudo dudhya-device-update cable
sudo dudhya-device-update radio
sudo dudhya-device-update cable mosquitto-dev build-base

Two existing projects on this exact device are worth following rather than re-deriving from scratch:

• in github masneyb/nexus-5-upstream project — the upstream mainline-kernel port this procedure relies on; demonstrates display, GPU, and sensors working under a full desktop session.
• in github Bry50/Old-Smartphone-as-a-server project — a Nexus 5 running postmarketOS repurposed as a Docker/Home Assistant host, i.e. close to dudhya's own "embedded system, source of telemetry" goal already, and the source of the install-command sequence above.

Google Pixel 3a, codename google-sargo, Snapdragon 670 (SDM670). postmarketOS "community" tier. Smallest and lightest of every candidate researched (151.3 x 70.1 x 8.2mm, 147g) — an advantage if mounting space in the eventual vehicle deployment is tight.

Not yet verified on the actual unit — do not assume this matches the Nexus 5's own experience, which had no "OEM unlocking" toggle at all and needed a direct fastboot oem unlock. Google's own Pixel line is generally documented as simpler: enable Developer Options, toggle "OEM unlocking" there, then fastboot flashing unlock (note: flashing unlock, not oem unlock — a different subcommand on Pixel devices per Google's own documentation). Confirm this directly on the actual device before relying on it — the Nexus 5's own procedure taught this project not to trust unlock documentation until physically checked.

pmbootstrap init      # select google-sargo when prompted
pmbootstrap install
pmbootstrap flasher flash_kernel
pmbootstrap flasher flash_rootfs

Matches the general postmarketOS install pattern already confirmed working for the Nexus 5, substituting the device codename — the exact flashing sequence for Pixel devices (fastboot-based, similar in spirit to hammerhead's own lk2nd/ fastboot flow) needs confirming hands-on rather than assumed identical.

• GPS needs manual intervention on every boot, no A-GPS: "the engine lock prevents the device from getting a useful position and the modem only outputs proprietary GPS NMEA messages," requiring

  qmicli -d qrtr://0 --loc-set-engine-lock=mt
  qmicli -d qrtr://0 --loc-set-nmea-types=all
  

  re-applied every boot (see the second-device annex for the full source). Without A-GPS, cold-start first fix is slow — plan for this, don't assume quick GPS lock during testing.

• ADSP can hang on resume from suspend: FastRPC continuing across suspend crashes the ADSP; a pre-suspend hook stopping FastRPC via elogind is the documented fix (pmaports #3052). If this device is ever suspended (not just powered down) as part of the eventual deployment, confirm this hook is in place.
• WiFi 5GHz reported not working in Europe (pmaports #3134) — directly relevant given this project's own location; test both bands rather than assume 5GHz works.
• CPU thermal throttling and an unsupported Titan M/secure element are also noted in prior research — lower priority for this project's headless telemetry use case, but worth knowing about.

Expected via the merged sensor-support framework (MR !5329, ADSP- based rather than SLPI — SDM670 shares the ADSP for sensors rather than having a dedicated SLPI, per the second-device annex). To confirm once running, matching the same physical-test rigor already applied to the Nexus 5 (real values, not just "device enumerated"):

Sensor	Expected	Confirmed
Accelerometer	yes	not yet
Gyroscope	yes	not yet
Magnetometer	yes	not yet
Light	yes	not yet
Proximity	yes	not yet
Barometer	unknown	not yet
GPS/GNSS	yes, with the manual steps above	not yet

See FutureResearch.org's "Power a candidate device without its battery" item for the general framework this fits into.

Confirmed, device-specific procedure found: three sources (two YouTube videos plus an Instructables writeup) are all the same author, SquareOrbits, and — a genuine stroke of luck — their own demo device is a Pixel 3a, not a different phone needing adaptation (Instructables, "Power a Phone Without a Battery" — see ResearchJournal.org).

Approach, and why it's better-suited to this device than the generic technique below: rather than build a "fake battery" from discrete parts, this method keeps the phone's own original battery protection board and only replaces the cell:

1. Disassemble the phone (the source used iFixit's own Pixel 3a guide) and remove the battery.
2. The battery has two parts — a bare cell, and "a long, thin circuit board that protects and monitors it." Desolder the board from the cell and discard the cell. The board alone "expects to see a voltage roughly between 3V to 4.2V depending on the state of charge" — feed it that range directly and the phone boots normally. This sidesteps needing to separately emulate a thermistor reading from scratch (the general technique below does need that) — the retained board already handles whatever sensing the phone's own PMIC expects.
3. Power source: a USB-C Power Delivery trigger module set to request 9V, feeding an XL4015 buck converter adjusted to output 4-4.2V, connected to the retained board's (+)/(-) tags (polarity matters).
4. Critical, empirically confirmed step: run a separate wire from the board's negative (-) tag to the phone's own chassis ground (e.g. under the USB-C port's mounting screw). The source states plainly: "Without this the phone may not boot."
5. Reassemble, connect a PD-capable power bank/charger — boots normally.

BOM coherence, checked as requested: all four listed parts are real, well-matched, and appropriately rated for this specific purpose — the XL4015 is a genuine, common buck-converter IC (input up to ~36V, several amps output, comfortably handles 9V-to- ~4.2V at phone-level currents); a USB-C PD trigger module is the correct way to get a stable voltage above 5V for the buck converter to regulate down from with good margin; a PD-capable power source is the necessary counterpart. No mismatched or inappropriate parts found.

Discrete-component KiCad schematic: see dudhya-pixel3a-battery-free-power.kicad_sch (plus its matching dudhya-pixel3a-battery-free-power.kicad_pro project file), regenerated via make kicad-regen (see the project's own README for build prerequisites, including packpay). Builds the equivalent of the trigger-module + buck-converter pair from real, individually sourced parts rather than pre-made boards: an STUSB4500 (ST's own dedicated, autonomous USB-PD sink controller IC, configured to request a fixed 9V with no microcontroller needed at runtime) driving a P-MOS power-path switch, feeding an XL4015-based buck converter matching the source's own design, plus a reverse-current protection diode (D2) on the output. Every symbol is copied verbatim from KiCad's own bundled libraries, and the STUSB4500 portion follows ST's own official "minimum implementation, fixed PDO, no MCU" reference circuit from its own datasheet. Primary sources: STMicroelectronics, STUSB4500 product page; STUSB4500 datasheet, DS12499 Rev 8 (the "minimum implementation, fixed PDO, no MCU" reference circuit and the pin table's own "typical connection" column, both used directly below); STL6P3LLH6 product page and STL6P3LLH6 datasheet, DS9257 Rev 4 (the P-MOS power-path switch, also part of ST's own reference design — 30V/6A/24mOhm typ., comfortably rated for this application).

The schematic is electrically verified: zero ERC errors, all real components carry a genuine, researched footprint (not a placeholder), and every component's own position is decided algorithmically from the real netlist rather than hand-placed (see DevelopmentStandard.org for how this generation pipeline works). The previous, hand-placed version of this same circuit is kept for reference at dudhya-pixel3a-battery-free-power-handplaced.kicad_sch (make kicad-handplaced-regen) and remains the real netlist source the promoted generator itself reads from.

Reverse-current protection on the output, per the source's own follow-up video: a diode on the buck converter's output ensures the phone cannot back-feed current into the buck converter, relevant if something else is later plugged into the phone and its own charging circuitry tries to draw or push current the other way. Practical consequence worth flagging: a series diode drops some voltage (a Schottky, as used here, drops less than a standard silicon diode — roughly 0.3-0.4V rather than 0.6-0.7V), so the output trimmer must be tuned by measuring voltage at the phone's own connector, after D2 — not at the buck converter's raw output pin — or the phone ends up slightly under-fed.

Breadboard-style companion diagram: a second, connectivity- focused rendering of this same circuit, styled to read like a breadboard rather than a formal schematic. Explicitly a visualization aid, not a literal build guide (the STUSB4500 and XL4015 above are not themselves breadboard-native packages). Generated by build_pixel3a_breadboard_autolayout.py (make breadboard-verify) — every component's own position and every wire derived directly from the real, loaded netlist, not hand-placed. A previous, hand-placed version remains available, unchanged, as build_pixel3a_breadboard.py (make breadboard-handplaced-verify) for reference and comparison.

Top pick: Xiaomi Poco F1 (xiaomi-beryllium, 2018). Best- balanced choice: GPS/GNSS works under postmarketOS (via ModemManager + Geoclue, documented to work even without a SIM), the full sensor suite works through the merged SDM845 Snapdragon Sensor Core framework, it sits in postmarketOS's "community" tier (the highest tier with any real population — "main" is currently essentially empty outside QEMU targets), and it is the cheapest serious candidate (~$90-160 used).

Alternates: OnePlus 6 (oneplus-enchilada, 2018) — near- identical SDM845 hardware and sensor support, but GPS reliably works only if OxygenOS 9.0.8 is flashed first; and Google Pixel 3a (google-sargo, 2019) — sensors and GPS both work, but GPS needs a qmicli engine-lock reset re-applied on every boot and has no A-GPS, making first fix slow and headless operation more fragile.

Not recommended for this project: Fairphone 4 (GPS only partially confirmed under postmarketOS, mobile data broken, newer/pricier), Samsung Galaxy S9 "starlte" (the community-tier port is the Exynos variant, with broken WiFi/Bluetooth), and Nokia N900 (GPS confirmed working, but 2009 hardware — 600MHz single- core, 256MB RAM, no gyroscope/magnetometer/barometer — is too weak for this project's actual sensor-telemetry workload).

Extended criteria (dimensions/weight, battery-free operation feasibility, cybersecurity/blob posture; see the three new sections below and ResearchJournal.org for the full reasoning): the Poco F1 still holds up as the top pick overall. But one real, newly-surfaced nuance changes the practical plan: the OnePlus 6/6T are the only candidates with a documented, reproducible method for booting without a battery at all (their pack carries its own smart-battery fuel-gauge chip, which the Poco F1's pack does not). Given the project's own separate, already-planned interest in battery-free operation (see "Powering the device without its battery" in FutureResearch.org), the practical plan is now: Poco F1 for the production node, OnePlus 6 or 6T as a dedicated battery-free R&D unit to prototype and de-risk that work before attempting it on the Poco F1 itself, where it remains unproven rather than confirmed infeasible.

Rank	Device	Codename	Tier	GPS under pmOS	Price
1	Xiaomi Poco F1	xiaomi-beryllium	community	Works	~$90-160
2	OnePlus 6	oneplus-enchilada	community	Works (a)	~$120-170
3	Google Pixel 3a	google-sargo	community	Works (b)	~$90-150
4	OnePlus 6T	oneplus-fajita	community	Works (a)	~$120-180
5	Fairphone 4	fairphone-fp4	community	Unconfirmed	~$200+
	Samsung Galaxy S9	samsung-starlte	community	Unconfirmed	~$90-140
	Nokia N900	nokia-n900	community	Works (c)	~$60-150

(a) needs a specific OxygenOS version pre-flashed first, see below. (b) needs a qmicli reset re-applied every boot, no A-GPS, see below. (c) works, but the 2009 hardware lacks a gyroscope, magnetometer, and barometer — see below. Sensor completeness for every device is covered in the per-device findings that follow, not repeated here to keep this table scannable.

For in-vehicle mounting planning. Source: manufacturer specs and GSMArena.

Device	Codename	H x W x D (mm)	Weight
Xiaomi Poco F1	xiaomi-beryllium	155.5 x 75.3 x 8.8	182 g
OnePlus 6	oneplus-enchilada	155.7 x 75.4 x 7.75	177 g
OnePlus 6T	oneplus-fajita	157.5 x 74.8 x 8.2	185 g
Google Pixel 3a	google-sargo	151.3 x 70.1 x 8.2	147 g
Fairphone 4	fairphone-fp4	162 x 75.5 x 10.5	225 g
Samsung Galaxy S9	samsung-starlte	147.7 x 68.7 x 8.5	163 g
Nokia N900	nokia-n900	110.9 x 59.8 x 18	181 g

The top three candidates cluster tightly (~156-158mm tall, 177-185g) — size/weight doesn't meaningfully distinguish between them. The Pixel 3a is notably smaller and lighter (147g), an advantage if mounting space is tight. The Fairphone 4 is the heaviest and thickest (225g, 10.5mm) — the cost of its user-serviceable design. The N900 is short but unusually thick (18mm+) because of its slide-out keyboard, an awkward shape for flat mounting — moot, since it's already ruled out on other grounds.

Device-specific characteristics only — the general method, procedure, tools, and bill of materials for battery elimination itself is a separate, not-yet-started research item (see FutureResearch.org, "Power the device without its battery").

The deciding factor is where the fuel-gauge chip lives:

• OnePlus 6 and 6T: the battery pack itself carries a TI BQ27411 fuel gauge, communicating with the phone over I2C on the battery flex — confirmed by the actual postmarketOS upstreaming patch enabling it (Caleb Connolly, "arm64: dts: qcom: sdm845-oneplus-*: add fuel gauge"). This on-pack "smart battery" design is why a documented batteryless-boot method exists for the 6T: reuse the pack's own BMS board plus a MUR460 diode to spoof battery presence, a technique credited to the GreatScott! YouTube channel and documented working under postmarketOS specifically (Kédio Blog, "Running a OnePlus 6T without battery [Smartphone Revival Project]"). This is the single best-documented batteryless-boot case found across every candidate.
• Poco F1 and Pixel 3a: the fuel gauge is integrated into the mainboard PMIC instead (kernel patch series, "Qualcomm 3rd gen fuel gauge support", confirming this specifically for both sdm845-xiaomi-beryllium and sdm670-google-sargo), and their packs are conventional cell + protection + NTC thermistor with no data line. Likely feasible (a real battery voltage plus a correctly-valued NTC resistor should satisfy the PMIC) but unproven — no published bench-supply boot was found for either. A real Poco F1 user report of a unit with a faulty battery "bootloop[ing] unless charger[/USB] plugged in" (XDA Forums, "[FIXED] POCO F1 stuck in bootloop unless charger connected / plugged in") is evidence it can run on external power but is unstable without a valid battery/gauge reading present.
• Fairphone 4 and Nokia N900: both have user-removable packs (easiest mechanical access, no soldering/adhesive to fight), but neither has a documented postmarketOS batteryless-boot procedure. A removable pack still has protection/NTC (and, on the N900, a BSI/ID resistor) that a dummy source must satisfy.
• Samsung Galaxy S9: pack is glued in place (least accessible mechanically); no batteryless-boot documentation found.

Cross-cutting principle, from general charger-IC behaviour rather than a device-specific source: disconnecting the battery also disconnects the NTC thermistor, which reads as out-of-range and can block boot or charging unless the temperature-sense input is either spoofed with a resistor or the relevant safety check is bypassed — this is why a naive "just apply DC power" approach doesn't reliably work, and why the OnePlus 6T's published recipe specifically routes through the pack's own BMS rather than wiring straight to the cell contacts.

Practical implication for this project: acquire an OnePlus 6 or 6T specifically as a battery-free R&D unit, using the documented 6T method to prototype and de-risk the general technique, before attempting it on the Poco F1 (where it remains a reasoned guess, not a confirmed procedure).

postmarketOS installs non-free firmware by default when a device needs it to function — confirmed via the project's own blog post ("Non-free firmware is installed by default", 2024-02-15): "All pre-built postmarketOS images have always included non-free firmware." Every Qualcomm candidate here needs some of it; the question is how much, and what it's exposed to.

Shared blob requirements, SDM845 trio (Poco F1, OnePlus 6/6T): Adreno GPU firmware, ath10k/WCN3990 WiFi firmware, modem/baseband firmware, and SLPI sensor-core DSP firmware (the same Snapdragon Sensor Core stack behind the sensor support covered above) — all extracted from a specific stock-ROM snapshot (MIUI for the Poco F1, OxygenOS for the OnePlus units). The Pixel 3a (SDM670) needs the same classes of blob, with its modem additionally hosting the sensor DSP. The Galaxy S9 "starlte" port's WiFi/ Bluetooth (a Broadcom chip) simply doesn't work at all rather than running on a blob, per the port maintainers — consistent with the earlier finding.

GPS confirmed to require an active modem blob, on every Qualcomm candidate — the same "GPS rides on the modem" pattern already established on this project's own Nexus 5. postmarketOS's own documentation confirms Qualcomm modems (explicitly naming the Poco F1 among others) "provide a QMI Location Interface to retrieve GNSS locations," managed through ModemManager (postmarketOS wiki, GPS troubleshooting) — meaning the modem/baseband firmware blob must be loaded and running for GPS to work at all, not an optional component.

Specific documented vulnerabilities, for context rather than alarm: "QualPwn" (CVE-2019-10538, CVE-2019-10539, CVE-2019-10540 — Tencent Blade Team, disclosed at Black Hat USA / DEF CON 27, 2019), an over-the-air WiFi-to-modem exploit chain affecting, per Qualcomm's own advisory, the Snapdragon 835/845 family (matching the Poco F1 and OnePlus 6/6T) among other chipsets. Separately, Adreno GPU firmware has had actively-exploited local privilege-escalation CVEs (e.g. CVE-2023-33106), added to CISA's Known Exploited Vulnerabilities catalog in December 2023 (CISA, "CISA Adds Four Known Exploited Vulnerabilities to Catalog"). Kr00k (CVE-2019-15126, a WPA2 decryption flaw) affects Broadcom/Cypress WiFi chips — the family used on the Galaxy S9 (ESET, "Kr00k") — though moot there since WiFi doesn't work on that port anyway. No device-specific CVEs were found for the SLPI sensor-core firmware itself; absence of findings, not a claim of absence of risk.

Mitigating factor worth naming directly: these blobs run on physically separate co-processors (modem, GPU, WiFi chip, sensor DSP), not inside the main Linux kernel — postmarketOS's own sensor-core documentation (linked above) notes "the SoC hypervisor prohibits accessing the sensors directly," which is why QMI/ FastRPC exist as the interface at all. Real isolation, not a security guarantee.

Practical takeaway for this project's actual deployment (a local WiFi AP/MQTT hub, not a general internet-facing host): the WiFi/modem interface is the realistic remote attack surface: if a deployed node doesn't need WiFi client connectivity in the field, disabling it shrinks that surface without affecting GPS (which rides the modem/QMI path, not WiFi).

PinePhone, PinePhone Pro, and Librem 5 are all community tier with well-supported GNSS and sensors, but as already agreed when this research was scoped, they sit outside this project's stated ethos of resuscitating abandoned Android hardware specifically, and none of them is dramatically better on GPS/sensors than the Poco F1 — not enough to override that ethos. Noted for completeness, not pursued further here.

Matching this project's own established discipline (verify directly, don't assume a spec sheet or a wiki page): before treating any candidate as confirmed, run through the same kind of check this project already did for the Nexus 5's own sensors — real values, real before/after physical tests, not just "the file exists."

1. Confirm sensors enumerate and respond to real stimuli (matching the Nexus 5's own IIO-based verification method already documented above), via monitor-sensor~/~lsiio~/ ~iio-sensor-proxy as appropriate for the target device's own sensor framework.
2. Bring up GPS following the device's own documented procedure (ModemManager CLI + Geoclue for the SDM845 devices; the per-boot qmicli reset for the Pixel 3a), and confirm an actual fix, not just that the service starts.
3. Script whatever startup steps GPS needs into a boot-time service, following the same pattern already established for dudhya-sensord's own gyroscope auto-zero and dudhya-wifi-mode's config-reload discipline.

• postmarketOS's own wiki blocks automated fetching (an anti-bot challenge); several device pages were read via search snippets and a mirror rather than the live wiki tables directly. The strongest evidence throughout is the merged GitLab pmaports merge requests, which are authoritative regardless.
• Gyroscope is inferred working on the Qualcomm candidates (same underlying sensor framework as the confirmed accelerometer/ light/proximity/compass) but not individually confirmed in any merge note — verify directly on the actual unit before relying on it, per the validation sequence above.
• Fairphone 4 GPS status under postmarketOS specifically remains genuinely unconfirmed, not just under-documented — treat as "needs bench verification," not as a soft "probably works."
• Prices are approximate secondhand ranges as of the research date and will vary by region, storage tier, and condition.
• Across every Qualcomm candidate, only XTRA A-GPS assistance is supported (not SUPL), so cold first fix can be slow; likely acceptable for a vehicle node with a clear sky view, but worth measuring rather than assuming.
• Battery connector pin counts are only partially verified (the Poco F1's specifically comes from a low-quality aggregator, not a confirmed teardown photo) — verify physically before any battery-free work begins.
• The batteryless-boot method is documented only for the OnePlus 6T specifically; its applicability to the OnePlus 6, Poco F1, Pixel 3a, Fairphone 4, and N900 is a reasoned inference from shared hardware, not independently proven for each.
• Whether cutting the NTC thermistor line alone faults a given device (versus firmware simply ignoring temperature sense) was not confirmed per device — inferred from general charger-IC behaviour, not a device-specific source.
• The CVEs cited (QualPwn, Adreno, Kr00k) are platform/chip-level, disclosed years ago and largely patched in current firmware; their real-world exploitability against a stripped-down postmarketOS node (optionally with WiFi disabled) was not independently assessed here. "No CVE found" for the SLPI sensor DSP specifically is an absence of findings, not proof of safety.

postmarketOS remains the correct choice for dudhya — it wins on every one of the priority-ordered criteria below: it is the only genuine mainline-Linux-kernel-first project with (1) a rigorous, enforced per-device tier system, (2) the broadest coverage of old Android phones specifically, (3) a documented, reusable Qualcomm sensor/GPS stack directly relevant to this project's own IIO-sysfs daemon, and (4) a funded, multi-developer organization mitigating bus-factor risk. No alternative found beats it on these criteria.

Mobian (Debian-based, also genuinely mainline-kernel-first) is the closest real peer and worth keeping as a documented fallback — it shares the same SDM845 kernel work as postmarketOS, but supports far fewer old Android phones and has thinner per-device documentation. Mobile NixOS and Maemo Leste are also genuinely mainline-first but too small/niche to be primary candidates.

Droidian and Ubuntu Touch (UBports) are confirmed Halium/vendor- kernel-based, not mainline — structurally the lower tier the original framing predicted, not excluded outright but not a fit for this project's own stated goal. Sailfish OS is confirmed proprietary (closed UI, EULA-covered components, Halium-based vendor kernels underneath) and stays out of scope entirely, the same way LineageOS-family systems already are.

A concrete, separate finding worth acting on: this project's own Nexus 5 GPS failure generalizes — GPS quality is device-specific, and the newer Snapdragon 845 generation (OnePlus 6/6T, Poco F1, already the recommended second device — see the annex above) has confirmed working GPS via ModemManager/QMI, materially better supported than the Nexus 5's older MSM8974 platform. This reinforces, rather than changes, the existing second-device plan.

The gating criterion. postmarketOS, Mobian, Mobile NixOS, and Maemo Leste all pass it. Droidian and Ubuntu Touch fail it (frozen vendor kernel via Halium). Sailfish fails both this and the open-source requirement. This is the same axis the original decision was built on, now re-confirmed against a wider candidate pool rather than just the two alternatives considered at the time.

Measured the way postmarketOS's own tier system does it (real per-device maintainer requirements, not raw install-count marketing):

• postmarketOS: funded, multi-developer, with formal governance (Trusted/Core Contributor roles) and a written Contributor Compensation Plan (postmarketOS Change Request 0004, "Contributor Compensation Plan"), supplementing volunteer work with paid contribution for otherwise-unsustainable maintenance tasks. Monthly engineering blog updates document sustained, broad activity — kernel work, governance changes, new Trusted Contributors — not just device-count growth (postmarketOS, "in 2026-02: generic kernels"). By a wide margin the strongest community found.
• Mobian: volunteer teams, healthy but smaller; no evidence of paid staff.
• Droidian: small volunteer team, Open Collective funded at a modest scale; real bus-factor exposure.
• Mobile NixOS / Maemo Leste: small contributor bases; Maemo Leste is explicitly recruiting.

• postmarketOS: by far the broadest, and the most rigorous about distinguishing "boots" from "actually usable." The official tier docs specify concrete, enforced requirements — e.g. community requires a "(close to) mainline kernel," no older than 6 months at time of release (postmarketOS packaging docs, "Device Categorization"). The main tier (the highest) is still essentially empty — deliberately: a 2026 change request describes tightening its requirements specifically so that once a device reaches main it gets "at least three years of security updates and bug-fix releases," mirroring major distributions' own LTS policies rather than lowering the bar to fill the category (postmarketOS Change Request 0009, "New main device category"). The v26.06 release ("Alpen Avocado," June 2026) lists 254 devices in the testing category alone, spanning exactly the kind of old, abandoned Android hardware this project targets — explicitly naming the Fairphone 4, Pixel 3a, Galaxy S9, Nokia N900, and OnePlus 6 among them (postmarketOS, "v26.06: Alpen Avocado"). Device-count figures vary by source and snapshot date (see Caveats) — treat the tier definitions as the reliable signal, not any single headline number.
• Mobian: a handful of old-Android phones (OnePlus 6/6T, Poco F1) plus Pine/Librem hardware; thinner per-device documentation, and explicitly defers to postmarketOS's own wiki for mainline boot status rather than maintaining an equivalent of its own.
• Droidian: a small curated set (single digits) as of its most recent snapshot releases; broader potential via Halium/GSI but not demonstrated at postmarketOS's scale.

This is dudhya's core requirement, and postmarketOS's clearest advantage — directly relevant to this project's own IIO-sysfs sensor daemon.

Sensors: postmarketOS has the only documented, reusable Qualcomm sensor framework found across every candidate. The architecture (confirmed directly, not assumed): on newer Qualcomm SoCs (SDM845 and similar) "the SoC hypervisor prohibits accessing the sensors directly," so a dedicated DSP — the Sensor Low Power Island (SLPI), also called Snapdragon Sensor Core (SSC) — must be used instead (postmarketOS wiki, "Qualcomm Snapdragon Sensor Core"). libssc (GLib-based, actively maintained) exposes these sensors to the standard Linux ecosystem via iio-sensor-proxy (libssc, Codeberg). Directly relevant to this project's own hardware: on older Qualcomm SoCs specifically including MSM8974 — the Nexus 5's own chip — sensors instead share pins with the AP and "these pins could be set to GPIO which allows the AP to access sensors by bit-banging their interfaces," i.e. closer to dudhya-sensord's own direct-sysfs approach (pmaports !4118, "Qualcomm Sensor Manager support") — confirming, from the OS side, exactly the sensor-access split this project has already lived through hands-on.

GPS: confirmed genuinely achievable, not just theoretically possible, on SDM845 old-Android phones. postmarketOS's own gnss-share project states plainly that Qualcomm modems in devices "such as… OnePlus6… Xiaomi POCOPHONE F1, and many other Qualcomm based devices in postmarketOS provide a QMI Location Interface to retrieve GNSS locations," via ModemManager, using XTRA A-GPS (gnss-share issue #10) — the same source already cited in the second-device annex above. First-hand confirmation: "GPS itself works fine" on the Poco F1 (Drew DeVault, "A review of postmarketOS on the Xiaomi Poco F1"). No equivalent documented GPS path was found for Mobian, Mobile NixOS, or Maemo Leste specifically (they would likely inherit the same ModemManager/QMI mechanism on shared SDM845 hardware, but this was not independently confirmed for those projects).

• postmarketOS: very healthy. Regular ~6-month releases, monthly engineering blog updates, active governance evolution, funded contributors — no abandonment risk found.
• Mobian: alive, slower cadence, volunteer-only.
• Droidian: alive, small team, real bus-factor exposure.
• Mobile NixOS: ongoing but low-visibility.
• Maemo Leste: active but perpetually pre-"daily driver," openly recruiting more developers.
• Ubuntu Touch: alive but structurally lower tier per above.

dudhya's daemon reads IIO sysfs directly and publishes MQTT. Alpine (musl/BusyBox) is lightweight and well-documented; apk is simple; pmbootstrap makes building/flashing reproducible; the postmarketOS wiki's per-device feature-status documentation is unmatched among the candidates researched. Mobian (Debian/apt, glibc) would be more familiar to some tooling and remains a reasonable secondary if a specific future device is better supported there — porting risk is low, since both expose sensors/GPS through the same mainline IIO + ModemManager/QMI plumbing.

1. Keep postmarketOS as the primary OS. It wins on every priority-ordered criterion above; continue investing in the existing infrastructure rather than switching.
2. Prefer the already-recommended SDM845-generation hardware (OnePlus 6/6T, Poco F1) over the Nexus 5 for GPS-critical work — this is a hardware-selection reinforcement, not an OS change, and matches the second-device annex above directly.
3. Keep Mobian noted as a documented fallback, not a switch — re-evaluate only if a specific future target device turns out to be better supported there.
4. Continue excluding Halium-based and proprietary options (Droidian, Ubuntu Touch, Sailfish) — they do not meet this project's own stated constraints, regardless of raw device counts.

Would change this recommendation: postmarketOS losing its funded contributor model or going quiet for 12+ months; a mandated target device with sensors/GPS working only under a Halium-based OS and never achievable on mainline; or Mobian reaching postmarketOS's own level of tier rigor and old-Android coverage.

• Device-count figures vary meaningfully by source and snapshot date — the v26.06 release notes cite 254 testing-category devices; other sources describe different, later or differently- scoped counts. Treat postmarketOS's tier definitions and requirements as the reliable signal, not any single headline device-count number.
• The live postmarketOS wiki was behind an anti-bot challenge at research time; several claims rely on GitLab issues/merge requests, official packaging docs, and cached search snippets rather than a live-rendered wiki page — re-verify the actual device feature tables before finalizing any specific hardware choice.
• GPS via SUPL (as opposed to XTRA A-GPS) is itself flagged as unconfirmed on the postmarketOS wiki's own troubleshooting page — XTRA is the confirmed-working path, not SUPL.
• No equivalent GPS/sensor documentation was found (or ruled out) for Mobian, Mobile NixOS, or Maemo Leste specifically — absence of findings, not a claim that they lack the capability.
• Community-strength assessment here is qualitative (governance structure, funding, release cadence, blog activity) rather than exact commit-count analytics, which could strengthen a future revision of this comparison.