Image | NanoPi NEO3

[MichaIng]

Creating an image request

Formal device information

• Device name | NanoPi NEO3
• Official product URL | https://www.friendlyarm.com/index.php?route=product/product&product_id=279&search=NEO3&description=true&category_id=0&sub_category=true
• GitHub resource URL (if available) |
• Image download URL | https://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO3

Is the SBC officially supported by the Debian installer?

• No

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

• https://www.armbian.com/nanopineo3/

Vote for this image on FeatHub: https://feathub.com/MichaIng/DietPi/+172

[StephanStS]

@MichaIng: I have generated a NEO3 image. You can download it from my cloud like before (or provide me an upload link). I generated it as "Generic Device (aarch64)" based on Armbian with linux kernel 5.4.51, an own device entry is appreciated. Branch was 'master', because 'dev' gave an error quite late by mounting /tmp. First short test with mopidy, Webmin, phpsysinfo and node-red (only install and start, no deep application test):

• Phpsysinfo: Works.
• Webmin: Problem with Webmin installation (will be investigated later)
• Mopidy: Works.
• Node-RED: Works.

[MichaIng]

Nice, I'll get a developer sample next month so will add native code support before that.

Branch was 'master', because 'dev' gave an error quite late by mounting /tmp.

You mean DietPi-PREP script branch or what you selected during process for the target image? AFAIK I made some other changes to DietPi-PREP dev branch that are not compatible for creating master branch images, so either both must be dev or (and I'd recommend that) use master for both. To apply three quick and dirty fixes I used the following (current state):

sed -i 's/taaem/MichaIng/' /boot/dietpi/dietpi-software
sed -i 's|$temp_bytes_result / $temp_time_result|$temp_bytes_result * 1000000 / $(printf '%.0f' "${temp_time_result}e6")|' /boot/dietpi/func/dietpi-benchmark
sed -i "s/G_WHIP_MENU_ARRAY+=('ARM Idle Frequency'/#G_WHIP_MENU_ARRAY+=('ARM Idle Frequency'/" /boot/dietpi/dietpi-config
rm -Rfv /{root,home/*}/.{bash_history,nano_history,local,config,cache,gnupg,dbus,gconf,nano,vim} /var/{cache/debconf,lib/dpkg}/*-old /etc/resolv.conf_bak

• The last only cleanup if I do some last checks or changes.

[StephanStS]

Branch was 'master', because 'dev' gave an error quite late by mounting /tmp.

You mean DietPi-PREP script branch or what you selected during process for the target image? AFAIK I made some other changes to DietPi-PREP dev branch that are not compatible for creating master branch images, so either both must be dev or (and I'd recommend that) use master for both. To apply three quick and dirty fixes I used the following (current state): I meant: DietPi-PREP script I always take dev branch, the selected target image I changed from dev to master.

Additionally I tested image generation (based on Armbian NEO3 image) with both master and both dev:

1. Both master:

   
   #### Details:
   - Date           | Sat Aug  1 21:02:13 UTC 2020
   - Bug report     |
   - DietPi version | v6.31.2 (MichaIng/master)
   - Image creator  |
   - Pre-image      |
   - Hardware       |  (ID=22)
   - Kernel version | Linux nanopineo3 5.4.51-rockchip64 #20.05.9 SMP PREEMPT Sun Jul 12 11:28:47 UTC 2020 aarch64 GNU/Linux
   - Distro         | buster (ID=5)
   - Command        | apt-get -qq --allow-change-held-packages install apt-utils bash-completion bc bzip2 ca-certificates console-setup cron curl debconf dirmngr ethtool fake-hwclock gnupg htop ifupdown iputils-ping isc-dhcp-client kmod locales nano p7zip parted procps psmisc sudo systemd-sysv tzdata udev unzip usbutils wget whiptail dropbear-run fdisk initramfs-tools haveged hdparm linux-dtb-current-rockchip64 linux-u-boot-nanopineo3-current linux-image-current-rockchip64 linux-buster-root-current-nanopineo3 sunxi-tools armbian-firmware
   - Exit code      | 100
   - Software title | DietPi-PREP
   #### Steps to reproduce:
   <!-- Explain how to reproduce the issue -->

2. Install Armbian NEO3 image
3. Run DietPi-PREP script, branch "master" and target image "branch master"

   Expected behaviour:

   • Image generation should run without errors

     Actual behaviour:

   • See error message below

     Extra details:

   • Manually changing the command by removing the "linux-buster-root-current-nanopineo3" from the apt-get command and rerun the command (option within the PREP script) works.
   • But then another problem occurs: Command: mount -o remount /tmp
   • Exit code: 32
   • DietPi version: v6.31.2 (MichaIng/master) | HW_MODEL: 22 | HW_ARCH: 3 | DISTRO: 5
   • Error log: mount: /tmp: mount point not mounted or bad option. Then: Changing the command to "mount /tmp" works and the PREP script finishes without further errors.

Additional logs:

E: Package 'linux-buster-root-current-nanopineo3' has no installation candidate

2. Both dev: 
Only the second problem given above within "Extra details" with "mount: /tmp: mount point not mounted or bad option." occurs and can be 'workarounded' with "mount /tmp".

[MichaIng]

E: Package 'linux-buster-root-current-nanopineo3' has no installation candidate

Okay it looks like the image/repo is not yet complete from Armbian side. DietPi-PREP only marks the already installed packages for install/upgrade, hence linux-buster-root-current-nanopineo3 is installed but missing in the (installed) APT repo.

Just checked, indeed its missing in the stable repo but available on beta: http://beta.armbian.com/pool/main/l/linux-buster-root-current-nanopineo3/ Strange that /etc/apt/sources.list.d/*armbian*.list doesn't use/include the beta repo if it's currently required.

mount: /tmp: mount point not mounted or bad option.

Ah I think that's coming from the dietpi-set_swapfile script, right? It adjusts the tmpfs size to match 50% of available memory but it expects it to be a tmpfs already which seems to be then not true on this Armbian image. You can try to solve it by mounting the tmpfs first: mount -t tmpfs none /tmp Makes sense to do that within the script as well if findmnt /tmp doesn't give a result.

[MichaIng]

DietPi-PREP fix: https://github.com/MichaIng/DietPi/commit/401a70f89c6450586b72aca238e6512b9cb969f9 but larger dietpi-set_swapfile enhancement which includes skipping the remount attempt if /tmp is not a mount: https://github.com/MichaIng/DietPi/commit/646eba8bd9cb1bf3923164ec55a7a0cb051625b8

[goney3]

I just received my Nanopi Neo3 and I am excited to see DietPi being worked on to run on it. Thank you guys so much for looking into this. I really appreciate it as I am a noob.

[StephanStS]

@MichaIng: Executing mount -t tmpfs none /tmp manually in the subshell and doing a retry of the DietPi-PREP mount -o remount /tmp worked. I used dev branch of DietPi-PREP. Should there have been a fix via 401a70f which should avoid the mount problem?

See how it worked:

[ INFO ] DietPi-PREP | Removing swapfile from image
[ SUB1 ] DietPi-Set_swapfile > Applying 0 /var/swap
[ INFO ] DietPi-Set_swapfile | Disabling and deleting all existing swap files
[  OK  ] DietPi-Set_swapfile | swapoff -a
[  OK  ] DietPi-Set_swapfile | Setting in /boot/dietpi.txt adjusted: AUTO_SETUP_SWAPFILE_SIZE=0
[  OK  ] DietPi-Set_swapfile | Desired setting in /boot/dietpi.txt was already set: AUTO_SETUP_SWAPFILE_LOCATION=/var/swap
[ INFO ] DietPi-Set_swapfile | Setting /tmp tmpfs size: 992 MiB
[FAILED] DietPi-Set_swapfile | mount -o remount /tmp
root@nanopineo3:/tmp/DietPi-Set_swapfile# mount -t tmpfs none /tmp
root@nanopineo3:/tmp/DietPi-Set_swapfile# exit
[  OK  ] DietPi-Set_swapfile | mount -o remount /tmp
[  OK  ] DietPi-PREP | Setting in /boot/dietpi.txt adjusted: AUTO_SETUP_SWAPFILE_SIZE=1

[StephanStS]

@goney3: I have an image for the NEO3 ready. Actually it is not downloadable via the dietpi download page. I could support you with a download link to my cloud. In this case please post here your email address so that I can send you the download link via email. Afterwards delete the email address posting to not keep your email address within this post.

[StephanStS]

@MichaIng: Do you want to add an unique ID for the NEO3 to the DietPi-PREP script?

[Oleks1y]

I have an image for the NEO3 ready. Actually it is not downloadable via the dietpi download page.

please share the link here

[goney3]

DietPi installed on the NEO3 fine with StephanStS's image, I set up an LXDE desktop without issue. Though I finally noticed the NEO3 runs very hot. It idles at 63°C and a survey test pushed it to 85°C in mere seconds. I went to examine the heatsink that's included but the smooth white case seems impossible to open? I ordered some thermal paste in the meantime. Are there any tests you'd like me to run and report back on? A huge thank you to StephanStS for the image!

[Oleks1y]

DietPi installed on the NEO3 fine with StephanStS's image, I set up an LXDE desktop without issue. Though I finally noticed the NEO3 runs very hot. It idles at 63°C and a survey test pushed it to 85°C in mere seconds. I went to examine the heatsink that's included but the smooth white case seems impossible to open? I ordered some thermal paste in the meantime. Are there any tests you'd like me to run and report back on? A huge thank you to StephanStS for the image!

I've read that the reason for the high temperature is a Bluetooth service that burns CPU.

[goney3]

There must be some truth to that, I set it to power saving mode ~400 MHz in dietpi-config and the temp was still around 61°C at idle 😬

I had no idea that it has Bluetooth though, I thought it was LAN only 🤔

[MichaIng]

Hey guys, jep I'll implement NEO3 support tomorrow with new hardware ID etc. Sorry for delay, I made some excursus into web design, css, js etc to update and freshen our website. Now back on DietPi shell coding 😃.

[Oleks1y]

Awesome news!!!!

[MichaIng]

NEO3 ID/detection added: #3713 Not sure about use cases where GPU support might be required, server-side (trans)coding or VNC with server-side rendered desktop? Is it even possible to start an Xserver instance or does it fail as no screen is attached, or RK3328 GPU disabled hardware/firmware/kernel-wise?

[StephanStS]

@Oleks1y: Same as above: I could support you with a download link to my cloud. In this case please post here your email address so that I can send you the download link via email. Afterwards delete the email address posting to not keep your email address within this post.

@MichaIng: Actually generating an image, based on dev with NEO3 ID. On the contrary to the image generation processes before, no error occured during the image generation. I.e. your fixing helped. 👍

[MichaIng]

Great. Please manually switch dietpi.txt > DEV_GITBRANCH=master so that systems are migrated to stable branch automatically once released.

In the past we did these migrations in steps via dietpi-update but, aside of patch overhead, then the previous branch update is in progress already and stable branch is only applied for the next available update. We could say "It's testing, hence take care yourself to switch the branch, if wanted." but I'd like to keep migration from testing image to stable DietPi code as seamless as possible 🙂. Also this allows users to stay at beta/dev if chosen manually without having dietpi-update reverting this choice.

For easy image creation, probably in such cases it is best if DietPi-PREP applies master/stable branch automatically, regardless if prior branch choice, so that the branch choice only applies to the initial code base but does not affect the target branch of the final system? For testing of recent beta/dev commits (as well when new SBC image-related) this means that one needs to manually switch. Kinda minor trade-off contributors/devs vs end-user testers 😄.

[StephanStS]

Regarding NEO3 temperature: I did not see any difference between BT enabled or disabled.

@goney3: I have unmounted the white plastic housing. I made some photos for this but I cannot attach them here. There are small noses in the housing parts where you can open it. The heatsink is mounted with a thermal pad, so there is no need to use a thermal paste as long as you do not use a different heatsink. @MichaIng: Can I attach photos (png, gif,...)?

[Joulinar]

Usually it should be possible on GitHub. Just move the picture into the text field or use add picture button

[StephanStS]

@MichaIng: OK, I changed the dietpi.txt to 'master' and generated the .7z again. So it is now downloadable from my cloud.

@Joulinar: By pasting a screenshot (-> .png) the editor flashes "![Uploading grafik.png]" but ternimates with Something went really wrong, and we can't process that file. Try again. I found the root cause: My Pihole blocked github-production-user-asset-6210df.s3.amazonaws.com. My fault. :-)

[StephanStS]

@goney3: Here come some pics from my NEO3 opened.

[goney3]

I've been throttling the CPU down to 408 MHz with a peak of 600 MHz in an effort to lower the temperature, but its hovering around 59 to 61 C at idle, this must be an issue with the RK3328

I used Snowflake to SSH and install optimized packages, I initially used SmarTTY but it didn't like it. I've installed LXDE and I use XRDP to connect through Windows Remote Desktop and select Xvnc at login

I apt installed the Arc-theme (Arc-Dark) and set a transparency for the panel. I then made a cheeky wallpaper to match the current state of the NEO3 lol

[MichaIng]

Nice to see it in action! I hope our testing sample arrives soon.

Is it possible to start a local X session to attach to via VNC? I.e. startx?

[goney3]

I'd need to read up on startx to try and do what you are suggesting Michalng. I unfortunately don't know enough yet 😭

[MichaIng]

It's the command that starts the Xserver with whichever default session has been applied. If you installed a desktop (which is done together with the VNC server) then it will start the desktop. Since it cannot run on a pseudo terminal like SSH session, it will be started on the first "real" TTY, i.e. /dev/tty1. But what I am not sure about is if the Xserver requires a screen/monitor being attached to this TTY or if this is solved via some internal framebuffer that can be used/manipulated by the Xserver. Then one would be able to start a local X/desktop session and attach to it via x11vnc to use it as shared desktop.

So a simple test is to call startx from the SSH session and see what happens. Either if fails with an error or it successfully initiates an X session in foreground (you only see console output, no desktop of course) that one can then interrupt via ctrl+c.

[Oleks1y]

I've got a parcel with neo3 and installed armbian. the same hot processor here as well. immediately after the start is 85C

[StephanStS]

My NEO also started idle at 65 degree. I then added an additional small heatsink which led to about 52 degree idle temperature. In my view the standard heatsink is too small, with this hot temperature the lifetime of the system degrades. As a rule of thumb it is said that increasing the chip temperature by 10 degrees will give half of the lifetime. In your case: Running the system at 55°C instead of 85°C will give a 8 x longer lifetime of the NEO3.

The plastic housing is too small to use a larger heatsink and also to use a fan. So we have to consider to use a different heatsink and forget the plastic housing. Or easier: Add additional heatsinks on top of the actual one (I know that this will give a poorer thermal transmission, but it helps: Use one heatsink with cooling fins upside down going into the actual heatsink cooling fins and put a second additional heatsink on top with cooling fins showing up). The acutal heatsink is mounted very elegantly with screws which I don't want to loose.

[MichaIng]

Note that Armbian kernel mostly raises clocks to hardware maximum by default. The official manufacturer kernel/images often ship with lower clocks, hence lower temperatures. I see clocks officially range from 400 MHz to 1296 MHz, what is yours? cpu But I see that you guys get high temperatures with manual throttling as well, so finally it seems this larger SoC on a tiny form factor that simply requires a heat sink at least.

Mine should arrive on Friday btw 😃.

[StephanStS]

@Oleks1y: An NEO3 image is now available there: https://dietpi.com/downloads/images/testing/. Image name is DietPi_NanoPiNEO3-ARMv8-Buster.7z.

[MichaIng]

Mine arrived as well. Did anyone manage to open the case without breaking anything 😄? Since I know whats inside (+ the thin head sink visible through the slits) I'll leave it closed for now. With this small slits I guess its clear that such a SoC in such small space heats up, while the heat sink can only have a very temporal effect here to cover short term loads. until itself + the case around has gotten hot.

Trying the image now.

[StephanStS]

@MichaIng: See my photos above and locate the small noses. I opened it without breaking them. :-)

[MichaIng]

Ah forgot about your very helpful photos. However, I'll leave it closed for now. Runs fine so far, initial temperature is 52 °C:

 ─────────────────────────────────────────────────────
 DietPi v6.31.2 (dev) : 14:35 - Fri 08/21/20
 ─────────────────────────────────────────────────────
 - Device model : NanoPi NEO3 (aarch64)
 - CPU temp : 52'C : 125'F (Running warm, but safe)
 - LAN IP : 192.168.1.41 (eth0)
 - MOTD : Help testing the new RPi3/RPi4 64-bit image:
          https://github.com/MichaIng/DietPi/issues/3570
 ─────────────────────────────────────────────────────

 DietPi Team     : MichaIng (lead), Daniel Knight (founder), Joulinar (support)
 Image           : StephanStS (pre-image: Armbian)
 Web             : https://dietpi.com | https://twitter.com/dietpi_
 Patreon Legends : Bryce
 Donate          : https://dietpi.com/#donate
 DietPi Hosting  : Powered by https://myvirtualserver.com

 dietpi-launcher : All the DietPi programs in one place.
 dietpi-config   : Feature rich configuration tool for your device.
 dietpi-software : Select optimized software for installation.
 htop            : Resource monitor.
 cpu             : Shows CPU information and stats.

root@DietPi:~# cpu

 ─────────────────────────────────────────────────────
 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 ─────────────────────────────────────────────────────
 Architecture |     aarch64
 Temperature  |     53'C : 127'F (Running warm, but safe)
 Governor     |     ondemand
 Throttle up  |     50% CPU usage

                 Current Freq    Min Freq   Max Freq
 CPU0         |      1512 MHz      408 MHz    1512 MHz
 CPU1         |      1512 MHz      408 MHz    1512 MHz
 CPU2         |      1512 MHz      408 MHz    1512 MHz
 CPU3         |      1512 MHz      408 MHz    1512 MHz

[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.

Max clock rates are really high, AFAIK ROCK64 (same SoC, much larger SBC) default clock with official kernel (non-Armbian) is 1.3 GHz.

[MichaIng]

Now at 60 °C. Interesting also how long it was in which state:

root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
408000 62343
600000 414
816000 78
1008000 111
1200000 21
1296000 10
1512000 9321

Temps settled at 63°C now on idle.

With ondemand throttle up at 50% you see that its basically either in lowest or highest frequency while the intermediate pstates are nearly unused:

root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table
   From  :    To
         :    408000    600000    816000   1008000   1200000   1296000   1512000
   408000:         0        32        11         3         4         1        40
   600000:        38         0         5         3         2         1        12
   816000:         9         6         0         4         2         2         9
  1008000:         6         4         5         0         3         1         9
  1200000:         0         4         1         7         0         2         2
  1296000:         0         2         0         1         2         0         3
  1512000:        38        12        10        10         3         1         0

Actually on modern kernel, schedutil governor should do a quite good job, lets see how this affects the pstate table:

root@DietPi:~# echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
root@DietPi:~# echo 1 > /sys/devices/system/cpu/cpufreq/policy0/stats/reset

Reminder to myself that we really need to add this governor to dietpi-config.

---

With schedutil CPU governor

With schedutil the picture is already quite a different one, cpu shows medium frequencies no certain cores instead of all max:

root@DietPi:~# cpu

 ─────────────────────────────────────────────────────
 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 ─────────────────────────────────────────────────────
 Architecture |     aarch64
 Temperature  |     64'C : 147'F (Running hot, not recommended)
 Governor     |     schedutil

                 Current Freq    Min Freq   Max Freq
 CPU0         |      1512 MHz      408 MHz    1512 MHz
 CPU1         |      1296 MHz      408 MHz    1512 MHz
 CPU2         |      1200 MHz      408 MHz    1512 MHz
 CPU3         |      1200 MHz      408 MHz    1512 MHz

[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.

But actually all cores always run on same clock, as all are added to a single policy. That shows only how the frequency is going down while the script loops through the individual files 😉. After little setup action, the intermediate pstates are used much better:

root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
408000 72288
600000 1224
816000 538
1008000 986
1200000 493
1296000 462
1512000 2606

[MichaIng]

🈴 haveged entropy daemon is failing

root@DietPi:/boot# haveged --Foreground
haveged starting up
haveged: Couldn't initialize HAVEGE rng 5

Found an old bug report which provides a workaround that works here as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866306

root@DietPi:/boot# haveged --Foreground -d 16
haveged starting up

It is strange since 16 should be the default fallback:

root@DietPi:/boot# haveged --help 2>&1 | grep '\-d'
     --data      , -d [] Data cache size [KB], with fallback to: 16

Never saw this on any other device. I was actually hoping for enabled hardware random generator, but it doesn't seem to be available.

Workaround:

G_CONFIG_INJECT 'DAEMON_ARGS=' 'DAEMON_ARGS="-w 1024 -d 16"' /etc/default/haveged

This should speed up boot and process starts quite a lot, especially when services are active which consume randomness, e.g. PHP was a prominent example.

---

Back on hardware random generator, actually this SoC should provide one: https://forum.pine64.org/showthread.php?tid=6118&page=2

root@NEO3:~# grep 'HWRNG' /boot/config-5.4.51-rockchip64
# CONFIG_ATH9K_HWRNG is not set
# CONFIG_CARL9170_HWRNG is not set
CONFIG_B43_HWRNG=y
CONFIG_B43LEGACY_HWRNG=y
root@NEO3:~# grep -E 'RNG|RANDOM' /boot/config-5.4.51-rockchip64
# CONFIG_SLAB_FREELIST_RANDOM is not set
# CONFIG_RANDOMIZE_BASE is not set
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_NET_TEAM_MODE_RANDOM=m
# CONFIG_ATH9K_HWRNG is not set
# CONFIG_CARL9170_HWRNG is not set
CONFIG_B43_HWRNG=y
CONFIG_B43LEGACY_HWRNG=y
CONFIG_HW_RANDOM=m
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_VIRTIO is not set
CONFIG_HW_RANDOM_MESON=m
CONFIG_HW_RANDOM_CAVIUM=m
# CONFIG_RANDOM_TRUST_BOOTLOADER is not set
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=y
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_USER_API_RNG=m
# CONFIG_RANDOM32_SELFTEST is not set
# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set
# CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET is not set

root@NEO3:~# find /lib/modules -name '*rng*'
/lib/modules/5.4.51-rockchip64/kernel/crypto/algif_rng.ko
/lib/modules/5.4.51-rockchip64/kernel/crypto/ansi_cprng.ko
/lib/modules/5.4.51-rockchip64/kernel/drivers/char/hw_random/rng-core.ko
/lib/modules/5.4.51-rockchip64/kernel/drivers/char/hw_random/meson-rng.ko
/lib/modules/5.4.51-rockchip64/kernel/drivers/char/hw_random/cavium-rng.ko
/lib/modules/5.4.51-rockchip64/kernel/drivers/char/hw_random/cavium-rng-vf.ko

root@NEO3:~# modprobe rng-core
root@NEO3:~# ls -al /dev/hwrng
crw------- 1 root root 10, 183 Aug 21 17:08 /dev/hwrng

There it is. Is it functional? Nope sadly not:

root@NEO3:~# rngd -fvo /dev/hwrng
read error

read error

Available entropy sources:
        Intel/AMD hardware rng
can't open /dev/hwrng: Invalid argument

Intel/AMD, hmm... just the same with meson and cavium modules which pull rng-core as well, but expected since those are simply the wrong chips.

Okay I give it up. @StephanStS @Oleks1y @goney3 is haveged failing the same way for you? journalctl -u haveged

[StephanStS]

Hello @MichaIng: The haveged output like you mentioned:

root@DietPi:~# journalctl -u haveged
-- Logs begin at Thu 2020-08-13 23:24:03 BST, end at Sat 2020-08-22 11:08:39 BST. --
Aug 13 23:24:04 DietPi systemd[1]: Started Entropy daemon using the HAVEGE algorithm.
Aug 13 23:24:04 DietPi haveged[375]: haveged: Couldn't initialize HAVEGE rng 5
Aug 13 23:24:04 DietPi haveged[375]: haveged starting up
Aug 13 23:24:04 DietPi systemd[1]: haveged.service: Main process exited, code=exited, status=1/FAILURE
Aug 13 23:24:04 DietPi systemd[1]: haveged.service: Failed with result 'exit-code'.

My time_in_state outputs are like yours, also when I did the schedutil command line like you did above. Then comparable results occur.

[MichaIng]

Strange with haveged. Probably we have to check if this is somehow a general issue with the current version (on ARM) or SBC/SoC-specific, at least neither on VM nor on PC I can replicate. Will try later on RPi where we generally use rng-tools since RPi kernel has a functional hardware random generator enabled.

For now we then should apply the workaround for the NEO3 image:

G_CONFIG_INJECT 'DAEMON_ARGS=' 'DAEMON_ARGS="-w 1024 -d 16"' /etc/default/haveged

You should be able to see the entropy pool filling much faster on boot: dmesg | grep random => random: crng init done timestamp. Until this is reached, depending on installed software/services boot can be delayed or network connectivity is not there before (I think in case of WiFi only), or it has a security decrease aspect when some task requires high quality random data and is forced to use pseudo-random data because the entropy pool is empty or such. Definitely something we should assure functional 😉.

[StephanStS]

@MichaIng: Shall I try to generate an image of the p.c.b. for https://github.com/MichaIng/DietPi-Website/tree/master/images/sbc_images? The image I can generate will not be as nice as all the other images...

[MichaIng]

I think we can go with the images from http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO3#Hardware_Spec. To be true, especially now that its on GitHub, I never through through the legal/license aspects, cannot find something about it. But practically for such product-related pictures its advertising and we potentially produce additional customers, so nothing to worry about.

[Oleks1y]

Okay I give it up. @StephanStS @Oleks1y @goney3 is haveged failing the same way for you? journalctl -u haveged

i have the following output

root@nanopineo3:~# journalctl -u haveged -- Logs begin at Tue 2020-08-25 23:53:00 CEST, end at Wed 2020-08-26 00:45:01 CEST. -- -- No entries --

[goney3]

[MichaIng]

Haveged fixed with: https://github.com/MichaIng/DietPi/commit/87ef9a48d138932381e3cf06ed691e59a29b64e2 On DietPi-PREP for new images as well.

[StephanStS]

@MichaIng: My proposal is to close this issue and also to close https://feathub.com/MichaIng/DietPi/+172 "Image | NanoPi NEO3".

[MichaIng]

Jep, I'll add the NEO3 image to our download page later, then close it. Often I keep issues open until the related milestone has been reached, v6.32 release in this case, so during beta phase tester feel more convenient to still report test results, bugs, requests or such, compared to when doing this on a closed issue.

[MichaIng]

I added NanoPi NEO3, R2S and K2 to the download page now, marked as beta until we have a few more reported users. I mark this as closed as suggested.

[Oleks1y]

[Oleks1y]

Nice reading https://www.cnx-software.com/2020/10/18/nanopi-r2s-nanopi-neo3-tested-with-armbian-thermal-test-ethernet-and-usb-performance/