“Supports secure boot” is incomplete unless it names the verified chain. ROM, first-stage loader, U-Boot, kernel, device tree and root filesystem can each have different signing and recovery behavior.
Build an evidence table
For each ArmSoM SKU record the SoC, boot media, loader build, key hierarchy, fuse state, debug policy and recovery procedure. Never infer a security property from Raspberry Pi or Jetson Nano documentation; their trust anchors and tooling differ.
cat /proc/cmdline
cat /proc/device-tree/compatible
dmesg | grep -iE 'verified|secure|rollback|avb'
These reads identify runtime context; they do not prove a production fuse configuration. Use the board manual and Rockchip security documentation for provisioning.
Product positioning
Sige5 (RK3576) and Sige7 (RK3588) target flexible Linux/Android development. Forge1 (RK3506J) targets industrial control with Buildroot. The right security design depends on update ownership, physical access and service life—not on TOPS or connector count.
References
Pre-publication check
- Name the exact boot chain and key owner.
- Separate lab debug from production fuse policy.
- Demonstrate recovery after a rejected image.