Contact

Image symbolizing communication and support for the Contact page

Summary

If you are contacting support or posting a help request in the community forums, keep the first message tight and useful. Exact hardware, the image file, the symptoms, and any logs you can capture are the basics. Leave those out and the thread usually starts with the same request for more detail.

This page sets out what to gather, how to describe the problem clearly, and which details actually move a diagnosis forward. It is aimed at people who want a reply that goes beyond guesswork.

Essential information for every support request

Every request should carry the same core facts. Miss one, and the first response is often just a request for the missing piece.

  • Board identification - Give the exact model name, such as Banana Pi, Banana Pro, HiKey or HiKey 960. Add the hardware revision if it is printed on the board, plus the storage type - either the microSD brand and capacity or the eMMC module.
  • Operating system image - Include the full file name, the download source URL from this site, the file size, and the SHA checksum if one is available.
  • Power supply details - State the voltage and current rating printed on the adapter, the cable type and approximate length, and whether the board is powered through a hub or direct connection.
  • Network configuration - Note whether the board uses Ethernet or WiFi, the router or switch model, DHCP or a static IP, and any VLANs or other non-standard network setup.
  • Symptoms and timeline - Quote exact error messages, record LED patterns, say when the problem started, and mention what changed recently.
  • Troubleshooting already attempted - List what you have already tried so nobody repeats the same steps.

Describe the fault without losing the useful bits

A solid symptom report usually follows the same shape: what you expected, what happened instead, how to reproduce it, how often it appears, and how badly it blocks you. That is much more useful than a broad complaint, even when the problem feels obvious to the person writing it.

  1. Expected behaviour - Say what you thought would happen based on the documentation.
  2. Actual behaviour - State what actually happened, with exact error messages.
  3. Reproduction steps - Give the minimum steps needed to trigger the problem consistently.
  4. Frequency - Does it happen every time, intermittently, or only under specific conditions?
  5. Impact - Can you work around it, or does it stop progress completely?

Example: Poor symptom description

"My Banana Pi won't boot. I've tried everything. Please help!"

Example: Excellent symptom description

"My Banana Pi (revision 1.2, 16GB SanDisk Ultra microSD) shows red power LED but no green activity LED when powered with 5V 2.5A adapter. Used Etcher to flash 2025-11-20-raspbian-bananapi.img.xz (1.2GB, SHA256: abc123...) verified checksum before flashing. Tried two different microSD cards and two power supplies - same behaviour. No output on HDMI. Serial console (115200 8N1) shows no data. This is a new board that has never successfully booted."

Complete diagnostic log bundle

Run these commands and include the output in your support request:

#!/bin/bash
# Save this diagnostic data for support requests

echo "=== System Identification ==="
uname -a
cat /etc/os-release
uptime

echo -e "\n=== Hardware Information ==="
cat /proc/cpuinfo | grep -E "processor|model name|Hardware|Revision"
cat /proc/meminfo | grep -E "MemTotal|MemAvailable"
lsusb
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE

echo -e "\n=== Storage Health ==="
df -h
mount | column -t

echo -e "\n=== Network Configuration ==="
ip addr show
ip route show
cat /etc/resolv.conf
ping -c 4 -W 2 8.8.8.8

echo -e "\n=== Service Status ==="
systemctl --failed
systemctl status networking --no-pager -l
systemctl status ssh --no-pager -l

echo -e "\n=== Temperature Monitoring ==="
cat /sys/class/thermal/thermal_zone*/temp 2>/dev/null
sensors 2>/dev/null || echo "lm-sensors not installed"

echo -e "\n=== Recent Boot Errors ==="
journalctl -b -p err --no-pager | tail -n 100

echo -e "\n=== Kernel Messages ==="
dmesg --color=never | tail -n 100

echo -e "\n=== Boot Diagnostics ==="
dmesg --color=never | grep -i -E "fail|error|warn|mmc|usb|eth" | head -n 50

Log privacy and security

Before sharing logs publicly, strip out anything that should not be posted.

  • Redact authentication credentials - Passwords, API tokens, private keys, WiFi PSKs, certificate data
  • Remove personal information - Full names, email addresses, physical locations, phone numbers
  • Sanitise network details - Public IP addresses, internal hostnames if sensitive, domain names you do not want revealed
  • Replace sensitive data with placeholders - Use ***REDACTED*** to keep log structure intact while removing secrets
  • Review device identifiers - MAC addresses, serial numbers, unique hardware IDs may or may not be sensitive depending on context

See our privacy page for detailed guidance on safe log sharing practices.

Hardware-level debugging steps

If the board does not boot at all, start with power and storage. Those are the usual culprits, and they are easy to check.

  1. Verify power supply - Measure the actual voltage with a multimeter. It should be 5.0V '0.25V under load.
  2. Test multiple storage devices - Try at least two different microSD cards from different manufacturers.
  3. Check LED patterns - Note which LEDs light up, which colours they show, and any blinking sequences.
  4. Attempt serial console connection - Use a USB-to-TTL adapter at 115200 baud, 8N1, no flow control.
  5. Inspect physical board - Look for bent pins, corrosion, component damage, or foreign material on connectors.
  6. Try minimal configuration - Remove all peripherals except power, then test with no microSD card to check the bootloader.

Set up serial console access

Serial console is the most reliable debugging path when the network is not available. It gives you the boot messages that never make it to HDMI or SSH.

Hardware requirements

  • USB-to-TTL serial adapter (3.3V logic level, FTDI or CP2102 chipset recommended)
  • Three jumper wires (ground, TX, RX)
  • Pin header identification guide for your specific board

Connection procedure

  1. Power off board completely
  2. Connect GND (ground) pin from adapter to board GND
  3. Connect adapter TX to board RX
  4. Connect adapter RX to board TX (note the crossover)
  5. Plug adapter into computer, identify serial device (/dev/ttyUSB0 on Linux, COM3 on Windows)
  6. Open terminal: screen /dev/ttyUSB0 115200 (Linux) or PuTTY at 115200 8N1 (Windows)
  7. Power on board and observe boot messages

Common issues and first checks

  • No boot / no LEDs - Power supply inadequate, wrong voltage, or board hardware failure
  • Red LED only, no green activity - Storage media not detected, corrupt boot partition, or incompatible image
  • Boots but no network - Check Ethernet cable, switch port status, try DHCP then static IP configuration
  • SSH connection refused - Verify sshd service running, check firewall rules, confirm correct IP address
  • Random crashes - Suspect power supply instability, overheating, or failing storage media
  • Slow performance - Check CPU frequency governor, thermal throttling, swap configuration, and running processes
  • Storage corruption - Always suspect cheap or counterfeit microSD cards, and try known-good media

Community support resources

Other places to find help include the following:

Response time expectations

The first message sets the pace. A clear request usually moves faster because it gives people something specific to check.

  • Well-documented requests - Usually receive an initial response within 24-48 hours
  • Incomplete requests - May need several rounds of clarification, delaying resolution by days or weeks
  • Hardware failure symptoms - May require physical board inspection beyond remote diagnosis
  • Community forums - Response times vary by community activity and question complexity

Frequently asked questions

What if I can't get any output from serial console?

Check that the adapter logic level is 3.3V, not 5V, confirm the TX and RX connections are crossed correctly, set the baud rate to exactly 115200, and try a different serial adapter if you can.

Should I include photos or videos?

Photos help for LED patterns, board revision markings, physical damage, and connector identification. Videos help for intermittent issues, LED blink sequences, and display problems. They are not useful for text output - copy and paste that instead.

How much log output is too much?

Include 50-100 lines of the most relevant logs, usually errors from journalctl or dmesg. If the log is longer, use a pastebin service and include the link rather than pasting thousands of lines inline.

What if my issue isn't covered in documentation?

That is expected. Documentation cannot cover every scenario. Send the diagnostic bundle above and describe your specific situation in detail.

Can I contact LeMaker about hardware warranties?

This documentation site provides technical support. For warranty claims, contact your point of purchase or the vendor you bought the board from.

What if I need urgent help?

No support channel guarantees an immediate response. Prepare thorough documentation, try multiple community resources, and have a backup plan if you need to keep moving.

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