HiKey Second specifications

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

Summary

HiKey Second bring-up lives or dies on the basics: power, storage, serial access and a clean first boot. This page sticks to those checks, with enough detail to separate a bad image from a bad cable and a flaky filesystem from a kernel problem.

That approach saves time later. Keep a short baseline report from a known-good boot and the next failure is usually easier to pin down.

Intended audience

This page suits anyone booting HiKey Second for the first time, developers working on kernels or device trees, and people moving an older setup to different storage. The flow is the same in each case: verify the image, flash to known-good storage, boot lean, then run a fixed set of health checks before changing anything else. Having a serial adapter available before you start is optional but strongly recommended if you expect to modify boot or kernel components.

Hardware checks at bring-up

The first pass is simple. Check the SoC and CPU with cat /proc/cpuinfo, confirm RAM with grep MemTotal /proc/meminfo, then verify the storage layout with lsblk and blkid. USB and peripheral detection should be checked with lsusb and dmesg.

The serial console is optional, but it is the sensible choice if you expect early boot failures or need a way back in when networking is broken. Relying on guesswork here is a bad habit.

First boot checklist

Use a high-quality USB-C cable and a stable PSU. Keep the first boot lean: no hub, no high-draw peripherals, and Ethernet if you can use it. If you expect to modify kernel or boot components, have serial access ready before you start. Keep the verified image file and checksum to hand for later checks.

In short, before powering on you want: a verified image with checksum matched; known-good storage, SD or eMMC as applicable; a USB-C PSU and cable you trust; Ethernet for first boot; an optional serial adapter for recovery; and the basic command set ip, lsblk, journalctl available.

USB-C power and cable quality

Unstable power and poor USB-C cables usually announce themselves as random resets, disappearing devices or a filesystem that quietly turns into a mess. If the symptoms are inconsistent, swap the PSU and cable before blaming the software.

Bring-up sequence

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 - but only after you have reliable access, serial or SSH.

Verification checks

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

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

Troubleshooting

Most failures fall into a small number of patterns. No boot or a very early hang almost always points to a bad image, a marginal PSU or a cable problem - capture serial output first, then re-flash from a verified image, and swap PSU and cable before trying different storage. If the board boots but has no network, check ip a for link state and ip r for a default route; Ethernet is much easier to validate than Wi-Fi at this stage.

USB devices that vanish intermittently are almost always a power draw issue. Test without hubs and check dmesg immediately after plug and unplug. Filesystem errors are a different matter: move to a new SD card or eMMC and run with minimal write load until the system is stable - do not try to repair a card that is already behaving oddly under a new OS.

If you lose access after a package update, reach for the serial console, check journalctl -b -p err, and revert the last change before trying anything else.

Common mistakes

A poor-quality USB-C cable is responsible for a disproportionate number of intermittent failures that get blamed on software. Check the cable first. Equally common is changing several variables at once - kernel, DTB and userland together - which makes root cause analysis nearly impossible. Change one thing, verify, then move on.

Skipping checksum verification on downloads is a small shortcut that occasionally costs a lot of time. Doing a headless bring-up with no recovery path, serial or local console, is a similar gamble. And not every SD card handles repeated updates and log writes well; assuming otherwise is a mistake you usually only make once.

Concrete example (confirm kernel logs are clean)

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

External reference

Linux kernel documentation (docs.kernel.org)

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