This document focuses on communication channel configuration for Qt development iteration scenarios. It is not a general board connection tutorial.

Development Environment Architecture

Windows 11 (Host)
  │
  ├─── USB OTG (Type-C) ──────────────────── LCSC-TaishanPi-3M Dev Board
  │         ↑ Serial debugging, ADB (operated from Windows side)
  │
  └─── VMware Bridged Network ──── Ubuntu 22.04 (VM / Development Environment)
                                    │
                                    └─── Ethernet (bridged, same subnet) ── LCSC-TaishanPi-3M Dev Board
                                              ↑ SSH, SCP, NFS (operated from Ubuntu VM)

Serial and ADB are operated from the Windows side. See: Serial Debugging, ADB Usage.

SSH / SCP / NFS and cross-compilation are all performed in the Ubuntu VM, which is the focus of this document.

Prerequisites

1. The board has been flashed with the Buildroot system and is connected to a router via Ethernet cable
2. The board's IP address has been confirmed via serial console (run ip addr show eth0 in the serial terminal and check the inet field)

This chapter has no dependency on SDK compilation and can be done in parallel while waiting for the full build to complete.

Ethernet configuration tutorial: Ethernet (Buildroot)

In the examples below, the board IP is 192.168.1.100 and the Ubuntu VM IP is 192.168.1.200. Replace these with your actual values.

Set root Password (Required)

Buildroot defaults to an empty root password, and most SSH clients (including MobaXterm) will refuse connections with empty passwords. Execute the following in the board's serial terminal:

passwd

After setting the password, all subsequent SSH and SCP operations will work properly.

SSH Connection

All operations below are performed in the Ubuntu VM.

# Connect to the board to test. If you can log in successfully after entering the password, the SSH channel is configured correctly.
ssh root@192.168.1.100

Configure Passwordless Login (Recommended)

# Generate key pair (skip if already exists)
ssh-keygen -t ed25519 -C "dev"

# Push public key to the board
ssh-copy-id root@192.168.1.100

If ssh-copy-id is not available, add manually:

cat ~/.ssh/id_ed25519.pub | ssh root@192.168.1.100 \
  "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

SCP File Transfer

SCP is suitable for occasional file transfers. Execute in the Ubuntu VM:

# Push build artifacts to the board
scp ./tspi-sysmonitor root@192.168.1.100:/root/

# Pull files from the board
scp root@192.168.1.100:/root/app.log ./

SCP is inefficient for frequent changes. NFS is recommended instead.

NFS Sharing (Preferred for Development Iteration)

The board directly mounts a directory on the Ubuntu VM. After compilation, no file transfer is needed — the board can immediately run the latest executable.

Configure NFS Server on Ubuntu VM

# Install
sudo apt update && sudo apt install nfs-kernel-server -y

# Create shared directory
sudo mkdir -p /srv/nfs/qt-dev
sudo chown -R $USER:$USER /srv/nfs/qt-dev

Edit /etc/exports and add the export rule:

/srv/nfs/qt-dev *(rw,sync,no_subtree_check,no_root_squash)

* allows access from all subnets — convenient for development environments. In production, restrict to a specific subnet such as 192.168.1.0/24. no_root_squash lets the board-side root retain root privileges, which is necessary for development environments.

Apply the configuration:

sudo exportfs -ra
sudo systemctl restart nfs-kernel-server
showmount -e localhost
# Expected output: /srv/nfs/qt-dev *

Mount NFS on the Board

mkdir -p /mnt/nfs
mount -t nfs -o nolock,vers=3 192.168.1.200:/srv/nfs/qt-dev /mnt/nfs

Verify: df -h | grep nfs

If you see mount: unknown filesystem t', it means the Buildroot image does not include the NFS client. You need to enable Target packages → Networking applications → nfs-utils in ./build.sh bconfig, then recompile and re-flash.

Auto-mount on boot (optional):

echo "192.168.1.200:/srv/nfs/qt-dev /mnt/nfs nfs nolock,vers=3 0 0" >> /etc/fstab

Ensure the Ubuntu VM's NFS service is ready when the board boots; otherwise, auto-mount failure will cause boot delays.

NFS mount hanging? Check the subnet

NFS requires the board to actively connect to the Ubuntu VM. If the board and VM are not on the same subnet (common when the board accesses the internet through Windows network sharing), NFS requests from the board cannot reach the VM, and mount will hang indefinitely.

Troubleshooting: Run ping <Ubuntu VM IP> on the board. If ping fails, the return route is broken. Solution: Change the VMware network adapter to bridged mode, bridging to the physical NIC that the board is connected to, so both sides are on the same subnet.

Communication Method Comparison

Method	Speed	Typical Use
SSH + SCP	High	Remote shell, occasional file transfers
NFS	High	Preferred for development iteration — run immediately after compilation
ADB	Medium	Fallback when network is unavailable (Windows side)
Serial	Low	Boot debugging, obtaining IP address (Windows side)

Next Step

After communication channel configuration is complete, first obtain the demo project source code, then choose a compilation method to start development.

Next: Demo Project tspi-sysmonitor

There are two development approaches — choose one:

• Prefer GUI → Qt-Creator Integration (recommended for beginners)
• Prefer terminal or need CI/CD → Command-Line Cross-Compilation

Both approaches use the same toolchain, produce identical build artifacts, and share the same deployment method.