The officially official Devuan Forum!

You are not logged in.

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

Registered: 2019-11-14
Posts: 135  

[ ARM64 ] Build for nanoPI R2S

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

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

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 '/'

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 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}

2) - Linux Kernel

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'

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 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 smile
Testing this image, and posting your feedback.

Best Regards,

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

Best Regards,


Board footer