Skip to content

BeagleV-Fire, the $150 RISC-V and FPGA SBC

I have to say straight up that this board is way more interesting than I expected. Worth every dollar!

What started as an SBC giveaway on a video about the Milk-V Duo 256M turned into nearly 200 people demanding I make a video about this MCU that I had no real interest in prior. How wrong I was.

So first up, the specs are pretty awesome.

Specifications

  • Mediatech PolarFire SoC with
    • Quad-Core RISC-V MCU (SiFive U54 – 677Mhz – cores)
    • Additional E51 Watchdog/RTOS Core
    • 23K Logic Element FPGA Fabric
  • 2GB LPDDR4 RAM
  • 12GB eMMC Onboard
  • 128Mbit (16MB) SPI Flash Onboard
  • 128KB eNVM and 56KB sNVM
  • microSD Card Slot
  • USB-C Connection
  • Gigabit LAN
  • SYZYGY Connector
  • MIPI CSI 4-Lane Connector
  • M.2 E-Key SOcket for Wifi and PCIe
  • Screw terminal for optional power input
  • JTAG and UART connectivity

And there we see the first few things that bothered me just a little.

Concerns

  1. The U54 cores don’t have any RISC-V vector extensions, not even RVV 0.7.1, so it’ll likely be outperformed by other similarly aged (U54 is from ~2017 if I recall correctly) RISC-V cores that do have such instructions, such as the C910 release by T-Head in 2019.
  2. The U54 frequency of 677MHz is not great, but it’s also not bad. MHz are often wasted, so I have no issue here for general SBC use. It’s not a desktop computer that you’re compiling huge projects on… I hope.
  3. The USB-C connection is only USB 2.0 aka 480Mbps. Given the rest of the board and MCU performance, this feels like a let-down.
  4. No 2nd USB connection. The HSS bootloader that the E51 core runs to bootstrap u-boot and then the kernel does have a sweet way of exposing the hardware as USB mass storage to a host, but I think a 2nd USB port could theoretically do this AND cover the UART or JTAG connections nicely with minimal hardware change.
  5. Why no additional eMMC port? There’s enough interfaces, and you’re essentially stuck with slow SD card or only 16GB of onboard eMMC. 16GB is plenty IMHO, and you could use SD for bulk storage, but the lack of option bothers me.
  6. No HDMI or DSI interface. I’ve not looked, but I’d expect the PolarFire SoC supports this, so it would have been hugely awesome to have this on the board (does someone want to implement this in FPGA for me? That’d be awesome).
  7. I cannot see an RTC clock or any spot for an RTC battery. fake-hwclock and ntp will be required I think!

I’m not all woe though, I was really impressed up-front with a few key takeaways from those specs.

Niceties

  1. USB-C is a nice step forward.
  2. Gigabit Ethernet is awesome (the SoC actually supports dual 1Gbps!).
  3. RISC-V is always a win for me.
  4. 2GB RAM, let alone DDR4, is enough to run Geekbench.
  5. 4-Lane CSI means we can do bulk camera data, eg push my Global Shutter Camera a bit more.
  6. M.2 gives us some good expansion options.
  7. 23K logic elements in an FPGA is pretty insane, especially with DFFs.

User Environment

As soon as I booted it up though, I was impressed. It comes with Linux 6.1.33 from factory, FPGA pre-flashed with required gateway for most interfaces (at the time of writing the CSI interface is still needing some love), and it also had ipconfig, vim, and sudo installed! It didn’t have screen or tmux but I’m not picky. It also auto-expanded the root partition – nice!

I also noticed the date and time was right. That had me confused, and I’ve not bothered to look into it. Later me problem.

Something I noticed though was it’s odd little banner;

Ubuntu 23.04 BeagleV ttyS0

BeagleBoard.org Ubuntu 23.04 Console Image 2023-11-21
Support: https://bbb.io/debian
default username:password is [beagle:temppwd]

Web console: https://BeagleV.localdomain:9090/

BeagleV login:

Specifically, what the hell was this ‘web console’? I had to find out, and wasn’t disappointed; cockpit.

I’ll definitely have to explore this platform more in the future, but for now it was consuming resources, so I uninstalled it along with ssh and a pile of other background processes that I didn’t need right now.

Faults

Since recording the video though, I have noticed a few faults. They are nothing huge, but could be worth documenting in case someone knows a fix, or to at least acknowledge that they are there.

IMX219 Driver

Firstly there is a message every boot about an IMX219.

There’s no camera attached, so this is presumably something to do with the CSI gateware or a forcefully loaded driver. It doesn’t appear to affect any operation, and it’s acknowledged in the Git repo readme.me to some degree, along with a related issue being open.

CSI Interface

Next up, as we touched on earlier the CSI gateware is not yet complete. The gateware demo documentation mentions this at the time of writing.

Kernel Panic

Now, it has hard-crashed once while I was downloading a file with curl, and I’ve not bothered digging into it, but it did have me a bit stumped. Click here if you want to see the output, and feel free to flick me a message if you want specifics. It was the stock-standard kernel that it came with though;

Linux BeagleV 6.1.33-linux4microchip+fpga-2023.06-20231121+

Segfaults

It also segfaulted once running Geekbench 5, and once running Geekbench 6, but the second run of each completed fine. I didn’t keep that output, but it’s probably reproduceable and it was also a very hot day (about 40C), with no cooling on the MCU which is sitting in a warehouse, so I imagine it could have been thermal-related.

Wireless

Wanting wi-fi to save on all the cables, I stuck one of my spare Intel AX210 M.2 add-ons into it and rebooted. wlan0 appeared, woo, but alas, I could not connect to anything, instead just getting a driver crash. I tried removing the newer microcode from /lib/firmware, forcing it to use older revisions – no luck. I tried downloading the latest module from an online repo and both newer and older microcode – no luck. I tried changing repos and pulling the latest linux-firmware package – no luck. I tried installing the backported driver – no luck. I even tried turning off every optional feature with a modprobe.d entry but alas, could not win.

From what I could read online, there is a lot of issues with the AX210 on Linux, so I’m not alone. I’ll have to come back to that one later, and maybe compile the driver myself. It could also be something to do with the gateware, as the M.2 interface is behind FPGA in this instance.

2024-02-25 Edit: I updated the M.2 gateware to 0.4.0 and now the wi-fi works fine!

Boot Hangs

Lastly, it seems to hang on boot quite often, at the stage of “DDR training”. When this happens, it’ll get to 80% very quickly, and then hang there forever. I left it two days, and it didn’t move:

When this happens you just have to keep power cycling it until you see it “train” at a normal speed, and then it’s fine. From the HSS bootloader I ran memtest, and it all passed. Odd!

The FPGA

Learning about this is still a work in progress for me, but I have realised that 23,000 logic elements is pretty insane. The TinyFPGA BX with the ICE40LP8K FPGA has only 7,860 logic elements.

But WHAT IS a logic element?

Well, this is where I may get it wrong. From what I understand though, I logic element consists of inputs, some basic gates, and a flip-flop. In this case, there are four input Look Up Tables (LUTs, not to be confused with LUTs used in cinematography), and ‘D’ flip-flops or DFFs, which serve as the latch for the logic.

When you’re “programming” the FPGA, you’re then essentially connecting these logic elements to memory, I/O pins, a clock source, or each other, and then configuring them with what operation they should perform, eg a NOT gate, a logical AND, etc. Then viola – you have your own custom chip!

I just don’t know how fast or powerful it would be. Eg could 20k logic elements run a softcore 386 and boot Windows 3.11? Or even Windows 95? It could be fun to try, if anyone has created such gateware. There are already many RISC-V implementations in HDL, so I might have to benchmark one of those.

Shawn Hymel from Digikey also did a great written and video series all about FPGA, that I thoroughly recommend you check out!

Gateware

So what the hell is gateware? I was utterly new to FPGA, so this had me stumped. It turns out though it’s just the right term to use for the code that becomes functional on the FPGA… I guess. The FPGA is hardware, the board is hardware, Linux is software, the wireless microcode variants I tried are essentially firmware, that makes the bitstream running on the FPGA gateware if nothing else.

Essentially you pick a Hardware Descriptor Language, or HDL, such as Verilog, and that gets compiled to a bitstream that can be flashed to the FPGA, and that’s what it runs. HDL does not run line by line or functionally like C and similar code though, as much as it resembles it. You’re writing wire connections and logic, which all executes at once. That’s not to say you can’t do anything with it you want!

In my mind, mechanical engineering, electrical engineering, and programming, are all the same – logical operations – just at different scales. GreatScott! kind of touches on this in an awesome video a while back.

Typically though, compiling your HDL to a bitstream and flashing can be a pain. You need the right software, a Tag-Connect or similar cable, the hardware to connect your software to the JTAG port, etc. I really was not going to bother, until I found that this board could update the FPGA from the Linux user environment, and that BeagleBoard host the compiler on their CI infrastruture for anyone to use! Ref https://docs.beagleboard.org/latest/boards/beaglev/fire/demos-and-tutorials/gateware/customize-cape-gateware-verilog.html. This meant I was going to have to make something, so that’ll be another video for sure!

Geekbench Results

Lastly, we have the benchmark. 2GB RAM was enough to run it, and onboard storage meant there were no performance hits from using a slow SD card or so. Not hugely fast, but not all too slow either;

However, it appears that the 600MHz cores and lack of vector instructions really uppercut it:

Link: https://browser.geekbench.com/v5/cpu/22234049

Link: https://browser.geekbench.com/v6/cpu/4971570

It’s also worth noting that Geekbench just isn’t great for benchmarking SBCs, especially not RISC-V which is still in preview and likely doesn’t have any vector instructions at all, but these results aren’t even as good as the original Banana Pi M1 (Cortex-A7).

Video

Lastly of course, there’s my actual video about it. This ones a bit long, but I like it! Click here to open it in a new tab, or watch inline below! Cheers.

Tags:

Leave a Reply