RoadTest: Review the BeagleV-Ahead Single Board Computer
Author: Fred27
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: The BeagleV Fire (if you want some FPGA too). Sipeed Lichee Pi 4A. Milk-V Meles
What were the biggest problems encountered?: As is often the case with BeagleBoard, teh documentation felt like things had already moved on to the next product.
Detailed Review:
My goals with reviewing the BeagleV-Ahead is to find out how easy it is to get started with using a RISC-V SBC. I'm also hoping to answer the question "Who is the board for?" Sometimes review focus on the features and capabilities of a board. Whilst I will outline these, I don't really feel that this will be the limiting factor for the use of the board. I'm sure it will be very capable. I'm sure it'll have all the GPIO and serial bus connectivity we're all used to. I find that the thing that sets one microcontroller or SBC against another is usability. It's bound to be able to do what you need, but how much stress will ti be getting there?
I generally like the fact that the Beagle guys supply only the essentials with the boards. Nobody needs yet another micro USB cable of unknown quality. The only things included are:
I don't normally so unboxing videos as I find them a bit unnecessary. If you like them, then the BeagleBoard guys have done one on the main information page for the board.
The ease of use of an SBC is paramount, so without reading anything I just connected a 5V power supply and an ethernet cable to the board and observed what happened.
As with most Beagle devices, connecting is simple. Once I could ping beaglev.local I coudl ssh in. I was a little surprised to see that the board came with a Yocto build of Linux when the image listed on the beagle site was Ununtu. I didn't really explore this build and thought I'd move right on to performing an OS upgrade.
Now, here's where things diverge from the "usual" BeagleBoard way of doing things. I'm used to either running the OS from microSD or more often flashing the onboard eMMC from the microSD. Whilst there is a microSD slot on the device, this board has a very different processor to the usual TI devices found on the "standard" range. Time to follow the instructions!
The first thing I noticed was that there are no instructions for updating the OS from a Windows machine. I dont' have a Linux desktop machine but I do have a few Raspberry Pis and other Beagle SBCs. However, I decided that I'd see if flashing from Windows is possible. I decided that the easiest thing to do on Windows was use WSL (Windows Subsystem for Linux). I suppose that's kinda cheating as it is Linux, but it felt like the best approach. I fired up WSL and followed the Linux instructions.
The first thing to do was install the Android debug tools. This seemed a little odd as the BeagleV Ahead is not running Android, but that's what's needed.
So far, so good. Next was downloading the zip file for the new OS and unzipping it. Still working fine.
I ran the fastboot_emmc.sh script as instructed and then I hit a snag. Something was copied over, but the new USB device that was instantiated as the first part was loaded appeared in Windows, but not within WSL. The process stalled with < waiting for any device >.
After a bit of Googling, it seems that I needed a small piece of software called usbipd to pass the USB connection through to WSL. The instructions for using this are here and it worked exactly as documented. The OS update process went a little further. usbipd showed me the T-HEAD USB download gadget that had appeared and let me pass this through.
The only hitch I has was that further on in the process a different device with a different VID/PID appeared and I had to pass this one through also.
Other than passing through the two USB devices, the process went exactly the same as the documentation shows for Linux and I had a nice fresh Ubuntu build
Once I install a new Linux OS, muscle memory kicks in. I find my fingers almost automatically typing sudo apt update && sudo apt upgrade -y without even thinking. Unfortunately, this didn't go as smoothly as it has the last 1000 times I typed it. There seems to be a clash between different versions of libusbgx. The suggested sudo apt --fix-broken install didn't seem to resolve it.
The board was usable it this point - unless I wanted to install any software. a bit of poking around showed a familiar Ubuntu environment and no real sign that it was running on RISC-V unless you asked by typing uname -a or similar.
I suppose now is the moment where we find out what sort of support you will find for the device. I've moaned in the past the downside of Beagle products is that support seems to be abandoned once a shiny new device comes out and since the BeagleV Ahead has been released the Beagle-Y AI has come along. I saw an unanswered question about this BeagleBoard forum. As it seems you get a much better response via Discord these days, that's where I went. You can see my post here. There was no official reply, but 4 days later another user came up with the answer.
sudo apt-get -o Dpkg::Options::="--force-overwrite" install libusbgx2
It wasn't particularly obvious, but I suppose if you know Linux well you might be familiar with this issue. To be fair, it seems to be a general Linux issue rather than one particular to the BeagleV Ahead. Anyway, now my board seems to be behaving normally.
Shortly after receiving the board some news appeared about a security vulnerability nicknamed GhostWrite affecting the particular TH1520 SoC used on the BeagleV Ahead. It's a hardware bug in the vector extension in this particular device. The only mitigation is to disable these vector extensions when compiling the Linux OS for the device. I don't think the Beagle team have produced a "safe" OS build as the latest version that can be downloaded is dated from before this vulnerability was discovered. To be honest, I'm not using this device for anything other than exploring RISC-V and it doesn't sit powered on with access to my network, so I can't say I'm particularly concerned about this. It might have been nice if a safe build of Ubuntu was provided though.
So, the main reason I was interested in the BeagleV Ahead was to explore building code for the RISC-V processor. I suspect that this will be the case for most users. I spend a lot of my time coding C# using the .NET Core framework - both for x64 and ARM. As it stands, there's no official support for running .NET Core on RISC-V. However, my interest was piqued when i saw that there had been some progress with unofficial builds for RISC-V. I tried getting this to run on the RISC-V processor on my BeagleV Fire board, but wil very little success. Maybe I'd have more luck with the TH1520 on teh BeagleV Ahead?
I first started with the build of .NET 8 that failed on the BeagleV Fire. This was a full SDK build - i.e. the tools to complie rather than just run .NET code. I copied over and installed the same SDK that failed with a "Bus Error" on the BeageV Fire. (A bus error is when the address requested doesn't even make sense for the processor. It's even worse that a segmenataion fault.) With this, I could successfully create and run a very simple console application.
This, however, is someone else's prebuilt .NET SDK. I wanted to try my own. I had successfully managed to build a version of the .NET 9 (preview 4) runtime a few weeks ago, but I hadn't managed to build the full SDK needed for compiling an application. The build scripts kept trying to download various tools that it expected to have precompiled for RISC-V and failed. However, now that I had compiled code succesfully against .NET 8, I shoudl be able to run this against the .NET 9 runtime.
I copied over my .NET 9 build, editied a file to hint that it shoud run against my runtime, and tried again.
Damn! A segmentation fault. Well, at least that's one better than a bus error. You can also see in the screenshot that the BeagleV Fire is happily showing both .NET 8 and .NET 9 installed.
As .NET 9 is now available as Release Candidate 1, I thought I'd try again. I been building .NET using a Docker container with the appropriate tools for RISC-V cross compliation installed. I won't bore you with the specifics of the build process, but here I go kicking it off again...
Unfortunately, something has gone awry between preview 4 and rc1 and I struggled to build it at all. Anyway, it was fun experimenting and trying to cross-complie a project for RISC-V on an x64 machine. It's creatinly possible, although perhaps I set my sights a bit too high with the size and complication of the code I was trying to use. Maybe a bit of basic C would have been a bit easier. However, this sort of experimenting with RISC-V is perhaps what the BeagleV Ahead is suited to...
The BeagleV Ahead is a nice SoC if you want to explore RISC-V. The Beagle team have provided an Ubuntu build for it, so it's reasonably easy to get started. However, as with most Beagle products it feels a little like you're left with a reasonable starting point but then it's "There you go. Feel free to dig into the datasheet and build the OS from source if you need anything else"..
A couple of things left me feeling this way. Firstly, the fact that the provided OS immediately fails on a fairly routine "sudo apt upgrade". Another helpful BeagleV user provided a solution but it sort of felt that a well supported SBC (e.g. the Raspberry Pi) wouldn't have been left in this position. Secondly, the fact that there's been no response from the Beagle team for the GhostWrite hardware bug. Sure it's not their bug, but it would certainly have been nice if there had been a build of the OS provided with the mitigation included.
I feel that if you were after an SBC to use for a project, I would certainly not be recommending the BeagleV Ahead. However, I don't think that's really the target market for the device anyway.
If you want to explore a RISC-V SoC that's capable of running Linux then this may well be just the device for you. The Beagle team do make some nice hardware. When looking at the support available, it's easy to feel it falls flat when compared to the Pi foundation. However, I suspect that if I comapred the support to that which you get from Sipeed or Milk-V (who make similar RISC-V boards) it would seem far more favourable.
