Image | NanoPi R4SE

[mrbluecoat]

Creating an image request

• Note: this is different than the NanoPi R4S, which is already supported by DietPi. That image does not work in the R4SE.

Formal device information

• Device name | NanoPi R4SE
• Official product URL | https://www.friendlyelec.com/index.php?route=product/product&path=69&product_id=288
• Official wiki URL | https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R4SE
• GitHub resource URL (if available) |
• Image download URL | https://download.friendlyelec.com/NanoPiR4SE

Is the SBC officially supported by the Debian installer?

• Not yet

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

• Buster kernel 4.19 provided by FriendlyElec: https://drive.google.com/file/d/1WKpfk8c7nDRzRtoUlpgmYkDXPhQavjIC/view?usp=sharing

[mrbluecoat]

It seems apt util-linux e2fsprogs are problematic with the official image from FriendlyElec. Here's as far as I could get with my testing:

# login with pi:pi

sudo su -

rm /etc/init.d/rkisp_3A.sh

for hold in $(apt-mark showhold); do apt-mark unhold $hold; done

apt-mark hold apt util-linux e2fsprogs

apt remove -y --purge libmali-midgard-t86x-r18p0-x11 rkisp-engine anacron adwaita-icon-theme arc-theme gnome-icon-theme gnome-themes-extra-data gnome-themes-extra hicolor-icon-theme lxde-icon-theme numix-icon-theme-circle numix-icon-theme papirus-icon-theme sound-theme-freedesktop '*office*' '*xfce*' '*qt5*' '*xserver*' '*xorg*' lightdm x11-common desktop-base

apt autoremove -y

passwd
# toor

sed -i 's/#PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config

reboot

# login with root:toor

export LC_ALL=C

deluser --remove-home pi

cat > /etc/apt/sources.list <<EOF

deb http://deb.debian.org/debian bullseye main
deb http://deb.debian.org/debian bullseye-updates main
deb http://deb.debian.org/debian bullseye-backports main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main

EOF

apt update
apt upgrade -y
apt full-upgrade -y
apt autoremove -y

reboot

export LC_ALL=C

# DietPi -- use "Generic Device"
apt update
apt install -y systemd-sysv ca-certificates sudo wget locales --reinstall
wget https://raw.githubusercontent.com/MichaIng/DietPi/master/.build/images/dietpi-installer
chmod +x dietpi-installer
./dietpi-installer

# hangs on:
Preparing to unpack .../archives/apt_2.2.4_arm64.deb ...                                                                           
Unpacking apt (2.2.4) over (1.8.2.3) ...                                                                                           
Setting up apt (2.2.4) ...                                                                                                         
                                                                                                                                   
Configuration file '/etc/apt/apt.conf.d/01autoremove', does not exist on system.                                                   
Installing new config file as you requested.                                                                                       
Installing new version of config file /etc/kernel/postinst.d/apt-auto-removal ...

[mrbluecoat]

It also has the odd partition structure mentioned on #5598

[mrbluecoat]

no luck with my second attempt:

# login with pi:pi

sudo su -

passwd
# toor

sed -i 's/#PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config

reboot

# login with root:toor

export LC_ALL=C

apt remove -y --purge libmali-midgard-t86x-r18p0-x11

for hold in $(apt-mark showhold); do apt-mark unhold $hold; done

apt-mark hold apt util-linux e2fsprogs

apt clean
apt update
apt install -y -f
apt upgrade -y
apt dist-upgrade -y
apt full-upgrade -y
apt autoremove -y

reboot

# login with root:toor

export LC_ALL=C

apt install -y systemd-sysv ca-certificates sudo wget locales --reinstall

sleep 5 && wget https://raw.githubusercontent.com/MichaIng/DietPi/master/.build/images/dietpi-installer

sed -i 's/# DietPi list of minimal required packages.*/G_EXEC apt-mark hold apt util-linux e2fsprogs/' ./dietpi-installer
sed -i 's/# Purging additional packages.*/G_EXEC apt-mark hold apt util-linux e2fsprogs/' ./dietpi-installer
sed -i "/'apt'.*/d" ./dietpi-installer
sed -i '/aPACKAGES_REQUIRED_INSTALL.*e2fsprogs/d' ./dietpi-installer

chmod +x dietpi-installer
./dietpi-installer

# select "Generic Device"

[mrbluecoat]

One step closer: https://github.com/coolsnowwolf/lede/blob/3211a973de1351e8387eced77526190947e39598/target/linux/rockchip/files/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4se.dts

[mrbluecoat]

And https://github.com/coolsnowwolf/lede/blob/master/package/boot/uboot-rockchip/Makefile#L96

[mrbluecoat]

And lastly: https://github.com/coolsnowwolf/lede/blob/d6f75eefa1e85cd325bdcef74dd1f0a17b1ea5d1/target/linux/rockchip/image/armv8.mk#L84

[mrbluecoat]

The good news is https://www.armbian.com/nanopi-r4s/ works on the R4SE (boots from SD card and recognizes both ethernet ports). Unfortunately, nand-sata-install doesn't work yet due to a missing patch.

[MichaIng]

Great, so no own image is required but we need to update ours for R4S. Long overdue anyway for the NanoPi's, to add them to our image generation CI.

[mrbluecoat]

Woot! Thanks to the great work by @pyavitz on #5598 (comment) and @coolsnowwolf on https://github.com/coolsnowwolf/lede/blob/master/target/linux/rockchip/files/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4se.dts I was able to compile rk3399-nanopi-r4se-dtb.zip then load rk3568-nanopi-r5s-debian-bullseye-5.19.8-arm64-2022-09-14.img.xz on to an SD card then add rk3399-nanopi-r4se.dtb to ROOTFS/boot/rockchip and edit ROOTFS/boot/extlinux/extlinux.conf to say fdt ../rockchip/rk3399-nanopi-r4se.dtb , boot then login as npi:npi for a working NanoPi R4SE Armbian OS!

P.S. Not sure if it was a necessary step, but I first cleared the eMMC boot loader via FriendlyElec's instructions with one of their provided OS images: dd if=/dev/zero of=/dev/mmcblk2 bs=8M count=1 (alternatively, you might need to press the "Mask" button on the side of the device for 3 seconds when powering to bypass the eMMC boot loader)

[mrbluecoat]

hmm.. having intermittent boot issues. will continue to investigate

[pyavitz]

hmm.. having intermittent boot issues. will continue to investigate

I'm suprised you are booting at all. U-Boot should be different for that board.

[mrbluecoat]

It must have been using the uboot from the eMMC. After I cleared the eMMC boot loader the modified R5S image doesn't boot as you expected. I'm recompiling for R4SE specifically now and I'll let you know how it goes.

[mrbluecoat]

No luck after a week of hacking. I'll take a break for a bit.

[pyavitz]

No luck after a week of hacking. I'll take a break for a bit.

Try the new image. I'm told it works.

[mrbluecoat]

Whoa! That worked - both SD card and eMMC!! You da' man, @pyavitz

wget https://github.com/pyavitz/binary/releases/download/images/rk3399-nanopi-r4se-debian-bullseye-5.19.11-arm64-2022-09-27.img.xz

xz -dc rk3399-nanopi-r4se-debian-bullseye-5.19.11-arm64-2022-09-27.img.xz | dd of=/dev/mmcblk2 status=progress

[pyavitz]

Whoa! That worked - both SD card and eMMC!! You da' man, @pyavitz

wget https://github.com/pyavitz/binary/releases/download/images/rk3399-nanopi-r4se-debian-bullseye-5.19.11-arm64-2022-09-27.img.xz

xz -dc rk3399-nanopi-r4se-debian-bullseye-5.19.11-arm64-2022-09-27.img.xz | dd of=/dev/mmcblk2 status=progress

enjoy.

[mrbluecoat]

@MichaIng, the dietpi-installer didn't work (no boot after eMMC updated with generic device selected) but at least the new Armbian image is a step in the right direction for DietPi

[MichaIng]

Are kernel/bootloader/firmware DEB packaged?

[pyavitz]

The kernel is a deb package. The bootloader is flashed and a copy of the bin(s) stored at /usr/lib/u-boot/. The firmware depending on the distro and board, is whatever the distro provides along with some drop in.

[MichaIng]

Is it named linux-image-*? Then it should stay after dietpi-installer, but if it has a different name, it would be purged, indeed.

[pyavitz]

in this case rockchip64-image-* rockchip64-headers-*.
I set kernel names in the patching function; https://github.com/pyavitz/debian-image-builder/blob/feature/lib/function/linux-patching#L4

[MichaIng]

This explains it. So the script needs to be edited to preserve these packages. However, I suggest to follow the Linux package naming convention (like linux-image-rockchip64), since I'm not keen to maintain a long list of 3rd party image package names 😉.

[pyavitz]

I think a PR should be open over at Armbian. The patching I'm using for the R4SE is very limited and wouldn't take much effort to get working. It's basically a u-boot hack and a kernel patch. Igor is currently working on the R5S, so now would probs be a good time to introduce it.

[MichaIng]

But Armbian kernel packages do follow this conversion, so nothing to patch on their end.

[pyavitz]

They would need to patch uboot and the kernel.

[mrbluecoat]

in this case rockchip64-image-* rockchip64-headers-*. I set kernel names in the patching function; https://github.com/pyavitz/debian-image-builder/blob/feature/lib/function/linux-patching#L4

So would it be possible it change packagename=rockchip64-linux-image to packagename=linux-image-rockchip64 @pyavitz ?

[pyavitz]

in this case rockchip64-image-* rockchip64-headers-*. I set kernel names in the patching function; https://github.com/pyavitz/debian-image-builder/blob/feature/lib/function/linux-patching#L4

So would it be possible it change packagename=rockchip64-linux-image to packagename=linux-image-rockchip64 @pyavitz ?

As a "somewhat" quick fix for this use case, sure.

You need to edit the function file lib/function/linux-patching; rockchip_packaging; L58
Then edit patches/packaging/builddeb starting at L270.

In a perfect world this would all be mostly automated through variables in the $board file but I haven't gotten around to it yet.

[MichaIng]

Ah sorry, yes they'd need to add your patches for proper R4SE support inkl. eMMC boot, but at least the kernel package has the common naming that is preserved by our installer 😅.

Wait, does extlinux support device tree overlays natively via fdtoverlays setting (just saw in one of your recent commits)? I didn't know that. If fdtoverlay_addr_r is defined consequently and correctly by U-Boot, looks like we can migrate everything over to extlinux soon and have a much simpler boot configuration compared to uEnv.txt => boot.cmd => boot.scr.

[Joulinar]

The image was not created by us. It was done by a user 😄 . Therefore it is not available on our download page.

[Renoria]

The image was not created by us. It was done by a user 😄 . Therefore it is not available on our download page.

I see, any chances it will be picked up officially?

[MichaIng]

I'll have a look, pyavitz's images/packaging looks pretty good.

[Renoria]

I'll have a look, pyavitz's images/packaging looks pretty good.

Thanks! Hopefully it's good to be included next release :D

[mrbluecoat]

@pyavitz thoughts on refreshing the R4SE base image to bookworm?

[pyavitz]

@pyavitz thoughts on refreshing the R4SE base image to bookworm?

Check.

[mrbluecoat]

That worked, thanks! A few notes, all minor issues:

1. WAN and LAN LED lights are switched
2. useraccount.txt doesn't let you set the root user password
3. Both NICs detected but both assigned same IP address

Conversion to DietPi went fairly smoothly. A couple notes, all minor issues:

1. eth1 detected but not assigned IP address (down). Fix via:

cat >> /etc/network/interfaces <<EOF

# Ethernet 2
allow-hotplug eth1
iface eth1 inet dhcp
address 192.168.0.101
netmask 255.255.255.0
gateway 192.168.0.1
#dns-nameservers 9.9.9.9 149.112.112.112

EOF

2. Failed to connect to bus: No such file or directory message on reboot. Fix via:

apt install -y dbus
systemctl unmask systemd-logind
systemctl start systemd-logind

For reference, here's the eMMC installation command:

# eMMC installation:
apt install -y pv
pv -ptera < DietPi_NanoPi_R4SE-ARMv8-Bookworm.img | dd of=/dev/mmcblk2 obs=512

Download: DietPi_NanoPi_R4SE-ARMv8-Bookworm.7z

[pyavitz]

That worked, thanks! A few notes, all minor issues:

I don't own the board so trouble shooting is limited on my end. If you have ideas on how to fix the issues let me know.

1. WAN and LAN LED lights are switched

Check the udev rule:

/etc/udev/rules.d/10-nanopi-led.rules

2. useraccount.txt doesn't let you set the root user password

I don't set root passwords by default. Users can do that sudo passwd root

3. Both NICs detected but both assigned same IP address

This could be related to a u-boot patch? rockchip-rk3399-add-ethaddr-and-serial-number-init
If you like I can build you a new binary without the patch?

[mrbluecoat]

I'm good with the current image -- all findings were minor and ignore-able for my use case. Thanks again for your quick turnaround.

[MichaIng]

I missed this issue. The NanoPi R4SE still requires an own bootloader binary and does not boot with R4S bootloader, right? Can be added pretty quickly to our build and installer scripts.

[mrbluecoat]

Personally I've moved on to their R5x and R6x lines but it would be nice if you supporte the R4SE officially since you have DietPi images for the other R4x models.

[MichaIng]

Agreed. A gap in the lineup is not nice, especially since people might unnecessarily waste time to test the R4S image.

[Nanianmichaels]

I might be able to test a new image, since I have one of these available.

Let me know what I can do to help, I'd love bringing this little one back to life.