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 https://github.com/MichaIng/DietPi/issues/5598#issuecomment-1206370852 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.

[pyavitz]

yes. narmstrong added support for it a whiles back. only downside to it is you can't define an overlay directory, so everything needs to be a direct path

for example

fdtoverlays ../amlogic/overlays/meson-g12a-opp-2ghz.dtbo ../amlogic/overlays/meson-g12-gxl-cma-pool-896MB.dtbo ../amlogic/overlays/meson-g12a-gpio-8-led.dtbo

extlinux treats its directory as root, so you can ../ out of it instead of doing /boot/dtb/overlays/etc....

[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 ?

I re-did the packaging, if you wanna give it a try.