search

MichaIng / DietPi

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

Image | NanoPi R4SE #5712

Open mrbluecoat opened 2 years ago

mrbluecoat commented 2 years ago

Creating an image request

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?

mrbluecoat commented 2 years ago

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

It also has the odd partition structure mentioned on #5598

mrbluecoat commented 2 years ago

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

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

mrbluecoat commented 2 years ago

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

mrbluecoat commented 2 years ago

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

mrbluecoat commented 2 years ago

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

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 commented 1 year ago

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 commented 1 year ago

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

pyavitz commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

pyavitz commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

Are kernel/bootloader/firmware DEB packaged?

pyavitz commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

pyavitz commented 1 year ago

They would need to patch uboot and the kernel.

mrbluecoat commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

mrbluecoat commented 1 year ago

The latest image seems to boot okay and I can get a prompt for the npi password via SSH but when providing the npi password it immediately disconnects (no error indicating wrong password, just a GNU welcome screen and then drops me back to my local machine prompt). Is there a root password to try?

mrbluecoat commented 1 year ago 
npi@192.168.75.22's password: <-- typed "npi"
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
Authenticated to 192.168.75.22 ([192.168.75.22]:22) using "password".
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Entering interactive session.
debug1: pledge: filesystem
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env WINDOWID
debug3: Ignored env QT_ACCESSIBILITY
debug3: Ignored env COLORTERM
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env XDG_SESSION_PATH
debug3: Ignored env XDG_MENU_PREFIX
debug3: Ignored env SAL_VCL_QT5_USE_CAIRO
debug3: Ignored env LANGUAGE
debug1: channel 0: setting env LC_ADDRESS = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: channel 0: setting env LC_NAME = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env XDG_DATA_HOME
debug3: Ignored env XDG_CONFIG_HOME
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env LXQT_SESSION_CONFIG
debug1: channel 0: setting env LC_MONETARY = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env XDG_SEAT
debug3: Ignored env PWD
debug3: Ignored env XDG_SESSION_DESKTOP
debug3: Ignored env LOGNAME
debug3: Ignored env QT_QPA_PLATFORMTHEME
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env GPG_AGENT_INFO
debug3: Ignored env XAUTHORITY
debug3: Ignored env HOME
debug1: channel 0: setting env LC_PAPER = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env LS_COLORS
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env XDG_SEAT_PATH
debug3: Ignored env GTK_CSD
debug3: Ignored env XDG_CACHE_HOME
debug3: Ignored env LESSCLOSE
debug3: Ignored env XDG_SESSION_CLASS
debug3: Ignored env TERM
debug1: channel 0: setting env LC_IDENTIFICATION = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env GTK_OVERLAY_SCROLLING
debug3: Ignored env LESSOPEN
debug3: Ignored env USER
debug3: Ignored env COLORFGBG
debug3: Ignored env DISPLAY
debug3: Ignored env SHLVL
debug1: channel 0: setting env LC_TELEPHONE = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: channel 0: setting env LC_MEASUREMENT = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env XDG_VTNR
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env QT_PLATFORM_PLUGIN
debug1: channel 0: setting env LC_TIME = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env BROWSER
debug3: Ignored env PATH
debug3: Ignored env SAL_USE_VCLPLUGIN
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug1: channel 0: setting env LC_NUMERIC = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 65536 rmax 32759
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: chan_shutdown_write: channel 0: (i0 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug2: chan_shutdown_read: channel 0: (i0 o3 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1 io 0x00/0x00)

debug3: send packet: type 1
Connection to 192.168.75.22 closed.
Transferred: sent 2712, received 1396 bytes, in 0.0 seconds
Bytes per second: sent 254170.5, received 130834.1
debug1: Exit status 1
pyavitz commented 1 year ago

I don't believe I included a root passwd for those imgs. I could do so though.

mrbluecoat commented 1 year ago

After some digging, I don't think it's a problem with ssh since I'm able to login and view the MOTD so I don't think root access is necessary. Perhaps compare the .bashrc, .profile, and sshd_config with your earlier image?

pyavitz commented 1 year ago

I uploaded a new img with the "common" kernel packaging naming. As for the older img, pretty sure it got tested yesterday and no one reported any login issues.

if you need it; root:toor

mrbluecoat commented 1 year ago

I can now login with npi again, thanks. The root login didn't work for me (timed out) but not a deal breaker. I'll try the dietpi-installer again

Joulinar commented 1 year ago

Use the dev brach for the installer. There is a small bug inside master that will set incorrect shell for root user during installation.

mrbluecoat commented 1 year ago

Woot! Success! DietPi_NanoPiR4SE-ARMv8-Bullseye.7z

results results2

You guys rock!

Renoria commented 1 year ago

Woot! Success! DietPi_NanoPiR4SE-ARMv8-Bullseye.7z

results results2

You guys rock!

I don't want to bump the thread however I am not seeing this build under the downloads section. Will it get added in the future or? I am looking to purchase the R4SE and would like to make use of the onboard memory to have the OS running.

Joulinar commented 1 year ago

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

Renoria commented 1 year ago

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 commented 1 year ago

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

Renoria commented 1 year ago

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

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

mrbluecoat commented 1 year ago

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

pyavitz commented 1 year ago

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

Check.

mrbluecoat commented 1 year ago

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
  1. 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

screen

pyavitz commented 1 year ago

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
  1. 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

  1. 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 commented 1 year ago

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 commented 6 months ago

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 commented 6 months ago

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.