HiKey Second specifications

Illustration for HiKey Second specifications documentation

Summary

This page summarises the practical specifications you’ll rely on when bringing up HiKey Second: what to check first, how to verify an image is healthy, and how to separate “power/storage” problems from software issues.

It focuses on actions and verification rather than a marketing datasheet. If you keep a short baseline report from a known-good boot, troubleshooting later becomes much faster.

Who this is for

People booting HiKey Second for the first time, developers iterating on kernels/device trees, and anyone migrating an older setup to a new storage device.

What you’ll do

  • Confirm the board is powered correctly and visible over serial/USB where needed.
  • Verify the image file and flash to reliable storage.
  • Boot with minimal peripherals, then validate networking and system health.
  • Run repeatable checks (logs, devices, storage) before changing anything else.
  • Use a short troubleshooting flow when boot or connectivity fails.

Hardware overview (what matters for bring-up)

  • SoC / CPU: verify with cat /proc/cpuinfo
  • RAM: verify with grep MemTotal /proc/meminfo
  • Storage: confirm device layout with lsblk and blkid
  • USB and peripherals: validate detection with lsusb and dmesg
  • Serial console (optional but recommended): capture early boot failures and recover access when networking is broken

First boot checklist

  • Use a high-quality USB‑C cable and a stable PSU.
  • Boot with minimal peripherals (avoid hubs and high-draw devices initially).
  • Prefer Ethernet for first boot where possible.
  • Have a serial console option ready if you expect to change kernel/boot components.
  • Keep the verified image file and its checksum for later reference.

USB‑C power and cable quality

Unstable power and marginal USB‑C cables often show up as random resets, corrupted filesystems, or devices disappearing. If symptoms are inconsistent, swap the PSU/cable before assuming it is a software regression.

Quick checklist

  • Verified image (checksum matches).
  • Known-good storage (SD/eMMC as applicable).
  • USB‑C PSU + cable you trust.
  • Ethernet for first boot (recommended).
  • Optional: serial adapter for recovery.
  • Basic command set available: ip, lsblk, journalctl.

Steps / guidance

  1. Verify the download: 
    sha256sum hikey-second.img.xz
sha256sum hikey-second.img
  2. Flash and confirm the device: 
    lsblk
blkid
  3. Boot with minimal peripherals: power, storage, Ethernet. Add USB devices only after the baseline boot is stable.
  4. Confirm system identity and resources: 
    uname -a
cat /proc/cpuinfo | head -n 40
grep MemTotal /proc/meminfo
lsblk
  5. Capture a baseline boot report: 
    journalctl -b -p err | tail -n 120
dmesg | tail -n 80
  6. Update packages and reboot once: do this only after you have reliable access (serial or SSH).

Verification checks

Use at least two of these every time you change boot/kernel/storage:

ip a
ip r
lsblk
dmesg | tail -n 50
journalctl -b -p err | tail -n 120

Troubleshooting

  • No boot / stuck early: capture serial output; re-flash from a verified image; swap PSU/cable; try different storage.
  • Boots but no network: check ip a for link, ip r for a default route; prefer Ethernet for initial validation.
  • USB devices vanish: suspect power draw; test without hubs; check dmesg immediately after plug/unplug.
  • Filesystem errors: move to a new SD/eMMC; run with minimal write load until stable.
  • After update, access lost: use serial console; check journalctl -b -p err; revert the last change first.

Common mistakes

  • Using a poor-quality USB‑C cable and chasing intermittent software symptoms.
  • Testing multiple changes at once (kernel + DTB + userland).
  • Skipping checksum verification on downloads.
  • Attempting headless bring-up without a recovery path (serial or local console).
  • Assuming any SD card is “good enough” for repeated updates and logs.

Concrete example (confirm kernel logs are clean)

journalctl -b -p err | tail -n 120
dmesg | tail -n 50

External reference

Author: LeMaker Documentation Team
Last updated: 2026-01-04