AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 17 Bitcoin

build: unify product and probe commands

Public commit record

What the developer wrote

Authored by Niklas Dusenlund

90/100 · Strong
build: unify product and probe commands

The growing set of products, editions and boards requires more Make
targets and separate flashing/debugging scripts for each combination.
Selecting the device once lets developers use the same image commands
across BitBox02, Nova and BitBox03 and reduces duplicated workflows.

Add make config to save product, board, edition, debug setting, probe
software and SWD speed in a local, ignored config.mk. The primary build
commands are firmware, factorysetup, bootloader-stage0 and
bootloader-stage1. The stage targets build the selected development image;
explicit production/development aggregates remain available.

Primary builds and matching flash/run commands follow the saved DEBUG
setting, which can also be overridden per command. DEBUG=no selects
RelWithDebInfo for BitBox02/Nova and release for BitBox03; DEBUG=yes
selects debug builds. Without configuration, firmware keeps the existing
BitBox02 multi RelWithDebInfo default. Replace profile-specific Make
aliases with this shared setting.

Store builds in flat product directories, with CMake profiles in their
names, so switching products keeps previous artifacts and backend caches
available. Changing probe settings does not trigger recompilation.
Update CI and artifact consumers to follow the new commands and paths,
retaining debug build coverage and distinct artifact names.

Add matching flash-<image> and run-<image> commands using the saved probe
settings, with hardware derived from the board. J-Link probes support
SEGGER software or OpenOCD; the ST-Link dev-kit uses OpenOCD. Start
debug-server separately, then run-<image> loads and verifies the built
ELF, initializes its entry state and continues with GDB attached.
BitBox02 stage1 uses finalized contents when flashing or debugging, and
BitBox03 factorysetup runs from RAM without a reset after loading.

BitBox03 defaults to OpenOCD. Its testboard currently shares the dev-kit
build, both editions build the same stub, and the production board remains
disabled.

Validation: Python formatting, 48 configured build/probe routing cases,
removed aliases, retained stage aggregates and CI matrix/artifact names.
Hardware probe workflows remain unverified.
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a developer-facing build-system refactor. It replaces many hard-coded Make targets with a single saved configuration (product, board, edition, debug mode, probe tool) and adds Python helper scripts to build, flash, and debug firmware across BitBox02, Nova, and the upcoming BitBox03. There is no direct change to wallet cryptography, secure-boot checks, or firmware runtime behavior. The main security-relevant concern is that the new scripts handle flashing and GDB startup commands, so any bugs there could affect how firmware is loaded onto devices during development or factory setup.

Recommended action

Treat as a normal build-system change. Review the new `probe.py` and GDB init scripts for correct quoting, path handling, and vector-table initialization before relying on them for production hardware bring-up. Run the updated CI matrix and symbol checks to ensure reproducible artifacts. No security patch or incident response is indicated.

Security signals we found

01

New developer tooling controls how bootloader/firmware ELFs are flashed and how GDB initializes device state (VTOR/SP/PC/xPSR).

02

BitBox03 factorysetup is intentionally loaded into RAM and resumed without reset; a script bug could leave the device in an unintended state.

03

J-Link Commander flash script is generated in a temporary directory and uses quoted paths; path-quoting bugs are a potential, though low-severity, issue.

04

OpenOCD/J-Link server commands are constructed from saved config values (SWD speed, probe adapter); no untrusted input path is evident.

05

No changes to secure-boot verification, signature checks, memory protections, or cryptographic code.

Risk score

Why this scored 17/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 2/15
Confidence 8/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.