Board Bring-Up Checklist

Advanced13 min read

Assumes: 0.4 Power Architecture & PMIC, 5.2 The Boot Chain, 10.1 The Debug Bench, 10.3 Debug Interfaces

TL;DR

Board bring-up is the hardware verification sequence that happens before Module 5.2’s boot chain even starts. PBL can’t execute if VDD_CX isn’t at the right voltage. The boot chain can’t load from UFS if the clock tree isn’t running. ADB won’t connect if the USB mux isn’t routed correctly. 70% of “board doesn’t boot” issues on new hardware are power-related, not software. This page gives you the systematic hardware checklist: power rail verification, clock tree checks, debug interface setup, and first-boot procedures. It’s the bridge between having a bare board on your desk and seeing the first UART log message.

You have a fresh PCB, a bench supply, and a UART cable. Someone asks if the software is ready to flash. Wrong question. Is the hardware alive? Start with PMIC rail verification before you trust any boot log. Board bring-up is the disciplined sequence you run before you trust a single byte of boot firmware. On SA8155P/SA8295P ADP boards and OEM carrier revisions alike, the pattern is identical: verify power, verify clocks, configure reset and boot mode, connect debug interfaces, then watch for PBL. Skip a layer and you’ll waste days chasing partition maps that were never the problem. Part art, part science, part staring at a UART console willing it to print something other than garbage.

The Bring-Up Mindset

You are a detective with a multimeter, an oscilloscope, and a UART cable. Your job is not to flash faster — it’s to prove each prerequisite before the next stage can possibly work.

• Work bottom-up: power → clocks → reset → boot ROM → first log
• Never assume; measure everything — a multimeter reading at idle tells you almost nothing about a 50 ms power-on transient
• The schematic is your map; the board is the territory — when they disagree, the schematic wins until you prove otherwise with a probe

Every “software bug” on a virgin board is guilty until the hardware checklist clears it.

Mental Model

Board bring-up is like starting a car engine from scratch. You don’t turn the key and hope. You check: is there fuel (power rails)? Is the timing belt connected (clock tree)? Is the starter engaged (reset sequence)? Is the key in the right position (boot mode pins)? Only after every mechanical prerequisite is verified do you turn the key (release PBL). Skip a step, and you get silence instead of the engine starting.

Power Rail Verification

Power is Layer 1. Always. On Qualcomm cockpit platforms, the PMIC (typically PM8150-class on SA8155P ADP) converts bench 12V into a dozen regulated rails. PBL ROM executes from on-chip memory, but it still needs VDD_CX stable before a single instruction runs reliably.

flowchart TD
    A["Step 1: Apply 12V input<br/>Measure PMIC VIN pin"] --> B["Step 2: Check each PMIC output<br/>against schematic nominal"]
    B --> C["Step 3: Scope VDD_CX<br/>Clean ramp, no oscillation"]
    C --> D["Step 4: Verify sequencing<br/>Always-on → Core → Peripherals → I/O"]
    D --> E["Step 5: Load test<br/>Rails under current draw, not idle"]
    E --> F{All rails in spec?}
    F -->|Yes| G["Proceed to clock verification"]
    F -->|No| H["Stop. Fix hardware.<br/>Do not flash software."]

Step	What to Measure	Pass Criteria	Common Failure
1. PMIC input	12V at connector → PMIC VIN	Within datasheet range (typically 4.5V–18V post pre-regulator)	Reverse polarity protection tripped, open fuse
2. Output rails	VDD_CX, VDD_MX, VDD_GFX, VDD_IO, VDDA_1P8	Match schematic ±3%	Wrong resistor in voltage divider, wrong PMIC OTP config
3. VDD_CX transient	Scope on core rail during power-on	Monotonic ramp, no oscillation, no dip below POR threshold	Missing or wrong-ESR bypass cap
4. Sequencing	Trigger scope on always-on, then each rail enable	ACPI order: always-on → core → peripherals → I/O	I/O enabled before core → latch-up risk
5. Under load	Re-measure after connecting UFS, display, USB	Rails hold within tolerance during inrush	Undersized inductor, cold solder on PMIC SW node

Mnemonic: “Measure twice, scope once, flash never — until rails pass.”

Think About It

You power a new board. The 12V input measures fine. VDD_CX reads 0V. VDD_MX reads 0V. VDDA_1P8 reads 1.8V. What does this tell you about where the power chain broke?

Reveal Answer

VDDA_1P8 is typically an LDO rail that comes up early in the always-on or analog phase, while VDD_CX and VDD_MX are high-current buck outputs that enable in the core phase. The PMIC is alive and converting — input and LDO paths work — but the core buck converters never enabled or are faulted. Probe PMIC PON/status registers over SPMI if available, buck enable lines, inductor continuity, and the feedback resistor network on VDD_CX. Don’t flash XBL until those bucks produce voltage.

Clock Tree Verification

No clock, no boot. PBL ROM needs a reference clock to drive its internal PLLs before it can talk to UFS or print on UART.

Check	Method	Pass Criteria
Reference crystal	Scope on 19.2 MHz test point (Qualcomm standard)	Clean sine/square, correct frequency, stable amplitude
Crystal oscillator	Probe XIN/XOUT or dedicated TP	Oscillation within 30 s of power-on
PLL lock	PMIC status register, GPIO lock indicator, or SoC clock monitor	Lock bit set; no repeated re-lock cycles
Derived clocks	Scope on downstream test points if exposed	UFS ref clock, USB PHY clock present when peripherals enable

If the crystal doesn’t oscillate:

1. Load capacitors — wrong value shifts frequency or prevents start-up; match crystal datasheet CL spec
2. PCB trace length — crystal to SoC must be short and symmetric; long stubs add capacitance
3. Crystal spec — verify part number matches BOM (frequency, load, ESR, drive level)
4. Damaged crystal — mechanical shock during assembly; swap and re-test

A board with perfect rails and a dead crystal produces exactly nothing on UART — indistinguishable from a power fault until you scope the reference.

Reset and Boot Mode Configuration

Power and clocks are necessary but not sufficient. The SoC must receive a valid power-on reset (POR) pulse and boot from the correct strap configuration.

Item	What to Verify
POR timing	Reset line held low until core rails exceed threshold; pulse width meets PMIC/SoC datasheet (typically ms-scale)
Boot mode pins / DIP switches	Set for intended mode: normal boot, EDL, or fastboot — before applying power
Force EDL	Platform-specific GPIO state during power-on (test-point short to GND on ADP boards)
Warm vs cold reset	Confirm you’re testing cold boot (full power cycle), not a warm reset that skips PMIC sequencing

Read 10.2 Boot Modes & Debug Modes for the full mode matrix — entry methods, available tools, and which USB port activates in each mode. Boot mode is step 7 of your bring-up; getting it wrong sends you debugging software while the board is in EDL waiting for QFIL.

First-Boot Checklist

When rails, clocks, and boot mode are verified, run this sequence exactly:

1. UART cable connected to debug UART header — 115200 baud, 8N1, 3.3V TTL (FTDI preferred)
2. USB cable to the correct port — check USB mux routing on schematic (device port vs host; EDL vs ADB path)
3. Boot mode switches set to normal boot (document switch positions in your bring-up log)
4. Open terminal on UART — you should see PBL messages within 1–2 seconds of power-on
5. If no UART output — go back to power rails and clock; do not open QFIL
6. If PBL starts but XBL fails — check UFS connection, flash integrity, UFS power rail under load
7. If XBL starts but ABL fails — check boot partition, secure boot state, AVB/fuse configuration
8. If ABL starts but no OS — check kernel, ramdisk, device tree, hypervisor guest load order

First log is the milestone. Everything before it is hardware. Everything after it is software — but only if you earned the first log honestly.

Reading Schematics for SoC Platforms

You cannot bring up a board you cannot read. Schematics for Qualcomm ADP and OEM carrier boards follow predictable structure. Learn to navigate them before you touch a probe.

flowchart TB
    subgraph read_order ["Schematic Reading Order"]
        BD["1. Block Diagram<br/>SoC, PMIC, memory, connectors"]
        PT["2. Power Tree<br/>12V → regulators → every rail"]
        PM["3. Pin Mux<br/>SoC pins → peripheral functions"]
        TP["4. Test Points<br/>Accessible measurement locations"]
    end

    BD --> PT --> PM --> TP

    subgraph sources ["Where to Get Them"]
        ADP["Qualcomm ADP reference design package"]
        OEM["OEM board schematic package<br/>(NDA, tier-1 portal)"]
        BSP["BSP device tree<br/>(confirms enabled peripherals)"]
    end

    TP --> ADP
    TP --> OEM
    PM --> BSP

Section	What You Extract	Bring-Up Use
Block diagram	SoC, PMIC, LPDDR, UFS, connectors	Orient yourself; identify critical ICs
Power tree	Every rail from 12V input to every consumer	Build your multimeter checklist in sequencing order
Pin mux	Which SoC balls serve UART, USB, JTAG, boot straps	Wire debug cables correctly the first time
Test points	TP labels on each major rail and clock	Scope without guessing probe placement

On ADP boards, Qualcomm ships schematics in the Hardware User Guide. On production carrier boards, your tier-1 supplies a schematic package under NDA — request it before bring-up day, not after the board arrives.

Common Gotcha

Beginner thinks “board doesn’t boot” = software problem. Reality: 70% of first-boot failures on new hardware are power-related. A missing bypass cap, a swapped resistor value, or a cold solder joint on a PMIC pin will prevent PBL from ever executing. Software can’t fix missing volts.

Common Gotcha

“I connected UART but see nothing.” Checklist: (1) Correct UART port? Some boards have multiple UARTs — debug vs BT vs GNSS. (2) Correct baud rate? 115200 is standard for Qualcomm early boot. (3) TX/RX swapped? Adapter TX → board RX, adapter RX → board TX. (4) Ground connected? Floating ground = floating garbage. (5) Level shifter needed? Some UARTs are 1.8V, not 3.3V — 3.3V adapter on 1.8V pins can damage the SoC or produce no valid logic. (6) Is the board actually powered? Don’t laugh — it happens.

Oscilloscope Tips for Bring-Up

A multimeter tells you the destination; a scope tells you the journey. On power-on, the journey is what kills you.

Tip	Why It Matters
Always use the 10× probe	1× probe loads the rail and adds capacitance; 10× is the accuracy default for rail measurement
Measure ripple	Target under 50 mV peak-to-peak on core rails at steady state; excess ripple causes timing errors
Check rise time of power-on ramp	Too slow → POR timeout; too fast → inrush collapse on input
Look for ringing on clock signals	Ringing indicates impedance mismatch — check series termination resistor, trace length
Ground spring or short ground lead	Long ground clips add noise at high frequencies; invalidates ripple and clock measurements

Rule: If a rail passes the multimeter but fails intermittently at boot, the scope is the tiebreaker. Meters average; scopes catch the 50 µs dip that kills PBL.

Advanced Bring-Up Tools

When multimeter and scope aren’t enough, these tools separate senior bring-up from guesswork:

• JTAG/SWD — Halt CPU at reset vector; verify PBL entry point before a single instruction executes. Requires fuse-open debug board and TRACE32/OpenOCD setup (Page 10.3).
• Logic analyzer on SPMI bus — Verify PMIC communication: rail enable commands, PON reason readback, fault interrupts. Confirms software-visible PMIC state matches hardware.
• Boundary scan (JTAG) — Board continuity testing without power — useful for BGA solder inspection on first article builds.
• Thermal camera — Spot hot spots instantly: shorted rails (PMIC or inductor glowing), excessive current draw on a specific domain, reversed polarity protection heating.

These are not daily tools. They are the escalation path when rails measure fine, clocks oscillate, UART is silent, and you’re out of ideas.

Where You'll See This

Bring-up discipline that saves projects:

• Keep a bring-up log — timestamp every measurement, every BOM change, every switch position. Future-you will not remember which test point was VDD_CX.
• Photograph probe positions — you’ll forget which TP was which within an hour
• Golden board — keep one known-working board as reference for voltage comparisons on every revision

War story: A new PCB revision had an intermittent PBL hang. 8 out of 10 boards booted fine. The 2 failures showed VDD_CX dipping to 0.58V during power-on (spec: 0.65V minimum). Root cause: a 22 µF bypass cap had wrong ESR from a component substitution. The cap’s ESR at -40°C was even worse. Fix: BOM lock on critical bypass caps. Lesson: always scope the power-on transient, not just steady-state.

Connect the Dots

• Module 0.4 (Power Architecture & PMIC): This is where you verify the power design from Module 0.4 — ACPI sequencing, rail names, POR behavior.
• Module 5.2 (The Boot Chain): PBL only runs after this bring-up succeeds. No rails, no XBL, no QHEE, no QNX.
• Module 5.6 (BSP): Device tree and board support build on working hardware — stdout-path, pin mux, and regulator nodes assume rails that actually exist.
• Module 10.2 (Boot Modes): Boot mode configuration is step 7 of your bring-up — wrong straps send you debugging the wrong layer.
• Module 10.3 (Debug Interfaces): UART, JTAG, and SWD are your bring-up tools — wire them before you power on, not after you panic.

Check Your Understanding

1. What is the correct hardware bring-up order before expecting the first PBL UART message?

Recall

A. Connect JTAG hot-plug → enable fastboot mode → apply 12 V bench supplyB. Flash QFIL → connect ADB → verify Ethernet → check powerC. Boot AAOS first → run logcat → scope power rails only if errors appearD. Power rails → clock ref → reset straps → debug UART → power on sequence

2. 70% of first-boot failures are power-related. What should you check BEFORE suspecting software?

Recall

A. SOME/IP service discovery and gRPC OTA agent connectivity over EthernetB. Kernel dmesg and QNX slog2 for driver probe failures and DT mismatchesC. Power rail voltages, sequencing, PMIC status, decaps, and POR transientsD. Partition map, A/B slot state, and AVB rollback index

3. Board powers on but UART shows no output. Power rails all measure correctly at steady state. What's the next thing to check?

Applied

A. UART connection: correct port, TX/RX wiring, baud rate, voltage level, and groundB. Reflash XBL via QFIL — the bootloader is corruptC. Disable secure boot in fastboot — AVB is blocking UART outputD. Replace the UFS chip — storage failure prevents PBL from printing

4. VDD_CX measures 0.82V steady-state but the oscilloscope shows a 200mV dip during the first 50ms of power-on. Why does this matter?

Applied

A. 200 mV ripple is normal and indicates healthy PMIC switching frequencyB. It doesn't matter — steady-state voltage is within spec so boot will succeedC. The dip indicates UFS storage corruption that will surface later during XBLD. PBL runs during POR; VDD_CX dip below minimum can cause intermittent boots

5. Rails are good but UART is still silent. You scope the 19.2 MHz reference test point and see a flat line. What does this imply?

Applied

A. JTAG_DISABLE fuse blocks UART output as both share the debug access policyB. Clock failure — PBL can't run PLLs or UFS/UART without reference oscillatorC. XBL partition is corrupt — use QFIL immediately to reflash the boot chainD. AAOS kernel panic during early init before the UART console driver loads

6. VDDA_1P8 reads 1.8V but VDD_CX and VDD_MX read 0V on a new PCB. What cross-domain diagnosis is most likely?

Synthesis

Connects to: Module 0 — Power Architecture

A. PMIC alive (LDO works) but core bucks failed — probe PON, enable, inductorsB. UFS firmware bug — reflash via EDLC. Wrong A/B slot selected in fastboot causing a boot into stale partition setD. QHEE hypervisor misconfiguration

Further Reading

• QNX Board Support Package Development — QNX BSP guide covering startup code, IFS build, and board-specific configuration that assumes the hardware checks on this page have passed.
• QNX Startup Programs — Documentation for startup-* verbose boot flags used to diagnose hangs before slog2info is available on first boot.
• The Linux Kernel — Device Tree Usage — Device tree model explaining how pin mux, regulator, and stdout-path nodes in BSP overlays depend on verified hardware from bring-up.
• eLinux — Boot Time Resources — Embedded Linux boot optimization and measurement techniques applicable to tracing boot stage timing after the first UART milestone.
• Keysight Oscilloscope Fundamentals — Oscilloscope measurement basics for rail ripple, rise time, and clock signal quality checks during power and clock verification.
• Qualcomm Developer Network — ADP schematic packages, Hardware User Guides, and PMIC reference material for SA8155P/SA8295P carrier board bring-up.
• ARM Debug and Trace — CoreSight and JTAG architecture reference for the advanced bring-up escalation path when UART is silent but rails and clocks measure correctly.
• IEEE 1149.1 — JTAG Boundary Scan — Boundary-scan standard used for board continuity testing on first-article builds before applying power, as noted in the advanced bring-up tools section.