Building an arm64 OpenBSD router using RockPro64

Possibly they were not compiled in the binary and you need to roll our own? I would imagine that the support should be standard across the aarch64 chips if they have the extensions. I know the RPis do not but the Amlogic chips do.

I will give it a look see when I get home.

1 Like

> be me
> new to ARM world other than RPi
> buy a RockPro64
> download OpenBSD
> dd onto an SD card
> plug SD in RockPro64
> plug power in
> see red LED turn on
> no display out
> ā€œwhy is it not working?ā€
> rewrite the SD card
> give up
> use the SD card to test something else
> 3 days later
> take a glance at the rkpr64 on the table
> see 2 buttons
> take a very close look
> ā€œPower Buttonā€
> open the pine64 wiki on rkpr64
> ā€œIT HAS A FLIPPINā€™ POWER BUTTON!ā€
> feel ashamed for not RTFM
> feelsbadman.png

Unbelievableā€¦

2 Likes

Thatā€™s seems to be the case. According to my thread on the FreeBSD Forums ARMv8 features are often not detected by default and most of the time relies on setting CPU flags like CPUTYPE?=cortex-a53+crc+crypto during compilation time.

Having said that recompiling GNUTLS and Nettle with those flags didnā€™t made a difference so Iā€™m building a custom kernel and world image with -mcpu=cortex-a53+crc+crypto and hopefully I can unlock the accelerated crypto extensions. Thankfully I can compile everything from the M1 without having to worry about dreadful CPU speeds on the RockPro64 or the hassle of cross compiling.

Meanwhile someone suggested me this:

GNUTLS_CPUID_OVERRIDE=0x24 gnutls-cli --benchmark-tls-ciphers
Testing throughput in cipher/MAC combinations (payload: 1400 bytes)
                   AES-128-GCM - TLS1.2  35.37 MB/sec
                   AES-128-GCM - TLS1.3  26.27 MB/sec
                   AES-128-CCM - TLS1.2  19.80 MB/sec
                   AES-128-CCM - TLS1.3  20.49 MB/sec
             CHACHA20-POLY1305 - TLS1.2  14.79 MB/sec
             CHACHA20-POLY1305 - TLS1.3  14.51 MB/sec
                   AES-128-CBC - TLS1.0  19.59 MB/sec
              CAMELLIA-128-CBC - TLS1.0  7.50 MB/sec
           GOST28147-TC26Z-CNT - TLS1.2  3.28 MB/sec

Testing throughput in cipher/MAC combinations (payload: 16384 bytes)
                   AES-128-GCM - TLS1.2  42.84 MB/sec
                   AES-128-GCM - TLS1.3  43.46 MB/sec
                   AES-128-CCM - TLS1.2  25.65 MB/sec
                   AES-128-CCM - TLS1.3  34.18 MB/sec
             CHACHA20-POLY1305 - TLS1.2  16.37 MB/sec
             CHACHA20-POLY1305 - TLS1.3  16.18 MB/sec
                   AES-128-CBC - TLS1.0  25.10 MB/sec
              CAMELLIA-128-CBC - TLS1.0  7.14 MB/sec
           GOST28147-TC26Z-CNT - TLS1.2  3.31 MB/sec

Setting this CPUID_OVERRIDE flag produced way better results! I suspect these results are as far as the RockPro64 can go in encrypted I/O data and thatā€™s good enough to me. I donā€™t need to encrypt every share.

Iā€™m really curious to see OpenBSD results.

2 Likes

Saw this article recently. NetBSD Blog

1 Like

I just found out about another disadvantage for RockPRo64 running any kind of BSD: none aside from gigachad NetBSD have big.Little aware scheduler. That means the system is not aware that there are 2 A72 powerful cores and 4 A53 weaker cores so it will use whatever CPU is available.

If you are running on your favorite BSD you might want to use something like cpuset(1) or equivalent on your main processes.

1 Like

Iā€™m starting to nope out of this board. It started at arrival when Iā€™ve discovered that the SATA card offered in the very official store is unanimously buggy and will often drop to read only mode on 2 drives. This is a known fact. Do they not even test their stuff? Software compatibility is also a bit weak. It seems there is a caveat at every corner I run to. Might as well just use a boring 1L used enterprise surplus PC instead.

I might convert it into a media device plugged into a 1080p television and wait for better RPis to be released. Weā€™re all being seduced by that PCI-E slot but at the moment success rate is not that great.

1 Like

True, everyone online recommends buying other models, I remember seeing some good recommendations. But I went with the Odroid HC4, because of its toaster form-factor and built-in SATA controller.

A PC will use a lot more power though.

The SBC itself is very well supported. But other devices around it are not, because ARM driversā€¦ most of them come in blobs in the kernel for x86. Linux kernel 5.16 has mainline support for the rkpr64. I am unsure if OpenBSD and FreeBSD have enough feature support for it. NetBSD is renowned for its portability, so I expect them to have more support, but I only need the OS to run, run securely and have drivers for a ethernet card with vlan support. So, not much to ask from it, it should fit my needs.

The only ARM based board that seems to have pulled this off correctly is the Khadas VIM 3. I am so stoked for the VIM4.

they focus mostly on x86 cmpatibility and feature set. NetBSD is like the Debian of the *BSD world, but comes with a steep learning curve. DragonFly would be a close second to me as they have no qualms about using GNU/Linux drivers and features to get a functional system. No need for emulation when you directly support the ABI.

1 Like

The difference is night and day with Linux.

LSB Version:	n/a
Distributor ID:	Manjaro-ARM
Description:	Manjaro ARM Linux
Release:	22.01
Codename:	n/a
sh-5.1$ uname -a
Linux dhomochevsky 5.16.11-1-MANJARO-ARM #1 SMP PREEMPT Wed Feb 23 12:30:41 UTC 2022 aarch64 GNU/Linux
sh-5.1$ gnutls-cli --benchmark-tls-ciphers
Testing throughput in cipher/MAC combinations (payload: 1400 bytes)
                   AES-128-GCM - TLS1.2  165.90 MB/sec
                   AES-128-GCM - TLS1.3  157.05 MB/sec
                   AES-128-CCM - TLS1.2  126.99 MB/sec
                   AES-128-CCM - TLS1.3  117.57 MB/sec
             CHACHA20-POLY1305 - TLS1.2  64.30 MB/sec
             CHACHA20-POLY1305 - TLS1.3  63.12 MB/sec
                   AES-128-CBC - TLS1.0  131.17 MB/sec
              CAMELLIA-128-CBC - TLS1.0  26.06 MB/sec
           GOST28147-TC26Z-CNT - TLS1.2  10.03 MB/sec

Testing throughput in cipher/MAC combinations (payload: 16384 bytes)
                   AES-128-GCM - TLS1.2  0.22 GB/sec
                   AES-128-GCM - TLS1.3  0.22 GB/sec
                   AES-128-CCM - TLS1.2  157.89 MB/sec
                   AES-128-CCM - TLS1.3  153.97 MB/sec
             CHACHA20-POLY1305 - TLS1.2  72.17 MB/sec
             CHACHA20-POLY1305 - TLS1.3  71.92 MB/sec
                   AES-128-CBC - TLS1.0  0.25 GB/sec
              CAMELLIA-128-CBC - TLS1.0  29.14 MB/sec
           GOST28147-TC26Z-CNT - TLS1.2  10.49 MB/sec

I totally forgot to run these for you. Let me set a reminder.

Its okay I got my answers. Iā€™ve repurposed the machine as a Librelec tv machine, after being disappointed by lots of crappy android options from borderline useless barebones to abandonware that used to be run maintained by some guy.

File server is now an Intel gen 9 nuc running on low power mode. Although I admit the RockPro64 would beautifully perform this task as long as its running Linux.

Librelec is actually pretty good. You can enable features like emulators and even docker from their add on repository. TV remote control integration works out of the box. Iā€™m running Emby and Docker. Plan to add Homeassistant as a docker container.

Roger that. I wish I had more experience with the RockPro but I am firmly in the AmLogic and Broadcom family when it comes to SBCs.

1 Like

RK3399 should yield around 600ish MB/s and s922x should be around 750-ish of AES using hardware extensions in openssl.

In theory, this should be enough to decrypt filesystem and encrypt for samba and/or vice-versa at 1Gbps ethernet.

Donā€™t know about gnutls.

1 Like

Hello all, have another update. I got into contact with Kevin Lo of OpenBSD and got a bug fixed for VLAN hardware tagging on rge(4). Yay!

However, I have found that performance significantly drops off as VLANs are added to the RockPro64 with a single trunk interface. It has dropped from 1Gbit easy to struggling to hit 250Mbit with 5 VLANs over a single LAN trunk. I would like to test whether splitting the VLANs to multiple interfaces might help but I havenā€™t found a card with multiple interfaces that works.

Iā€™ll continue debugging to see if I can work around these performance issues, but if anyone finds a card with multiple interfaces that works please post.

2 Likes

Thanks for the update. The results so far are no totally surprising.

I know Iā€™m a bit late but OpenSSL performance should be much better as of
259937 ā€“ OpenSSL is 20x slower at AES-GCM than on Linux on ARMv7 and ARM64 (unless you built 13 off the stable branch it wasnā€™t fixed)
Thereā€™s also a patch in the works which fixes arm64 detection and assembly code for nettle (which GnuTLS uses)

Performance will jump around a little depending on which core ends up doing the work as youā€™ve noticed earlier but much better than before :slight_smile:

Testing throughput in cipher/MAC combinations (payload: 1400 bytes)
                   AES-128-GCM - TLS1.2  130.21 MB/sec
                   AES-128-GCM - TLS1.3  132.70 MB/sec
                   AES-128-CCM - TLS1.2  98.37 MB/sec
                   AES-128-CCM - TLS1.3  99.88 MB/sec
             CHACHA20-POLY1305 - TLS1.2  41.95 MB/sec
             CHACHA20-POLY1305 - TLS1.3  40.68 MB/sec
                   AES-128-CBC - TLS1.0  82.36 MB/sec
              CAMELLIA-128-CBC - TLS1.0  20.26 MB/sec
           GOST28147-TC26Z-CNT - TLS1.2  7.89 MB/sec

Testing throughput in cipher/MAC combinations (payload: 16384 bytes)
                   AES-128-GCM - TLS1.2  0.21 GB/sec
                   AES-128-GCM - TLS1.3  0.22 GB/sec
                   AES-128-CCM - TLS1.2  110.59 MB/sec
                   AES-128-CCM - TLS1.3  69.45 MB/sec
             CHACHA20-POLY1305 - TLS1.2  51.04 MB/sec
             CHACHA20-POLY1305 - TLS1.3  53.96 MB/sec
                   AES-128-CBC - TLS1.0  104.68 MB/sec
              CAMELLIA-128-CBC - TLS1.0  22.99 MB/sec
           GOST28147-TC26Z-CNT - TLS1.2  7.97 MB/sec
1 Like