[ ARM64 ] Build for nanoPI R2S

tuxd3v · 2020-11-18 23:19:33

Hello All,
I made a build for the NanoPi R2S..

Its a headless server image..
eth0 - Wan( Gigabit )
eth1 - Lan( Gigabit )

NOTA!
Its strongly advised to buy the metal enclosure,
Due to the fact that RockChip rk3328, with 2 nic's in a so small closed board environment will heat a lot!!
Even in a open environment it reaches [ 55 - 57 ]°C on iddle.
The fact that there are 2 network chips, and the usual PMIC, with rk3328 on a so small board, will make the cpu heat more than usual..

Features & Versions:

1) - Arm Trusted Firmware - ATF v2.3
U-boot boot-loader - v2020.10, with support patch for nanoPI R2S
2) - Linux Kernel - MainLine 5.8.16. with patch's to add support for nanoPI R2S
3) - UserSpace - Devuan Beowulf ( for arm64 )
4) - ChangeLog - create Beowulf image,created Kernel deb packages, with Wireguard vpn,iscsi, nfs,etc
Apply patches to Uboot/Kernel device tree, plus USB3 support added for the
usb-to-Ethernet 8153b Gigabit Nic( eth1 - LAN )
5) - Problems & to be done - This Image have been tested with a high performance blower, spreading fresh air to it during 1 day,
at full throttle..
To be Done,
Port the Image to Kernel 5.9.x or 5.10.x( next LTS ), this work is in progress..

1) BootLoader( ATF + u-boot )

Disk Partitioning scheme:

# parted /dev/mmcblk0
(...)                                                         
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start    End       Size      Type     File system  Flags
 1      32768s   262143s   229376s   primary  ext2         boot
 2      262144s  3743744s  3481601s  primary  ext4         esp

a) - Bootloader( Arm Trusted Firmware + U-Boot ),
1st pseudo-partition( starting at sector 64, til sector 8063 ) 'idbloader.img'
2nd pseudo-partition( starting at sector 16384, til sector 24575 ) 'uboot.itb'
3rd pseudo-partition( starting at sector 24576, til sector 32767s ) 'none - empty'
a1) - The Bootloader will search for a file called 'boot.scr', and after initialize the u-boot environment, will execute that script..
a2) - In 'boot.scr', for this image, it will point to 'nanoPI R2S' Device Tree Binary File by default..
b) - 1st partition( starting at sector 32768 ), is mounted as '/boot', and contain 'boot.scr' referred in a1),a2).
c) - 2nd partition( starting at sector 262144 ) is mounted as rootfs '/'

NOTA!
The Bootloader in a) usually takes ~16MiB( idbloader.img + uboot.itb + none )..
Each time a bootloader is built, all area [ sectors 64 - 32767 ], needs to be clean first( so that you can flash the new bootloader.. because could still be there any bits of the previous one.. which could lead to unpredictable consequences.. ).

The 'boot.cmd' script( format, Human Readable ):

~# cat /boot/boot.cmd 
setenv eth1addr "B2 54 C3 7B 35 A8"
setenv macaddr1 "B2 54 C3 7B 35 A8"
#setenv console tty1
setenv devtype mmc
setenv devnum 1
part uuid ${devtype} ${devnum}:2 rootfsuuid
setenv bootargs "earlyprintk earlycon=uart8250,mmio32,0xff130000 swiotlb=1 coherent_pool=1m consoleblank=0 net.ifnames=0 biosdevname=0 console=ttyS2,1500000n8 cma=64M usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u root=PARTUUID=${rootfsuuid} rw fsck.repair=yes rootwait elevator=noop"
if ext2load ${devtype} ${devnum}:1 ${kernel_addr_r} vmlinux; then
  if ext4load ${devtype} ${devnum}:2 ${fdt_addr_r} usr/lib/linux-image-5.8.16/rockchip/rk3328-nanopi-r2-rev00.dtb; then
    fdt addr ${fdt_addr_r}
    fdt resize 65536
    fdt set /ethernet@ff550000 local-mac-address "[${macaddr1}]"
    booti ${kernel_addr_r} - ${fdt_addr_r}
  fi;
fi;

2) - Linux Kernel

Packages:
Linux Kernel 5.8.16:

~# dpkg -l |grep -E "(linux-.*(headers|image|libc-dev))"
ii  linux-headers-5.8.16       5.8.16-20                          arm64        Linux kernel headers for 5.8.16 on arm64
ii  linux-image-5.8.16         5.8.16-20                          arm64        Linux kernel, version 5.8.16
ii  linux-libc-dev:arm64       5.8.16-20                          arm64        Linux support headers for userspace development

There are support for the most common things like nfs,iscsi,wireguard vpn,tun,tap, etc
The target will be to reach, at least Linux kernel 5.10, improve the Device Tree Bindings, when possible..

3) - UserSpace -Users & Passwords:

a) root - password 'toor'
b) devuan - password 'devuan'

NOTA!
SSH is enabled, so that you can login, but root login, is disabled, you should login as 'devuan', only then switch to 'root', if you want to.. for that,
After Login as 'devuan', issue:

sudo su -

And type your 'devuan' password, that's it..

4) - Changelog

a) kernel mainline 5.8.16,
b) Beowulf Userspace,
c) Lima Kernel Graphics Driver( not needed..its a headless system.. but still present ),
d) Patches for Device tree, reworked to find better power supply values for regulators( lower values ) and DVFS reworked, to those regulator lower voltage levels,
Also DRAM DVFS was reworked, but not much only in the upper frequencies..
Patchs to usb-to-Ethernet reworked to fix eth1 Mac address.
Reworked Device tree for the leds on the device( three leds, )

    ~# ls /sys/class/leds
    nanopi-r2s:green:lan  nanopi-r2s:green:wan  nanopi-r2s:red:sys

e) traditional kernel deb-packages( .deb )
f) Swap is on and its Zram based, mounted on boot, by default, enforced in '/etc/rc.local'..

~# cat /etc/rc.local |grep swap
swapon -a

5) - Problems and testings to be done..

a) In beowulf, its impossible, for now, to automount zramfs as swap, automatically.. its enforced, see 4f)
b) - Testing is needed, to check if interfaces maintain themselfs with same names, between reboots.
c) - If you attach a usb-Serial debugger, with the board powered up.it sometimes restart..
So, when using a usb-to-serial converter conected, do it before powerup..
d) - When network interfaces come up the 'post-up' command brings the leds on, but when you disconnect, the 'pre-down' commands have no efect, and the leds
are maintained on..
This need to be investigated..

For this image, to reach more Supported Hardware and Users, your help is also needed
Testing this image, and posting your feedback.

Best Regards,
tux

Last edited by tuxd3v (2020-11-18 23:42:15)

tuxd3v · 2020-12-06 17:12:03

Tests done with version 0.2 of the Devuan Image( iperf3 )
This includes the new driver for the lan nic 8153b( rtl8152 v2.14.0 - 2020.09 ):
This tests were conducted with the default Window Congestion algo 'reno', the 'cubic' algo in long periods of time, provokes resets of the Lan interface( so it was not tested bellow )..

with 'ondemand' governor:

---=== LAN ===---
Under 100% cpu load( cpu 100% occupied ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on lan( usb rlt8153b ) - [ 839Mbit/s, 839Mbit/s ]
Under 0% cpu load( cpu idle ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on lan( usb rlt8153b ) - [ 845Mbit/s, 845Mbit/s ]

---=== WAN ===---
Under 100% cpu load( cpu 100% occupied ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on wan( usb rlt8211e ) - [ 690Mbit/s, 690Mbit/s ]
Under 0% cpu load( cpu idle ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on wan( usb rlt8211e ) - [ 862Mbit/s, 862Mbit/s ]

Peaks of around ~920Mbit/s were observed sometimes..

with 'performance' governor:

---=== LAN ===---
Under 100% cpu load( cpu 100% occupied ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on lan( usb rlt8153b ) - [ 846Mbit/s, 846Mbit/s ]
Under 0% cpu load( cpu idle ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on lan( usb rlt8153b ) - [ 841Mbit/s, 841Mbit/s ]

---=== WAN ===---
Under 100% cpu load( cpu 100% occupied ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on wan( rlt8211e ) - [ 687Mbit/s, 687Mbit/s ]
Under 0% cpu load( cpu idle ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on wan( rlt8211e ) - [ 920Mbit/s, 920Mbit/s ]

Peaks of around ~922Mbit/s were observed sometimes..

NOTA!
This values may vary a bit, depending on the load you have in the nanoPi R2S, and also on the temperature..

The tests were done in both extremes( no load -idle, or 100% load -all 4 cores saturated ), using ondemand/performance governor..
There are still a problem to solve in interface lan, which uses a usb-to-ethernet rlt8153b, and depends on USB 3.0 rk3328 driver..

The r8153b driver was updated with the last official driver( v2.14.0 ), and made a lot of improvements.. but still from time to time it resets the interface, we mitigated the problem by resetting to the same macaddress..

Last edited by tuxd3v (2020-12-20 22:43:15)

tuxd3v · 2020-12-11 00:14:16

5) - Problems and testings to be done..

b) - ~~Testing is needed, to check if interfaces maintain themselfs with same names, between reboots.~~
Tests have being made, and the interfaces seems fixed with:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8152", KERNEL=="eth*", NAME="lan"
SUBSYSTEM=="net", KERNEL=="eth*", ATTR{ifindex}=="2", NAME="wan"

Last edited by tuxd3v (2020-12-20 22:45:06)

The officially official Devuan Forum!

#1 2020-11-18 23:19:33

[ ARM64 ] Build for nanoPI R2S

#2 2020-12-06 17:12:03

Re: [ ARM64 ] Build for nanoPI R2S

#3 2020-12-11 00:14:16

Re: [ ARM64 ] Build for nanoPI R2S

Board footer