NanoPi R2S Plus

Anyone have success with the NanoPi R2S Plus?
I tried searching but didn’t see any hits.

I have been using dietpi on the NanoPi R2S with great success, and had hoped that the same build might work on the R2S Plus, but it isn’t getting an IP on boot so I’ll need to do some investigation. Will report back here with any findings, but please let me know if there’s prior art for me to refer to.

Is there any difference in the specs such as different ethernet chips and drivers?

Those are some pretty neat little rigs…

I used a R4S and OpenWRT as my home router…and it EASILY passes 1GB from my internet…smoking fast!

Ethernet was changed from
RTL8211E to

So perhaps that needs some sort of different driver.

There’s an added RTL8822CS M.2 SDIO Wi-Fi

If I’m reading Supported hardware - Docs correctly - I should be able to just take the friendlyelec provided Debian 11(Bullseye) Core image and turn it into dietpi.

Guess that can be added to my to-do list.

Do not use these images if you can avoid it, they are “rubbish” :smile:.

My goodness, FriendlyELEC throws out new board variants for outdated SoCs all the time. Pretty annoying for any distributor. Likely a new device tree is required, at least for onboard WiFi. Our latest kernel build has one for R2C Plus, but not R2S Plus:


Same for latest mainline Linux sources: rockchip « dts « boot « arm64 « arch - kernel/git/stable/linux.git - Linux kernel stable tree

We could test whether the R2C Plus device tree works, at least for Ethernet. The YT8521S might just be a rebranded RTL8211F. The “LAN” port is the same RTL8153B: NanoPi R2C Plus - FriendlyELEC WiKi
The M.2 socket of course won’t work.

Since the chip for the “LAN” port is the same on R2S non-Plus, did you try to use the LAN port instead of WAN port? And do you have a USB-UART adapter at hand, to check serial console output? That might give a hint which device tree U-Boot is trying to load, and whether a non-existing device tree is the issue or that a wrong one fails later in kernel stage.

1 Like

it has a “USB-C Debug: onboard USB to Debug UART converter, 1500000bps”

Is that as easy as plugging a USB-C cable into it and a macbook and doing something like:

screen /dev/tty.usbsomething 1500000

update: well, hasn’t been as easy as that yet. Don’t see anything at /dev/cu.usbserial or similar

Yeah, these USB-UART ports are usually not used by U-Boot, but a PCB pin debug port instead. But I see the PCB debug port seems to have no head/pins attached on the R2S Plus. The U-Boot build is for R2S, which does not have the USB-UART capability (AFAIK), hence it makes sense this U-Boot build does not try to make use of it. I am not even sure whether U-Boot in general can use USB-UART consoles, as this requires additional drivers.

Although, at least Armbian adds it for kernel output as well for the R2S config: build/config/boards/ at 40d9c0b6101cde3205661b86961dd3f78d307d63 · armbian/build · GitHub

Did you try with a baud rate of 115200 instead of 1500000? If U-Boot cannot make use of it, maybe the kernel can. For this, edit /boot/dietpiEnv.txt on the ext4 filesystem or dietpiEnv.txt on the FAT partition (if it is still there, both work), and add console=ttyGS0 to the consoleargs line. The existence of the FAT partition is actually an indicator that the init system was not started yet, hence it failed in bootloader stage or the kernel crashed early. If there is no FAT partition anymore, then the init system loaded, and obviously it is only network which did not come up.

I see now that we hardcoded the R2S device tree in our image/dietpiEnv.txt, as otherwise one is chosen which has less optimisations in the current kernel build. I however see this changes with Linux 6.6 builds.

Let me know whether using the LAN port (instead of WAN) is not getting you started either, and USB-UART does not output anything on 115200 baud rate. I’ll then generate new images with a newer kernel (which has the R2C Plus device tree at least) and either using the R2C device tree or not hardcoding it at all, in the hope U-Boot selects a better suiting one.

I realized soon after posting that last message that the USB cables could have been the issue.
I tried with a different cable and now I see the connection at least.



screen /dev/cu.usbserial-1440 1500000
screen /dev/cu.usbserial-1440 115200

and got garbled characters.

Close. I should be able to find the magic number eventually.

Do you see a lot of garbled characters, multiple pages/scrolling, or is it just a few on the first line? Because if U-Boot does not actively use it for its serial output, and the kernel does not either (you need to edit dietpiEnv.txt for this), then these might be just from some scan, if a USB drive is attached.

1500000 slowly adding to this first line
115200 more voluminous

screen /dev/cu.usbserial-1440 1500000

screen /dev/cu.usbserial-1440 115200

Eq���+}YY[��9u<��+1Q����c�)Q���ߙ�j����ت��+��d����+���}w0����,�1���q�=Qqڼ̏Y���G�q#�h��,Ŋ������yG����,��Q��թ�n�홵Ț�Q�_QS�\l�᧽��8�"aQ��|��k�Ց(�!��2q�����Ϸ�mы�,����Gli�(���5���ޡյᱼ����*�    �ɱ橍��������-�;��>Zqz�yWr:�ݪ�ш���>x���
l�JC�Yj��              ���/孕�����m�꿵a8����xyqUu��YW4�:u�\��}�G����,�U���yG��q8j���w�������]n٨�������-��u�&����Uru�W�լK���Uru�!���c��(Ջ���b�d���b+��mQrS�٭������]Q0i١�
                                                                ����������8�������ъ��ʫ.����M�U�q�[���9�j��ѵ)�*�>᪊���ݹ���푑Ź:�ץ��ʋ�:�������� ������z���������������+�/]}x���l�ɪٳ�x�]SS�ܮ���������٫�*��U�����������y����Ut
                                                                                                                           ���`uQ���y��ͣժ�j��,�/S�ˋú���+�]]TΪ��庮�}Q��Ū��q���(�������ͺq��\Sr��+��p�+�ř����(���Wx��ۣިqWU��ɨ0u�]]y���qx:������z������� ��ի�ꑫ���(�Ѩ-�����m./kŭ�ы:�+�,��飋���x�+�U}�����h���WS�q��k�A���u�QU}u�z���遽������z��q

Can you try slower speeds…mabe 9600?

I have tried booting using the LAN (eth1) port instead of WAN (eth0) - but it did not ask for an IP using either one.

I have tried several baud rates, 1500000, 115200, 57600, 38400, 19200 ,9600, 4800. Tried passing cs8 and cstopb. I’m handy but not experienced in this area so I could be doing something very wrong.
Their documentation says:

Baud rate 1500000
Data bit 8
Parity check None
Stop bit 1
Flow control None

I did try to mount the SD card back on the MacBook, but it was unrecognized.

Thank you for your help working on this. I will keep at it, but it is not my #1 priority at the moment. (but who knows, maybe I’ll be up all night this week since the better half is on call)

Then it seems to be an issue with the SD card and/or filesystem. You could try to repair it on another Linux system, or better try with another SD card.

EDIT: Ah, or is it just due to the fact that macOS does not support ext4 filesystems while the card is detected well hardware-wise?

Could definitely be that I need to try to mount it to a linux VM instead. But I overwrote it already :slight_smile:

Was going to play with some fresh installs today, but armbian apt repos have been down.

oof, looks like whatever new stuff is out there broke the nanopi r2s build. Guess I should post this… somewhere. This was when doing the initial boot update from a freshly written image.

[ INFO ] DietPi-Software | APT dist-upgrade, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  armbian-firmware linux-dtb-current-rockchip64 linux-image-current-rockchip64
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 117 MB of archives.
After this operation, 12.4 MB of additional disk space will be used.
Get:1 bookworm/main arm64 armbian-firmware all 24.2.1 [75.2 MB]
Get:2 bookworm/main arm64 linux-dtb-current-rockchip64 arm64 24.2.1 [462 kB]
Get:3 bookworm/main arm64 linux-image-current-rockchip64 arm64 24.2.1 [40.6 MB]
Get:4 bookworm/main arm64 linux-u-boot-nanopi-r2s-current arm64 24.2.1 [362 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 117 MB in 5s (25.3 MB/s)
(Reading database ... 17476 files and directories currently installed.)
Preparing to unpack .../armbian-firmware_24.2.1_all.deb ...
Unpacking armbian-firmware (24.2.1) over (23.11.1) ...
Preparing to unpack .../linux-dtb-current-rockchip64_24.2.1_arm64.deb ...
Armbian 'linux-dtb-current-rockchip64' for '6.6.16-current-rockchip64': 'preinst' starting.
Armbian 'linux-dtb-current-rockchip64' for '6.6.16-current-rockchip64': 'preinst' finishing.
Unpacking linux-dtb-current-rockchip64 (24.2.1) over (23.11.1) ...
Preparing to unpack .../linux-image-current-rockchip64_24.2.1_arm64.deb ...
Armbian 'linux-image-current-rockchip64' for '6.1.63-current-rockchip64': 'prerm' starting.
Armbian 'linux-image-current-rockchip64' for '6.1.63-current-rockchip64': 'prerm' finishing.
Armbian 'linux-image-current-rockchip64' for '6.6.16-current-rockchip64': 'preinst' starting.
Armbian 'linux-image-current-rockchip64' for '6.6.16-current-rockchip64': 'preinst' finishing.
Unpacking linux-image-current-rockchip64 (24.2.1) over (23.11.1) ...
Armbian 'linux-image-current-rockchip64' for '6.1.63-current-rockchip64': 'postrm' starting.
Removing obsolete initramfs images
Armbian 'linux-image-current-rockchip64' for '6.1.63-current-rockchip64': 'postrm' finishing.
Preparing to unpack .../linux-u-boot-nanopi-r2s-current_24.2.1_arm64.deb ...
Unpacking linux-u-boot-nanopi-r2s-current (24.2.1) over (23.11.1) ...
Setting up linux-image-current-rockchip64 (24.2.1) ...
Armbian 'linux-image-current-rockchip64' for '6.6.16-current-rockchip64': 'postinst' starting.
Removing obsolete initramfs images
removed '/boot/uInitrd-6.1.63-current-rockchip64'
removed '/boot/initrd.img-6.1.63-current-rockchip64'
update-initramfs: Generating /boot/initrd.img-6.6.16-current-rockchip64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for module r8152
update-initramfs: Converting to U-Boot format
Image Name:   uInitrd
Created:      Sun Mar  3 00:12:47 2024
Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
Data Size:    12905709 Bytes = 12603.23 KiB = 12.31 MiB
Load Address: 00000000
Entry Point:  00000000
'/boot/uInitrd' -> 'uInitrd-6.6.16-current-rockchip64'
Armbian: update last-installed kernel symlink to 'Image'...
'/boot/Image' -> 'vmlinuz-6.6.16-current-rockchip64'
Armbian: Debian compat: linux-update-symlinks install 6.6.16-current-rockchip64 boot/vmlinuz-6.6.16-current-rockchip64
Armbian 'linux-image-current-rockchip64' for '6.6.16-current-rockchip64': 'postinst' finishing.
Setting up linux-dtb-current-rockchip64 (24.2.1) ...
Armbian 'linux-dtb-current-rockchip64' for '6.6.16-current-rockchip64': 'postinst' starting.
Armbian: DTB: symlinking /boot/dtb to /boot/dtb-6.6.16-current-rockchip64...
'dtb' -> 'dtb-6.6.16-current-rockchip64'
Armbian 'linux-dtb-current-rockchip64' for '6.6.16-current-rockchip64': 'postinst' finishing.
Setting up linux-u-boot-nanopi-r2s-current (24.2.1) ...
Armbian 'uboot-nanopi-r2s-current' for '2022.07-Se092-P184f-H8c72-V3e30-B11a8-R448a': 'postinst' starting.
Armbian 'uboot-nanopi-r2s-current' for '2022.07-Se092-P184f-H8c72-V3e30-B11a8-R448a': 'postinst' finishing.
Setting up armbian-firmware (24.2.1) ...
[  OK  ] DietPi-Software | APT dist-upgrade
[  OK  ] DietPi-Software | eval > /boot/dietpi/.skip_distro_upgrade
[ INFO ] DietPi-Software | A reboot is done to finalise the kernel upgrade

Did not come back up reachable. (yes, this was on an R2S not an R2S Plus)

ok, the last issue with that armbian image for the original R2S seems resolved.
Today I’ll make a clean r2s setup. Then back to the r2s plus tomorrow.

Hello Michalng,

I’m trying to compile an R2S-Plus img with Buildroot. However, at boot, I encounter this error:

Failed to load DTB
Failed to get kernel dtb, ret=-19

I presume the issue lies with the DTB. Alternatively, I would like to specify a custom DTB in Buildroot during compilation.

Could you please let me know where you found this .DTB file?

Thank you!

I should hopefully have some spare cycles to pick this back up this weekend as well if there are some guides for how to hack on this. Just need some more breadcrumbs to pickup the trail.

When you use Buildroot, where do you get the kernel from? It should ship with the DTB. When you use the Armbian kernel packages, it would be located at /usr/lib/linux-image-<branch>-rockchip64/rockchip, and when having the linux-dtb-<branch>-rockchip64 package installed as well, additionally below /boot/dtb/rockchip.


I built Buildroot from the FriendlyElec repository (Buildroot - FriendlyELEC WiKi). However, the DTB for R2S-Plus is not provided with the files, so I had to obtain the DTB from FriendlyWRT. The new issue I encountered is that the DTB from FriendlyWRT is for kernel version 6.1, whereas the Buildroot kernel version is 4.9. Consequently, I am unable to build Buildroot with the 6.1 kernel version. (I attempted to build the FriendlyWRT DTB on Buildroot, but encountered an error in the process)