The Banana Pi M7

My quest for high-powered ARM development boards has progressed a bit spottily over the past few weeks, but after almost three months of testing, here are my notes on the Banana Pi M7.

This is a long overdue post that was delayed for a bunch of reasons, but the short version is that I think this is the nicest, most compact RK3588 board I’ve tested so far.

Disclaimer: Banana Pi sent me a review unit (for which I thank them), and this article follows my Review Policy. I have since bought the official case, and provided my own NVMe drive for testing.

If you’ve handled any recent RK3588 board, the M7 will strike you as dense–that’s because it’s only very slightly bigger than a Raspberry Pi, and both sides of the PCB are fairly crowded:

The use of lower-profile connectors (and, lets face it, less connectors, since it only has one HDMI out) makes it a fair bit more compact than the Orange Pi 5+ while still being able to take a full-size NVMe underneath, which adds to the feeling of density.

The silkscreen mask on mine said “Bpi v1.1”, but the board came in a box labeled “ArmSoM Sige7”, since ArmSoM is a partner company to Banana Pi.

Like most of the Rockchip SBCs I’ve looked at lately, the M7 follows a very familiar pattern:

• It’s a full RK3588 (4xA76/2.4GHz cores and 4xA55/1.8GHz cores, plus a Mali-G610 GPU and an NPU)
• An underside M.2 2280 PCIe 3.0x4 NVMe slot (leveraging the PCIe 3.0 lanes the 3588 provides)
• Dual 2.5GbE ports, plus integrated WiFi 6/BT 5
• HDMI 2.1 and DisplayPort 1.4 (8K30) via USB-C (sadly, incapable of taking power, but it does have a separate USB-C PD port, which is very nice)
• The usual set of GPIO pins, plus multiple DSI and CSI camera and display connectors)

My sample came with 16GB RAM and a 128GB eMMC, and I used a 1TB Corsair NVMe for most of my testing.

As usual, the board came without a cooling solution (the add-on metal case has an internal bulge for heat dissipation–see below), and I used my trademark copper blocks:

Like previous boards, the M7 idled at around 40^oC when powered off a 100W desktop USB-C PD charger, and it averaged 2-3W in routine use (browsing or moderate to light desktop load), idling at 1W or less–also in line with other boards.

In fact, it took me a bit of effort to make it draw past 6W, with it only drawing above 10W when running ollama or WebGL benchmarks.

One of the reasons I was very interested in the M7 is that it is one of the very few boards that have Armbian Platinum support–so I tested two variants of it:

• Armbian Jammy (Ubuntu 22.04 with a GNOME desktop and GPU drivers)
• Armbian Bookworm (Debian 12 with a CLI interface, which is what I use as a basis to run Proxmox).

For the sake of novelty (and a more mainstream experience) I also tried Ubuntu Rockchip 24.02 (a new distribution that tries to provide updated Ubuntu images for Rockchip devices), but all my benchmarking was done in Armbian Bookworm (more on that later).

Update: in the weeks since my testing took place, Armbian has released a new version of Ubuntu Noble, which is supposed to have better MESA and VPU support. I haven’t had time to test it yet, but I will update this post when I do.

Both of these come with kernel 6.1.43, which is a fair cry from all the SBCs still shipping with 5.x kernels.

Overall, the Armbian experience was very good, with the usual caveats about the RK3588’s GPU drivers (which are still a bit flaky, but noticeably in use). I had no trouble whatsoever in getting a usable GNOME desktop up and running, and the M7 was very responsive.

From a server perspective, upgrading the Bookworm install to Proxmox was uneventful,and I was able to join it to my cluster without any issues.

Having tested quite a few RK3588 boards by now, I have to say there were no surprises whatsoever–while running Armbian Bookworm, the M7 scored within 5% of the Orange Pi 5 and the YeeYooToo, and almost exactly the same score on NVMe throughput (because, well, I actually used the same drive):

I decided to skip benchmarking the internal EMMC since I was both booting and running the OS off the NVMe drive and didn’t even have a filesystem on it.

As usual, I used fio:

# fio --filename=/<path>/file --size=5GB --direct=1 --rw=randrw --bs=64k --ioengine=libaio --iodepth=64 --runtime=120 --numjobs=4 --time_based --group_reporting --name=random-read-write --eta-newline=1

…and the results were pretty good, with the M7 slightly edging out the Orange Pi 5+ in terms of throughput, but not by much:

I then moved on to ollama, measuring token generation in CPU mode for both tinyllama and dolphin-phi (which were the models I used in previous tests):

for run in {1..10}; do echo "Why is the sky blue?" | ollama run tinyllama --verbose 2>&1 >/dev/null | grep "eval rate:"; done

This yielded the following results:

To my initial surprise, the M7 was slightly slower than the Orange Pi 5+, and it took me a while to figure out why–I suspect it has everything to do with thermal throttling, since the M7 got very hot during these tests (throttling back the clock speed as it got past 80^oC), and the Orange Pi 5+ was not only tested back in February (when it was cooler), but was also mounted in a case that encouraged convection cooling.

So I’m effectively calling it a tie–and since I now have 16GB RAM to play with on the M7, and an official case on the way (which should improve cooling) I will be revisiting this with phi3:instruct (initial results were OK, but I want to see if better cooling really makes a difference).

Update: See below for a few shots of the case. I did’t do very systematic testing yet, but I did notice that the case does help with heat dissipation–a bit.

As usual, I investigated the state of rknn support. RKNN-LLM is now a thing, but it has a few quirks:

• It requires you to convert your model to a .rknn file on a Linux x64 machine with Python 3.8 installed (which is surprisingly ancient)
• It then lacks any documentation on how to actually run the model on the device

…so I wasn’t really able to get it to work–I’ll revisit this when I have more time.

But most of my testing (and where I got stuck for a while) was on Ubuntu Rockchip 24.02, which is a new distribution that tries to provide updated Ubuntu images for Rockchip devices.

It seemed quite promising, but I had a number of issues with it:

• The M7 got very hot while running it, reaching 76^oC while installing, and also during regular use (browser, terminal, etc.)
• It was very slow to boot (over a minute to get to the login prompt).
• After trying to install it to the EMMC, I got a really weird uboot error that prevented me from booting it with a single power button press.

Comparatively, the Armbian kernels ran it much cooler on average, even when both were set to performance (and all my benchmarking was done in Armbian Bookworm using the ondemand governor).

It took me a couple of weeks, but I was eventually able to fix the boot issue by re-flashing the uboot image from the official Wiki, with the caveat that that also required me to use an actual Windows machine to flash it–using a VM was very hard due to the way the OTG port would change USB IDs, and I couldn’t get RKDevTool to work inside a Windows VM on Linux.

A critical step in being able to use RKDevTool (besides installing the ADB drivers in windows) is being able to use it in English, since all the recent versions I could get defaulted to Chinese.

The trick is setting the Selected language in the config.ini that comes with it to 2:

#选择工具语言:Selected=1(中文);Selected=2(英文)
[Language]
Kinds=2
Selected=2
LangPath=Language\

Lang1File=Chinese.ini
Lang1FontName=宋体
Lang1FontSize=9

Lang2File=English.ini
Lang2FontName=Arial
Lang2FontSize=9

Otherwise the interface will be a bit of a challenge to navigate–but this was a minor issue compared actually figuring out I had to reflash the uboot image…

While debugging the boot issues, I used an USB-to-TTL adapter with the ms-vscode.vscode-serial-monitor extension.

However, that extension does not support the 1.5Mbps baud rate that seems to be all the range these days, so I had to add this to the VS Code config to use custom baud rates:

"vscode-serial-monitor.customBaudRates":[1500000]

Although I really haven’t found a use for rknn-toolkit2 and ollama still can’t make use of the RK3588’s advanced hardware, I was finally able to test Jellyfin with RK3588 support–it’s a bit crashy (and sometimes it’s hard to figure out if it’s the clients or the server that crash), but the lessening in CPU load is markedly noticeable, and makes it more appealing as a media server–although it’s hard to compete with Intel’s QuickSync.

Bear in mind that you have to pick the right Docker images to achieve this, and that it isn’t blanket GPU support–only ffmpeg seems to have been patched to do this, and I’ve yet to get HandBrake to work (which would be a more interesting test).

But I intend to come back to this topic after another Jellyfin release or two and do more systematic testing, since the RK3588 VPU supports both H.265 and AV1 hardware decode and H.264/H.265 hardware encode.

We just need the software support to improve a little more, and I think we’ll be in a good place.

Update: Like I mentioned above, in the weeks since I fleshed out this draft Armbian came out with an Ubuntu Noble version with improved MESA/VPU support, but I haven’t had time to test it yet. I’ll update this post when I do.

It’s not hard to see the appeal of the M7–you get a lot included on the board that is immediately useful, and that is either an add-on or non-existent in other boards:

• EMMC storage (which the Orange Pi 5 doesn’t come with)
• Wi-Fi (which neither the Orange Pi or the YouYeeToo R1 come with, even though they have M.2 slots)
• Dual 2.5GbE networking
• An M.2 2280 NVMe slot (there’s more choice of 80mm NVMe drives than 42mm)

The one thing that disappointed me (and which is normal in current SBCs) is the lack of single-cable operation to plug it in to a monitor and power it that way–that feels like a missed opportunity.

But the hardware features and official Armbian support make it much more appealing than the Raspberry Pi 5 if you want an ARM Linux machine that you can actually develop on–the Pi 5 can’t match any RK3588 board in terms of raw CPU power or throughput (be it network or storage), and the M7 is at least equivalent to the other Rockchip boards I’ve tested.

And yes, documentation and software support are still a bit of a mess, but that’s par for the course with these boards–and the M7 is at least better supported than most.

It arrived only a few days after I posted this, but it took me a while to both assemble it and test it.

As I expected, it provides additional cooling, but not much. In fact, idle temperatures rise a little to 44^oC since the board is now enclosed.

Even with the internal “bump” that the case provides to be in full contact with the CPU (using a thermal pad), temperatures still rise above 70^oC under load–they just do so more slowly.

The bottom half of the case is also metal (with very small fins) and clearly thought out to help with heat dissipation for an NVMe drive, which is a nice touch.

After a bit of load testing, I came to the conclusion that the case does help dissipate heat more effectively, even if it gets very hot all around when running extreme workloads like ollama–the big plus for me is that it managed to prevent the CPU from underclocking.

Should you get one? Well, it depends on your use case–if you’re going to be running the M7 at full tilt for extended periods of time it’s a good idea, but if you’re just going to be using it as a desktop or a mostly idle server, it’s not strictly necessary.

It is, however, quite convenient if, like me, you like to take small computers on the road and want to protect them from the inevitable bumps and scrapes. I’ve also since ordered the Wi-Fi antennas that go with it for that very reason (obviously, the case massively impacts Wi-Fi performance…).