Nanopi M4v2 support request

The Nanopi M4v2 is out with DDR4 support, the NanoPC T4 image does not work on this board due to the DDR4. A supported DietPi image for this board would be greatly appreciated.

Thank you! :smiley:

purist
I linked your request to our general NanoPi M4 image request: https://github.com/MichaIng/DietPi/issues/2399
Hmm AFAIK then two images are required due to different RAM :thinking:. Does the T4 image work well on M4 otherwise? It should in theory but not all users reported success.

The T4 imager works for the most part, but not the M4v2.

Hey there, are there any tips for making this board (m4v2) work with Kodi (it seems to work in Armbian)?

Actually it should work, does it not?

Alas no (notwithstanding that I might be doing something dumb!)

This is a freshly flashed and installed image

root@DietPi:~# startkodi

X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-8-arm64 aarch64 Debian
Current Operating System: Linux DietPi 5.4.49-rockchip64 #20.05.7 SMP PREEMPT Sun Jun 28 18:17:52 UTC 2020 aarch64
Kernel command line: root=UUID=de090c8b-a8e7-471d-a04e-0d7c5d74aa66 rootwait rootfstype=ext4  consoleblank=0 loglevel=4 ubootpart=f0548abe-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u  
Build Date: 05 March 2019  08:11:12PM
xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
Current version of pixman: 0.36.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug 13 20:23:36 2020
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
ERROR: The DDK is not compatible with any of the Mali GPUs on the system.
The DDK was built for 0x860 r2p0 status range [0..15], but none of the GPUs matched:
(II) modeset(0): Initializing kms color map for depth 24, 8 bpc.
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.



dietpi@DietPi:~$ startkodi


X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-8-arm64 aarch64 Debian
Current Operating System: Linux DietPi 5.4.49-rockchip64 #20.05.7 SMP PREEMPT Sun Jun 28 18:17:52 UTC 2020 aarch64
Kernel command line: root=UUID=de090c8b-a8e7-471d-a04e-0d7c5d74aa66 rootwait rootfstype=ext4  consoleblank=0 loglevel=4 ubootpart=f0548abe-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u  
Build Date: 05 March 2019  08:11:12PM
xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
Current version of pixman: 0.36.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/dietpi/.local/share/xorg/Xorg.0.log", Time: Thu Aug 13 20:26:19 2020
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE) 
Fatal server error:
(EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/home/dietpi/.local/share/xorg/Xorg.0.log" for additional information.
(EE) 
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error



dietpi@DietPi:~$ sudo startkodi


X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-8-arm64 aarch64 Debian
Current Operating System: Linux DietPi 5.4.49-rockchip64 #20.05.7 SMP PREEMPT Sun Jun 28 18:17:52 UTC 2020 aarch64
Kernel command line: root=UUID=de090c8b-a8e7-471d-a04e-0d7c5d74aa66 rootwait rootfstype=ext4  consoleblank=0 loglevel=4 ubootpart=f0548abe-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u  
Build Date: 05 March 2019  08:11:12PM
xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
Current version of pixman: 0.36.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug 13 20:27:15 2020
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
ERROR: The DDK is not compatible with any of the Mali GPUs on the system.
The DDK was built for 0x860 r2p0 status range [0..15], but none of the GPUs matched:
(II) modeset(0): Initializing kms color map for depth 24, 8 bpc.
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.

yes starting as non-root user is actually not possible. I guess you would need to add user group tty, video and audio to user dietpi. Anyway the original issues still persist

ERROR: The DDK is not compatible with any of the Mali GPUs on the system.
The DDK was built for 0x860 r2p0 status range [0..15], but none of the GPUs matched

Can you please paste the output of this:

dmesg | grep -i mali

Ah is of original thread, you used the new M4V2 image from the download page, not the T4 one, right?

root@DietPi:~# dmesg | grep -i mali
[   28.186654] panfrost ff9a0000.gpu: mali-t860 id 0x860 major 0x2 minor 0x0 status 0x0

Its the pukka M4v2 image: DietPi_NanoPiM4v2-ARMv8-Buster.img

Any thoughts on how I can get it working?

Hmm probably the proprietary driver blob does not work with the open-source panfrost kernel driver.

Please try to install the Debian mesa driver packages:
apt install --reinstall libgles2 libegl1
Confirm oud itā€™s a downgrade and the libmali package will be removed.

Thanks, that does enable Kodi to start at least, although itā€™s smashing the processor even when idling (causing it to overheat in not much time) + thereā€™s no sound and no CEC (both of which work on this box with libreelec/armbian)

(also this kodi install doesnā€™t seem quite the same as the on the old raspberry pi (under diet-pi) it didnā€™t by default install the add-on repos for some reason?

Yes that is the generic Debian Kodi, now with Debian (Mesa) EGL/GLES drivers, and the respective Xserver version. Sound and CEC support are of course included, so I guess a configuration issue. I didnā€™t use Kodi for a long time, maybe others can help better, but recheck your ALSA/audio settings, check if aplay or any other audio player can play sound successfully.

libreelec is a pure Kodi OS, Iā€™d expect they support most boards better, despite RPi and Odroids where we simply have full support. The RPi foundation+community is quite active in developing and updating their kernel, GPU drivers/firmware and several GPU applications like Kodi and Chromium and others, so there we have no issue. (Plain) Armbian does not have any GPU support, does it? The community creates this media feature script, but that is basically made for Ubuntu, meanwhile quite outdated, so I donā€™t believe its working on a current Armbian Buster image, is it?

So basically it seems that for the ARM proprietary Mali drivers one needs a special kernel build or module at least, the Mali library blob of course, a special Xserver build on that and likely special Kodi build as well. The current Debian Buster open-source Mesa/panfrost drivers do not yet (fully) support RK3399, or the Kodi build does not work well with it. I read that panfrost and current Mesa (available on Debian Bullseye) has very good RK3328 support now, even better then ARM proprietary driver (to be tested), and read as well about Mesa 19 supporting RK3399 quite good already (Buster is on Mesa 18, Bullseye on Mesa 20). This means that Debian Bullseye potentially solves/enabled GPU supported for a bunch of SoCs.

I could create a M4V2 Bullseye image, interested to test it?
We anyway need to start testing Bullseye more broadly then only my VirtualBox instance I run changes through, so proper GPU/Kodi support seems a good reason for ā€œofficialā€ testing images.

Thanks for the update, yes Iā€™d be very happy to help with testing.

Confirmed that the closest Iā€™ve got to having this run satisfactorily so far has been with Armbian Bullseye.

I think that the issue with sound is tied to it wanting to play through the realtek codec (which I assume is the 3.5mm socket) and I can find no way to switch it to HDMI, it seems like kodi is just not seeing the CEC (I can see that the CECLib is installed, itā€™s just not seeing it for some reason).

Was having all sorts of bother getting it to work nicely with Kodi so Iā€™ve had a shuffle around and itā€™s been relegated to running Transmission, Couch Potato and PiHole, but itā€™s really unreliable.

Transmission regularly stops working, Ican log in and restart the transmission-daemon service but then quite often the whole lot just drops the ethernet connection and I have to powercycle it to get it back up (as I just get ā€˜no route to hostā€™ on ssh and can see via my router control panel that itā€™s not connected).

Any thoughts on how to improve the stability of transmission and the ethernet port on one of these boxes?

Hi,

check kernel messaged once the issue happen dmesg -l err,crit,alert,emerg
Plus, having a look to journal about related massages journalctl -n 100 --no-pager
Or dedicated for transmission messages journalctl -u transmission-daemon.service -n 100 --no-pager
Have a look as well to CPU + Mem usage.

Maybe there are some indications why services and connections are failing

Please have an eye on memory usage (by Transmission), e.g. via htop. On Debian Stretch there was a bug that made it using more and more memory until OOM killer kicks in. This should have been resolved but he had at least one other report that it still uses too much memory. Since we pull the official Debian build, this is a bid out of our control, but there is at least a way to limit itā€™s memory usage, worst case it needs a restart if it fails with that reached: https://github.com/MichaIng/DietPi/issues/2413#issuecomment-502152193

Thanks both,

Transmisson is at least restartable (incidentally how much memory is too much?), however I now canā€™t start Couchpotato at all

root@pihole:~# service couchpotato restart
Job for couchpotato.service failed because the control process exited with error code.
See "systemctl status couchpotato.service" and "journalctl -xe" for details.



root@pihole:~# systemctl status couchpotato.service
ā— couchpotato.service - LSB: CouchPotato PVR for Usenet and torrents
   Loaded: loaded (/etc/init.d/couchpotato; generated)
   Active: failed (Result: exit-code) since Wed 2020-09-16 20:40:10 BST; 1min 3s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 24198 ExecStart=/etc/init.d/couchpotato start (code=exited, status=2)

Sep 16 20:40:10 pihole systemd[1]: Starting LSB: CouchPotato PVR for Usenet and torrents...
Sep 16 20:40:10 pihole couchpotato[24198]: Starting CouchPotato:start-stop-daemon: matching on world-writable pidfile /var/run/couchpotato/couchpotato.pid is insecure
Sep 16 20:40:10 pihole couchpotato[24198]:  failed!
Sep 16 20:40:10 pihole systemd[1]: couchpotato.service: Control process exited, code=exited, status=2/INVALIDARGUMENT
Sep 16 20:40:10 pihole systemd[1]: couchpotato.service: Failed with result 'exit-code'.
Sep 16 20:40:10 pihole systemd[1]: Failed to start LSB: CouchPotato PVR for Usenet and torrents.

And I was just trying to get ā€˜journalctl -xeā€™ but itā€™s severed itself from the network (the router is showing it as disconnected, itā€™s given up on ethernet) so Iā€™ll leave this here for now, while I go and manually restart it.

Please try:

rm -R /run/couchpotato
systemctl restart couchpotato