Dietpi: Image | NanoPi M4

[N3mill0]

Specs:
https://www.friendlyarm.com/index.php?route=product/product&product_id=234

Give us some formal device information:

• Device name | NanoPI M4
• Official product URL | https://www.friendlyarm.com/index.php?route=product/product&product_id=234

Is the SBC officially supported by the Debian installer?

• No

If not, is a reliable 3rd party Debian image available for this SBC?

• Armbian

[MichaIng]

@N3mill0
Thanks for your request.

I added it to FeatHub: https://feathub.com/MichaIng/DietPi/+33

[cocoflan]

I hope i get an native installer image soon for my nanopi M4!

[jftuga]

Is there any update on this?

Thanks.

[MichaIng]

@jftuga
Currently the device and man power is missing.

If you want you could help testing DietPi on your NanoPi M4 (if you have one) and building an image.

Steps would be:

• Download and flash: https://dl.armbian.com/nanopim4/Debian_stretch_default.7z
  
  
  
  • FriendlyELEC itself ships Android and Ubuntu images only...
  
  
• Then run DietPi-PREP on it: https://github.com/MichaIng/DietPi/issues/1285#issue-280771944
  
  
  
  • Select "22 Generic device" when asked for device model.
  
  

If the installer walks through nicely and reboot works well, then we can start adding the M4 with separate device ID to our code and do fine tuning + configuration options.

[cocoflan]

Did all the steps a while ago and system works, is there anything else i can help you with ?
The installer walked through nicely and reboot worked well.

Image : COCOFLAN NANOPI M4 (pre-image: NANOPI M4 2GB)

you can always contact me at e-mail: christophe.[email protected]

Greetings

Van: "MichaIng" [e-mail]
Aan: "MichaIng/DietPi" [e-mail]
Cc: "cocoflan" [e-mail], "Comment" [e-mail]
Verzonden: Zaterdag 30 maart 2019 19:57:56
Onderwerp: Re: [MichaIng/DietPi] Image | NanoPi M4 (#2399)

[ https://github.com/jftuga | @jftuga ]
Currently the device and man power is missing.

If you want you could help testing DietPi on your NanoPi M4 (if you have one) and building an image.

Steps would be:

* Download and flash: [ https://dl.armbian.com/nanopim4/Debian_stretch_default.7z | https://dl.armbian.com/nanopim4/Debian_stretch_default.7z ] 
    * FriendlyELEC itself ships Android and Ubuntu images only... 
* Then run DietPi-PREP on it: [ https://github.com/MichaIng/DietPi/issues/1285#issue-280771944 | #1285 (comment) ] 
    * Select "22 Generic device" when asked for device model.

If the installer walks through nicely and reboot works well, then we can start adding the M4 with separate device ID to our code and do fine tuning + configuration options.

—
You are receiving this because you commented.
Reply to this email directly, [ https://github.com/MichaIng/DietPi/issues/2399#issuecomment-478277872 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AAY6mC11rTPxTPYVBVQPOphNF3ngxIBUks5vb7O0gaJpZM4Z09go | mute the thread ] .

[MichaIng]

@cocoflan
This is great does basic sound and video functionality work?

If you don't mind could you send a bug report? Even if no error happens you can use dietpi-bugreport, so I can check system logs and service statuses etc for any unusual behaviour.

[MichaIng]

Now that I had a closer look. I think our NanoPC T4 image can be used for NEO4 and M4 as well since they share the same core chip: https://dietpi.com/downloads/images/DietPi_NanoPCT4-ARMv8-Stretch.7z

Especially since it's an installer, AFAIK. Also the FriendlyCore image for all three boards is the same and looks similar than ours from the file structure. Of course DietPi will show the wrong SBC name but as long as we do not access special features that only one of these have (and I am not aware of), it should work. We could rename the device ID to NanoPi T4/M4/NEO4 similar to what we did for the 2nd and 3rd generation NanoPi M3/T3/F3 (F3 = Fire3) and NanoPi M2/T2. NanoPi for all the T variants is actually not correct naming (it's NanoPC there), but we didn't take care about this in the past 😉.

@cocoflan
Only if you find time and have a spare SDcard, it would be great if you could test this. I am not sure which image was the source for our NanoPC T4 image, I will check this out.

[jftuga]

@MichaIng: I have been monitoring this thread for awhile now and was hoping it would become officially supported before purchasing. Based on your last reply and @cocoflan's information, I will purchase one today and run through the steps listed above. This way, you can have two confirmed reports of successful installs and/or help locate any remaining issues. I currently have 2 new 32GB SD cards that I can be testing this with.

[MichaIng]

@jftuga
That is great. Especially helpful would be indeed if our NanoPC T4 image works. It is not clear if there are some uboot/kernel/firmware/dtb parameters based on hardware capabilities outside of the RK3399 chip.

[cocoflan]

I have send a bug report, could i be informed if you find some things

Greetings

Van: "MichaIng" [e-mail]
Aan: "MichaIng/DietPi" [e-mail]
Cc: "cocoflan" [e-mail], "Mention" [e-mail]
Verzonden: Zondag 31 maart 2019 17:28:21
Onderwerp: Re: [MichaIng/DietPi] Image | NanoPi M4 (#2399)

[ https://github.com/cocoflan | @cocoflan ]
This is great does basic sound and video functionality work?

If you don't mind could you send a bug report? Even if no error happens you can use dietpi-bugreport , so I can check system logs and service statuses etc for any unusual behaviour.

—
You are receiving this because you were mentioned.
Reply to this email directly, [ https://github.com/MichaIng/DietPi/issues/2399#issuecomment-478351483 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AAY6mD7FHiFM1-I0Ay3P6IxuY7e_qOkOks5vcNQVgaJpZM4Z09go | mute the thread ] .

[MichaIng]

@cocoflan
Couldn't find the bug report. Which ID did it prompt after sending?

[cocoflan]

cf33b03e-575c-49e5-9455-e3a0ad85561f

Greetings

Van: "MichaIng" [e-mail]
Aan: "MichaIng/DietPi" [e-mail]
Cc: "cocoflan" [e-mail], "Mention" [e-mail]
Verzonden: Donderdag 4 april 2019 23:08:55
Onderwerp: Re: [MichaIng/DietPi] Image | NanoPi M4 (#2399)

[ https://github.com/cocoflan | @cocoflan ]
Couldn't find the bug report. Which ID did it prompt after sending?

—
You are receiving this because you were mentioned.
Reply to this email directly, [ https://github.com/MichaIng/DietPi/issues/2399#issuecomment-480064600 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AAY6mEBb5cytg_FTLudA4rPsbzfdYoNEks5vdmnngaJpZM4Z09go | mute the thread ] .

[cocoflan]

Video works even with 3d, 33 frames on glmark2.
Audio i cant select any other audio device than HDMI, audio works well with external usb dac.

[N3mill0]

I´m trying to install TC4 image on my M4 but I can´t enter into MASKROM mode. How can I install that image without AndroidTool. I can flash my EMMC like a MicroSD, I have purchased a EMMC -> MicroSD adapter.

EDIT: Installed via Armbian + DietPi-PREP. Working well, bug reported with ID 55df2c21-1c4c-4993-ab14-d889ba49bc91

Thanks

[MichaIng]

@N3mill0
Ah I see, it looks like our AndroidTool based installer works only with the T4 in particular. An idea would be to ship an SDcard image as well which can then be flashed onto either SDcard or eMMC (via adapter). Although not 100% sure if this works due to different drive naming. Would require uboot to be based on UUID only.

[cocoflan]

Any update on testing the nanopc T4 image on the nanopi M4, someone?

[jspanitz]

Any update on an M4 image? Really want to order a few and load dietpi on them to deploy as an Emby server and a NAS.

[MichaIng]

NanoPi M4v2: https://dietpi.com/phpbb/viewtopic.php?f=12&t=6451

[MichaIng]

@N3mill0 @cocoflan @jftuga @jspanitz
New NanoPC T4 (SDcard) image available for testing: https://github.com/MichaIng/DietPi/issues/2979
I am pretty sure this works fine on NanoPi M4 + NanoPi NEO4 as well, if you want to test. If not, I can create new ones for those devices as well.

[MichaIng]

M4v2 image is ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPiM4v2-ARMv8-Buster.7z

[cocoflan]

This also works on NanopiM4 or only the NanopiM4 v2?

[MichaIng]

@cocoflan
Nope this is v2 only, most likely not compatible with M4/T4/NEO4 due to DDR4 vs DDR3 RAM.

The updated T4 image works on M4v1 as well but I'll upload a dedicated M4 image later to check if it boots faster. T4 image seems to boot relatively slow, probably due to additional loaded device tree features which are not present in M4/NEO4.

[cocoflan]

Ok i will wait for that upload for the M4v1.

Greetings

[MichaIng]

@cocoflan
M4v1 image ready for testing: https://dietpi.com/downloads/testing/DietPi_NanoPiM4-ARMv8-Buster.7z

[cocoflan]

Ok thx will try it soon.

Greetings

[cocoflan]

I am trying to run the image but doesn't seem to boot, nothing on screen with HDMI connected monitor.

Greetings

[MichaIng]

@cocoflan
Hmm, many thanks for testing. Very strange that the T4 image is the only one which works (on M4v1 and NEO4 as well), but NEO4 and M4 images do not. Probably it is a specific faulty kernel or dtb or bootloader package version that I caught. I'll re-create it soon for another test.

[cocoflan]

yes must be something like that, keep me informed i will test the next version you sent me.

Greetings

[rafee74]

Hi, I'm new to GitHub. This is my first comment.
I downloaded your image for M4 and used it on my brand new board with 8Gb eMMC. It boots correctly but before seeing something on monitor I have to wait about 1 minute. What I see is last few lines of the booting process, and than it takes other 6-7 seconds to complete and finally I have the login prompt.
During boot process, the yellow LED of the LAN connector blinks some times but the green LED is always off. When the login prompt appears, then the green LED is on.
Also the green STAT LED on the board is always off during boot, and then light it on when on the monitor I see the last boot lines.
I've completed the configuration and installed few software, it seems to works well. I don't have yet tested Wi-Fi and audio.
A couple of times, after rebooting it (required by the configuration process) my keyboard stoped working. The keyboard was already connected before reboot. Unplugging and reconnecting it don't solve the problem. I tried to connect a mouse but it never light on the red LED on bottom. Also changing ports never solve. I had to unplug the power source and plug it again to reboot and have my keyboard work again.
Finally, I installed the X server and LXDE but on next reboot it failed to start X, this are last lines on XOrg log:

[ 62.952] (II) LoadModule: "modesetting" [ 62.953] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 62.954] (EE) Failed to load /usr/lib/xorg/modules/drivers/modesetting_drv.so: librga.so: cannot open shared object file: No such file or directory [ 62.954] (EE) Failed to load module "modesetting" (loader failed, 0) [ 62.954] (EE) No drivers available. [ 62.954] (EE) Fatal server error: [ 62.954] (EE) no screens found(EE) [ 62.954] (EE)

For the last errors now I try to solve it.

Ah, one last thing: on various menus and log messages there is still "NanoPi T4". Obviously not a big problem, but if you can correct it.....

Anyway, the booting time seems a bit long to me. In an old Raspberry Pi 2 the DietPi boots in very less time.

I hope my test help you, and thank you very much for your work.

[MichaIng]

@rafee74
Many thanks for testing. Just to be sure, which of the two images did you use:

• https://dietpi.com/downloads/testing/DietPi_NanoPiM4-ARMv8-Buster.7z
• or https://dietpi.com/downloads/images/DietPi_NanoPCT4-ARMv8-Stretch.7z

Nasty issue with the keyboard, probably dmesg or journalctl give a hint why it is not enabled correctly on boot.

Thanks for reporting the issue with modesetting. Indeed the GPU acceleration support for RK3399 is experimental. I just followed packages and configs provided by RockChip:

1. https://github.com/rockchip-linux/rk-rootfs-build/blob/master/overlay/etc/init.d/rockchip.sh
2. https://github.com/rockchip-linux/rk-rootfs-build/blob/master/overlay/etc/X11/xorg.conf.d/20-modesetting.conf

It configures the modesettings driver for X11 by default..

... found it, can you please try:

wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/rga/lib/librga.so -O /usr/lib/

Source: https://github.com/rockchip-linux/rk-rootfs-build/blob/master/mk-rootfs-stretch.sh#L88

Alternative:

apt install --reinstall xserver-xorg-core xserver-common

I was wondering if this would not work with the regular Debian packages, as long as Mali library and correct xorg.conf is installed.

[rafee74]

I'm using the M4 image.
Thanks to your instructions, now X11 is working without errors. I launched both commands, wget and apt install

[rafee74]

Every time DietPi ask me to reboot (for example, closing dietpi-config after changed autostart) and I confirm to do it, it fails with this message:
/DietPi/dietpi/dietpi-config: line 161: reboot: command not found
I've readed on Debian Buster they changed the way to launch that command.

[MichaIng]

@rafee74
Grat that X11 works now. Have you tested if GPU acceleration works, e.g. with Kodi, Chromium or other X applications?

Would have been interesting if it works with the X11 packages from RockChip as well, as they might serve better support for the specific Mali GPU of the SoC, however just if you find time to retest:

wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/xserver/xserver-common_1.20.4-1_all.deb
dpkg -i xserver-common_1.20.4-1_all.deb
rm xserver-common_1.20.4-1_all.deb
wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/xserver/xserver-xorg-core_1.20.4-1_arm64.deb
dpkg -i xserver-xorg-core_1.20.4-1_arm64.deb
rm xserver-xorg-core_1.20.4-1_arm64.deb

---

Very strange about the reboot command. With systemd it is basically systemctl reboot, but the reboot command should be only an alias/alternative for this. Could you paste:

which reboot
# If this indeed does not show anything, check:
ls -Al /sbin/reboot

[rafee74]

I don't test any GPU acceleration, I'll test it this evening and I'll test X11 from RockChip.

reboot command didn't work, but systemctl rebbot command or /sbin/reboot works well, so the reboot file is there.

[MichaIng]

@rafee74
Hmm, then the PATH variable seems to be wrong:

echo $PATH

This should be set for all login sessions from /etc/profile:

2020-03-17 15:56:45 root@micha:/tmp# grep 'PATH' /etc/profile
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
export PATH

[rafee74]

easy@monitor01:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

root@monitor01:/home/easy# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/sbin/

root@monitor01:~# grep 'PATH' /etc/profile
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
export PATH

The echo from root is showing /usr/sbin/ because I've added it in root's .bashrc file, otherwise the simply reboot command didn't work.
And if I try to reboot from normal user i get:

easy@monitor01:~$ /sbin/reboot 
Failed to set wall message, ignoring: Interactive authentication required.
Failed to reboot system via logind: Interactive authentication required.
Failed to open initctl fifo: Permesso negato
Failed to talk to init daemon.

easy@monitor01:~$ reboot
-bash: reboot: comando non trovato

easy@monitor01:~$ systemctl reboot
Failed to set wall message, ignoring: Interactive authentication required.
Failed to reboot system via logind: Interactive authentication required.
Failed to start reboot.target: Interactive authentication required.
See system logs and 'systemctl status reboot.target' for details.

[rafee74]

I try to install RockChip's X11 package and I have this error installing first package:

root@monitor01:/tmp# dpkg -i xserver-common_1.20.4-1_all.deb
dpkg-deb: errore: "xserver-common_1.20.4-1_all.deb" non è un archivio in formato Debian
dpkg: errore nell'elaborare l'archivio xserver-common_1.20.4-1_all.deb (--install):
 il sottoprocesso dpkg-deb --control ha restituito lo stato di errore 2
Si sono verificati degli errori nell'elaborazione:
 xserver-common_1.20.4-1_all.deb

It's in Italian and it say that it's not an archive in Debian format

[rafee74]

Sorry, I was forgetting to write you I've tried the GPU using glxgears leaving it to run for a few seconds and this is the result:

282 frames in 5.0 seconds = 56.227 FPS
297 frames in 5.0 seconds = 59.311 FPS
274 frames in 5.0 seconds = 54.686 FPS
279 frames in 5.0 seconds = 55.767 FPS
287 frames in 5.0 seconds = 57.393 FPS
287 frames in 5.0 seconds = 57.255 FPS
288 frames in 5.0 seconds = 57.420 FPS
295 frames in 5.0 seconds = 58.955 FPS
294 frames in 5.0 seconds = 58.781 FPS
296 frames in 5.0 seconds = 59.027 FPS
296 frames in 5.0 seconds = 59.002 FPS
295 frames in 5.0 seconds = 58.767 FPS
295 frames in 5.0 seconds = 58.876 FPS
295 frames in 5.0 seconds = 58.973 FPS
294 frames in 5.0 seconds = 58.768 FPS
296 frames in 5.0 seconds = 59.066 FPS
296 frames in 5.0 seconds = 59.010 FPS
294 frames in 5.0 seconds = 58.795 FPS
295 frames in 5.0 seconds = 58.976 FPS
278 frames in 5.2 seconds = 53.269 FPS

Attached is the result of glxinfo.

All es2gear* program return this error:

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:
EGLUT: failed to initialize EGL display

I don't know if this is enough for you.
info_glxgears_X11-default.txt

[MichaIng]

@rafee74
Okay your PATH matches btw the default for non-root users, while mine does not, probably changed by Raspbian or a very old default, not sure:

2020-03-18 11:41:33 root@micha:/tmp# diff /usr/share/base-files/profile /etc/profile
7c7
<   PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
---
>   PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"

However for sudo that actually doesn't matter, since it by default does not migrate the environment, as long as you do not use the option -E. In case the variable is not set, bash uses /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin as fallback internally, hence this should always be the PATH when you execute a script with sudo. If that is not the case, then not only the missing reboot would be an issue, but most scripts should show a missing command error regularly and fail.

So lets go through it:

grep 'PATH=' /etc/bash.bashrc /etc/bashrc.d/* /etc/environment /{root,home/*}/.bashrc

• /etc/profile + /etc/profile.d/* + ~/.profile do not matter, since scripts are no login shells.
• All bashrc ones should not matter as well, because they _should_ contain an entry at the start to exit if it's not an interactive shell, and scripts are no interactive shells. However, those are indeed sourced by scripts as well.
• I have actually no idea when/if /etc/environment is sourced/read at all. It used to contain locale some time ago, but /etc/default/locales is used for that nowadays.
• As above, actually, when using sudo to execute a script without -E (preserve environment), -s (start as interactive shell) or -i (start as login shell), then there must never be anything applied from any of those files. If it is, then those are wrong configured. Actually I retested and was not able to pass any variable via .profile/.bashrc through sudo to an executed script with any sudo option, so I'm not sure if any of those are really sourced by scripts at all 🤔.

Another way to test the default environment in bash shells:

env -i bash -c 'echo $PATH'

And more targeted:

echo -e '#!/bin/bash\necho "$PATH"' > testscript
chmod +x testscript
./testscript
sudo ./testscript

---

About Xserver, whoopsie, I gave you the html page links, corrected it:

rm xserver-common_1.20.4-1_all.deb xserver-xorg-core_1.20.4-1_arm64.deb
wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/xserver/xserver-common_1.20.4-1_all.deb
dpkg -i xserver-common_1.20.4-1_all.deb
rm xserver-common_1.20.4-1_all.deb
wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/xserver/xserver-xorg-core_1.20.4-1_arm64.deb
dpkg -i xserver-xorg-core_1.20.4-1_arm64.deb
rm xserver-xorg-core_1.20.4-1_arm64.deb

[rafee74]

Here are all outputs command:

root@monitor01:~# diff /usr/share/base-files/profile /etc/profile
root@monitor01:~# 
root@monitor01:~# 
root@monitor01:~# 
root@monitor01:~# 
root@monitor01:~# grep 'PATH=' /etc/bash.bashrc /etc/bashrc.d/* /etc/environment /{root,home/*}/.bashrc
/root/.bashrc:export PATH="$PATH:/usr/sbin/"
root@monitor01:~# 
root@monitor01:~# 
root@monitor01:~# 
root@monitor01:~# env -i bash -c 'echo $PATH'
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
root@monitor01:~# 
root@monitor01:~# 
root@monitor01:~# echo -e '#!/bin/bash\necho "$PATH"' > testscript
root@monitor01:~# chmod +x testscript
root@monitor01:~# ./testscript
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/sbin/
root@monitor01:~# 
root@monitor01:~# 

To clarify, my problem with reboot is using normal user, not root user. And after trying and searching on Internet I found the solution.
I don't tell you that I've created a new user called "easy" (I thought you saw it in code blocks in my previous messages).
Using my new user and modifying configuration or launching commands with sudo, the problem was Diet-Pi say me that my user was not on sudoers group. So I tried to add my user name to /etc/group, at the end of sudo line, and all works well. But, reading the /etc/sudoers I saw at the end of the file there is an include. So, entering in the /etc/sudoers.d directory I saw there is the file dietpi with policy for that user. I copied this file with name easy and modified it changing dietpi name with easy. Now from my user I can use correctly the sudo command.
Sorry for all this confusion.
Anyway, I found this request and I think this can solve also my problem.

---

I try to install new xorg and it works like before, I try glxgears and the FPS is quite the same as before. Did I have to check something else?

But, I found those differences.
From glxinfo | grep -i vendor it say VMware

server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
    Vendor: VMware, Inc. (0xffffffff)
OpenGL vendor string: VMware, Inc.

from lsmod | grep "kms|drm"

rockchipdrm           131072  2
analogix_dp            40960  1 rockchipdrm
dw_mipi_dsi            20480  1 rockchipdrm
dw_hdmi                40960  2 dw_hdmi_i2s_audio,rockchipdrm

and in /etc/X11/xorg.conf

# DietPi X.org config
# All credits go to Rockchip: https://github.com/rockchip-linux/rk-rootfs-build/blob/master/overlay/etc/X11/xorg.conf.d/20-modesetting.conf

Section "Device"
    Identifier  "Rockchip Graphics"
    Driver      "modesetting"
    Option      "AccelMethod"    "exa"
#    Option      "AccelMethod"    "glamor"
    Option      "DRI"            "2"
    Option      "FlipFB"         "always"
EndSection
...
...
...

Is it correct that graphic driver is from RockChip but X finds VMware?

[MichaIng]

@rafee74
Okay, basically the PATH fallback for bash is proven in your case, also that export PATH="$PATH:/usr/sbin/" is not required for the root user, as it is now doubled.
I thought your initial issue is that your non-root user can call scripts via sudo but the scripts then end with "reboot command not found" error?
If the user does not have sudo permissions then it should not even be able to execute the scripts, as they check for root permissions, else should exit with error.

So I tried to add my user name to /etc/group, at the end of sudo line, and all works well.

Do never touch those files directly! There are hash files that must match in certain cases. Always user usermod to add a user to a group: usermod -aG sudo easy
The sudoers.d/ config is an alternative that does not rely on group membership.

Okay, great that both Xserver packages work. So we could even use those from Debian repo. However on Stretch they would be outdated, hence we use the RockChip ones on all RK3399 SBCs.
I have no idea what OpenGL vendor string usually shows? However for the xorg.conf it should not matter. The "Identifier" has no practical effect, is just like a name you give it, from all I know, although those identifiers can be referenced from elsewhere, e.g. another xorg.conf.d/ file. Driver and AccelMethod is what counts when it's about GPU acceleration.

[MichaIng]

@cocoflan
How long did you wait for the M4 image to boot? Since for @rafee74 it works, but with long boot time (same as the T4 image) 🤔. On the other hand this was on eMMC, and you tried it on SDcard, right? There it probably even boots slower, or otherwise, as I read a bunch of other issues with the current Armbian RK3399 images, it probably fails on SDcard while it succeeds on eMMC for some reason...

[cocoflan]

Yes it was on an sdcard, i have waited 1-2 min., i will try again and wait a longer time to see if it gets true the boot procedure.

Greetings cocoflan

[rafee74]

@MichaIng
I've tested LXQT as desktop instead of the previous LXDE and I tried to test again with glxgears. Here are the results, as you see now it's 5 times faster than before. I don't know if this help you.

1251 frames in 5.0 seconds = 250.058 FPS
1369 frames in 5.0 seconds = 273.706 FPS
1421 frames in 5.0 seconds = 284.103 FPS
1326 frames in 5.0 seconds = 265.186 FPS
1238 frames in 5.0 seconds = 246.935 FPS
1351 frames in 5.0 seconds = 270.149 FPS
1292 frames in 5.0 seconds = 256.740 FPS
1352 frames in 5.0 seconds = 270.342 FPS
1274 frames in 5.0 seconds = 254.788 FPS
1332 frames in 5.0 seconds = 265.750 FPS
1309 frames in 5.0 seconds = 261.686 FPS
1270 frames in 5.0 seconds = 253.891 FPS
1222 frames in 5.0 seconds = 243.810 FPS
1423 frames in 5.0 seconds = 284.595 FPS
1310 frames in 5.0 seconds = 261.882 FPS
1262 frames in 5.0 seconds = 252.285 FPS
1288 frames in 5.0 seconds = 257.482 FPS

[MichaIng]

@rafee74
That is great and basically means that indeed the RockChip X11 packages are required for best GPU acceleration.

[rafee74]

@MichaIng
Mmmm.... not sure.
On LXDE and both default X11 or RockChip pacckages, the FPS was the same.
On LXQT and RockChip X11 packages goes better.
This, for me, means LXQT handles better the GPU.
Or am I wrong?
Next days I'll try with default X11 packages and LXQT.

[MichaIng]

@rafee74
Ah, okay, I thought you tested only the Debian X11 on LXDE. Strange that LXQt is that much faster if nothing else is running beside, I mean it's just the frontend while all "real" work is done on+after X server level 🤔.

[MichaIng]

New NanoPi M4 (v1) image uploaded, lets see if this boots more reliable.

[cocoflan]

Download link ?

[MichaIng]

@cocoflan
The same as before: https://dietpi.com/downloads/testing/DietPi_NanoPiM4-ARMv8-Buster.7z

[cocoflan]

Screen flashes afther some time takes 30 sec. or more,
and is trying to look for some kind of resolution, then its black again.

Strange or not?

[MichaIng]

@cocoflan
Hmm, can you SSH into it?

[cocoflan]

video component problem i guess, i use an old flatscreen monitor with vga to hdmi convertor, works good on the script version but not on the image you sent me.

[cocoflan]

My build from the ground up works perfect, so there must be some trouble in the hardware drivers you compiled or so i guess.

[cocoflan]

what i have noticed is that the mac address with nanopi m4 v1, always changes after reinstallation. so i can't test ssh without screen for the moment.

[cocoflan]

Can't the "Image | NanoPi M4" name be changed to "Image | NanoPi M4v1" to avoid confusion in issues?

[rafee74]

Boot time is as before:

• power on and after about 01:02 minutes I see something on the monitor

• after other 4-5 seconds I have the login prompt

This times are without any software ore services added to the standard installation.

[MichaIng]

@cocoflan

My build from the ground up works perfect, so there must be some trouble in the hardware drivers you compiled or so i guess.

I didn't compile anything. It's just the DietPi installer run on the official Armbian image, nothing else. How did you build from ground up? The Armbian build tools or what you mean?

what i have noticed is that the mac address with nanopi m4 v1, always changes after reinstallation. so i can't test ssh without screen for the moment.

That is indeed annoying. I have to look into this, there must be something actively covering the real hardware MAC address but IMO this should not be done without user knowledge, so routers can always identify known hardware.

Can't the "Image | NanoPi M4" name be changed to "Image | NanoPi M4v1" to avoid confusion in issues?

I am not even sure if I add this image at all. From all our test results it looks like it doesn't make a difference if M4, NEO4 or T4 is used, hence a single image is sufficient, and since T4 image currently works best and is the only one that enables full hardware features on T4, this is what we'll keep, as of current state.

@rafee74
Okay thanks for your testing @cocoflan as well. So at least it boots now from SDcard and eMMC, only slow, same as the T4 image already did. As long as the official Armbian image, or one build with their build tools does not do better, we cannot do much, as this is all we get. However Linux mainstream support for ARMs is increasing fast and as long as it's only boot time, not a major issue (IMO).

[cocoflan]

The tool i used for my good working setup is https://github.com/armbian/build, and then used the script from dietpi. https://github.com/MichaIng/DietPi/issues/1285

Used minimal non graphical terminal base build for the building process.

Greetings cocoflan :-)

[MichaIng]

@cocoflan
What is the kernel version?

uname -a

[cocoflan]

4.4.192-rk3399 is the kernel version.

Linux DietPi 4.4.192-rk3399 #6 SMP Tue Oct 8 18:32:46 CEST 2019 aarch64 GNU/Linux

Greetings

[MichaIng]

@cocoflan
Ah, this is the major difference, I used the 5.4 mainline kernel image. But probably the advantages do not yet outweigh the disadvantages.

[cocoflan]

Ah ok yes this must be it, i will test a new image with armbian build tool on kernel 5 to test and see.

Greetings en thx to keep me informed.

[cocoflan]

Or cane you make an image with the lower kernel version to test?

Greetings

[MichaIng]

@cocoflan
Okay, I'll do that later.

[MichaIng]

@cocoflan
Done: https://dietpi.com/downloads/testing/DietPi_NanoPiM4v1-ARMv6-Buster_Linux4.4.7z

[cocoflan]

Ok thx will test it soon.

Greetings

[cocoflan]

Did a first run, and boots like normal, no delays or no screen trouble with this image!!!

Will run some test to see if all is running like on my image!!

At first sight it looks likes it's ok with this kernel!!

Greetings cocoflan

[rafee74]

I confirm the booting time is half than the previous images.
I'll test graphics and analog audio (what I'm interesting in) and let you know.

[MichaIng]

Okay many thanks for testing guys. I think I'll recreate M4/NEO4/T4 images with 4.4 kernel then. Not sure if we want to offer both? 5.X kernel has several other advantages that might outweigh the long boot time for some users. Depends on use case...

[cocoflan]

You are welcome, keep ont he good work.
Will the install image of dietpi M4v1 be available on the SBC list on dietpi website?

Greetings cocoflan

[cocoflan]

How can i change the wifi hotspot adress for dhcp in commandline, because i see it is using the same adress like my other SBC with dietpi and i think i have a conflict, it is to test on this new image that works great for the moment?

[cocoflan]

Netdata package is not working from the package installer list on nanopi M4v1 image.

I installed it from https://docs.netdata.cloud/packaging/installer/ with the installer script:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

This does work.

Greetings cocoflan

[MichaIng]

@cocoflan
On Debian Buster, the APT package is quite new, isn't it? But generally this is not a NanoPi M4 issue, could you open a new issue and paste the installer outputs/errors on this?

[rafee74]

I'm having trouble with LXDE or LXQt in the last image. I've installed them (LXQt the first time and the unistalled it and Xserver and installed LXDE) and selected the automatic login with a user of mine (not dietpi). At boot the login process stops when it has to start X server and on Xorg.0.log there sre those lines:

...
...
...
[    18.667] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    18.668] (EE) Failed to load 
/usr/lib/xorg/modules/drivers/modesetting_drv.so: librga.so: cannot open 
shared object file: No such file or directory
[    18.668] (EE) Failed to load module "modesetting" (loader failed, 0)
[    18.668] (EE) No drivers available.
[    18.668] (EE)
Fatal server error:
[    18.668] (EE) no screens found(EE)
[    18.668] (EE)
Please consult the The X.Org Foundation support
       at http://wiki.x.org
   for help.
[    18.668] (EE) Please also check the log file at 
"/home/easy/.local/share/xorg/Xorg.0.log" for additional information.
[    18.668] (EE)
[    18.783] (EE) Server terminated with error (1). Closing log file.

I've tried to solve and searched on Internet but I haven't found anything. I've tried also to compile librga.so following the instructions on this forum but it didn't work.
Am I doing something wrong?

---

About the reboot command not working (see my previous messages), I've found the problem come when I login with normal user and then I launch su to become root. In this state, even if I'm root, when i launch reboot or any other root command it always response command not found
The problem is in the $PATH variable, because if I launch echo $PATH I have those results:

• login with my normal user (called easy):

easy@DietPi:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

• user root after sued from normal user:

root@DietPi:/home/easy# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

• login with dietpi user:

dietpi@DietPi:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

• login with root user:

root@DietPi:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

As you can see, even if I become root from normal user, the PATH variable is always the same. Only if I login directly with root the PATH variable is ok for root user. I'm used to that if I sued to root I can do anything like I login directly with root.
Is that ok or again I'm doing something wrong?

[MichaIng]

@rafee74
Ah jep, known issue fixed with v6.29. Please try:

wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/rga/lib/librga.so -O /usr/lib/

[cocoflan]

Try update the system first with apt update and apt upgrade there are 2 updates for xwin env., and then try again.
i had the same problem, and was fixed with first updating the 2 packages.

I am running the lxde env.

Greetings

[MichaIng]

@cocoflan
Hmm, I hope it did not simply overwrite the xserver packages with the ones from Debian repo. Need to check the package versions then. Because AFAIK the Debian repo packages do not provide full GPU acceleration.

[cocoflan]

ok good to know, i will test your other solution.

Greetings

[cocoflan]

wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/rga/lib/librga.so -O /usr/lib/

i get an error "/usr/lib/: Is a directory"

[rafee74]

I test the @cocoflan solution and it worked ok.

@MichaIng I'll test also your solution, I want to reinstall again your last image and compare GPU acceleration

[cocoflan]

ok nice to hear that.

thx

[MichaIng]

@cocoflan
Ah, since when wget -O does require a filepath. Okay then:

wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/rga/lib/librga.so -O /usr/lib/librga.so

[cocoflan]

It worked with your wget solution also! i think it's a better solution indeed for the full GPU acceleration.

Greetings

[cocoflan]

es2gears is working now, did not work on my apt update apt upgrade solution.

So your solution is the one to use!

Greetings

[cocoflan]

The problem with netdata is it makes no errors on install, only can't open the web interface on port 19999.

Greetings

[MichaIng]

@cocoflan
Okay I'm not sure when I find time to test the Netdata installer, until then I suggest to install the APT package respectively via dietpi-software.

Great that acceleration works now. I'll see if I can upload new package versions that don't get overwritten by Debian packages.

[cocoflan]

ok very good thx

greetings

[MichaIng]

Okay the xorg-server-core package as least has been updated, although no visual version string change:

cd /tmp
wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/xserver/xserver-xorg-core_1.20.4-1_arm64.deb
dpkg -i xserver-xorg-core_1.20.4-1_arm64.deb
rm xserver-xorg-core_1.20.4-1_arm64.deb

I updated that one on our server as well.

[cocoflan]

Ok nice to hear!

Greetings

[rafee74]

So, as promised, here are the results of the hardware acceleration tests. All tests were done with desktop environment LXDE and LXQt (I've done a brief test with Mate but I don't report it here as the final result is the same). I've done tests for:

• default Xorg package (last MichaIng image - Rockchip?) + librga
• default Xorg package (last MichaIng image - Rockchip?) + librga and then installed Xorg Core as per last MichaIng post
• Xorg package installed after apt upgarde (Debian/Armbian)
• Xorg package installed after apt upgarde + librga (Debian/Armbian)

Each configuration was tested with es2gears and glxgears commands. I leave each command running so that it give me at least 10 results for each configuration. Then I make an FPS average of those 10 results.

A parenthesis about es2gears: it didn't work for me, contrary to what @cocoflan wrote. If I launch it, I have this error on shell:
es2gears: error while loading shared libraries: libEGL.so.1: cannot open shared object file: No such file or directory
To make it work, I have to apt install libegl-mesa0; it didn't worked again because libEGL.so.1 was not created. I have to ln -s /usr/lib/aarch64-linux-gnu/libEGL_mesa.so.0.0.0 /usr/lib/aarch64-linux-gnu/libEGL.so.1 and finally it worked. So I don't know it this library is necessary or not.

By the way, here are my results, ordered by FPS:

Configuration | FPS avg |   | Configuration | FPS avg
-- | -- | -- | -- | --
es2gears_lxde_rck-xorg+librga+last-xorg | 326,44 |   | glxgears_lxqt_rck-xorg+librga | 69,46
es2gears_lxqt_rck-xorg+librga+last-xorg | 589,52 |   | glxgears_lxqt_rck-xorg+librga+last-xorg | 98,58
es2gears_lxqt_rck-xorg+librga | 595,78 |   | glxgears_lxqt_deb-xorg+librga | 249,00
es2gears_lxde_deb-xorg | 661,64 |   | glxgears_lxqt_deb-xorg | 258,36
es2gears_lxde_deb-xorg+librga | 789,60 |   | glxgears_lxde_rck-xorg+librga | 258,62
es2gears_lxde_rck-xorg+librga | 924,32 |   | glxgears_lxde_rck-xorg+librga+last-xorg | 270,10
es2gears_lxqt_deb-xorg+librga | 1363,24 |   | glxgears_lxde_deb-xorg | 327,98
es2gears_lxqt_deb-xorg | 1400,94 |   | glxgears_lxde_deb-xorg+librga | 350,04

As you can see, for both desktop environments and for both commands, the best configuration is using the Debian/Armbian Xorg package.

[MichaIng]

@rafee74
Many thanks for doing all these tests.

• librga btw should not do any difference. It is used and required for the RockChip X.org packages but should not affect the FPS (of the Debian repo X.org). Your results, considering natural fluctuations, also reflect this.
• What I find strange is es2gears_lxde_rck-xorg+librga+last-xorg 326,44 but es2gears_lxde_rck-xorg+librga, like the newer RockChip X.org core broke performance dramatically. Do you remember if you changed anything else between those two tests?

But one reason could be apt install libegl-mesa0. Note that those mesa lib packages are the vendor-independent ones without any GPU acceleration. And installing this package should have purged the RockChip Mali library for Mali-T864 support. To reinstall it:

cd /tmp
wget https://dietpi.com/downloads/binaries/rk3399/libmali.deb
apt install ./libmali.deb
rm libmali.deb

• You should be even able to see it replacing the mesa package you installed.
  Now lets re-create the symlinks for GLES/EGL, including the missing one that made you install the mesa package:

cd /usr/lib/aarch64-linux-gnu
ln -sf libMali.so libEGL.so.1.1.0
ln -sf libMali.so libEGL.so
ln -sf libMali.so libEGL.so.1.0.0
ln -sf libMali.so libEGL.so.1.4
ln -sf libMali.so libEGL.so.1 # The one that was missing before
ln -sf libMali.so libGLESv2.so
ln -sf libMali.so libGLESv2.so.2.0
ln -sf libMali.so libGLESv2.so.2.0.0
ln -sf libMali.so libGLESv1_CM.so
ln -sf libMali.so libGLESv1_CM.so.1
ln -sf libMali.so libGLESv1_CM.so.1.1

This could have a major impact on your results, but I am not 100% sure whether the Mali driver was really removed and libEGL.so.1 the one link used by es2gears or not. glxgears btw should not play a role on SBCs, since all good software uses EGL (invoking GLES) or GLES directly, not OpenGL on those, compared to x86 systems. This might be also the reason why it is so much slower, since not accelerated at all. Also see that not symlinks for OpenGL are created for libMali.so, only EGL and GLES.

[MichaIng]

Added this symlink to installs on DietPi v6.29: https://github.com/MichaIng/DietPi/commit/1ee20325d3f2400dfdf7ab8448c556e24f15120d

[rafee74]

Do you remember if you changed anything else between those two tests?

No, all tests where done after installed Mesa library.

I redone the tests after reinstalled libMali library and recreating all simlinks. I've done tests with only last RockChip Xorg package and this is a 10 tests average:
LXDE: 1369,4
LXQt: 1373,62

Now FPS are quite the same for both desktops.

BUT
All previous tests were done by my normal user easy. With libMail installed when i launch es2gears I have these error:

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:
EGLUT: failed to initialize EGL display

Accessing to desktop with root user the program runs ok.

And, as last information, yesterday I forgot to tell you that when I launch es2gears I don't see any rotating gears even if the FPS where counted anyway. The same was today with libMali library and executing with root. glxgears show me rotating gears.

[rafee74]

I have another issue: I have no audio out from jack connector. Only HDMI audio and only after installing manually pulseaudio
I don't know if this is another known issue, I have searched but I didn't find anything.

[MichaIng]

@rafee74
Hmm, strange about the error. Did you try to add the easy user to video and render groups? Should actually not be required within X session but just to test:

usermod -aG video,render easy

I found a very similar issue: https://forum.armbian.com/topic/5416-gpu-driver/
Other SoC but similar driver sources, error etc.

_I am not sure if those gear test tools might invoke DRM and/or KMS as well. There are two other packages available for that: https://github.com/rockchip-linux/rk-rootfs-build/tree/master/packages/arm64/libdrm
Also I am not sure if those are in any way different from the ones from Debian repo. Usually the Mali/GPU-specific drivers should be the most important ones, EDIT: Nope these should be working just the same from both sources._

Audio jack should not be related. You selected (prior to installing pulseaudio) the sound card via dietpi-config? Did you try to configure the ALSA mixer?

[rafee74]

@MichaIng
Tried you suggestion to add my user to video and render groups with no success.
Now, when I execute es2gears through easy user I have this error
EGLUT: failed to initialize EGL display
Like the previous error but without first 2 lines

Tried also to install libdrm packages you linked, though you wrote they were the same as of Debian. Again I not see anything on the window, only a dark window.

---

I know audio jack is no related to video issue.
I've selected sound card from dietpi-config during first boot configuration and i selected realtekrt5651co option, detected as hw:2,0 (indeed, I don't remember if it was already automatically selected). However, I just checked and it is already selected.

[MichaIng]

@rafee74
Can you please paste the output of:

ls -Al /dev/mali*

[rafee74]

@MichaIng

root@DietPi:/var/log# ls -Al /dev/mali*
crw-rw---- 1 root video 10, 52 mar 31 16:02 /dev/mali0

[rafee74]

@rafee74
Please try:

apt install xserver-xorg-legacy

Tried with no success, same error as before

I try to check the list of upgradable packages an this is the result:

root@DietPi:~# apt list --upgradable -a
Elencazione... Fatto
libdrm2/stable 2.4.97-1 arm64 [aggiornabile da: 2.4.97-1]
libdrm2/now 2.4.97-1 arm64 [installato, aggiornabile a: 2.4.97-1]

But the installed version and the proposed upgrade version are the same. Is this related to library installation by link you posted?

[MichaIng]

@rafee74
Ah, it should have been the X.org package from RockChip of course:

cd /tmp
wget https://github.com/rockchip-linux/rk-rootfs-build/raw/master/packages/arm64/xserver/xserver-xorg-legacy_1.20.4-1_arm64.deb
apt install ./xserver-xorg-legacy_1.20.4-1_arm64.deb
rm xserver-xorg-legacy_1.20.4-1_arm64.deb

All symlinks now point to the Mali lib?

ln -Al /usr/lib/aarch64-linux-gnu/*{GL,Mali}*.so

And btw, es2gears executed with root is still black?

Finally from what I see, most other RK3399 solution use another acceleration option and the one suggested by RockChip seems to be not even available on other X.org packages. So probably it is better to switch to one which always works, regardless of which X.org packages are used:

sed -i 's/exa/glamor/' /etc/X11/xorg.conf

[rafee74]

@MichaIng
After my message, I used dietpi-software to change log system configuration and then selecting Install option it upgrades automatically the package mentioned before.

Ok, I installed xserver-xorg-legacy_1.20.4-1_arm64.deb as you ask me, again the same package to upgrade

root@DietPi:/tmp# apt list --upgradable -a
Elencazione... Fatto
xserver-xorg-legacy/stable 2:1.20.4-1 arm64 [aggiornabile da: 2:1.20.4-1]
xserver-xorg-legacy/now 2:1.20.4-1 arm64 [installato, aggiornabile a: 2:1.20.4-1]

All symlinks point to Mali lib (I think you mean ls and not ln :wink: )

root@DietPi:/tmp# ls -Al /usr/lib/aarch64-linux-gnu/*{GL,Mali}*.so
lrwxrwxrwx 1 root root 10 mar 30 22:27 /usr/lib/aarch64-linux-gnu/libEGL.so -> libMali.so
lrwxrwxrwx 1 root root 10 mar 30 22:27 /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so -> libMali.so
lrwxrwxrwx 1 root root 10 mar 30 22:27 /usr/lib/aarch64-linux-gnu/libGLESv2.so -> libMali.so
lrwxrwxrwx 1 root root 10 lug 16  2019 /usr/lib/aarch64-linux-gnu/libMaliOpenCL.so -> libMali.so
lrwxrwxrwx 1 root root 29 lug 16  2019 /usr/lib/aarch64-linux-gnu/libMali.so -> libmali-midgard-t86x-r14p0.so

Instead to use your sed command, I noticed in the xorg.conf there is already a commented line with glamor option. So I commented the line with esa option and commented out the other. Reboot but there is the same error.
I upgraded xserver-xorg-legacy package through apt upgrade, reboot but again the error.
Now I noticed that also with root user there is the same problem with es2gears.

And yes, es2gears executed by root user show a black window.

[MichaIng]

New image, again a NanoPC T4 one but there has been no difference between the Linux v5 images: https://dietpi.com/downloads/images/testing/DietPi_NanoPCT4-ARMv8-Buster.7z

As of another report, the long boot time seems to have been resolved with current kernel/dtb/bootloader stack.

[cocoflan]

Back trouble with video signal on booting, signal out of range and stripes, I will test it on a newer monitor with hdmi and no convertor to hdmi.

Greetings

Van: "MichaIng" [e-mail]
Aan: "MichaIng/DietPi" [e-mail]
Cc: "cocoflan" [e-mail], "Mention" [e-mail]
Verzonden: Donderdag 28 mei 2020 23:10:27
Onderwerp: Re: [MichaIng/DietPi] Image | NanoPi M4 (#2399)

New image, again a NanoPC T4 one but there has been no difference between the Linux v5 images: [ https://dietpi.com/downloads/images/testing/DietPi_NanoPCT4-ARMv8-Buster.7z | https://dietpi.com/downloads/images/testing/DietPi_NanoPCT4-ARMv8-Buster.7z ]

As of another report, the long boot time seems to have been resolved with current kernel/dtb/bootloader stack.

—
You are receiving this because you were mentioned.
Reply to this email directly, [ https://github.com/MichaIng/DietPi/issues/2399#issuecomment-635609324 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AADDVGDKGY65TR2BGJV7XVLRT3HMHANCNFSM4GOT3AUA | unsubscribe ] .

[MichaIng]

Back trouble with video signal on booting, signal out of range and stripes, I will test it on a newer monitor with hdmi and no convertor to hdmi.

Ah right this was the other issue with mainline kernel, yes would be good to know if this works better with never monitor. Probably there is also a way to increase HDMI signal strength like can be done on RPi, at least worth to check/test.

[MichaIng]

I'll mark this as closed for now, image has been moved to stable. As long as things generally work, we'll go with a T4+M4+NEO4 combined image. If certain issues can be replicated and are fixed by using the M4 bootloader + root files, we'll reconsider creating a separate M4-only image.

[cocoflan]

Ok that is good !