Contact

Image symbolizing communication and support for the Contact page

Summary

When you contact support or post a help request in community forums, the fastest path to a useful answer is a short but complete report containing specific hardware details, exact image information, clear symptom descriptions, and relevant diagnostic logs. Well-prepared support requests often receive actionable responses within hours rather than days of back-and-forth clarification questions.

This page provides a comprehensive guide to gathering diagnostic information, describing problems effectively, and understanding what information actually helps resolve issues quickly.

Essential information for every support request

Include these specific details in every support inquiry:

  • Board identification - Exact model name (Banana Pi, Banana Pro, HiKey, HiKey 960), hardware revision if printed on board, and storage type (microSD brand/capacity or eMMC module)
  • Operating system image - Complete file name, download source URL from this site, file size, and SHA checksum if available
  • Power supply details - Voltage and current rating printed on adapter, cable type and approximate length, whether using hub or direct connection
  • Network configuration - Ethernet or WiFi, router/switch model, DHCP or static IP, any VLANs or non-standard network setup
  • Symptoms and timeline - Exact error messages (copy-paste, not paraphrased), LED patterns, when problem started, what changed recently
  • Troubleshooting already attempted - What you've already tried, so responders don't suggest duplicate steps

How to describe symptoms effectively

Good symptom descriptions follow this pattern:

  1. Expected behavior - What you thought would happen based on documentation
  2. Actual behavior - What actually happened, with exact error messages
  3. Reproduction steps - Minimum steps 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 completely block progress?

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 behavior. 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:

  • Redact authentication credentials - Passwords, API tokens, private keys, WiFi PSKs, certificate data
  • Remove personal information - Full names, email addresses, physical locations, phone numbers
  • Sanitize network details - Public IP addresses, internal hostnames if sensitive, domain names you don't want revealed
  • Replace sensitive data with placeholders - Use ***REDACTED*** to maintain log structure 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 doesn't boot at all:

  1. Verify power supply - Measure actual voltage with multimeter (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 - Document which LEDs illuminate, which colors, and any blinking sequences
  4. Attempt serial console connection - Use 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, test with no microSD card to check bootloader

Setting up serial console access

Serial console provides the most reliable debugging path when network fails:

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/counterfeit microSD cards, try known-good media

Community support resources

Additional places to find help:

Response time expectations

When submitting support requests:

  • Well-documented requests - Usually receive initial response within 24-48 hours
  • Incomplete requests - May require multiple 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?

Verify adapter logic level (must be 3.3V, not 5V), check TX/RX connections are crossed over correctly, confirm baud rate is exactly 115200, and try a different serial adapter if possible.

Should I include photos or videos?

Photos help for: LED patterns, board revision markings, physical damage, connector identification. Videos help for: intermittent issues, LED blink sequences, display problems. Not helpful for: text output (use copy-paste instead).

How much log output is too much?

Include 50-100 lines of the most relevant logs (errors from journalctl or dmesg). For longer logs, use a pastebin service and include the link rather than thousands of lines inline.

What if my issue isn't covered in documentation?

That's expected'documentation can't cover every scenario. Provide 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 immediate response. Prepare thorough documentation, try multiple community resources, and have a backup plan if waiting for support.

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