About

Image representing collaboration and community for the About page

Summary

LeMaker documentation focuses on practical bring-up notes, downloads guidance, and small checklists you can follow on real hardware. Every page emphasizes repeatable steps, clear assumptions, and verifiable outcomes rather than lengthy theory or marketing claims. Whether you're deploying your first single-board computer or maintaining a fleet of edge devices, you'll find concrete procedures tested on actual hardware.

This documentation site serves as a comprehensive technical reference for LeMaker single-board computers including Banana Pi, Banana Pro, HiKey, and HiKey 960. It preserves years of community knowledge, troubleshooting procedures, and hard-won insights from real-world deployments across education, development, and production environments.

What makes this documentation different

Unlike generic board documentation that lists specifications without context, LeMaker guides answer the practical questions users actually face:

  • Real command examples - Every procedure includes copy-paste ready commands with expected output
  • Troubleshooting integrated throughout - We document what goes wrong and how to fix it, not just happy-path scenarios
  • Hardware context matters - Power supply quality, cable length, and storage media brand impact success rates
  • Validation at every step - Know what success looks like with specific LEDs, log messages, and health checks
  • Stable long-term references - URLs remain consistent to support bookmarks, citations, and educational materials

Who this documentation serves

Our documentation targets several key audiences:

  • Hobbyists and makers - First-time SBC users building home automation, media centers, or learning projects
  • Educators and students - Teaching environments where reliable setup procedures prevent wasted class time
  • Developers and engineers - Professional contexts requiring stable reference platforms for embedded development
  • System administrators - Edge deployment scenarios needing documented maintenance and troubleshooting procedures
  • Researchers - Academic projects citing stable documentation URLs in papers and grant applications

How to use this site effectively

For the best results, follow this workflow:

  1. Start with your board overview page - Understand capabilities, limitations, and typical use cases before purchasing
  2. Read the specification page - Know which interfaces matter for your project and what power/storage you'll need
  3. Follow downloads guidance - Verify image checksums before flashing to catch corrupt downloads early
  4. Use the concrete examples - Run the provided commands to validate expected behavior at each stage
  5. Keep troubleshooting sections bookmarked - Quick triage checklists save hours when issues arise
  6. Follow internal links - Related guides provide context without leaving the documentation ecosystem

Documentation structure and conventions

Every technical page follows a consistent structure:

  • Summary - Two to four sentences explaining what the page covers and who needs it
  • Prerequisites - Required hardware, software, and knowledge before proceeding
  • Step-by-step procedures - Numbered instructions with specific commands and expected outcomes
  • Validation checks - How to confirm each step succeeded before moving forward
  • Troubleshooting - Common symptoms, probable causes, and specific fixes
  • FAQ - Frequently asked questions answered with practical examples
  • Related guides - Internal links to prerequisite and next-step documentation

Collecting a diagnostic report

When troubleshooting or requesting help, gather this baseline information:

# System identification
uname -a
cat /etc/os-release

# Hardware health
df -h
free -h
cat /sys/class/thermal/thermal_zone0/temp

# Service status
systemctl --failed
systemctl status networking

# Recent errors
journalctl -b -p err | tail -n 80
dmesg --color=never | grep -i -E "error|fail|warn" | tail -n 50

# Network connectivity
ip a
ip route
ping -c 4 8.8.8.8

Quality standards and testing

All procedures documented here meet these criteria:

  • Tested on actual hardware - Commands run on real LeMaker boards, not emulators
  • Multiple OS versions - Verified across different distributions when relevant
  • Clear scope boundaries - We document what we've tested, not theoretical possibilities
  • Regular review cycles - Content updated as software and best practices evolve
  • Community feedback - Procedures refined based on user reports and forum discussions

Privacy and data handling

When sharing logs publicly, redact secrets (tokens, passwords, private keys) and any personal data you do not want published. Use placeholders like ***REDACTED*** to indicate removed content while preserving log structure. See our privacy page for detailed guidance on safely sharing diagnostic information.

Content philosophy

Our editorial approach prioritizes:

  • Accuracy over completeness - Better to document what we know works than speculate
  • Practical over theoretical - Show how to accomplish tasks, not just explain concepts
  • Specific over generic - Name exact file paths, package versions, and board revisions
  • Stable over trendy - Focus on reliable fundamentals, not cutting-edge experiments
  • Accessible over expert-only - Write for intermediate users who can learn advanced topics

Frequently asked questions

Why aren't there video tutorials?

Text documentation is searchable, accessible, translatable, and easy to update. Videos go out of date quickly and can't be searched effectively. Screenshots supplement text when visual identification matters.

Can I contribute corrections or improvements?

Report issues through our contact page with specific page URLs, the incorrect information, and proposed corrections with sources.

Why do some procedures vary by OS distribution?

Different distributions use different package managers, network configuration tools, and service managers. We document the most common variations and indicate which distribution each command applies to.

How often is documentation updated?

Core pages receive quarterly reviews. Time-sensitive content (download links, security procedures) updates as needed. Last-updated dates appear at the bottom of each page.

Why keep documentation for older boards?

Many users continue running LeMaker hardware in long-term deployments. Stable documentation URLs support ongoing projects, educational materials, and reference systems that don't change frequently.

What if the procedure doesn't work for me?

Review the troubleshooting section first. If issues persist, gather diagnostic output using the commands on this page and submit a detailed report via our contact page.

Can I link to this documentation from my project?

Yes, all pages maintain stable URLs specifically to support external references from projects, papers, courses, and other documentation. Deep linking to specific sections is encouraged.

Why UK English spelling?

Consistency matters more than dialect. We chose UK English and maintain it throughout. Technical terms, commands, and code remain standard across all English variants.

Documentation continuity commitment

This site maintains stable URLs and preserves historical content to ensure long-term reference availability. Pages remain accessible at their original locations, supporting ongoing projects and educational materials that link to these resources. We update content regularly while maintaining compatibility with bookmarks and citations from external sources. This approach provides reliable documentation regardless of when users first discovered these guides.

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