Note: this review uses a modified set of rating parameters due to the specific nature of the board. Explanation further down below.
Today, we’re taking a look at quite a special board. When it comes to SBCs, or any computing hardware, in general, we’re used to seeing ARM and x86-based processors: the former mainly in mobile devices and the latter in desktop and server gear. Differing in many important aspects, these two architectures both have one thing in common: both are completely closed-source.
While this might not be a deal-breaker for end-users, closed-source ISAs virtually bar a significant amount of people, and especially individuals and small chip design teams, from ever implementing the tech due to huge license fees and royalties involved.
RISC-V began as a project at UC Berkeley, aiming to produce an ISA which was open, free to use and modify, but also viable for use in general computing. This open-source approach has many advantages, which are all well-known from software with similar policies. Accessible technology naturally has much more community support, which taps into a huge talent pool and makes the cogs of innovation and refinement spin much, much faster.
The approach definitely worked out for RISC-V, with multiple major companies utilizing it in parts of their designs. Some, like SiFive, base their business model exclusively on RISC-V, creating CPU core designs and other essential hardware leveraging this open ISA.
Today’s VisionFive 2 board comes from StarFive, a Chinese company closely linked to SiFive, and features StarFive’s own JH7110 SoC. It also features up to 8 GB of RAM and is touted as “the world’s first high-performance RISC-V single board computer (SBC) with an integrated GPU”. While this might seem a bit oddly specific, it’s important to remember that this isn’t StarFive’s first rodeo with SBCs. VisionFive 2’s predecessor, the aptly named VisionFive, notably lacked any sort of dedicated 3D GPU hardware. Thankfully, through a partnership with Imagination Technologies, StarFive managed to get the BXE-4-32 MC1 GPU included in the JH7110 chip.
Envisioned as an affordable development kit of sorts for the RISC-V platform, the VisionFive 2 is meant to offer an easy way for developers to port their software to the new ISA. The relatively low price, which is around $100 depending on the RAM configuration, puts RISC-V general computing within reach of hobbyists and small teams while offering performance of yesteryear’s ~$500 RISC-V boards.
This all sounds quite exciting, and to us, promising. But, enough backstory – let’s take a closer look at the hardware itself!
We’d like to use this chance to thank 52Pi, a StarFive distributor, for sending us a VisionFive 2 board for review.
Specs
The JH7110 SoC is undoubtedly a product of collaboration between StarFive and SiFive, featuring cores designed by the latter. Namely, the chip features an U74-MC core cluster running at 1.5 GHz and a 32-bit E24 real-time core cluster.
SiFive’s documentation reveals what this “core cluster” is. Essentially, a U74-MC contains four 64-bit U7 cores and an S7 monitor core, along with the required supporting peripherals, like interrupt timers and debugging circuitry.
Extrapolating the logic, and confirming it with a quick glance at the relevant data-sheet, we see that the E24 core cluster is based around an E2 core and adds to it the required circuitry.
The U74-MC cluster isn’t to be confused with the U74 (no MC, which we presume stands for “multi-core”) core cluster, which features a single U7 core (and, you guessed it, the required circuitry around it). According to the official data-sheet, the U74-MC cluster consists of four U7 cores, and not U74 clusters, which would imply a single set of the aforementioned supporting circuits shared across the cores. This is shown by a diagram found on page 25 of the manual. However, this very diagram also uses the term “U74 core” when referring to U7 cores, which implies five separate copies existing, based on info from the U74 manual.
This doesn’t make sense, especially since the S7 core is referred to as such. The U7 is the official name for these cores on the SiFive website and most of the data-sheet, so we’ll stick to it for the rest of the review.
As to why this required such a lengthy explanation: most reviews, and the official StarFive JH7110 specs call these cores “U74 cores”, which we believe is a misnomer caused by SiFive’s own convoluted labeling schemes and general familiarity with ARM’s Cortex-A-series naming methodology (where a U74 core would definitely make more sense than a U7 one).
So, to summarize, we’re dealing with four U7, one S7 and one E2 core here. The U7 cores are application cores, capable of running Linux, thanks to all the ISA extensions they feature (these are RV64GC cores, i.e., RV64IMAFDCZicsr_Zifencei cores with the G shorthand expanded to full form). These have a dual-issue, in-order execution pipeline (comparable to an ARM Cortex-A55).
The S7 core is extremely similar in design to the U7 one, but is incapable of running full Linux. This is mostly due to the OS expecting at least the RV64IMAFDC ISA, and this core utilizing the RV64IMACB one, lacking F and D extensions for single- and double-precision floating point support. Additionally, the lack of a memory management unit presents another obstacle to running full-fledged operating systems on this core.
Instead, the S7 core is meant to run as a supervisor of sorts, useful for performance monitoring or offloading certain routine tasks to a lower software level than the OS. Without delving too deep into RISC-V’s privilege modes, it’s sufficient to note here that the S7’s ability to run in M-mode, the highest privilege level, enables code written for it to access every single peripheral and register on the system and run interrupt-free from code running on lower, U- and S-mode, privilege levels. In theory this enables construction of software which leverages this independent core for system monitoring or peripheral management even if an irrecoverable error incapacitates the main application processor.
The E2 features the RV32IMAFCB ISA (note that this is a 32-bit core), and sports a single-issue, in-order pipeline. In a similar fashion to the S7, the E2 core is meant to be used for low-level routine tasks, but also as a simple low-power real-time processor. This provides the system with better energy efficiency when idling.
Sadly, both the S7 and E2 currently remain unused by the Linux kernel, essentially being inaccessible to the system, only being utilizable by bare-metal code. Down the road, we hope to see system-level software utilizing these and providing APIs for offloading low-level code onto these cores and getting data off of them. Managing this without breaking the security paradigms set forth by the privilege modes will be a challenge, naturally, but it would offer RISC-V-based systems unique advantages compared to other architectures.
photo: magazin Mehatronika
As mentioned in the first section of the review, the JH7110 chip contains an integrated GPU: Imagination’s BXE-4-32 MC1. Breaking this naming scheme down a little reveals some details about the core. Let’s start with the “MC1”, which denotes that we’re dealing with a single GPU. This terminology is similar to what ARM uses in their Mali-series GPUs. “BXE” is the lineup designator, indicating a B-series GPU optimized for space efficiency (XE series). Finally, the “4-32” part is actually a peek at the performance: the former denotes the number of texels processed per clock cycle, and the latter denotes the number of FP32 FLOPs per clock cycle. According to Imagination, the GPU can also deliver double the amount, 64, of FP16 operations each clock cycle.
According to official documentation from RVspace, this GPU can run at up to 600 MHz, but is set to 400 MHz by default. Doing some quick calculations gives us 19.2 FP32 GFLOPs (38.4 FP16 GFLOPs) performance when running at 600 MHz, and 12.8 FP32 GFLOPs (25.6 FP16 GFLOPs) at the stock speed. While these numbers aren’t exactly mind-shattering, they are more than enough for simple graphics tasks and are miles ahead of what a CPU could offer utilizing software rendering.
This SoC is paired with 2, 4 or 8 GB of LPDDR4 RAM, produced by BIWIN. Our board is an 8 GB model, and the single RAM chip is marked BWMZCX32H2A-64G. Sadly, there doesn’t seem to be a data sheet on this chip readily available online, so we can’t be sure of the RAM speed, although the official document claims speeds of “up to 2800 Mbps”, which is an odd number all-around for this type of memory. It seems that we’ve only got single-channel RAM here, so expectations aren’t too high, but we’ll check the exact performance out further below in the benchmark section.
photo: magazin Mehatronika
The IO selection is standard. We’ve got four USB 3.0 ports (or in modern terms, USB 3.2 Gen 1 ports) driven by a VIA Labs VL805 controller, which should allow for speedy 5Gbps transfers. This is a familiar chip, as it’s found on the Raspberry Pi 4, too. Somewhat worryingly for performance, the official data sheet mentions that these have been multiplexed with a PCIe 2.0 1x lane. This PCIe lane is routed to an M.2 NVMe connector on the bottom of the board for storage expandability. We’ll check out the performance of both of these connectors further down.
photo: magazin Mehatronika
Flipping the board over reveals two more important storage options: a microSD card slot and an eMMC connector, meant to take a storage module. This is a good amount of storage options for a board of this type. As long as the IO performance is decent, the VisionFive 2 could perform excellent as a local storage server or backup box.
photo: magazin Mehatronika
Next to the USBs is an HDMI 2.0 port, capable of displaying up to 4K30 or 1440p60 video. Curiously, the hardware video decoder itself can handle 4K60. Other video options present on the board include two different MIPI DSI display ports, one 2-lane and one 4-lane, capable of up to 1080p30 and 1440p30 output, respectively. The onboard video encoder can handle 1080p30 input, and fittingly, the 2-lane MIPI CSI port can handle cameras up to this spec. A four-pole 3.5 mm audio jack is also present, thankfully. It’s a feature we see dropped more and more often, which is a shame as workaround solutions – HDMI audio or external DACs – are nowhere as neat.
photo: magazin Mehatronika
Two gigabit Ethernet ports are also there, which makes for a pretty powerful networking setup. Sadly, the board features no built-in Wi-Fi or Bluetooth, so external USB adapters are a must if wireless networking is essential.
photo: magazin Mehatronika
Power can be supplied to the board in a few different ways: either using the onboard USB-C port (a 5V/3A USB-C supply should do the trick), or via a set of GPIO headers, or finally, through PoE, which does require a PoE HAT attached to the Raspberry Pi 4-style PoE header.
photo: magazin Mehatronika
A full 40-pin GPIO header is also present and uses the Raspberry Pi 4 pinout. This is great, as it’s become somewhat of an industry standard, present on various systems made for vastly different applications.
photo: magazin Mehatronika
Finally, the board features a reset button (self-explanatory) and a DIP switch for selecting boot mode. This is directly related to the experimental, early-adopter nature of the board. Offloading boot priority selection to a hardware switch is a smart move to prevent bricking the board if software handling these operations isn’t fully stable yet.
photo: magazin Mehatronika
Hardware look and feel
The VisionFive 2 is undoubtedly a gorgeously-made board. With a high-quality silkscreen and robust, thick PCB, there’s no question that there was a certain sense of pride in designing it, which translated to a higher-than usual level of attention to detail. Every single port and connector is robust and the solder work is impeccable.
While there’s no built-in backplate to keep the bottom side of the board away from dirt and grime, like there is on the Jetson Orin Nano or LattePanda Sigma (we’ll have a review on it up soon), which is a bit problematic given the bottom-side positioning of the M.2 slot (the whole board teeters a bit due to it), it’s no major oversight and is easily fixed with even the simplest solutions – four plastic standoffs will do the trick.
photo: magazin Mehatronika
The presentation here is also quite nifty. The VisionFive 2 ships in a sturdy translucent plastic box inserted into a colorful cardboard sleeve. We’ve seen a similar type of packaging with the Radxa Zero, and we personally like it as it reasonably protects the fragile pin headers during transport.
“Embrace change,” the cardboard sleeve remarks right next to the product logo. “Embrace the future.” These are some big words, and while the hardware itself looks promising at a glance, the actual usability of the platform will determine how true they are.
photo: magazin Mehatronika
Benchmarks
The VisionFive 2 is an immature system. Unlike a freshly-released ARM-based board, which might be considered immature, due to challenges relating to peripheral component implementation the VisionFive 2 faces the challenge of taming a relatively recent CPU architecture which has just recently taken its first steps into the Linux world.
The first Linux-capable RISC-V SoC, the Freedom U540, was released by SiFive in 2018, with the company’s 2020 HiFive Unmatched being the first desktop platform based on the architecture. To put things into perspective, the first time a mainline Linux distro supported ARM was in 2000, with the release of Debian 2.2. That’s over 20 years ago – and that’s ignoring the fact that Russell King, perhaps the most prominent figure in porting the Linux kernel to ARM, had already began work on the project in 1994, working on an Acorn A5000.
However, it wasn’t until 2007 and the release of Android, more than a decade after Russell’s original work, that Linux on ARM got into the hands of mainstream audiences, and until 2012 and the first Raspberry Pi that more traditional distros got a viable audience on the architecture.
“What’s with the backstory?” we hear you say. “Isn’t this bit with the benchmarks?”
Well… erm… as you’ll quickly see, both this and the next section of the review will have to navigate around software immaturity. Keeping the ~25-year gap in software maturity in mind, both when it comes to software selection and stability, but also toolchain optimization, we’d urge readers to take results below with more than just a grain of salt. With RISC-V, we’re essentially where ARM was in the late ‘90s. It’s impressive how far the community has gotten this quickly, which is in no small part due to the open-source nature of the ISA (if anything, this is a glorious proof-of-concept for open hardware), but there’s still a lot of work to be done and essential software to be ported.
Finally, comparing ARM and x86 is problematic, and both of those are stable, well-supported architectures where the general expectation is that all software is optimized to get the most out of every chip. Comparing ARM and RISC-V boards is even more of a challenge, and is essentially an unfair undertaking, since most software, benchmarks included, aren’t optimized to take full advantage of the hardware they’re running on.
photo: magazin Mehatronika
With that in mind, let’s move on. We’re kicking off the benchmarks with Geekbench 5, with Primate Labs thankfully offering RISC-V binaries. The 77/270 single-/multi-core result is in line with the Raspberry Pi 3B’s 98/258 result. Again, there seems to be potential for a lot more performance overhead over the Pi 3’s four A53 cores, though we don’t expect it to ever quite reach Raspberry Pi 4 levels.
Geekbench 6 is also seemingly available for RISC-V, but the official link 404’d on us, so we decided to skip it for now.
Sysbench is our go-to benchmark for testing CPU and RAM performance, and we really wanted to run it, as it gives a great insight into how the chip handles simple, repeated operations. Sadly, we were met with a few problems. Initially, after apt failed to locate the sysbench package, we thought it was due to nobody bothering to compile it yet, so we headed to GitHub and cloned the source code of the suite. Sadly, soon after, we discovered the reason the package was missing: LuaJIT, an essential dependency wasn’t available at all for RISC-V yet! This foiled our plans yet again, which meant we had to skip this test for now.
With two tests down, it was pretty essential that the rest were functional (remember our whole spiel about the system being immature – yeah, this is why).
Moving onto OpenSSL scores, it’s important to note a few things. The JH7110 does have cryptography accelerators, but these are nowhere as well-supported as ARM’s own. U7 cores also predate the ratification of RISC-V’s crypto extensions, which further complicates things. Still, judging by these results, we think that OpenSSL 3.0.7, the build which we used for testing, does use some sort of hardware crypto acceleration as the reported scores hit significantly above what earlier OpenSSL versions could achieve (on average, we saw a fourfold improvement).
However, when compared to the Raspberry Pi Zero 2W’s scores, which are software-only, we can notice them being pretty similar. This might point to the crypto engines still being dormant, but OpenSSL’s algorithms being manually optimized for RISC-V. If we see a huge performance boost yet again in the future, this is the more likely scenario.
The next test on our list, tinymembench, did compile, thankfully, but the scores that we got were rather low (consistent with others’ scores, however). Importantly here, we’re seeing a general ~800 MB/s speed, which is surprisingly even across tests.
We’ve got a lot more experience interpreting ARM and x86 scores, so we aren’t quite sure what’s causing the lower scores, but it’s probably due to the early MMU revision used in U7 cores, as well as general software instability. Anyhow, it seems we’ve got a single-channel RAM configuration here, which isn’t too ideal with 8 GB setups. Still, even with slower RAM (and sadly, only one test to confirm this), we’re satisfied with how the board performs. Again, we’re happy to see RISC-V boards just running decently, so it would be unfair to expect cutting-edge performance just yet.
UnixBench is where things start looking up for the VisionFive 2. The results put it somewhere in line with the Raspberry Pi 4’s results, which is quite impressive. UnixBench is a great test because it’s been constructed on simple, basic operations and levels the playing field somewhat between different architectures. This is a major win for the VisionFive 2 and we’re proud of how well it scored.
Octane 2.0, one of our legacy tests which relies heavily on software optimisation also gives the VisionFive 2 a decent score, much above the Raspberry Pi 3B+. It’s not quite up to Raspberry Pi 4 levels yet, but it showcases a certain degree of software optimisation and hardware power not always seen, even on some cheaper ARM boards.
IO performance is decent. We’ve managed to measure up to 20.94 Mbps on the SD card using hdparm. The NVMe speeds, on the other hand, are slow, at just 171.2 MB/s, measured using the same command. The Kingston NV2 SSD which we’ve used is rated at up to 3,000 MB/s, which is almost 15 times faster than what we’re seeing here. We don’t usually test for USB speeds as we’ve found that most boards reach reported ones, but that “multiplexed with a PCIe 2.0 1x lane” got us a bit suspicious.
USB 3.2 Gen 1 ports should be capable of hitting 5 Gbps, which should give it a theoretical bandwidth of up to 625 MB/s, or in reality, a bit below 500 MB/s, with encoding overhead accounted for.
Checking with several USB flash drives specified for these speeds, we end up with an average of just 168.2 MB/s (and no, there weren’t any duds that brought this number down, all of the singular scores were within ~5% of each other). This is suspiciously similar to the NVMe performance. Perhaps the NVMe connection is implemented thru the VIA USB controller, with the bandwidth split between ports (it would just about add up), or we’re facing some software issues. A single PCIe 2.0 lane should achieve 500 MB/s. We’re hoping it’s just software, but we have to note that Jean-Luc Aufranc over at CNXSoft has faced very similar issues during his time with the board.
We’ve got a hardware video encoder onboard which promises 1080p30 encoding capabilities. Surprisingly, it only supports H.265 encoding in hardware, and not H.264, which is a bit of a shame, but it works surprisingly well!
To test the hardware encoder, we ran:
ffmpeg -i big_buck_bunny_1080p_H264_AAC_25fps_7200K.MP4 -c:v hevc_omx -preset medium -b:v 4000k output_h264.mp4
This gave us around 31 FPS – as promised by the spec sheet. Impressive results for this little board, and definitely serviceable as a camera encoder or even for light transcoding workflows.
Software encoding was a different story, though. We ran:
ffmpeg -i big_buck_bunny_1080p_H264_AAC_25fps_7200K.MP4 -c:v libx264 -preset medium -b:v 4000k output_h264.mp4
This time around, the board managed around 1.6 FPS, which is too slow to be useful for basically any application. Switching the -preset flag to ultrafast did speed up the process a little, getting us 10 FPS, which is still a little low. It seems that the four U7 cores just can’t keep up with demanding software encoding workflows, which isn’t surprising given their general benchmark results.
The GPU is somewhat of a black box still, with Vulkan being the main “supported” API. We’re putting that under quotation marks as it’s still quite finnicky, with a lot of performance issues holding the board significantly back. We’d love to get an accurate assessment of the Imagination GPU being used here, but that’ll have to wait until more stable graphics drivers are out.
This gives us a pretty decent overview of the main performance points of the board. Decent CPU performance which definitely has room to grow with future updates (with whole bits of silicon sitting unused), somewhat weak RAM performance, which would definitely benefit from a dual-channel chip, and finally, weak file IO performance which, in our opinion, severely hinders server usage.
If this were an ARM SBC, we would have cracked down way harder on the flaws, but we’re dealing with brand-new tech and it’d be unfair to compare it head-to-head with a decades-old platform. Still, there’s a lot of room for improvement, both in hardware design (especially with RAM) and with NVMe and USB performance.
User experience and software support
We’ve grouped these together this time around as, just like benchmarks, user experience is going to be pretty reliant on the software support itself.
At a glance, there’s seemingly a lot of distros available, like Debian, Arch, Gentoo, Ubuntu and Deepin. There’s specialty OSs like OpenWRT and ROS, but also China-specific images like OpenEuler and OpenKylin. Great! It’s lovely to see so much community effort being put into developing software for the platform.
However, almost every single one of these is either highly experimental or… just mostly experimental. It’s hard to describe to someone without letting them have a go at using the VisionFive, but there’s a lot of quirks and issues on every corner and a lot of know-how required to get around them. Debian is the only “official” OS for the board, and it’s basically coming apart at the seams. One sudo apt-get update && apt-get upgrade is essentially enough to break the system to such an extent that only a fresh re-install will save it.
Many things here don’t work as they should, or work – but barely. And that’s Debian, the official OS.
For example: if you try to run sudo apt-get upgrade, you’ll break the whole OS, but issues start even before that: with sudo apt-get update notifying users of expired repository signature keys. Multiple packages don’t work, even though they are available, and some system features tend to break. We’ve even experienced a few system crashes along the way. It’s definitely not an ideal experience here.
Canonical, the makers of Ubuntu themselves, have put in a wonderful effort to provide first party support for the board, and they’ve, in partnership with StarFive, developed a functional port of the OS. However, it’s also got significant flaws. Not all of the onboard hardware is supported. The list of stuff which simply doesn’t work includes USB ports, PCIe and the graphics subsystem in general, making UART communication the only viable method here.
To make matters just a tiny bit worse, there are two versions of the board in circulation: a common v1.3B variant which generally has better support, and a much rarer and older v.1.2A board which usually requires some device tree modification and usually even more limitations (for example, one of the Ethernet ports is also disabled in Ubuntu here).
photo: magazin Mehatronika
It goes without saying that you’ll be manually compiling, tweaking and changing code all the time to get some basic utilities to work, so if you’re not comfortable with that, this board definitely isn’t going to be for you.
So, the software options aren’t exactly polished and are very much work-in-progress projects. However, this isn’t the biggest challenge to new users.
All v1.2A and early-production v1.3B boards come with an old version of the bootloader firmware. Only the newest firmware renders the board capable of booting the latest OS images, so updating should be your first priority. If you’re lucky enough to get the board with new – or at least one of the intermediate – firmware releases, the update procedure will be no more complex than a few commands typed into the Linux terminal.
However, if you’re unlucky – like we were – and receive one of those early boards (ours is a v1.2A one), what awaits you is a newcomers’ nightmare.
photo: magazin Mehatronika
To get the bootloader to the newest version, you’ll first require a USB-to-UART cable for serial comms in order to access the U-boot console. After that, you’ll need a spare Linux machine to run a TFTP server. After you’ve set this up, and ensured that your TFTP server is fully functional, you’ll need to point U-boot to your TFTP server by sending a few commands over serial from your computer. If this all goes well, you’ll have successfully updated the firmware! Congratulations!
However, as simple as it sounds, it’s not that easy in practice. StarFive has a guide in their official docs, but as James Chambers pointed out in his excellent article regarding the updating process, the official docs have some flaws. An experienced embedded Linux user can wrangle their way through this process, but we’re seriously doubting just how much a beginner could get done. In fact, we’re doubting this very fact so much as to have a tough time recommending the VisionFive 2 to those still fresh to embedded Linux boards.
Still, we have to admit that everything did end up working out. There were no dead-ends. There were no unsolvable issues. We got everything up and running, and that’s saying a lot about StarFive’s work.
This is a board for developers and experienced Linux tinkerers. It aims to provide users with an inexpensive platform which enables them to contribute to RISC-V’s development. It’s a board for those wanting to keep up-to-date with the latest in the development of Linux for this new ISA, but it definitely isn’t a good starter board, or a board meant for general audiences.
For this reason, we’ve decided to, for this review only, in order to avoid unfairly harming the overall score of such an adventurous system, suspend the Software support category, which would objectively be somewhere in the sub-5 range.
Still, we give this rating based on user-friendliness of a system and its wealth of software, which are both absent here – but not without good reason. Using a rating factor meant for stable, end-user products would be unfair in this case.
In the future, if and once we have a few more RISC-V boards to compare head-to-head, we might introduce a RISC-V-specific Software Support rating, in which case this article too will be updated.
Conclusion
The VisionFive 2 is an exciting board. It truly is. It’s so exciting because it’s the first time we’ve seen such computing power and community support behind a device that’s based on a truly open ISA. It takes open hardware down to the literal silicon-level, and we’re all for it.
As we’ve explored in the previous paragraph, all software is essentially in different shades of experimental. Nothing available is a true production release, but it doesn’t need to be, as the VisionFive 2 is more of a development system. Its true goal wasn’t bringing RISC-V to the masses, not yet, but enabling hobbyist developer to jump in and help out the case by significantly lowering the cost of a fully-functional RISC-V machine. Depending on where you get yours, it might cost you as little as $70 on a good deal. For a $100, it’s more than possible to nab one of the 8 GB models, too, and for around $140 you can grab kits which pack in the required accessories to get you started.
photo: magazin Mehatronika
Our only real gripe is the performance (somewhat unrelated to raw CPU performance, which we find satisfactory), but we’re willing to overlook these given the system’s currently competitive price.
Overall, the VisionFive 2 is a board for those skilled and daring enough to straddle the bleeding edge of current embedded tech. Its software is still in its early phases, but its whole CPU architecture is, as well, so the instability is understandable. Impressively enough, software support is much better than what even leading ARM embedded boards had just a decade ago, with a passionate community coming together to make RISC-V a viable desktop and server architecture. And that is truly remarkable.
He’s also the key person behind Mehatronika's English translations, especially of education- and maker-oriented texts.
- Raspberry Pi AI Camera review: Even more approachable AI - 10/22/2024
- Arturia AstroLab review - 09/29/2024
- Raspberry Pi AI Kit review - 08/16/2024