Dietpi: Image | NanoPi NEO4

[FusionPlmH]

detail：
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO4

ADMIN EDIT: Vote for it on FeatHub: https://feathub.com/MichaIng/DietPi/+2

[MichaIng]

Added to FeatHub, feel free to leave a vote: https://feathub.com/MichaIng/DietPi/+2

[FusionPlmH]

any feature support of rk 3399 board ?

[MichaIng]

Another vote: https://dietpi.com/phpbb/viewtopic.php?f=12&t=6003

[MichaIng]

@LeeMenHin
New NanoPC T4 (SDcard) image available: 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.

[FusionPlmH]

Ok now i going to test it

[FusionPlmH]

Ok I finally get sometime to test it , it seem that can boot up successfully .
But the booting time too long , take a few minutes then come up signal to hdmi

Here is 2 file , log1 is first boot , log2 is second boot

https://drive.google.com/open?id=1oAstb6FwQPNfr9qCcHEHdpuxwivRGd2r

[MichaIng]

@LeeMenHin
Many thanks for testing. So one thing is the long taking rootfs unpacking:

[    6.016570] Trying to unpack rootfs image as initramfs...
[   29.479928] Freeing initrd memory: 5924K

[    6.228864] Trying to unpack rootfs image as initramfs...
[   29.707305] Freeing initrd memory: 5924K



md5-4864e34aadbcb25c08d40eef4609c764



[   41.670166] Initialise system trusted keyrings



md5-efa336707c413b6761510c34b3898a74



[   42.069092] Initialise system trusted keyrings



md5-fd8a14d3271d0c05090cec21467edc19



mv /boot/dtb/rockchip/rk3399-nanopc-t4.dtb /boot/dtb/rockchip/rk3399-nanopc-t4.dtb_bak
ln -s /boot/dtb/rockchip/rk3399-nanopi-neo4.dtb /boot/dtb/rockchip/rk3399-nanopc-t4.dtb

So the bootloader now loads the correct NEO4 device tree 🤓. Just in case there is anything in the bootloader that depends on anything specific in the T4 device tree, only do this if you can manually revert it from an external machine.

[MichaIng]

@LeeMenHin
I uploaded a dedicated NEO4 image, lets see if this boots faster: https://dietpi.com/downloads/testing/DietPi_NanoPiNEO4-ARMv8-Buster.7z

[FusionPlmH]

@LeeMenHin
I uploaded a dedicated NEO4 image, lets see if this boots faster: https://dietpi.com/downloads/testing/DietPi_NanoPiNEO4-ARMv8-Buster.7z

This image seem not given any signal ,not showing in hdmi also via ethernet

[MichaIng]

@LeeMenHin
Okay, many thanks for testing, that is bad... I'll recheck it, but did nothing compared with the T4 image :thinking:. Especially HDMI on boot must work of course.

There is some thread on Armbian that with NEO4 and some other boards there are powering troubles when using a PD-compatible PSU: https://forum.armbian.com/topic/8361-usb-c-powered-boards-important-information/
But since it worked with the T4 image, that cannot be the reason in your case.

[MichaIng]

Btw I'll redo a NEO4 image once there is a new one build by Armbian: https://dl.armbian.com/nanopineo4/archive/

• The current one is based on 17.02.2020 Buster current desktop.
• Until then then NanoPC T4 image works, aside of the long taking boot: https://dietpi.com/downloads/testing/DietPi_NanoPCT4-ARMv8-Buster.7z

[FusionPlmH]

Okay , i will use the T4 image first

[FusionPlmH]

[FusionPlmH]

This 2 image is from Armbian 4.4 kernel,it stuck on 2 different point . I need to power off 2 time to bypass those

[MichaIng]

@LeeMenHin
Yeah I got those start job messages as well on fresh Armbian images, first boot. You should try to wait for a few minutes. On my emulator it finished after ~30 seconds, if I remember right.

And btw, since another user managed to boot the NanoPi M4 image, just by waiting for 1-2 minutes (booting from eMMC), you could try this as well with the above NEO4 image (5.X kernel). Indeed it seems to only take a longer time, probably again longer when booting from SDcard, before first HDMI signal appears.

There is also a new 5.X kernel+dtb package available from Armbian, will upgrade the image accordingly, probably you want to wait for that.

[MichaIng]

New image has been uploaded, I also reinstalled the bootloader. Hopefully this works better.

[FusionPlmH]

It seem that using armbian minial image boot up very fast ,after a few time install

[MichaIng]

@LeeMenHin
You used the Linux kernel 4.4 minimal image right? For NanoPi M4 we also observed that the 4.4 image boots normal while the Linux 5.4 image (that our beta images are based on) are booting slow. The question is if the advantages of the massively newer Linux version outweigh a 1.5 minutes boot or not, and if/which other issues might be present with the 5.4 Linux image.

[FusionPlmH]

@LeeMenHin
You used the Linux kernel 4.4 minimal image right? For NanoPi M4 we also observed that the 4.4 image boots normal while the Linux 5.4 image (that our beta images are based on) are booting slow. The question is if the advantages of the massively newer Linux version outweigh a 1.5 minutes boot or not, and if/which other issues might be present with the 5.4 Linux image.

ys using 4.4 minimal image.It boot pretty nice and normal .maybe at this stage keep 4.4 kernel not moving to 5.4

[MichaIng]

@LeeMenHin
I think we'll provide both images and add the hint about 5.4 image boot time. Users that run the device as 24/7 server probably do not case about boot times but might need features and enhancements from the new kernel.

[MichaIng]

Okay I uploaded a separate Linux 4.4 image: https://dietpi.com/downloads/testing/DietPi_NanoPiNEO4-ARMv8-Buster_Linux4.4.7z

[MichaIng]

New image, a NanoPC T4 one again, but the Linux v5 ones booted with no noticeable difference: https://dietpi.com/downloads/images/testing/DietPi_NanoPCT4-ARMv8-Buster.7z

According to another report the long boot time has been resolved with the current kernel/dtb/bootloader stack.

[StephanStS]

@MichaIng: May this isse be closed?

[FusionPlmH]

sorry to reply so late , I just order the M4v2 for test also .

It seem that m4v2 is also facing this issue , need some time to showup

My neo4 is not available at the moment , sorry about it

[StephanStS]

@MichaIng: I could do boot up time measurements with NEO4 and M4v2 using the actual images on DietPi. Testing the boot up time and also the WiFi behaviour.

[MichaIng]

If the new image boots fine on NEO4, we can indeed close it. Would be interesting if boot times are better now, otherwise a Linux 4.4 image would be required to solve this. But IMO a shorter boot time is not reason enough to stay on a legacy kernel.

I'm currently redoing the M4v2 image as well, will post on the other issue regarding this.

[StephanStS]

@MichaIng: Read below and decide whether to close this issue or not. :-)
The new image worked fine. The same tests like there were executed.
The only thing I saw is that at firstboot the SSID scan did not work, it immediately came back without any scan result. After a reboot this worked fine. This issue I saw several weeks ago, I do not memorize at which hardware setup (which NanoPi board).
I could assume that this is an issue due to the PC-T4 image referenced above compared to a NEO4 image. In the past I generated my own NEO4 image based on the actual Armbian image and this issue worked fine.

But at least there is a difference:
The NEO4 from above (T4) shows:
root@NEO4:~# uname -a Linux DietPi 5.4.43-rockchip64 #20.05.2 SMP PREEMPT Tue Jun 2 22:47:34 CEST 2020 aarch64 GNU/Linux

The M4v2 image I generated several weeks ago shows:
root@M4v2:~# uname -a Linux necl 4.4.213-rk3399 #7 SMP Sat May 30 13:20:02 CEST 2020 aarch64 GNU/Linux

Also a NEO4 image I generated several weeks ago shows the rockchip64 (5.4.32-rockchip64).
When I do an apt upgrade I also get the 5.4.43-rockchip64 kernel which seems to work.

All three, the NEO4, M4v2 and PC-T4 are based on the rk3399 chip. But the new NEO image from above shows rockchip64. Do you know the difference? Possibly this image is based on a NanoPi A64 basis which is an Allwinner A64?

Then I switched to optimistic mode (or was it stupid mode?) and tried to change the kernel on the NEO4 from 5.4.43-rockchip64 to a rk3399 via the command
apt install linux-image-rk3399
Then reboot, etc. Then nothing worked any more. :-(

Then I took my oder NEO4 image 5.4.32-rockchip64 and did a apt upgrade to the 5.4.43-rockchip64 kernel, which works fine. (I then did not dare anymore to test a different rk3399 kernel on the NEO4...).

[MichaIng]

The legacy 4.4 kernel was indeed for RK3399 only while the mainline 5.4 kernel is more generic for all 64bit RockChips, which includes RK3399.

What could make the difference is the u-boot package since this loads a different device tree when using the explicit NEO4 one:

apt install linux-u-boot-nanopineo4-current

[StephanStS]

@MichaIng: How do I have to interpret your posting above regarding

apt install linux-u-boot-nanopineo4-current

Shall I use the T4 image given above, install it with first run, then do the update to the mentioned u-boot package, then generate an NEO4 image from this step and test it (whether the first time SSID scan then works)?

[MichaIng]

As long as onboard WiFi finally works fine, the u-boot image should not make a difference actually. Not sure about the reason for failing scan on firstboot, but very unlikely related to u-boot. I just checked to any stored rfkill state (as this was the issue with RPi image) but none is present on the T4 image.

So IMO no need to run further tests with u-boot. If you or anyone else faces persistent hardware or kernel-related issues, the following could be tested:

1. Upgrade all kernel+firmware packages: apt update; apt full-upgrade
2. If issue(s) persist, switch to NanoPi NEO4 u-boot + rootfs package:

apt update
apt install linux-u-boot-nanopineo4-current linux-buster-root-current-nanopineo4
. /usr/lib/u-boot/platform_install.sh
write_uboot_platform "$DIR" "/dev/$(lsblk -no PKNAME $G_ROOTFS_DEV)"

[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 above NEO4 bootloader + root files, we'll reconsider.