Silicon Bring-up · All levels

Where Boot Hangs: Stage-Aware Debug Strategy: Debug Playbook

Debug Playbook for Where Boot Hangs: Stage-Aware Debug Strategy.

Debug playbook

Debug Playbook for Where Boot Hangs: Stage-Aware Debug Strategy is anchored on Mean time to isolate first failing boot stage and reproducibility score across cold boot, warm reset, and voltage corners.. Convert observed behavior into mechanism-backed and owner-bound actions.

Freeze setup metadata and preserve first-failure state.
Locate first persistent boundary where behavior diverges.
Classify mechanism: dependency, margin, protocol, software, or silicon.
Apply one focused reproducer and one bounded fix.
Re-run replay, corner, and soak confidence matrix.

Review memo template

diagram

BRING-UP REVIEW MEMO - Boot Flow Bring-up / Where Boot Hangs: Stage-Aware Debug Strategy

1. Symptom
   - Failing metric: Mean time to isolate first failing boot stage and reproducibility score across cold boot, warm reset, and voltage corners.
   - Trigger context: <board/firmware/corner/test window>
   - First failing boundary: <power/reset/clock/interface/firmware>

2. Mechanism hypothesis
   - Candidate mechanism: When silicon hangs during boot, the primary challenge is visibility before full logging is alive. A stage-aware strategy divides boot into checkpoints with independent proof-of-life signals: GPIO pulse points, UART minimal prints, mailbox breadcrumbs, JTAG halt markers, and on-chip trace triggers. Debug proceeds by binary narrowing: identify the last confirmed stage, compare expected versus observed register/clock/reset state, and replay with controlled perturbations such as alternate boot media, reduced clock, or bypass paths. Corner-sensitive hangs frequently involve analog settle assumptions, race conditions in interconnect initialization, unmasked interrupts, or cache enable before coherency fabric readiness. High-quality teams maintain a failure taxonomy and scripted triage packet so every new hang captures identical evidence, enabling faster clustering of root causes and reducing lab iteration time.
   - Competing hypotheses: setup, dependency, margin, software path, silicon defect
   - Missing evidence: <trace/scope/register/report>

3. Proposed action
   - Smallest reversible change: <setup/script/config/firmware>
   - Expected movement: <repro rate/latency/pass trend>
   - Regression risk: stability, safety, release timeline, ownership handoff

4. Signoff
   - Required artifact: Boot hang triage playbook with checkpoint ladder, mandatory evidence bundle, and hypothesis-to-test matrix.
   - Required owners: silicon debug lead, firmware debug owner, SoC integration owner, lab automation owner, reliability and characterization owner
   - Final decision: ship, bounded rollout, rollback, respin escalation

Silicon bring-up deep dive

Boot closure depends on stage-level checkpoints and explicit transition evidence from reset release to runtime handoff.

Concept diagram

diagram

BOOT CLOSURE FLOW

POR -> ROM -> stage-1 -> stage-2 -> runtime
  |      |       |         |
 checkpoints and traces define first failing handoff

Metric graph

diagram

BOOT STABILITY SIGNALS

ROM handoff stalls      ████
stage repeat failures   █████
clean progression       ████████

Metrics and artifacts to collect

boot stage progression heatmap
checkpoint latency distribution
boot failure signature classifier
firmware-hardware ownership map

Mini case study

A persistent boot hang was resolved only after aligning reset and clock-domain checkpoints with firmware stage logs.

Debug branches

Lock metadata and confirm first missing checkpoint.
Differentiate auth, transport, and dependency failures.
Validate one bounded fix against cold and warm boot paths.

Senior review question

Ask: what is the first failing boundary, which artifact proves it, and who owns bounded closure?

Key takeaways

Tie every bring-up claim to one reproducible setup state and one proving artifact.
Prefer bounded fixes with clear owner and rollback trigger over broad multi-variable edits.

Common pitfalls

Running parallel uncontrolled experiments and losing causality.
Declaring closure without replaying across representative corners.
Escalating severity before bench/setup hypotheses are disproven.

Debug ladder

Sequence: reproduce -> classify -> isolate -> instrument -> bounded fix -> replay.

Avoid parallel broad edits before first root-cause class is proven.

Practice this lesson