HiKey960
Summary
This page is a stable starting point for HiKey960 bring-up: a practical first-boot checklist, verification commands, and internal links to related topics. The aim is to help you confirm the board is healthy before you start debugging kernels, peripherals, or performance.
When behaviour is inconsistent, the fastest wins are usually power, storage quality, and having a recovery console (serial or local). This page is organised around that reality.
Who this is for
HiKey960 owners doing first boot, developers validating images after changes, and people migrating from older setups who want a repeatable baseline.
What you’ll do
- Prepare stable power and reliable storage.
- Boot with minimal peripherals and establish access (serial or SSH).
- Confirm system identity, storage layout, and basic connectivity.
- Capture a baseline boot report and keep it.
- Use troubleshooting steps to isolate power/storage/network issues.
Quick checklist
- Stable PSU and a known-good cable.
- Reliable storage (and a spare card/module for A/B testing).
- Ethernet for first boot (recommended).
- Optional: serial console adapter for recovery and early boot logs.
- A place to save baseline logs.
Steps / guidance
- Boot with minimal peripherals. Power + storage + Ethernet. Avoid hubs and high-draw USB devices initially.
- Confirm identity and resources.
uname -a cat /proc/cpuinfo | head -n 40 grep MemTotal /proc/meminfo - Confirm storage layout.
lsblk blkid - Confirm network.
ip a ip r - Capture a baseline boot report.
systemctl --failed journalctl -b -p err | tail -n 120 dmesg | tail -n 80 - Update once under supervision. Reboot, then repeat verification checks.
Verification checks
Use at least two after updates or hardware changes:
ip a
lsblk
dmesg | tail -n 50
journalctl -b -p err | tail -n 120
Troubleshooting
- No boot / stuck early: capture serial output; swap PSU/cable; try different storage.
- Random resets: suspect power first; reduce peripherals; use a simpler setup.
- No network: prefer Ethernet; check
ip aandip r; confirm DNS if relevant. - USB devices unreliable: check
dmesgimmediately after plug/unplug; avoid hubs initially; suspect power draw. - Services failing: use
systemctl --failedandjournalctl -b -p err.
Common mistakes
- Assuming a “working once” storage device is reliable.
- Adding many peripherals on first boot (making problems hard to reproduce).
- Changing kernel, userspace, and network settings in one session.
- Running headless without a recovery path.
- Not saving a baseline boot report.
Concrete example (basic health checks)
uname -a
systemctl --failed
journalctl -b -p err | tail -n 120
dmesg | tail -n 50
Author: LeMaker Documentation Team
Last updated: 2026-01-04