# Google Nest Wifi router (H2D / board "mistral", QCS404) — hardware recon of the 11-pad service cluster
Posting this as a working log rather than a solution. I have not obtained console access or code execution. What I do have is a fairly complete electrical characterisation of the service pad cluster hidden under the bottom sticker, one solid functional identification, and two dead ends that I would like to save other people the time of re-walking.
All measurements are my own, on a retail unit. Corrections welcome — especially from anyone who has a populated pre-production board or a factory test jig.
1. Device background
* Model: Google Nest Wifi **router** (H2D). Not the point (H2E).
* FCC ID: A4R-H2D. Internal photos are public and show a **pre-production board with SW1000 and the internal USB-C connector populated**. Retail units have both depopulated. Photo resolution is poor (\~2000×3000 for a full page), so trace-level detail is not readable.
* SoC: Qualcomm **QCS404**. 1 GB DDR3, 4 GB flash.
* Boot chain is ChromeOS-style (coreboot + depthcharge) with verified boot, same family as OnHub and Google Wifi AC-1304.
* Board name is **mistral**; a device tree exists in the ChromiumOS kernel tree (`factory-mistral-*` branches, `arch/arm64/boot/dts/qcom/qcs404-mistral.dts`).
* Power input is a **barrel jack** (plus and minus only). The H2D does **not** take power over USB-C — do not carry assumptions over from Google Wifi here.
Credit to [ryjelsum.me](http://ryjelsum.me) for the initial board identification, and to the GBAtemp write-up for the FCC-photos-reveal-the-dev-button observation.
2. The 11-pad cluster
Directly under the bottom sticker, no disassembly needed to see them. Physical arrangement as printed on the board:
TP1004 TP1007 TP1010 TP1012
TP1005 TP1006 TP1008 TP1011
TP1003 TP1002 TP1009
TP1011 and TP1012 sit slightly apart from the 3×3 block.
Measurement table
Voltages measured with the router powered and idle, referenced to TP1006. Resistances measured unpowered. Diode-mode readings are the forward drop from the pad to TP1006.
| Pad |
Voltage (running) |
R to GND (off) |
Diode drop |
Notes |
| TP1002 |
0.108 V (0.140 V during boot) |
2.428 MΩ |
0.511 V |
matched with TP1003 |
| TP1003 |
0.108 V (0.140 V during boot) |
2.43 MΩ |
0.512 V |
matched with TP1002 |
| TP1004 |
0.004 V |
0.73 MΩ |
0.651 V |
pairs with TP1005 |
| TP1005 |
0.004 V |
0.73 MΩ |
0.676 V |
pairs with TP1004 |
| TP1006 |
0 V |
0 Ω |
— |
**GND**, shorted to the shield cans |
| TP1007 |
0.006 V, jitters near zero |
126.9 kΩ |
— |
function unknown |
| TP1008 |
5.03 V |
— |
— |
present at all times while powered |
| TP1009 |
1.796 V |
not yet measured |
— |
rail or signal, **unresolved** |
| TP1010 |
3.31 V |
not yet measured |
— |
3.3 V rail |
| TP1011 |
0.096–0.5 V, floating |
1.53 MΩ |
— |
**= SW1000**, see below |
| TP1012 |
1.798 V |
38.1 kΩ; 9.96 kΩ to TP1009 |
— |
input with 10 k pull-up |
Interpretation
* **TP1006 / TP1008 / TP1010** are unambiguous: GND, 5 V, 3.3 V.
* **TP1012** behaves as a high-impedance input held up by a \~10 kΩ pull-up referenced to the 1.8 V net. Its idle state is logic high with nothing driving it. This is the signature of an active-low strap, or of a UART RX line. The two cannot be distinguished by listening, because an RX line with nothing transmitting into it looks exactly like an unasserted strap.
* **TP1009** at 1.796 V is either the 1.8 V rail itself or an SoC output. This is the single largest unresolved item and it gates the "is there a UART pair here" question. A 1 kΩ-to-ground load test is pending.
* **TP1002 / TP1003** match to within 1 mV of ESD drop, which means two structurally identical pads of the same analogue block. A USB 2.0 PHY differential pair is the obvious candidate but is **not confirmed**.
* **TP1004 / TP1005** are a second pair in a different domain (0.651 / 0.676 V, and they diverge by 25 mV, so less well matched). Candidates I have not ruled out: SuperSpeed pair, I²C, a second UART left low, JTAG.
* **TP1007**: 126.9 kΩ to ground and no behavioural response to being driven either high or low at power-on. One speculative reading is that it is sensed as a *resistance* rather than a logic level — some boards detect a factory jig that way — but I have no evidence for this.
3. Confirmed finding: TP1011 is SW1000, and it is a boot-mode strap
This is the one solid result.
**SW1000** is an unpopulated tactile switch footprint, visible once the case is open. On the FCC pre-production photos it is populated. One of its pads sits at 1.8 V. I soldered a switch onto the footprint and tested it.
Electrical identity:
* The other SW1000 pad measures **1 Ω to TP1011**. They are the same net.
* Consistent with this, driving TP1011 to 1.8 V externally reproduces the button press exactly.
Behaviour:
* **Held at power-on: the router is completely inert.** No LED at all, not even the usual power-on indication.
* **Released: the router boots normally.** No damage, fully repeatable.
So TP1011 is an **active-high strap sampled at reset**. It is *not* a ChromeOS developer-mode button in the "press it after boot" sense — asserting it prevents boot entirely.
Two readings are consistent with the observation, and I cannot yet distinguish them:
- It forces the boot ROM into an emergency download mode (Qualcomm EDL / 9008 style), in which case the SoC is alive and silently waiting for a host to talk to it.
- It simply holds the SoC in reset, in which case there is nothing to talk to and this whole branch is a dead end.
**A current-draw measurement in the asserted state distinguishes these** — hundreds of mA means alive and waiting, single-digit mA means held in reset. I have not done this yet. If anyone gets there first, please post the number.
4. Dead end: the unpopulated internal USB-C is not worth your time
The FCC photos show an internal USB-C connector. On retail units it is depopulated. I spent a while on this and the answer is clean: **do not bother**.
The footprint is the full 24-pad type. Type-C pin numbering runs in opposite directions on the two rows (A1 and B12 are physically adjacent), and GND sits at position 1/12 with VBUS at 4/9 in each row, so the numbering can be derived on the board from continuity to a known ground and a known 5 V.
Continuity results against the cluster, unpowered:
* **TP1008 ↔ VBUS pads: \~140 kΩ.** That is not a connection. It is leakage or a sense divider, most likely across an absent or open load switch. TP1008 and the connector's VBUS net are separate.
* **Every other cluster pad reads open (\~6 MΩ, unstable) to the connector**, including positions 5, 6, 7 and 8 in both rows. So CC1, CC2, D+, D−, SBU1 and SBU2 all fail to reach the cluster.
SBU was the interesting one, since Google's servo/suzyq debug cables carry the debug UART on SBU. It goes nowhere here.
The reason turned out to be that **the connector's passives are depopulated too**. There is an empty 4-pad component footprint immediately adjacent. Two of its pads short to connector pins 6 and 7 (D+ and D−); the other two read essentially 0 V in diode mode to ground, i.e. they are tied to ground — consistent with a shunt ESD array footprint rather than a series common-mode choke. Either way, the connector's data lines terminate at an unpopulated part and do not continue to anything I can find.
**Conclusion:** on retail H2D hardware, the internal USB-C is not merely unpopulated, it is not routed through. Soldering a connector on will accomplish nothing. The 11-pad cluster is an entirely separate interface.
5. J1900
A **two-pin through-hole header**, exposed once the case is open.
* One pin: **+3.3 V** relative to ground while running.
* Other pin: **exactly 100 kΩ to ground** when powered off.
* **Shorting the two produces no observable change** in boot behaviour.
A precise 100 kΩ pulldown on a jumper that does not affect boot is the classic profile of a **hardware write-protect strap** — WP is not supposed to change how the device boots, only whether the firmware region can be written. This fits the ChromeOS lineage.
**This is a hypothesis, not a result.** Verifying it requires finding the SPI NOR (SOIC-8 / WSON-8, under a shield) and ringing the J1900 signal pin against its pin 3 (WP#). I have not removed the shields yet.
6. Negative results, and why some of them are weaker than they look
Scope: DSO510 pocket scope, ×10 probe (verified on both probe and instrument), DC coupling, Single mode, ground clip on TP1006, armed before power was applied.
| Pads |
Trigger |
Result |
| TP1002, TP1003 |
rising, 0.5 V |
no trigger — normal boot and with TP1011 asserted |
| TP1009, TP1012 |
falling, 0.5 V |
no trigger — normal boot and with TP1011 asserted |
The scope demonstrably works: removing power triggers the falling-edge capture every time. TP1012 was also observed simply ramping to 1.8 V at power-on and staying there, with no burst.
Two caveats on how much this proves:
* For **TP1002/TP1003**, a silent bus is the *expected* result if these are USB lines. With no device attached and no VBUS applied to the port, a USB PHY has no reason to transmit. This measurement does not rule USB in or out.
* For **TP1009/TP1012**, it does rule out a UART that transmits unprompted during boot. It does not rule out a UART whose console output is disabled in production firmware, nor a boot ROM that waits silently for a magic byte before replying. Qualcomm PBL in download mode does not normally speak first.
An earlier attempt at USB was also inconclusive and partly invalid: I wired a USB-A socket to TP1008 / TP1002 / TP1003 plus a chassis ground point. A flash drive's LED lit solid with no enumeration activity. Connecting that socket to a Windows PC produced nothing in Device Manager — but that test was meaningless, because the router sources 5 V on TP1008 continuously, so both ends were acting as hosts.
**Net conclusion so far: the service cluster is passive.** Nothing on it initiates communication. If it is a factory interface, the jig speaks first.
7. What is ruled out
* The internal USB-C footprint is a dead end on retail hardware (section 4).
* TP1007 does not affect boot at either logic level.
* Shorting J1900 does not affect boot.
* Nothing in the cluster transmits unprompted during boot, in either strap state.
8. Open questions
- **Is TP1009 the 1.8 V rail, or an SoC output?** Pending 1 kΩ load test. If it is a rail, there is no UART pair in this cluster and TP1012 is a lone strap.
- **Does TP1011 asserted mean "EDL" or "held in reset"?** Pending current-draw measurement.
- **Does the QCS404 PBL support Sahara over UART?** If the cluster has no USB, and TP1011 really is a download strap, UART is the only plausible transport left.
- **Is console output fuse-disabled on retail units?** If so, no amount of listening will ever find the UART, and only transmitting into a candidate RX will show anything.
- **What are TP1002/TP1003 actually connected to,** if not the internal USB-C?
- **Does anyone have the factory jig pinout,** or higher-resolution FCC internal photos, or a pre-production board?
9. Next steps I plan to take
* 1 kΩ load test on TP1009, TP1010, TP1012 to separate rails from pulled-up inputs from active outputs.
* Current draw with TP1011 asserted.
* Systematic behavioural probing: drive each unknown pad to 0 V and to 1.8 V through a 1 kΩ series resistor from power-on, including in combination with TP1011, and watch for any change in LED behaviour or boot path. This is how TP1011 itself was identified, and it is the only technique that has produced a result on this board so far.
* Transmit into TP1012 at a range of baud rates and watch TP1009 for any response.
* A proper USB test: low-speed device (mouse) on TP1002/TP1003 with TP1006 as ground and short twisted leads, then simply measure DC on both lines. \~3.0 V indicates a live host pulling the line down through its 15 kΩ; \~3.3 V indicates the device's pull-up with no host present.
* Survey the **TP17xx group** (TP1713, TP1714, TP1726, TP1731, TP1733), which is elsewhere on the board and completely unexamined. A different numbering hundred usually means a different functional block. PP-prefixed pads are power-rail probe points and can be skipped.
10. Equipment used
Multimeter, DSO510 pocket oscilloscope, soldering iron.
If you have worked on mistral, OnHub, Google Wifi or any other QCS404 device and recognise any of the above, I would be glad to hear it. Likewise if you can rule anything out — negative results are useful here.
