At the end of my review of “RPI All-in-One” PC with Raspberry Pi 4, I noted the system also appeared to be compatible with NanoPi M4V2 single board computer. I’ve now tried it out, and assembling the board inside the 10.1-inch display is even easier than I initially thought. That means I now have a NanoPi M4V2 All-in-One PC running Ubuntu Hirsute or Debian Buster with XFCE desktop environment from Armbian, and most features work including the display and wireless connectivity, but I still have an issue with the touchscreen function.
Here are the steps I followed initially:
- Download Armbian Buster XFCE image from Armbian and flash it to a microSD card with tools like USBimager.
- Insert the microSD card in the board
- Install the USB Type-C and HDMI-A adapters in the display.
- Insert the USB Type-C and HDMI port of the NanoPi M4V2 SBC into the adapters
- Install the RPI3 side plate from the display kit with openings for USB ports, Ethernet, and as well see below the antennas…
- Secure the board in the display with four screws (or three since I lost one)
- Install the USB cable (green, white, black) for the touchscreen display.
- Attach the two SMA connectors to the two remaining holes of RPI3 side plate
- Close the bottom cover of the display and secure it for the provided screws
- Install the two 2.4/5.8 GHz antennas
- Connect the power supply and profit!?
Not so fast! Did you really think it would be that easy? When Armbian boots it will ask the user to input a new root password in the terminal. So I connected my wireless keyboard USB dongle, and… I wasn’t able to type. I borrowed a USB keyboard, but I could not type… hmm what’s going on? I then decided to disconnect the USB touchscreen cable and it worked! I was able to complete the setup, configure WiFi and browse the web using a wireless mouse and keyboard.
It’s really odd the touchscreen does not work and causes other USB devices not to work. So let’s see what happens when we connect the USB cable:
Jan 23 14:43:46 nanopim4v2 kernel: [ 2022.707554] usb 5-1.3: new full-speed USB device number 5 using xhci-hcd
Jan 23 14:43:46 nanopim4v2 kernel: [ 2022.846721] usb 5-1.3: New USB device found, idVendor=0416, idProduct=c168
Jan 23 14:43:46 nanopim4v2 kernel: [ 2022.846742] usb 5-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 23 14:43:46 nanopim4v2 kernel: [ 2022.846751] usb 5-1.3: Product: MTouch
Jan 23 14:43:46 nanopim4v2 kernel: [ 2022.846758] usb 5-1.3: Manufacturer: TSTP
Jan 23 14:43:46 nanopim4v2 kernel: [ 2022.846765] usb 5-1.3: SerialNumber: CMTP_1.0
Jan 23 14:43:46 nanopim4v2 kernel: [ 2022.852061] usb 5-1.3: ep 0x81 - rounding interval to 32 microframes, ep desc says 40 microframes
Jan 23 14:43:56 nanopim4v2 kernel: [ 2032.895554] xhci-hcd xhci-hcd.8.auto: xHCI host not responding to stop endpoint command.
Jan 23 14:43:56 nanopim4v2 kernel: [ 2032.895589] xhci-hcd xhci-hcd.8.auto: Assuming host is dying, halting host.
Jan 23 14:43:56 nanopim4v2 kernel: [ 2032.909118] xhci-hcd xhci-hcd.8.auto: HC died; cleaning up
Jan 23 14:43:56 nanopim4v2 kernel: [ 2032.915224] usb 5-1: USB disconnect, device number 2
Jan 23 14:43:56 nanopim4v2 kernel: [ 2032.915259] usb 5-1.3: USB disconnect, device number 5
Jan 23 14:43:56 nanopim4v2 kernel: [ 2032.916507] usb 6-1: USB disconnect, device number 2
It’s perfectly recognized, but then there’s an error, and eventually, the xHCI host is halted and all USB peripherals disconnected. The Debian Buster image runs Linux 4.4, so maybe it’s a driver issue? I tried Armbian Bullseye (client/headless) image with Linux 5.10, but a similar issue occurred.
Scrolling down in Armbian, there are unstable images with Linux 5.13, I flashed Ubuntu Hirsute with XFCE, and nothing changed:
_ _ ____ _ __ __ _ ___ ______
| \ | | _ \(_) | \/ | || \ \ / /___ \
| \| | |_) | | | |\/| | || |\ \ / / __) |
| |\ | __/| | | | | |__ _\ V / / __/
|_| \_|_| |_| |_| |_| |_| \_/ |_____|
Welcome to Armbian 21.08.1 Hirsute with bleeding edge Linux 5.13.12-rockchip64
System load: 2% Up time: 17 min Local users: 2
Memory usage: 21% of 3.77G IP: 192.168.100.104
CPU temp: 45°C Usage of /: 32% of 15G
[ 4 security updates available, 14 updates total: apt upgrade ]
Last check: 2021-08-26 09:29
[ General system configuration (beta): armbian-config ]
jaufranc@nanopim4v2:~$ sudo tail -f /var/log/syslog
[sudo] password for jaufranc:
Jan 24 03:27:23 nanopim4v2 anacron: Updated timestamp for job `cron.daily' to 2022-01-24
Jan 24 03:27:23 nanopim4v2 systemd: Starting Daily apt upgrade and clean activities...
Jan 24 03:27:23 nanopim4v2 systemd: Starting Cleanup of Temporary Directories...
Jan 24 03:27:23 nanopim4v2 systemd: systemd-tmpfiles-clean.service: Succeeded.
Jan 24 03:27:23 nanopim4v2 systemd: Finished Cleanup of Temporary Directories.
Jan 24 03:27:23 nanopim4v2 systemd: apt-daily-upgrade.service: Succeeded.
Jan 24 03:27:23 nanopim4v2 systemd: Finished Daily apt upgrade and clean activities.
Jan 24 03:27:24 nanopim4v2 cracklib: no dictionary update necessary.
Jan 24 03:27:24 nanopim4v2 anacron: Job `cron.daily' terminated
Jan 24 03:29:11 nanopim4v2 systemd: Started Session 9 of user jaufranc.
Jan 24 03:30:01 nanopim4v2 CRON: (root) CMD (/usr/lib/armbian/armbian-truncate-logs)
Jan 24 03:30:01 nanopim4v2 CRON: (CRON) info (No MTA installed, discarding output)
Jan 24 03:30:09 nanopim4v2 kernel: [ 1089.411130] usb 3-1.2: new full-speed USB device number 5 using xhci-hcd
Jan 24 03:30:10 nanopim4v2 kernel: [ 1089.561002] usb 3-1.2: New USB device found, idVendor=0416, idProduct=c168, bcdDevice= 0.00
Jan 24 03:30:10 nanopim4v2 kernel: [ 1089.561044] usb 3-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 24 03:30:10 nanopim4v2 kernel: [ 1089.561068] usb 3-1.2: Product: MTouch
Jan 24 03:30:10 nanopim4v2 kernel: [ 1089.561087] usb 3-1.2: Manufacturer: TSTP
Jan 24 03:30:10 nanopim4v2 kernel: [ 1089.561105] usb 3-1.2: SerialNumber: CMTP_1.0
Jan 24 03:30:20 nanopim4v2 kernel: [ 1100.011163] xhci-hcd xhci-hcd.1.auto: xHCI host not responding to stop endpoint command.
Jan 24 03:30:20 nanopim4v2 kernel: [ 1100.011203] xhci-hcd xhci-hcd.1.auto: USBSTS:
Jan 24 03:30:20 nanopim4v2 kernel: [ 1100.024802] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
Jan 24 03:30:20 nanopim4v2 kernel: [ 1100.025575] xhci-hcd xhci-hcd.1.auto: HC died; cleaning up
Jan 24 03:30:20 nanopim4v2 kernel: [ 1100.027969] usb 3-1: USB disconnect, device number 2
Jan 24 03:30:20 nanopim4v2 kernel: [ 1100.028018] usb 3-1.2: USB disconnect, device number 5
Jan 24 03:30:20 nanopim4v2 kernel: [ 1100.029502] usb 4-1: USB disconnect, device number 2
Again, I can use the Ubuntu image and browse the web without issues. it’s just that nagging USB touchscreen issue.
Loading the hid-multitouch module with modprobe did not help. I’ve read somewhere that TSTP Mtouch drivers have been part of the Linux kernel for several years, so it may be a hardware issue instead…
The USB cable only carries GND and data signal, so the 5V signal comes from another location in the display, and I suspect there may be an issue with the 5V signal or grounding that makes the USB host turn it off completely. I haven’t found a solution yet.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
20 Replies to “Building a NanoPi M4V2 based All-in-One Linux PC running Armbian (Ubuntu/Debian)”
It definitely looks like a hardware issue. Usually such USB errors appear when you’re connected to a device that seems to short the pins (i.e. possibly not powered and pulling too much from the DM/DP pins through the protection diodes that route the voltage to the Vcc rails). Maybe something in your connections doesn’t work and the touchscreen is not properly powered (e.g. if it takes the power from the HDMI connector, maybe one optional pin is not connected). If you have an HDMI cable extender, you could try to connect the screen to another board and see if the touchpad continues to block USB. If not, it could confirm the issue is with the HDMI part not properly delivering power.
I have the exact same issue on the NanoPi M4V1, I’ve an externally powered HDD I use for backups, if connected everything else on the usb3 ports doesn’t work at all be it a pendrive or the remote for wireless keyboard. Not a big issue since I use it completely headless but sometime I have to make some work on console and it’s annoying to juggle with cables every time.
I seem to remember (but I have not rechecked) that there’s a USB3 hub on these boards, it’s possible that it’s powered from the same power rails that are delivered to the ports, through a regulator, and that if too much power is pulled there, the hub itself disappears.
I’ve only used thumb drives on my M4V1 and don’t remember observing such issues.
> there’s a USB3 hub on these boards
VIA Labs VL817-Q7
My apologizes Willy I’ve given a wrong explanation of the problem, it’s not the USB disk that’s unavailable, it’s everything else attached that doesn’t get recognized. And yes as tkaiser said every rear usb 3 port is connected to a VIA Labs usb switch.
That was my understanding, yes. If the USB hub is powered down, everything behind it disappears as well.
I’m guessing it’s what happens here because everything is taken down from the USB bus… I’ll try with a USB powered hub to see if it changes anything.
I’ve tried with a USB hub and a USB-powered hub, and the result is the same. Inserting the USB touchscreen cable will shut down the USB host.
It would be useful to connect one of these USB power-meters between the cable and the board (or another board) to completely rule out this aspect, then this will mean that it could be a signaling bug (e.g. the devices sending non-compliant frames or so).
Maybe you should try to connect the touchscreen to the 24-pin connector on 16 & 18 or 22 & 24. Then you keep the usb3 ports free and you minimize the problem of short circuit in the usb connector. I had once the same problem on my M8S tv-box and there I had to retract the usb stick a little bit and then usb worked again. It seemed when putting a usb-stick to far in the usb ports, it gave a short circuit that made the usb switch off.
Isn’t CPU on bottom side of Nanopi without heatsink(no space) and in enclosed space would melt into LCD panel, you should have tested thermals with this configuration.
Yes, correct the CPU faces down.
IMHO, there’s zero risk the CPU melts the LCD panel.
This is what the bottom looks like:
Based on the CPU temperatures we see in the terminal, the fan is still cooling the CPU, even though it’s far from an optimal configuration.
Debian Buster and kernels 4.4, 5.10, and 5.13? That’s a huge problem with third party SBC manufacturers, no good up-to-date software support. Also XFCE makes me worry how the legacy X graphics support will work after RPi and other systems have switched to Wayland/Pipewire by default. Vulkan capable systems with kernel 5.17 and Mesa 22 will perform a lot faster and have full video acceleration in browsers.
Jerry, care to elaborate exactly what you mean by “third party SBC manufacturers” ? How is a manufacturer a “third party” ? Maybe you wear “third party jeans”, drive a “third party car”, or take a “third party train” ? 🙂
“of, relating to, or being software that is created by a vendor to be compatible with the products of another vendor”
The typical workflow is: Customer (first party) buys products that either conform to the specs (form factor), or are directly produced by the second party (RPi Trading).
Ah, so you’re considering RPi as the second party hence the original, and the other ones as third parties. I’m having a different view where each of them benefitted from each other’s improvements. For example, regarding 64-bit support, RPi definitely is the third party since for many years they refused and claimed it was pointless, before finally accepting to adopt the obvious solution all others already adopted. Also it’s pretty possible that others did replace the RCA video connector with an HDMI connector before RPi did the same. Also you’ll note that among the vast majority of SBC, almost only the one that’s your reference still fails to provide storage, even optional, and continues to require the use of crappy SD cards that tend to be a showstopper in anything at least a little bit professional.
I may propose a stupid thing, but sometimes with low-quality USB hardware it helps to connect them through a powered USB hub.
Yep, that’s what Jean-Luc will try. We’re all putting him under pressure on this 🙂
Just received mine today. I’ll be attempting to use it with a Rock Pi 4. Judging by your photos I have a newer version as the main display board in mine shows as CX101PI-C_V2 while your photo shows CX101PI-C_V1. I wonder what was changed.
Don´t know, if it is to late, but I use the same Touch-Display with an Raspberry4, Raspi-Image and there are no problems.