HiKey specifications

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

Summary

This page gathers the HiKey details that matter in practice: the hardware surfaces you touch, the boot paths people actually use, and the checks that tell you whether an image is behaving properly.

It is aimed at bring-up and maintenance, not at sales copy. Expect concrete commands, recovery assumptions, and a short checklist that helps before you start chasing deeper faults.

Who this is for

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

What you'll do

Start by identifying the board and confirming the CPU, memory, and storage layout from Linux. Then pick a boot method and decide what a clean boot should look like on your setup.

After that, check the basic connections first - network, USB, storage - before adding more software to the mix. The last step is the one that saves time later: run verification checks early so power or storage problems surface before they become harder to unwind, and keep a short troubleshooting flow ready for common failures.

Hardware overview (practical)

The most useful specification details are the ones you can verify from the running system. When you have a shell, confirm the SoC and CPU with cat /proc/cpuinfo and uname -a, then check RAM with grep MemTotal /proc/meminfo.

Storage needs the same treatment. Use lsblk and blkid to confirm the eMMC or SD layout, and check connectivity with ip a for network and lsusb for USB. Serial console access is still the sensible default for early boot logs and recovery. There is no substitute for that when something fails before userspace.

Supported OS images (internal)

Use the downloads page on this site and pick an image that explicitly names your board model. Before flashing, verify the checksum and keep a copy of the exact image file you used. That is what lets you reproduce a result instead of guessing which build ended up on the card.

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

Before first boot, make sure the power supply is stable and the cable is known good. Reliable storage matters just as much, along with a way to flash it from the workstation.

Keep a USB'TTL serial adapter to hand if you can. It is optional, but for recovery it is the difference between a clean diagnosis and a blind restart. Ethernet on first boot reduces variables, and a verified image means the checksum matches. The image should also include the basic tools: ip, lsblk, and 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 or 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 that you flashed the correct image for the exact model, and suspect power and storage first.

Kernel boots but no network: confirm interface names with ip a, then check for a default route with ip r.

Intermittent hangs: try a different PSU or cable first, then 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 or cable and misreading the symptoms as software faults.
  • Changing multiple variables at once - kernel, DTB, and userspace together.
  • 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