A Review Of The YouYeeToo R1

A little while after writing about the Orange Pi 5+, I got another single-board computer in the mail that I was quite excited about (and still am).

It was a YouYeeToo R1, an RK3588S development board with built-in EMMC storage, a plethora of ports, and, (much more important for me given my interest in edge AI) a much more reasonable 8GB of RAM.

Disclaimer: YouYeeToo sent me a review unit (for which I thank them), and this article follows my Review Policy. Again, I purposely avoid doing any price comparisons, etc., because they never stand the test of time, and also because I trust you will be able to do your own reasoning.

The YouYeeToo R1 is another pretty standard Rockchip design. It has an RK3588S SoC, sporting the usual 4xA76/2.4GHz cores and 4xA55/1.8GHz cores, plus a Mali-G610 MP4 GPU and (in keeping with the times) an NPU.

Mine came with 8GB of RAM and a 64GB EMMC (besides a TF/Micro SD card slot), and the board itself has:

• An M.2 2242 PCIe 2.0x4 NVMe slot
• An M.2 E Key 2230 slot (for WiFi/BT/LTE)
• A single HDMI 2.1 output (8K60 or 4K120)
• A single gigabit Ethernet port
• DisplayPort 1.4 (8K30) via USB-C

…and a lot of MIPI slots, as well as an NFC antenna, a console UART port and even a CAN port (it requires a conversion board, but is a dedicated peripheral).

It also has a 30-pin GPIO port for I2C/SPI and ADCs and a few tiny, tiny buttons (more on all of those later).

Compared to an RK3588 board, the main differences are in I/O and throughput–the RK3588S has less display, MIPI CSI and PCIe lanes (it can only do PCIe 2.0), but the rest is pretty much identical, and manufacturers typically break out the same sets of ports.

The R1, though, has so many that they go along all four sides of the board, and are pretty densely packed. This isn’t your maker-focused single-board computer, and is a better fit for industrial prototyping and field use.

I received the board, a 12V adapter, a Realtek RTL8852BE Wi-Fi card and an USB-to-TTL adapter (a modern one able to do 1.5Mbps, which is a baud rate that has become common in SBCs and embedded systems).

To those I added a completely overkill Corsair P600 Micro Gen 4 NVME in M.2 2242 format.

I picked that one because I am not using it (yet) for its intended purpose and because being PCIe 4.0x4 it removed any conceivable bandwidth constraints on the SSD side.

I got a nice, compact (and pretty effective) aluminium heatsink and thermal pads, but, as usual, I eventually switched to a set of copper heatsinks (I have an embarrassing amount of them). With either, the CPU idled at 38^oC, but the copper came in handly when I ended up pushing it a little past 84^oC during benchmarks–more on that further down.

YouYeeToo makes cases available, but also as usual, I intend to design and print my own–I started modeling the board a week or two ago but haven’t been able to finish the actual case in time. Since I have the board sitting in front of me on a daily basis, I intend to keep tweaking the model on idle moments, and will update this post once the design is up on GitHub.

As to power, although I prefer USB-C for personal machines and things I might carry around with me, the R1 sports a barrel jack–but, more importantly for industrial applications, it can be also be powered from a PCB connector, which is something I wish more boards would do.

And if you think about it for a bit, a 12V adapter is trivial to replace and seems like a saner choice for an industrial product as well.

Something that surprised me was that when idle the board actually dipped to less than one watt when measured at the wall (I had to confirm that with two different metering sockets). I managed to push it up to 9W during benchmarks, which is also pretty good for a board with this much CPU power.

This is where things got a little tricky.

There are Debian, Android and Ubuntu images available and a fairly comprehensive (albeit a tad incomplete) Wiki with a good chunk of documentation and even some development examples (which, let’s face it, is more than most SBCs have).

My unit came with the Debian XFCE image preloaded on the EMMC, set up in Chinese. That was easy enough to change, but I quickly realised that apt was somewhat confused¹ and I managed to break the system after upgrading it.

That led me to explore the UART (and the wonderful, wonderful world of screen /dev/ttyS0, which I lived in for many years when dealing with routers and networking gear), and I was happy that the USB-to-TTL adapter was included–which, to be fair, is par for the course for anyone doing actual hardware integration.

So I embarked on a quest to re-image the device. However, things were a bit more tricky than I expected:

• There were two options to download a Debian image: Google Drive or a Synology server. Both had different versions of the image, which is… sub-optimal. I get that smaller manufacturers don’t have the resources to host their own images, but…
• I was unable to flash the OS using rkdevtool in Linux. There was no documentation for doing that (only screenshots for flashing with the Windows Rockchip Factory Tool, which I’ll come to in a bit).

I know my way around rkdevtool but I didn’t know the right image base offsets, so my initial attempts yielded a non-booting board.

Being familiar with this situation, I decided to check out the sources. I’ve rebuilt Android and embedded Linux (including Armbian) in the past (even on the Mac), but I didn’t feel like spending days dealing with 250GB of Android sources, so I tried the Linux tarball.

As it happens, the source tarball YouYeeToo makes available for building the Debian image was older than the most recently available version, and contained another source tarball of the same directory tree (which kind of explains why it was 53GB in size).

In a time when many SBC manufacturers are finally moving to GitHub and hosting their firmware images (and source trees) there, this is clearly an area to improve.

Nevertheless I spun up a build environment on my homelab and managed to rebuild u-boot, kernel and recovery, but didn’t find an easy way to do so that let me try for an Armbian port.

Yet.

I then spent literally hours trying to find a way to flash the image to the board, since YouYeeToo only provided Windows instructions. With Chinese screenshots.

I can deal with the fact that they were in Chinese, but managing to pin down the exact version of the Windows tool that was being used was impossible–and the Wiki mentioned the download being available but failed to link to it.

Again, been there, got the T-Shirt–I have a Windows 7 netbook with older versions of many of those tools and a Windows VM on my Fedora Laptop that could talk to the Rockchip USB device, so I set out to try as many as I could.

I finally managed to go as far back as RKDevTool v2.84 for Windows, which could take the .img file and figure out all the right offsets. Then disaster struck.

During my successive attempts at re-flashing the board the Recovery button, one of four tiny SMD buttons along the bottom left edge of the board, came loose and tore off one of the pads:

Despite my being careful, to enter recovery or bootloader mode have to hold down while multiple buttons (in my case, also while pressing Reset), and the front solder points (where the button frame was held to the board) came loose, letting the button dangle by the solder pads–which then broke.

Even though this can be attributed to mis-handling and highly unlikely to happen once the board is deployed in the field, the choice of these relatively fragile 90 degree buttons and their placement might be something to improve…

I cleaned things up as best I could and tried to re-flow the rest of the buttons to make sure they wouldn’t face the same fate, but the upshot of this was that I now have to short one of the pads to a nearby cap with tweezers to re-flash the board.

After finding out my own image didn’t boot (recovery did, but the OS image itself didn’t, which only means I didn’t build it right), I re-flashed the official Debian image and called it a day.

With all that said, how does the board actually fare performance-wise? As it turns out, not bad at all.

Networking (both wired and wireless, up until I remove the antenna for a case fitting) was solid, and the board was very responsive. I had no issue saturating a 1Gbps link, and the Wi-Fi card worked as expected (although there is very little in my environment that would be challenging for it).

I ran fio on both the internal EMMC and the SSD, which gave the following results:

# 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

EMMC:   673 IOPS Read  676 IOPS Write
SSD:   4670 IOPS Read 4677 IOPS Write

This is both better than most of my Intel machines, but way below what the Corsair NVME can do (I did point out it was excessive. And it confirms that the RK3588S is a little hampered I/O-wise when compared to a RK3588 system:

Nevertheless, for an industrial setting, this is fine. Even the EMMC is fast enough for most applications, and a PCIe 2.0 SSD should be enough for many edge AI workloads.

If, say, capturing video or handling IoT sensor data, the board will still be capable of nearly 293MBps throughput, and I don’t think there will be a lot of applications that require even half that.

My key benchmark, though, is ollama, since (like I explained before) it is a very compute intensive workload where, once the models are loaded, I/O is of no consequence whatsoever.

Again, I did this for both tinyllama and dolphin-phi, since the models I’m interested in running on this are comparable:

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

…and also ran this just to keep an eye on the temperature:

# poor man's charting helper ('ts' is in the moreutils package)
while true; do cat /sys/class/thermal/thermal_zone0/temp ;sleep 5; done | ts "%s" >> temp.tsv

And the thermal results were interesting:

The above was a “cold” run when I stopped the benchmark after reaching 85^oC. For all others I let things ride, even if the CPU was throttling a little.

And, again, looking solely at the eval rate, the figures were just a little below what I had previously gotten on an RK3588 board:

However, these figures don’t show the whole picture–because with the 8GB of RAM in this board I can run bigger and more flexible models like dolphin-mixtral – not as fast, but (and this is the interesting thing for me) fast enough for batch use. Or I can run whisper.cpp and a smaller model and have a workable (if not sprightly) local voice assistant².

Although I’m inclined to stop using it for benchmarks since there is still a bias for I/O, I also ran OnnxStream on the R1, again averaging the results over three runs:

# time OnnxStream/src/build/sd --xl --turbo --rpi --models-path stable-diffusion-xl-turbo-1.0-onnxstream --steps 1 --seed 42
----------------[start]------------------
positive_prompt: a photo of an astronaut riding a horse on mars
SDXL turbo doesn't support negative_prompts
output_png_path: ./result.png
steps: 1
seed: 42
...

I ran this on the SSD alone, since the EMMC would have penalised the R1, and got these results:

Again, not completely unexpected. Overall, the YouYeeToo R1 was only slightly less performant than the Orange Pi 5+, and even then I don’t really think it matters–so the RK3588S looks like a good enough compromise.

I haven’t yet gotten around to testing Jellyfin on the board, but I would expect broadly the same results as I did with an RK3588–i.e., very limited hardware acceleration support–which reminds me there are some recent, encouraging news regarding that, but nothing generally usable yet.

I have also been trying to figure out a good, repeatable way to use rknn-toolkit2 in as close as possible a fashion to what I want to achieve, but that is very much on the back-burner.

Again, these boards are not something you would pick for, say, a home media server (which an Intel N100 mini-PC would excel at doing), and their AI capabilities are still very much a work in progress. You can take one off the shelf and run vision applications on it (like I did for the RK3588), but mainstream support for things like Frigate and Obico will be spotty. Frigate does support the GPU for video processing and can run YOLO on the NPU, but if you’re doing more custom work you will have to run your own models and software–which, again, is fine for an industrial setting, but not for a home user.

Right now I have the board on my electronics bench and am using it as a “desktop” to look up documentation and do some quick prototyping, since it not just handles I2C displays and sensors directly but, unlike the Raspberry Pi, can also run a “normal” development environment with ease.

In that regard, doing anything with the R1 that requires hardware integration is pretty straightforward–for instance, this is something I got working in under an hour using pure C and libssc1306–and all of it hacked together using VS Code:

And when I’m not sitting in front of it, I have ollama serve available via Wi-Fi to use as a tiny LLM endpoint. I have a lot more compute available to run LLMs, but one of my main goals with LLMs is to keep exploring what can be done on-device, and this consumes so little power on idle that I can leave it running 24/7 without feeling guilty.

The YouYeeToo R1 is a great board for prototyping and industrial settings, provided you’re OK with either running YeeYooToo’s Linux version or building your own (at least until there are more options available).

I like its compactness, the very low idle power consumption, the sheer number of ports and the fact that it ships with EMMC storage by default–although I admit I am biased because it is the first RK3588 family device that I got with enough RAM to be usable for running larger models (and I can’t wait to get my hands on a RK3588 board with 32GB of RAM!).

Software-wise, I think the board could use a little more polish, and I would like to see more options and documentation for building and flashing the OS (again, I am not afraid of incomplete information and like to figure these things out, but having to stumble through basic gaps in the documentation is a bit of a pain).

I realize this is a bit of a recurring theme with single-board computers, and that with my just recently having tried the Orange Pi 5+ and having had a much easier time with it (and Armbian), I am also biased in that regard. But I think it plain that the YouYeeToo R1 could use a little more attention to detail in both software support and documentation.

Then again, part of the reason I like it is bridging those gaps, and the opportunity it provides for me to spend a little more time trying to get a passable build of Armbian running on it.

Hardware-wise, I can’t really fault it. The feature set is very good, the expansion capabilities make it suitable for anything from industrial control (including object detection and device control) to digital signage, and in the limited time I’ve had so far, it seems like a solid hardware product. In retrospect, I should have been more careful with the Recovery button, but I also think that a simple BOM fix (i.e., more resilient buttons) will help in that regard.

I’m looking forward to using it for a few more projects, and will update this post (or link to it) once I have finished my case design for it.