HiKey specifications

HiKey specifications - Technical diagram with ARM Cortex-A53 processor, memory layout and interfaces

Summary

This page collects the practical specifications you need when working with a HiKey board: what hardware surfaces you'll interact with, what boot paths are commonly used, and the checks that confirm your image is behaving correctly.

It's written to support bring-up and maintenance rather than marketing: you'll find concrete commands, recovery assumptions, and a checklist you can run through before you start debugging deeper issues.

Who this is for

Developers bringing up a fresh image, people validating a board after storage changes, and anyone who needs a quick reference while working on kernels, device trees, or userspace updates.

What you'll do

  • Identify the board and confirm the CPU, memory, and storage layout from Linux.
  • Pick a boot method and understand what 'good boot' looks like.
  • Confirm basic connectivity (network, USB, storage) before installing extra software.
  • Run verification checks to catch power/storage issues early.
  • Triage common failures with a short, repeatable troubleshooting flow.

Hardware overview (practical)

The most useful 'spec' details are the ones you can verify from the running system. When you have a shell, confirm:

  • SoC / CPU: cat /proc/cpuinfo and uname -a
  • RAM: grep MemTotal /proc/meminfo
  • Storage: eMMC/SD layout via lsblk and blkid
  • Connectivity: network via ip a, USB via lsusb
  • Serial console: recommended for early boot logs and recovery

Supported OS images (internal)

Use the downloads page on this site and choose an image that explicitly names your board model. Before flashing, verify the checksum and keep a copy of the exact image file you used so you can reproduce results.

Boot options (what to expect)

  1. Fastboot-style bring-up (where applicable): useful for iterative kernel testing; keep a serial console open so you can capture boot logs.
  2. SD card boot: simplest for testing images; prioritise a high-quality card to avoid intermittent failures.
  3. eMMC boot: preferred for stability once you've validated the image; treat the flash process as a change that needs verification checks.

Quick checklist

  • Stable power supply and a known-good cable.
  • Reliable storage (SD/eMMC) and a way to flash it from your workstation.
  • Optional but recommended: USB'TTL serial adapter (3.3V) for recovery.
  • Ethernet available for first boot (reduces variables).
  • Verified image (checksum matches).
  • Basic tools on the image: ip, lsblk, journalctl.

Steps / guidance

  1. Verify the image: 
    sha256sum hikey-image.img.xz
sha256sum hikey-image.img
  2. Flash to storage and confirm partitions: 
    lsblk
blkid
  3. First boot with minimal peripherals: Ethernet and serial (if available). Avoid adding USB devices until the system is stable.
  4. Confirm identity and resources: 
    uname -a
cat /proc/cpuinfo | head -n 40
grep MemTotal /proc/meminfo
lsblk
  5. Update under supervision: keep a console open, update packages, then reboot once.
  6. Record a short boot report: save the output of journalctl and dmesg when the system is healthy. It becomes your baseline for later comparisons.

Verification checks

Run these after first boot and after any kernel/storage changes:

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

Kernel / device tree note

If you are testing kernels or device trees, change one variable at a time (kernel, DTB, or rootfs). Keep the last known-good combination available so you can revert quickly when a regression appears.

Troubleshooting

  • No boot / stuck early: capture serial logs; re-check you flashed the correct image for the exact model; suspect power and storage first.
  • Kernel boots but no network: confirm interface names with ip a; check for a default route with ip r.
  • Intermittent hangs: try a different PSU/cable; then try different storage; then reduce peripherals.
  • USB devices not detected: check dmesg | tail -n 50 after plugging in; test with a powered hub if the device is high-draw.
  • Services failing after update: use systemctl --failed and journalctl -b -p err; revert the last change if you need the board stable quickly.

Common mistakes

  • Skipping checksum verification and debugging a corrupt image.
  • Testing with an unreliable PSU/cable and misreading symptoms as software faults.
  • Changing multiple variables at once (kernel + DTB + userspace).
  • Attempting headless bring-up without a serial recovery option.
  • Assuming storage is fine because it works on a laptop'SBC workloads can expose marginal cards.

External reference

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