HiKey Second

Illustration for HiKey Second documentation

Summary

HiKey Second is a development board used for Linux testing and prototyping. This page is the practical “first stop”: it provides a first-boot checklist, guidance on power and access, and a safe flow for validating the system before you start changing kernels or peripherals.

The key outcome is a repeatable bring-up: you can flash an image, boot reliably, confirm storage/network/log health, then keep a short baseline report to compare against future changes.

Who this is for

New board owners, developers validating images, and people migrating from older setups who need a stable first boot before any deeper debugging.

What you’ll do

  • Prepare stable power and storage, then flash a verified image.
  • Boot with minimal peripherals and establish access (serial or SSH).
  • Run quick checks for storage, networking, and service health.
  • Update once under supervision and reboot.
  • Use a focused troubleshooting checklist for common failures.

First boot checklist

  • USB‑C PSU + cable you trust (cable quality matters).
  • Known-good storage (SD/eMMC as applicable) and a reliable writer.
  • Ethernet for first boot (recommended).
  • Optional but recommended: serial console adapter for early boot and recovery.
  • Verified image file (checksum matches).

USB‑C power + cable quality warning

If you see inconsistent behaviour (random resets, storage corruption, USB devices dropping), swap the cable and PSU before changing software. Marginal USB‑C cables are a very common root cause on development setups.

Quick checklist

  • Verified image (checksum matches).
  • Stable USB‑C power and cable.
  • Minimal peripherals for first boot.
  • Ethernet cable for initial access.
  • Optional: serial console adapter.
  • Spare storage for A/B testing.

Steps / guidance

  1. Get an image and verify it.

    Use the internal downloads page and verify integrity before flashing:

    sha256sum hikey-second.img.xz
sha256sum hikey-second.img
  2. Flash to storage and confirm the device layout. 
    lsblk
blkid
  3. Boot with minimal peripherals. Power + storage + Ethernet. Avoid hubs and high-draw USB devices initially.
  4. Establish access. Serial console is optional but very helpful. If using SSH, confirm you can log in reliably before making changes.
  5. Run baseline checks and save them. 
    uname -a
ip a
ip r
lsblk
systemctl --failed
journalctl -b -p err | tail -n 120
dmesg | tail -n 50
  6. Update once under supervision. Reboot, then repeat the verification checks.

Where to get images (internal)

Verification checks

Pick at least two after flashing or updating:

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

Troubleshooting

  • No boot: swap PSU/cable; re-flash from a verified image; try different storage; capture serial logs if available.
  • Boots but no network: check ip a and ip r; prefer Ethernet for first validation.
  • USB devices unstable: remove hubs and high-draw devices; check dmesg after plug/unplug; suspect power.
  • Filesystem errors: treat as storage until proven otherwise; move to new storage and retry.
  • Services failing: use systemctl --failed and journalctl -b -p err.

Common mistakes

  • Using a poor-quality USB‑C cable and chasing intermittent behaviour as a software issue.
  • Skipping checksum verification.
  • Adding many peripherals on first boot (making failures hard to reproduce).
  • Attempting headless bring-up without a recovery path (serial/local console).
  • Updating immediately without first capturing a baseline boot report.

Concrete example (basic checks)

uname -a
ip a
systemctl --failed
journalctl -b -p err | tail -n 80

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