HiKey

Illustration for HiKey documentation

Summary

HiKey is an ARM development board commonly used for Linux development and testing. This page is the “start here” guide: it tells you what you’ll do, what to have ready, and how to verify your first boot is healthy.

If you are bringing up a new image (or returning to a board after time away), follow the checklist and steps below before making changes—most hard problems become easier once power, storage, and access are reliable.

Who this is for

New board owners, developers validating images, and anyone who needs a repeatable first-boot checklist before debugging kernel or driver issues.

What you’ll do

  • Choose an image from this site, verify it, and flash to reliable storage.
  • Boot with minimal peripherals and establish stable access (serial or SSH).
  • Confirm network, storage, and service health with quick commands.
  • Update once under supervision, reboot, and re-check system health.
  • Use a short troubleshooting flow if boot or connectivity is unreliable.

Quick checklist

  • Stable PSU and cable (avoid undervoltage and flaky adapters).
  • Known-good storage (SD/eMMC depending on your setup).
  • Ethernet available for first boot (recommended).
  • Optional but recommended: serial console adapter for recovery.
  • Verified image file (checksum matches).
  • A way to capture a “known-good” baseline boot report.

Steps / guidance

  1. Get the correct image and verify integrity: 
    sha256sum hikey-image.img.xz
sha256sum hikey-image.img
  2. Flash to storage and confirm the device layout: 
    lsblk
blkid
  3. First boot with minimal peripherals: power + storage + Ethernet. Avoid adding USB devices until the baseline boot is stable.
  4. Establish access: use serial if available; otherwise confirm the board has an IP address and you can log in reliably (SSH or local console).
  5. Capture a baseline boot report (keep it): 
    uname -a
ip a
systemctl --failed
journalctl -b -p err | tail -n 120
dmesg | tail -n 50
  6. Update under supervision and reboot once: keep a console open; after reboot, repeat the verification checks.

Verification checks

At minimum, run two checks after every image flash or kernel update:

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

Troubleshooting

  • No boot: confirm the image matches the board model; re-flash from a verified download; then swap storage and PSU/cable if symptoms persist.
  • Boots but no network: check ip a for link and address; check ip r for a default route; prefer Ethernet for first validation.
  • Unstable behaviour: suspect power first; then storage; then drivers. Reduce peripherals to the minimum and re-test.
  • Services failing: use systemctl --failed and journalctl -b -p err; if you need the board stable quickly, revert the last change before debugging deeper.

Common mistakes

  • Skipping checksum verification and debugging a corrupted flash.
  • Trying Wi‑Fi first boot with unknown dongles instead of Ethernet.
  • Testing with a marginal PSU/cable and misreading the symptoms.
  • Making several changes at once (kernel + userspace + network settings).
  • Not keeping a serial recovery path when doing kernel work.

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