Building a workstation with Radxa ROCK 5 ITX (Arm) or Milk-V Jupiter (RISC-V) mini-ITX motherboard – Part 1: The hardware

42 Replies to “Building a workstation with Radxa ROCK 5 ITX (Arm) or Milk-V Jupiter (RISC-V) mini-ITX motherboard – Part 1: The hardware”

1. Wow! Comparative ARM vs RISC-V review with everything else but the SOC/Mobo being the same!

   Looking forward to your results, although I fear RISC-V is going to take a beating ( last time I checked, neither the Linux toolchain nor the kernel were optimized for it yet, and both were for ARM).

   PS: if you can, please include power usage numbers, specially at idle and at full load.

   I would also be very interested in learning whether they can be fed thought their 12VDC jack directly from a 11.5 – 14.2VDC battery bank (electrically very clean as it’s charged from a MPPT solar charger and panels and not from a car alternator).

   Reply

   1. The Rockchip RK3588 will be much faster (Cortex-A78/A55) than the SpacemIT K1 (Cortex-A55 like performance). The most interesting parts about the RISC-V motherboard will be to find out which parts are working, which parts are not.

      Reply

      1. > The Rockchip RK3588 will be much faster (Cortex-A78/A55)

         It’s A76 and on the Milk-V Jupiter there currently seems to be a DRAM initialization issue (or maybe the memory controller is not very capable).

         Reply

      2. > SpacemIT K1 (Cortex-A55 like performance)

         According to https://forum.banana-pi.org/t/banana-pi-bpi-f3-spacemit-k1-8-core-risc-v-chip-brief/17457, not quite:

         “The computing power for single core in K1 is 30% ahead of ARM A55”.

         And according to https://www.cpubenchmark.net/compare/4929vs5104/ARM-Cortex-A76-8-Core-1800-MHz-vs-ARM-Cortex-A55-8-Core-1800-MHz, at the same clock speed the A55 is actually *faster* than the A76 (CPUMark 3013 vs 2792)

         Perhaps the key phrase is, “at the same clock speed”. I haven’t seem the SpacemIT K1 clock mentioned anywhere (not in your post, nor anywhere easily googlable at least, only vague references to it being ‘probably’ around 1600Mhz), so perhaps this (combined with lack of general RISC-V optimization/tuning on the Linux toolchain and kernel) would afford the 3588 its better performance.

         Reply

         1. > I haven’t seem the SpacemIT K1 clock mentioned anywhere

            It’s 1800 MHz (at the moment, the Banana clowns run/ran the K1 on their board with 1600 MHz): https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md

            Good luck navigating the Internet in the future if you come to conclusions like marketing BS originating from the Banana clowns reflects reality or Cortex-A55 being faster than A76 🙂

            Reply

2. The ROCK 5 ITX is a really great board to make a server or NAS. It balances its PCIe I/O pretty well, with Gen3 x2 for SATA and Gen3 x2 for M.2. This allows to place a 10GbE adapter on the M.2 slot and deliver line-rate 10G from SATA to Ethernet.

   It suffers from a small defect which is Rockchip-specific: the DDR5 performance. It ought to run at 2736 MHz (DDR5-5472) but recently the RK3588 ddr init code was downgraded to 2400 MHz (DDR5-4800) “to fix stability issues” (without more details) and at this speed it’s ~10% slower than the ROCK 5B’s DDR4X-4224. It’s sad because DDR5 was initially advertised as a speed increase over previous generations and it ends up being slower. Also, be careful when you test performance, Jean-Luc, when the DDR is configured at 2400 MHz, the DMC is enabled and its “ondemand” governor keeps it running at 536 MHz even under load! I didn’t understand why the RAM had huge access times until @tkaiser pointed this out to me. You’ll likely have to force the min_freq to max_freq so as to get correct numbers.

   Another serious regret I had is that they limited the onboard eMMC to 8GB, and decided to condemn it to place that totally useless roobi OS image (it’s basically just a one-use recovery image serving as a boot loader for the first installation, they could have installed it on the SPI instead, or even better, just install EDK2 on SPI and leave eMMC free). That’s annoying because in a NAS you **want** to install your OS on a separate storage device, and while 8GB eMMC is huge for some distros (e.g. debian fits pretty well), others do not (e.g. slackware). I found a solution consisting in adding a cheap M.2 key A+E to B+M converter, on which I plugged a 2242 SSD. This features a single PCIe Gen2 lane but that’s quite sufficient for an OS image (400 MB/s or equivalent to eMMC). It’s just needlessly complicated when you think about the tiny cost difference of a 16 or 32 GB eMMC…

   The SoC can run fanless (but with a heat sink). You’ll probably end up just not connecting the fan connector, like many of us who got this board. I also found it difficult to find a CR1220 battery for the RTC and would finally have preferred either a vertical CR2032 socket or just a 2-pin header for an external battery. Finally I found a CR1216 that fits.

   The board’s idle consumption is quite low. I seem to remember that my whole machine (board, 4xSATA SSD, 10GbE board with link up, Optane SSD for OS) is less than 10W at the wall. BTW, the onboard DC/DC converters are quite efficient, as I found that powering the board from the 12V jack consumes a few percent less than by passing via the external 12V->ATX adapter that was present in my enclosure.

   I’m still in the process of replacing my Odroid-H3 server with this much more capable one. I had not been pleased that much with the design and build quality of an ARM board in a while to be honest.

   Reply

   1. it suffers from a small defect which is Rockchip-specific: the DDR5 performance. It ought to run at 2736 MHz (DDR5-5472) but recently the RK3588 ddr init code was downgraded to 2400 MHz (DDR5-4800) “to fix stability issues” (without more details) and at this speed it’s ~10% slower than the ROCK 5B’s DDR4X-4224. It’s sad because DDR5 was initially advertised as a speed increase over previous generations and it ends up being slower. Also, be careful when you test performance, Jean-Luc, when the DDR is configured at 2400 MHz, the DMC is enabled and its “ondemand” governor keeps it running at 536 MHz even under load! I didn’t understand why the RAM had huge access times until @tkaiser pointed this out to me. You’ll likely have to force the min_freq to max_freq so as to get correct numbers.

      As a reviewer, I should probably not tweak the system to optimize benchmark results. Unless, I do a benchmark before, and then a benchmark after tweaking.

      Maybe Radxa will read your comment, explain what’s going on here, and whether a fix is needed/in the works.

      Reply

      1. > As a reviewer, I should probably not tweak the system to optimize benchmark results.

         IMO a reviewer should do an active review trying to spot such issues. And if I remember correctly the real issue in Willy’s case was a mismatch between the two boot BLOBs that resulted in the DRAM being clocked at the lowest frequency.

         This mismatch can happen pretty easily when there’s conflicting stuff residing in the onboard SPI flash and the media the user wants to boot the board from.

         Reply

         1. No, it’s even worse: when the two blobs mismatch, the DMC devfreq is disabled so it constantly runs at full speed. That’s why 2736 MHz was so fast. Once they perfectly match, it’s enabled and seems to be too conservative, not showing a willingness to jump to higher bins that fast.

            Reply

   2. > my whole machine (board, 4xSATA SSD, 10GbE board with link up, Optane SSD for OS) is less than 10W at the wall.

      That’s quite encouraging! You mean when idling, right?

      > BTW, the onboard DC/DC converters are quite efficient, as I found that powering the board from the 12V jack consumes a few percent less than by passing via the external 12V->ATX adapter that was present in my enclosure.

      If you have idle power usage numbers at the 12VDC jack (by measuring the amps eg with a clamp DMM) and could share them, I would be very interested.

      Reply

      1. > If you have idle power usage numbers at the 12VDC jack

         4W measured with an ODROID SmartPower 3 and nothing connected.

         Reply

      2. > You mean when idling, right?

         Sorry, yes, I thought I mentioned it but I might have lost it in rewording the sentence. For a home server I consider that idle is the most relevant since it’s basically what it does 24×7.

         Also I tend to think that I’d observe what @tkaiser reports with everything unplugged. the 10G NIC is super hot (nothing new, it’s an AQC107, I even added one extra heat sink). The Optane is hot as well. Spec’d at 800mW or so. And my SSDs are four good old 120GB, not exactly the most efficient by todays standards. That would mean ~6W for all of them or roughly 1W per device, that sounds quite reasonable for their generation.

         Reply

3. Just to put the comparison in perspective, though priced three-times less, SpacemiT’s K1 is also accordingly three-times slower than the RK3588 in both single and multi-threaded and has roughly slightly over half the memory bandwidth.

   So, the question on everyone’s minds isn’t who is faster but whether the K1 is fast enough for NAS and maybe get a feel for how that fast GPU coupled with 8 in-order cores fairs when used as a streamer / point-of-sale (desktop widget rendering… video playback… maybe light browsing and PDF rendering?).

   Reply

   1. > SpacemiT’s K1 is also accordingly three-times slower than the RK3588 in both single and multi-threaded

      Just use the ‘appropriate’ benchmark and RK3588 gets ten times faster: https://browser.geekbench.com/v6/cpu/compare/6979805?baseline=5769184

      And while it’s pretty obvious that Geekbench on RISC-V is pure nonsense this won’t stop reviewers publishing these garbage numbers. As for real-world performance ‘three-times slower’ is more realistic but I also suspect a DRAM initialization issue currently slowing the K1 unnecessarily down.

      Reply

      1. I think comparing GB scores among RISC-V boards is meaning, but comparing across architectures are nonsense at all (at least nonsense for GeekBench)

         Reply

         1. I’m not sure why architecture differences would matter to Geekbench:

            > Geekbench 6 scores are calibrated against a baseline score of 2,500 (which is the score of a Dell Precision 3460 with a Core i7-12700 processor). Higher scores are better, with double the score indicating double the performance.

            ( https://www.geekbench.com/doc/geekbench6-benchmark-internals.pdf )

            I believe the bad result @tkaiser mentioned was due to various bugs and incorrect configurations. But regardless, over time, as people submit more results from different distros, we’ll be able to tell apart the outliers.

            Reply

            1. > I believe the bad result @tkaiser mentioned was due to various bugs and incorrect configurations.

               Nope, that’s mostly since Geekbench sucks (on RISC-V). And the marketing BS you quoted is not really an explanation for anything – at least definitely in the context of cross-platform benchmarking 🙂

      2. I’m mostly relying on what Thomas Kaiser’s sbc-bench figures show. But if I thought they reflect real-world performance, I wouldn’t be here.

         Regardless, there’s also the power-consumption to consider since out-of-order speculation tends to be quite more wasteful than what little prediction in-order cores do. But it being a new design with immature software and kernel support will probably spoil this… We’ll see.

         Reply

         1. > I’m mostly relying on what Thomas Kaiser’s sbc-bench figures show

            My script uses the 7-zip benchmark as main metric for a number of reasons (maybe the main one generating scores that can be compared even when they were made in different years) but maybe 7-zip’s hugest downside is overvalueing the performance of primitive/efficiency cores compared to complex/performance cores.

            Reply

4. What a good idea to ship a rear panel with the board.
   Is this a common practice whe buying a mainboard ?

   Like Vall, I’m looking forward to your results.

   Reply

   1. > What a good idea to ship a rear panel with the board.
      Is this a common practice whe buying a mainboard ?

      For PCs following the ATX family of form factors, yes, but other SBCs, no since there’s no standard form factor. But yes, in the end this integrates pretty well into a standard PC case and when you see it you don’t imagine it’s running Arm cores. See there for some photos in a slim enclosure: https://wtarreau.blogspot.com/2024/05/an-affordable-10gbe-capable-nas.html

      Reply

      1. Thank you Willy.
         I’m used with SBC’s but haven’t play with “Dektop like” gears since years.
         It’s good To know that the integration of this kind of board in an existing case is easy compared to SBC’s.

         I will take time to read your extensive review.

         Reply

5. Is there a possibility of booting an ISO image on this board?

   Reply

   1. I think that if you flash EDK2 on it, it could work. There’s one image for the ROCK 5 ITX but I haven’t tested it. However the one I’m having on SolidRun’s LX2K happily booted from an ISO image on a USB thumb drive.

      Reply

      1. Interesting. If i can boot and install RHEL i’d probably have at least a couple of these for OpenShift Single Node instances! These would be ideal for such a home lab environment.

         The SolidRun LX2K board seems to support EDKII UEFI BIOS as well as U-Boot, so that’s a great thing.

         Thanks for you feedback @Willy, appreciated!

         Reply

         1. Note that there remains a major difference between LX2K and ROCK 5, LX2K uses an NXP chip and NXP is among those best supported in mainline kernel, with everything working out of the box very early, so it does help a lot. Rockchip devices rely on a BSP kernel and only start to be ported after boards are sold, so in general support is much less complete for a long time. So even if you manage to boot, say, RHEL on a ROCK 5 (I don’t even know if it would work), it’s very possible that many peripherals will not be supported (typically network, PCIe, etc). Maybe everything will work but I preferred to warn you so that you’re not too disappointed if it’s a blocker for your project.

            Reply

            1. Good to know about NXP chips!

               Re. ROCK 5, yep, i am aware it might not be able to boot and/or get RHEL working properly at all.

               Thanks again for your feedback and “warnings” 🙂

6. that radxa board is looking like the sweet spot for a home made low powered NAS 🙂 cant wait to see the power measurements

   Reply

7. Anyone tested whether we are able to run a KVM guest inside of this low power device? That would be a possibility of getting RHEL to run as a VM with VirtIO drivers is my thought.

   Or would it be too much of a task for such ARM to perform satisfactory with virtualization?

   Reply

   1. No idea but that’s an interesting idea. With today’s chip power, and with enough pass-through it could make sense to try to run a dirty, insecure and bogus BSP kernel on the host and present generic hardware to a well maintained OS. I wouldn’t bet much on a performant NAS this way but that might work with graphics, network and/or storage via PCIe cards in pass-through mode.

      Reply

      1. Yeah, it’s something i’ll test if i choose to go for such an SBC. If 32GB is made available, i’ll consider it as i’ve some other uses cases with whatever OS/distro with BSP kernel such as running some Podman containers and some PHP apps.

         But if this is an indication of it’s performance, it’s pretty good i believe when it’s ~25% inferior in single-threaded and ~15% in multi threaded compared to AMD Ryzed Embedded V1756B which is a 45W TDP CPU.

         https://browser.geekbench.com/v6/cpu/compare/7009977?baseline=5769184

         Another usecase for me is based on it’s “NPU” performance to run some InstructLab or IBM’s Granite AI models for learning purposes. I just have no clue about it’s performace for such AI workloads.

         Reply

8. It’s not starting well.

   1. My ROCK 5 ITX won’t boot. I’m using a 12V/2.5A power adapter and the fan is working, but nothing shows up on the HDMI display, and the serial console is not showing anything because I don’t have a USB to TTL adapter that works a 1.5 Mbps in my current location.
   2. I switched to the Jupiter RISC-V SBC. I tried to flash the Bianbu Desktop OS, but the Linux flashing utility (all in Chinese for now, translation is planned for later) won’t work because the OS image is over 1.5GB in size…

   Reply

   1. Oops. My bad about the RISC-V bard. It was trying to tell me (in Chinese) that my laptop’s SSD is almost full LoL. After deleting a few files, I can go forward…

      Reply

      1. Thanks for keeping us posted, @Jean-Luc! Seems like things are more than a little rough ATM.

         Crazy to send a serial adapter set to 1.5Mbps by default. What were they thinking? Trying to do Ethernet-over-serial or something? 🤪

         Ditto error messages in Chinese. I would have thought that developers around the world (which would be the public for these boards right now) would all understand English, even the ones in China… so why not use English for everything (or at least error messages) and translate later, including to Chinese?

         Never heard of Biambu. A little googling brought this: https://bianbu-linux.spacemit.com/en; Is it so hard to just support Debian?

         Anyway, great update and looking forward to your further progress.

         Reply

      2. But still the My ROCK 5 ITX doesn’t boot anymore?

         Reply

         1. My ROCK 5 ITX board never booted successfully. I’ve been told to try with the ATX power supply.

            Reply

            1. There’s no reason the 12V jack wouldn’t work. For me a 12V/2A power brick does the job. I suggest that you check among your USB-UART adapters to find one that supports 1.5 Mbps. The CH340, CP2102 and FTDI ones are fine for me.

            2. BTW in the worst case, another rockchip board will support 1.5 Mbps on its other UARTs routed to the 40pin header!

            3. I’m in a house with some old USB-UART adapter. When I run:

               bootterm -b 1500000

               1	bootterm -b 1500000

               Bootterm selects 1000000, so I guess the higher speed is not supported. I’ll move to another house in the next few days that has some newer adapters that I know work at 1.5 Mbps.

            4. OK in this case indeed no need to insist! Reminds me when I had to fight with adapters to find one that would accept anything close to the ESP8266’s 74880 bps speed…

   2. That’s a perfect illustration of the reason why I continue to plea for always having an onboard USB console port on any SBC.

      Reply

      1. Yeah, I’ve experienced my first integrated serial to usb on the quartzpro64, and it’s absolutely delightful not having to reach the pile of serial adapters and cables that are always at the bottom of the drawer…

         Please every sbc manufacturer, always add one to your designs. Really.

         Reply

Leave a Reply

Connect with:

Your email address will not be published. Required fields are marked *

Comment *

Name *

Email *

Website