Main Page

Summary

This is the curated hub for the LeMaker Wiki archive. Use it to find stable entry points for common tasks (first boot, login, GPIO work, bootloader/kernel builds) without having to guess which older page is relevant.

If you're unsure where to start, pick a board hub first, establish reliable access (serial or SSH), then capture a baseline boot report before making changes.

Who this is for

People new to LeMaker boards, developers doing bring-up or kernel work, and anyone migrating from older notes who needs a reliable 'start here' index.

What you'll do

• Choose a board hub or a task hub (login, GPIO, bootloader/kernel).
• Prepare a minimal bring-up setup that is easy to reproduce.
• Capture a baseline boot report and keep it for later comparisons.
• Use verification checks after any change to storage, kernel, or networking.
• Follow troubleshooting links when you need a quick recovery path.

Topics

• Banana Pro / Pi hub ' archived GPIO and bootloader notes.
• HiKey960 hub ' bring-up checks and access tips.
• LeMaker Guitar hub ' bring-up flow and related topics.
• Log in to the Banana Pi ' account/access basics.
• BananaPro/Pi: GPIO library ' GPIO tooling entry point.
• BananaPro/Pi: Building U-Boot, script.bin and Linux kernel ' bootloader/kernel workflow notes.
• WiringPi ' GPIO tooling notes (archival).

Common tasks

• First boot: verify the image, boot with Ethernet and minimal peripherals, then capture logs.
• Login/access: confirm SSH or local console access before you change networking.
• GPIO: start with a minimal test, confirm pin numbering, then build up.
• Bootloader/kernel: change one variable at a time and keep the last known-good artefacts available.

Quick checklist

• Stable PSU and cable.
• Known-good storage and a reliable writer.
• Ethernet for first boot (recommended).
• Optional: serial console adapter for early boot logs and recovery.
• A place to save a baseline boot report.

Steps / guidance

1. Choose your board hub

Navigate to the hub page that matches your hardware:

• Banana Pro / Pi hub ' Allwinner A20-based boards with GPIO, SATA, and (on Pro) WiFi/Bluetooth. Most documentation here is archival; for current quick-start guides, see the main site resources.
• HiKey960 hub ' ARM Cortex-A73/A53 development board with high-performance compute, PCIe, and UFS storage. Use this hub for bring-up checks, flashing procedures, and known limitations.
• LeMaker Guitar hub ' Actions S500 quad-core ARM Cortex-A9 board. Check here for bootloader workflow and GPIO library notes.

If unsure which board you have, check the silkscreen on the PCB or compare the port layout (SATA connector, WiFi antenna, etc.) with product photos.

2. Establish access method

Before making changes, verify you can log in reliably. Choose one or more of the following:

• SSH over Ethernet (recommended): Simplest for headless setups. Requires network and default credentials. See Log in to the Banana Pi for defaults.
• Local console (HDMI + keyboard): Useful if network is unavailable or you are debugging network configuration itself.
• Serial console (3.3V USB-to-TTL): Critical for bootloader work, early kernel debugging, or recovering from SSH misconfigurations. Connect TX/RX/GND to the board's debug header (check board pinout).

Test your access method with a simple command like uname -a before proceeding.

3. Confirm storage layout and health

Verify that storage is detected correctly and partitions are mounted as expected:

lsblk           # List block devices and partitions
blkid           # Show filesystem UUIDs and types
df -h           # Verify mount points and free space
dmesg | grep mmc  # Check for SD card or eMMC errors

If you see I/O errors or "XFS/ext4 error" messages, replace the storage media before debugging further.

4. Capture a baseline boot report

Save this output to a text file on your workstation. If behaviour changes after an update or configuration change, you can diff against the baseline to identify what broke:

uname -a                          # Kernel version
cat /proc/cpuinfo | head -n 20   # CPU details
ip a                              # Network interfaces
ip r                              # Routing table
systemctl --failed               # Failed services
journalctl -b -p err | tail -n 80  # Boot errors
dmesg | tail -n 50               # Recent kernel messages

Copy/paste this into a file named baseline-YYYY-MM-DD.txt on your workstation.

5. Proceed to board-specific tasks

Use the hub page links to access:

• GPIO work: GPIO library, WiringPi ' Confirm pinout and test a minimal example before scaling up.
• Bootloader/kernel: Building U-Boot and kernel ' Change one variable at a time and keep the last known-good artefacts available.
• Configuration: FEX Configuration ' For legacy systems using script.bin instead of device tree.

Critical: Do not mix instructions from different board hubs. GPIO pinouts, bootloader commands, and kernel configurations are not portable across different SoCs.

Verification checks

Pick at least two after flashing or updating:

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

Troubleshooting

Board does not boot or shows random resets

• Symptoms: Power LED on but no activity; board resets unpredictably; no serial output.
• Steps:
  1. Swap power supply and cable first. Use a 5V 2A or higher supply with a short, thick cable. Measure voltage at the board if possible (should stay above 4.75V).
  2. Try a different SD card or eMMC module. Flash from a freshly verified download.
  3. Remove all USB peripherals except keyboard (if using local console).
  4. Connect a serial console (3.3V USB-to-TTL) to capture bootloader and early kernel messages.
  5. Check for visible damage (blown capacitors, burn marks). If found, the board may be faulty.

Board boots but no network access

• Symptoms: Login prompt appears on serial/HDMI, but no DHCP lease or IP address on Ethernet interface.
• Steps:
  1. Check link LEDs on the Ethernet port. Try a different cable and switch/router port.
  2. Run ip a to see if eth0 is up. If "state DOWN", bring it up: sudo ip link set eth0 up.
  3. Verify DHCP client: ip r should show a default gateway. If missing, run sudo dhclient eth0.
  4. Check DNS: cat /etc/resolv.conf should list nameservers. Test with ping -c 3 8.8.8.8.
  5. Review network service logs: journalctl -u NetworkManager or journalctl -u systemd-networkd.

Services fail to start

• Symptoms: Boot completes but functionality is missing (no SSH, no web server, etc.).
• Steps:
  1. List failed services: systemctl --failed.
  2. Check service status: systemctl status SERVICE_NAME.
  3. Review logs: journalctl -u SERVICE_NAME -n 50.
  4. If a service depends on network, verify network is up first (ip a, ip r).
  5. Restart the service after fixing configuration: sudo systemctl restart SERVICE_NAME.

Inconsistent or intermittent behaviour

• Symptoms: Board works sometimes but not others; random lockups; filesystem corruption.
• Steps:
  1. Remove all non-essential peripherals (USB devices, extra displays, etc.).
  2. Swap power supply, cable, and SD card/eMMC before deeper investigation.
  3. Monitor temperature: cat /sys/class/thermal/thermal_zone0/temp. If above 80'C (80000 millidegrees), add cooling.
  4. Check for undervoltage warnings in dmesg (board-specific messages vary).
  5. Run a storage integrity check from another Linux system: sudo fsck.ext4 -f /dev/sdX2.

GPIO not working as expected

• Symptoms: Pins do not change state; permission errors when accessing /sys/class/gpio; conflicts with other functions.
• Steps:
  1. Confirm pinout using the board-specific hub page. Pin numbers vary between physical, BCM, and WiringPi numbering.
  2. Check if pin is already exported: ls /sys/class/gpio/.
  3. Verify user permissions: sudo usermod -aG gpio $USER (logout and login required).
  4. Test with a minimal example (LED blink) before building complex circuits.
  5. Check for pin conflicts with I2C, SPI, UART. Some pins are multiplexed and require device tree changes to use as GPIO.

Common mistakes

• Changing several variables at once (image + power + peripherals).
• Doing headless updates without a recovery console path.
• Assuming an SD card is reliable because it worked once.
• Not saving a baseline boot report.

FAQ

Which board hub should I start with?

Check the silkscreen on your board ("Banana Pi", "Banana Pro", "HiKey960", "LeMaker Guitar"). If still unsure, look for distinctive features: SATA connector (Banana Pi/Pro), WiFi antenna connector (Banana Pro), PCIe slot (HiKey960).

What is the difference between this wiki and the main site resources?

The main site (www.lemaker.org) has current quick-start guides, product specifications, and OS download links. This wiki contains archival technical notes (GPIO, bootloader work, FEX configuration) that are still useful for advanced users but may reference older software versions.

Do I need a serial console?

Not for typical usage. Serial consoles are essential for bootloader debugging, early kernel work, or recovering from SSH misconfigurations. If you plan to modify U-Boot or device tree files, a serial console is highly recommended.

Can I use instructions from Raspberry Pi tutorials?

Partially. GPIO pin numbering, bootloader commands, and kernel configurations differ. Userspace tools (Python GPIO libraries, SSH setup) are often portable. Always verify pinout and SoC-specific details against LeMaker documentation before assuming compatibility.

How do I know if my image uses FEX/script.bin or device tree?

Check the boot partition for script.bin (FEX) or .dtb files (device tree). Run ls /boot/ after booting. Device tree is standard for modern kernels (4.x+); FEX is legacy (3.4.x kernels). Use the FEX Configuration page only if your kernel is 3.4.x or documentation explicitly mentions script.bin.

What GPIO numbering scheme is used?

It varies by tool. Physical (pin 1-40 on the header), BCM (Broadcom GPIO numbers), WiringPi (WiringPi library numbering), and SoC (Allwinner PA/PB/PC/PD naming). Always confirm which scheme your library or script expects. Check the board-specific hub page for a pinout diagram.

Can I boot from USB or SATA instead of SD card?

On Banana Pi/Pro, booting from SATA requires U-Boot on the SD card to load the kernel from SATA. Full SATA-only boot (no SD card) is not supported by default. Some community builds enable USB boot. Check the bootloader documentation on your board's hub page.

How do I recover from a bad kernel or bootloader change?

Keep a known-good SD card with a working system as backup. If the board does not boot, swap back to the backup card. If you can reach U-Boot via serial console, you may be able to manually boot from a different partition or revert boot.scr changes. Always test changes on non-production boards first.

Where can I find community support?

Check the docs and search for your board model and error messages. For Linux kernel or driver issues, consider asking on linux-sunxi (for Allwinner SoCs) or board-specific IRC channels.

Concrete example (find a topic quickly)

Use your browser search (Ctrl+F) for:
- GPIO
- U-Boot
- login
- kernel
- serial
- device tree
- FEX
- pinout

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