search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.76k stars 494 forks source link

Image | NanoPi M4 #2399

Closed N3mill0 closed 4 years ago

N3mill0 commented 5 years ago

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

Give us some formal device information:

Is the SBC officially supported by the Debian installer?

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

MichaIng commented 5 years ago

@N3mill0 Thanks for your request.

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

cocoflan commented 5 years ago

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

jftuga commented 5 years ago

Is there any update on this?

Thanks.

MichaIng commented 5 years ago

@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:

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 commented 5 years ago

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.kinet@telenet.be

Greetings

Van: "MichaIng" notifications@github.com Aan: "MichaIng/DietPi" DietPi@noreply.github.com Cc: "cocoflan" christophe.kinet@telenet.be, "Comment" comment@noreply.github.com 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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

Greetings

Van: "MichaIng" notifications@github.com Aan: "MichaIng/DietPi" DietPi@noreply.github.com Cc: "cocoflan" christophe.kinet@telenet.be, "Mention" mention@noreply.github.com 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 commented 5 years ago

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

cocoflan commented 5 years ago

cf33b03e-575c-49e5-9455-e3a0ad85561f

Greetings

Van: "MichaIng" notifications@github.com Aan: "MichaIng/DietPi" DietPi@noreply.github.com Cc: "cocoflan" christophe.kinet@telenet.be, "Mention" mention@noreply.github.com 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

jspanitz commented 5 years ago

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 commented 4 years ago

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

MichaIng commented 4 years ago

@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 commented 4 years ago

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

cocoflan commented 4 years ago

This also works on NanopiM4 or only the NanopiM4 v2?

MichaIng commented 4 years ago

@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 commented 4 years ago

Ok i will wait for that upload for the M4v1.

Greetings

MichaIng commented 4 years ago

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

cocoflan commented 4 years ago

Ok thx will try it soon.

Greetings

cocoflan commented 4 years ago

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

Greetings

MichaIng commented 4 years ago

@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 commented 4 years ago

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

Greetings

rafee74 commented 4 years ago

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 commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago 
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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

rafee74 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

cocoflan commented 4 years ago

Download link ?

MichaIng commented 4 years ago

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