Bits of networks

Bits of networks

Networking, system, research

29 Sep 24

BananaPi BPI-F3: hardware and software overview

This post is part of the Upstream RISC-V serie:

The BananaPi BPI-F3 hardware

I recently received several BananaPi BPI-F3 boards from RISC-V International, thanks to them for their support. After some software experimentation, the boards will be made available to all users of cfarm.net.

This hardware is interesting for a couple of reasons:

  • it is the first widely available hardware with RISC-V Vector Extensions (RVV 1.0)
  • it comes with 8 CPU cores and up to 16 GB of RAM, which is double that of the VisionFive 2
  • it comes with complete storage connectivity (NVMe, internal eMMC, SD card) and even has a mini-PCIe slot for e.g. a Wi-Fi card
  • this is a completely different SoC compared to the VisionFive 2: it uses the SpacemiT K1 SoC with SpacemiT X60 cores at 1.60 GHz

Power consumption and performance

Initial power measurements and performance benchmarks look quite good. Overall, it is very similar to the VisionFive 2 as measured in a previous article:

  • single-threaded performance is roughly the same as the VisionFive 2 (but the BPI-F3 has twice as many cores)
  • power consumption is also similar to the VisionFive 2: around 5 to 8 W when idle, around 13 to 15 W when fully loaded. These power figures are measured on the 230 V AC side, which means that they are very dependent on the power adapater: take them with a grain of salt.
  • CPU frequency scaling works, with 5 steps: 614 MHz, 819 MHz, 1000 MHz, 1.23 GHz, 1.60 GHz. Idling at 614 MHz saves around 1 W of power compared to idling at 1.60 GHz. Again, this is very similar to the VisionFive 2.

These measurements were done on Bianbu Linux 2.0rc6, with their vendor kernel based on Linux 6.6.

EDIT 2024-10-03: actually, CPU frequency scaling has unfortunate side-effects with the vendor kernel. When using a dynamic cpupower governor such as powersave or schedutil, a kernel thread starts spinning at 100% CPU on one core: this is unexpected. When using a fixed frequency with performance or powersave, everything is working fine.

Operating system support

As usual, the operating system offer from the vendor is clearly unsatisfying. They provide a weird "Bianbu Linux" distribution, which seems to be a heavily customised version of Ubuntu. When trying it, I managed to crash their version of openssl. They also provide modified versions of OpenWrt, Fedora, Armbian...

Overall, I have zero confidence in their software, so I would like to run a standard Debian OS on the board. The next article will focus on how to install an upstream Debian on the board.

It should be noted that third-party distributions started supporting this board: Armbian (official support), Gentoo (unofficial), Irradium (never heard of it before). They all use the vendor u-boot and Linux kernel, for very good (or rather very bad) reasons, see below.

Linux kernel support

Unfortunately, we are very far from upstream support in the Linux kernel.

The vendor maintains a custom Linux kernel, with two base kernel versions: bianbu 1.0 based on linux 6.1, and bianbu 2.0 based on linux 6.6. These kernels are themselves based on a kernel from SINOVOIP, with small changes to DTS and cpufreq code.

All the sources are available, which is good, but they are not based on the upstream kernel git tree, so it's hard to figure out what they changed. I experimented a bit with the bianbu 2.0 kernel, and the code seems to be low-quality. For instance, many of their drivers completely fail to build when built as module, so it's likely that they were never tested this way.

On the upstream side, some initial patches have been posted by the community, independently from the vendor. As of now, no code has been merged in the upstream kernel. Let's hope that progress will be made on this front.

Rebuilding a kernel for cfarm95

Somebody reported an issue when using vector instructions and signals on cfarm95 with the vendor kernel. It turns out to be a kernel bug that was fixed recently upstream, but the vendor kernel does not include this fix.

So, we are now building our own kernel for cfarm95, based on the vendor source + assorted patches. The build happens here: https://framagit.org/compile-farm/riscv64-kernel-build-bananapi-f3