HiKey Second specifications

HiKey 960 specifications - Advanced schematic showing 3GB RAM, high-performance processor and interfaces

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-12