HiKey Second specifications
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
lsblkandblkid - USB and peripherals: validate detection with
lsusbanddmesg - 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
- Verify the download:
sha256sum hikey-second.img.xz sha256sum hikey-second.img - Flash and confirm the device:
lsblk blkid - Boot with minimal peripherals: power, storage, Ethernet. Add USB devices only after the baseline boot is stable.
- Confirm system identity and resources:
uname -a cat /proc/cpuinfo | head -n 40 grep MemTotal /proc/meminfo lsblk - Capture a baseline boot report:
journalctl -b -p err | tail -n 120 dmesg | tail -n 80 - 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 afor link,ip rfor a default route; prefer Ethernet for initial validation. - USB devices vanish: suspect power draw; test without hubs; check
dmesgimmediately 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
Related guides
Author: LeMaker Documentation Team
Last updated: 2026-01-04