Arch Linux Image for VisionFive 2

Linux Distros
,
4

I was able to boot on it and log in via SSH but the output is blank (maybe because my device is a 2K one).
I ran some bench with crypsetup and openssl (thanks for 3.0.7 version) and I can say that it’s roughly half the figures I can find on my rpi4:

  • openssl
# openssl speed --multi $(nproc) rsa4096 2>&1 | tail -n 2 |  awk 'BEGIN {"openssl version"|  getline opensslversion; close("openssl version"); print opensslversion} { printf ("%s\t%s\n",$(NF-1),$NF) }'
OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022)
sign/s  verify/s
40.6    3004.4
  • cryptsetup
# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       133068 iterations per second for 256-bit key
PBKDF2-sha256     172010 iterations per second for 256-bit key
PBKDF2-sha512     146449 iterations per second for 256-bit key
PBKDF2-ripemd160  114774 iterations per second for 256-bit key
PBKDF2-whirlpool   44582 iterations per second for 256-bit key
argon2i       4 iterations, 235741 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 237449 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b        32.2 MiB/s        32.1 MiB/s
    serpent-cbc        128b        18.9 MiB/s        20.1 MiB/s
    twofish-cbc        128b        30.1 MiB/s        32.1 MiB/s
        aes-cbc        256b        32.1 MiB/s        32.1 MiB/s
    serpent-cbc        256b        19.7 MiB/s        20.1 MiB/s
    twofish-cbc        256b        30.4 MiB/s        32.1 MiB/s
        aes-xts        256b        28.2 MiB/s        29.0 MiB/s
    serpent-xts        256b        19.5 MiB/s        20.1 MiB/s
    twofish-xts        256b        31.0 MiB/s        32.0 MiB/s
        aes-xts        512b        29.0 MiB/s        29.0 MiB/s
    serpent-xts        512b        20.1 MiB/s        20.1 MiB/s
    twofish-xts        512b        31.9 MiB/s        32.1 MiB/s
  • And finally, the entropy is quite good:
#  cat /proc/sys/kernel/random/entropy_avail
3781
1 Like
5

One error:

# sudo pacman -Syyu
:: Synchronizing package databases...
 core.db failed to download
error: failed retrieving file 'core.db' from riscv.mirror.pkgbuild.com : SSL certificate problem: certificate is not yet valid
error: failed to synchronize all databases (download library error)

SSL certificate problem: certificate is not yet valid

The mirrorlist file was unchanged:

# grep -B 1 ^Server /etc/pacman.d/mirrorlist | head -n 2
## Worldwide
Server = https://riscv.mirror.pkgbuild.com/repo/$repo

Edit: solved by setting time

6

Its because time is not in sync. You need to set the right system time.

1 Like
7

Yes, thanks !

1 Like
8

Cool! Could you share your kernel config ?

9

To be fair none of those tests are using hardware acceleration from the Encrypt Engines, because openssl does not (yet).
And even once support is added, and patches pushed up stream, the Encrypt Engines will probably not help at all with ripemd160, whirlpool, serpent, twofish.

10

The kernel config is already in /boot/boot

11

Yes probably but I have a CPU comparaison now and I think that starfive RISC-V can really improve.

And also, I have an OS where I can install almost everything that I want and which is almost up-to-date (besides the kernel for now).

Are not the ones, that I need/wanted. I would be more focused on AES,chacha and blake2.
I know that when NEON instructions were included in the kernel crypto layer, we saw improvements on ARMv8. I hope it will be the same for RISC-V with hardware acceleration integration.

1 Like
12

Ah… the output is blank because I didn’t start the X or any DM. I didn’t do anything about it, from what I see on Debian image 69, they patched and build a lot of things in /usr/local my image is roughly an Arch origin.

13

I don’t even see any console/login prompt.

14

Because the GPU driver doesn’t support framebuffer yet.

15

yet

1 Like
16

2 changed files with 9 additions and 0 deletions .

small changes to see “things”…

17

I’m sure that there was lots of time spent gaining all the knowledge to know exactly what needed to be added and where. And head scratching and going “Why is this not working, this should be working”.

1 Like
18

May be I will try patching the kernel and rebuild it once I get back to office after my long weekend.

2 Likes
19

Indeed !
Sometimes, small changes make some great things: HUGE Improvements made to Linux Kernel Functions!! 8450% Increase - Open Source is Great. - YouTube

1 Like
20

It would be great ! But don’t worry we all can wait after your long week-end I think.
Do you plan to cross-compiling it ? (I think that manjaro-arm guys use cross compilation to save time)
If not it should take a looooooooooot of time, shouldn’t it ?

21

@cwt I hade to change the ownership of the /home/user because it was owned by root and it was also to much opened (755 instead of 700).

1 Like
22

Oh! Will fix it in the next image.

And for cross compiling, I tried it on my PC which was faster but not much. Building the kernel in VF2 itself took around 1 - 1.5 hours I can’t remember the exact time, but I didn’t feel it was too long.

3 Likes
23

I have seen on the bash history of root account all your commands.
You may probably purge it.

3 Likes