Add bootrom subcommand: dump or inspect the SoC mask-ROM region

[widgetii]

Summary

ipctool bootrom replaces the build-toolchain-scp-dump dance that came up repeatedly during the #161/#162 / #164 work. One command, no extra build, no separate dumper binary to maintain.

Default mode (YAML metadata)

bootrom:
  base: 0x04000000
  size: 65536
  accessible: 1
  first_bytes: 10 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5
  chip: hi3516av300

accessible: 0 means the region reads as all zeros — the Goke V4 case where the silicon hides the bootrom from userspace post-boot (caught during the #162 follow-up; see the kaeru lesson hisi-v4-bootrom-accessibility-differs-goke-vs-hisi).

CLI

ipctool bootrom [--base ADDR] [--size N] [--dump] [--json]
  --base ADDR   override per-family default (e.g. 0x04000000)
  --size N      override per-family default size in bytes
  --dump        write raw binary to stdout (redirect / pipe to md5sum)
  --json        machine-readable JSON metadata (ignored with --dump)

Matches the existing clocks / cpubench / membw shape.

Per-family defaults

Source: widgetii/HI3516CV500-SDK/sdk/bootrom/bootrom.cpp #define BOOTROM 0x04000000 + SRAM at 0x04010000, so 64 KB max. Empirically reconfirmed on V4 (#162 follow-up) and V4A (this PR).

Family	chip_generation	base	size
HISI_V4	0x3516E300	0x04000000	0x10000
HISI_V4A	0x3516C500	0x04000000	0x10000
Other	—	—	--base / --size required

Cross-board verification

ipctool bootrom --dump \| md5sum reproduces the stand-alone dump_bootrom.c results from the issue follow-up byte-for-byte:

Board	accessible	--dump | md5sum	First bytes
hi3516ev300 (V4 HiSi)	1	669081159f4fed97ad4db0bfd5251dca	10 00 00 ea 14 f0 9f e5 ... (ARM vector table)
gk7205v300 (V4 Goke)	0	fcd6bcb56c1689fcef28b57c22475bad	00 00 00 00 ... (all zeros, silicon hides ROM)
hi3516av300 (V4A)	1	1c2198a0a30c8258f5ab0c27aa523ff9	10 00 00 ea 14 f0 9f e5 ... (different mask than V4 — vector targets at 0x100 vs V4 HiSi's 0x120)

The accessible heuristic (all-zero buffer scan) correctly classifies all three real-world cases on first try.

What the diagnostic flow looks like now

# Inspect on a strange board
$ ipctool bootrom
bootrom:
  base: 0x04000000
  size: 65536
  accessible: 0          # ← Goke V4 silicon hides ROM
  first_bytes: 00 00 00 00 ...
  chip: gk7205v300

# Capture a real ROM for offline analysis
$ ipctool bootrom --dump > bootrom.bin
$ md5sum bootrom.bin
669081159f4fed97ad4db0bfd5251dca  bootrom.bin
$ xxd bootrom.bin | head

vs the previous procedure: build a static-ARM dumper with the cv100 toolchain, UPX-pack it, scp to the camera, chmod, run, scp the .bin back. About 90 seconds reduced to one ssh command.

Test plan

• bootrom (no flags) → YAML metadata, three boards behave as documented above
• bootrom --json → valid JSON via jq round-trip
• bootrom --dump | md5sum reproduces the stand-alone dumper MD5 on all three boards (byte-identical pipeline)
• bootrom --help → prints concise usage
• bootrom --size outside 1..16M → clean error
• cv100 toolchain build + UPX — no warnings under -Wextra
• Non-V4/V4A chip → bootrom: no first-party default for chip family 0x%x ... + clean exit 1 (verified by passing a fake chip via gdb; defaults table covers only V4 and V4A)

Known limitations (documented in --help)

• --base / --size accept any address. Reading non-bootrom MMIO regions byte-by-byte (e.g. CRG at 0x12010000) will SIGBUS as the kernel signals unaligned/word-only access. That's appropriate behavior — the per-family defaults are the supported path.
• --dump writes raw binary to stdout. Redirect to a file or pipe through xxd / md5sum; don't run it in an interactive terminal unless you want binary garbage on screen.

🤖 Generated with Claude Code