Jupiter 2 – RVA23-compliant SBC features SpacemiT K3 octa-core RISC-V AI SoC, up to 32GB RAM, 256GB UFS

33 Replies to “Jupiter 2 – RVA23-compliant SBC features SpacemiT K3 octa-core RISC-V AI SoC, up to 32GB RAM, 256GB UFS”

1. nm ?
   12V via 2-pin ATX connector… , SOC may not be usable for portable devices ? maybe underclocking ? but is rk3588 used in portable devices ?

   Reply

2. > I was first surprised to find out the SpacemiT K3 is an octa-core processor, since tests on a remote K3 RISC-V platform showed 16 cores in Linux (Ubuntu 26.04), albeit with only eight cores usable.

   I’ve been using the remote test machine for several weeks and we just in the last couple of days got the information on how to run Linux programs (the same ones as for the X100 cores) on the A100 cores.

   In general the A100 cores are around 40% to 60% of the speed of the X100 cores, but that’s enough to provide a meaningful boost to normal workloads, not just “AI” ones. For example just using the 8 “AI” cores alone builds a Linux kernel in 39m23s, which is faster than the 42m12s of the previous fastest cheap(ish) SBC the Milk-V Megrez with EIC7700X (which is just quad core). The eight X100s manage this in 16m56s, and using distcc to combine both X100 and A100 cores (which adds a lot of preprocessing / compression / networking overhead drops this to 14m26s, a full 3 times faster than the Megrez.

   On my own (single core) primes test a 2.0 GHz A100 core comes in at 12.0 seconds, just a little faster than the original 1.5 GHz Pi 4 at 12.1s and a little slower than the 1.85GHz C910 cored TH1520 (LPi4A, Melez). And that’s the slow cores! The 2.4 GHz X100 cores do it in 6.9s, faster than a Core 2 Duo with the same clock speed (7.55s), and just a little slower than a Graviton 2 (Neoverse N1) at 6.53s.

   Reply

3. The prices are on this page
   https://arace.tech/collections/milk-v-jupiter-2-series

   $275 Milk-V Jupiter 2
   $275 Milk-V Jupiter 2 NX
   $330 Milk-V Jupiter 2 Dev Kit

   Reply

   1. Thanks. I’ve updated the post. I have $199, $199, and $239 here, but I guess it depends on whether VAT and/or tariffs are applied. I assume those are the models with 8GB RAM.

      Reply

      1. Milk-V Jupiter 2
         €170,95
         Out of stock

         Milk-V Jupiter 2 Dev Kit
         €204,95
         Out of stock

         Milk-V Jupiter 2 NX
         €170,95
         Out of stock

         Reply

         1. So lower numbers in the EU than in USA. Because of Trump Taxes? And/or lower dollar?

            Reply

            1. Those EU prices don’t include VAT, while the US prices include the tariffs. With 20% VAT, it should be around 205 Euros (about $245 US) for the Jupiter 2.

   2. Really odd to label the new one Milk-V Jupiter “2” when its not the same mini-itx form factor as the first one…

      Reply

4. “I was first surprised to find out the SpacemiT K3 is an octa-core processor, since tests on a remote K3 RISC-V platform showed 16 cores in Linux (Ubuntu 26.04), albeit with only eight cores usable.”

   With a single command you can use the 8 higher cores: https://github.com/sanderjo/SpacemiT-K3-X100-A100/blob/main/processes_on_higher_cores.md

   But I think it’s safer to position & market as 8 core cpu, and 8 cores AI.

   Reply

   1. They are marketing it as 8-core chip with high potential for AI (seems to target automation, industrial, robotics, etc.).

      The additional 8 cores are different (lacks of hypervisor, vector length is different, cache sizes are different, some AI block seems to be shared between two cores, etc).

      It looks like you probably can run 16-cores (still, asymmetric 8 + 8) if you run RV64GC. If you use vectors (e.g. IFUNCs in glibc for optimized mem* str* functions) you probably need to make sure those aren’t migrated between cores with different vector length.

      Think of it like Esperanto (ET-SoC-1, 1000+ vector optimized cores + 4 big OoO cores) or like Tenstorrent (Blackhole, 16 SiFive X280 cores + 120 Tensix cores [also RISC-V]). The main difference here is that those 8 AI cores are still kinda big and not optimized fully for AI. The above products use RISC-V, but those cores are highly optimized for vectors and matrix operations.

      Reply

      1. Yes.

         With distcc I was able to use the 8 lower and the 8 higher cores at the same time.

         See https://github.com/sanderjo/SpacemiT-K3-X100-A100/blob/main/processes_on_higher_cores.md

         Reply

      2. “It looks like you probably can run 16-cores (still, asymmetric 8 + 8) if you run RV64GC. If you use vectors (e.g. IFUNCs in glibc for optimized mem* str* functions) you probably need to make sure those aren’t migrated between cores with different vector length.”

         The current software NEVER migrates a process between core types. You can force a one-time move to an A100 core, which is safe if you do it early in a statically-linked asm program — I’ve written such a program, in 40 instructions, which I’ve made available as /usr/local/aix on the SpacemiT test machine, and a tiny shell script wrapper to do PATH lookup (tedious in asm without using libraries). so e.g. you can type “aix /usr/bin/gcc -O hello.c -o hello” which switched to an A100 core and then execve’s “/usr/bin/gcc -O hello.c -o hello” in the same process. Overhead is almost exactly 1ms. Or you can use the shell wrapper and type “aix gcc -O hello.c -o hello” which does PATH lookup then exec’s aix and adds 1ms more overhead.

         Note that the AI cores by themselves build a Linux kernel 7% faster than my previous fastest machine, a Milk-V Megrez with EIC7700X. Using both X100 and A100 cores it’s 3x faster than the Megrez.

         You can use the full ISA not just RV64GC. The only ISA difference is H, which does not concern User mode programs. All you have to do is make sure you switch to the AI core **before** starting to use the V extension. My aix helper uses only RV64IMC.

         Reply

         1. Why do other people’s messages keep paragraph breaks, but mine get all run together?

            Ohhh … cancel that … it’s only because my messages are long enough to get a “READ MORE”

            Reply

5. 60 TOPS (INT4) guys, It is not clearly written anywhere. You might think int8 , it will give similiar performance with Jetson Orin Nano but THATS NOT TRUE!!!. Price is same with jetson orin nano(250 USD for korea ) but HALF THE PERFORMANCE!, Carrier board also extra money. no cuda, chinese vendor , low documentation, not having community. It is riscV not arm, so power consumption will be much more than JETSON. So if someone find a single reason to buy this over jetson orin nano, please inform me. Because I dont see a single reason to buy this board. (note I support all small hardware companies, but i am against scammers.) Nvidia already pricing everything crazy, how you can be less powerful and more expensive? Its just a scam.

   Reply

   1. You can’t estimate performance just by looking at the advertised TOPS. It’s mostly irrelevant. A 3 TOPS accelerator can work just as well as a 24 TOPS one on specific workloads. This needs to be tested.

      Reply

      1. I agree but we talk on paper, the device not released yet.
         On paper , more TOPs gives you better FPS.
         Nvidia have better ecosystem and and better pricing compare to this one.
         For korea this device is 300 USD (not including a fan)
         And from my experience , ARM microprocessors, always have better power consumption than the RISC-V microprocessors.
         So, more expensive (even from NVIDIA) , less powerful AI (on paper), more power consumption , less document. I think I made my point very clear. If you have any specific application for this device , i would like to know. I cant believe riscV companies become more expensive than ARM , and giant tech companies.

         Reply

         1. No argument here. RISC-V can’t compete against Arm in the application processor space right now. It’s a long-term process.

            Reply

            1. It’s getting closer! This is competitive with Graviton 1 launched in November 2018. I believe the K5 later this year is likely to be roughly comparable to Graviton 2 (deployed on AWS in 2020). There are some other considerably faster chips expected this year too.

            2. Besides raw performance, there’s also the performance/price ratio. Now, most RISC-V platforms are quite expensive compared to their performance. I suppose a RISC-V SoC with Rockchip RK3588 level of performance would work if boards were priced accordingly, but that’s really the case for now.

            3. The RISC-V chips are generally a bit smaller than equivalent Arm ones (or certainly no larger) which makes them cheaper to make.

               The issue is that the selling price depends almost entirely on spreading the fixed many millions of dollars initial cost of making a mask set — not to mention the NRE — over however many chips are sold.

               If RISC-V SoCs and SBCs are more expensive than Arm ones it’s 99% because there simply aren’t very many sold.

               In their presentation SpacemiT said they’d sold 150,000 K1s. That’s TINY. And I think they said they currently have firm orders for 30,000 K3s.

               There can’t be price parity until those number are in the millions.

               The first Raspberry Pis and Odroids used unsold chips made for mass-market set-top boxes (Pi, Odroid C2) or phones (Odroid XU3/XU4).

               RISC-V isn’t yet in those markets because the performance level required to do so is much higher now than it was in 2010 and RISC-V SoCs are just now reaching performance levels for those markets today.

               If someone wants to order 10 million K3s then I’m sure SpacemiT will give them a very nice price.

            4. perhaps we have reached the point where risc v wont beat ARM in compute ever but it’s good enough for some tasks that can replace ARM such as routers/AI accelerators/IoT/ etc but for mass production i bet the price difference would be marginal against a comparable ARM chip.. and the situation is not quite comparable either to MIPS vs ARM 30-25 years ago

            5. I’m confident RISC-V will beat Arm and x86 long term because it’s open to anyone in the world with a brilliant idea for a new µarch or a new specialised accelerator for the latest application area to step in and get something designed and made. It’s not only a few engineers at Intel/AMD or Arm and its very few architecture licencees (Apple, Qualcomm, NVIDIA, Google, Amazon, Samsung, Broadcom).

               Already almost all security research is done using RISC-V. Everyone doing AI accelerators is basing them on RISC-V. Anything new and exciting in future is very likely to be done on RISC-V — **even** by companies that hold Arm licences.

               Often the highest performance implementations will be proprietary, but there are also already respectably high performance open source implementations. In the Xiangshan project, for example.

               The SpacemiT K3 just being launched is the overall best RISC-V SoC available so far from any company [1] and SpacemiT acknowledges building off open source work such as the OpenC910 core from THead.

               Note that SpacemiT is a startup founded in 2021 and currently has around 150 employees.

               They are able to stand on the shoulders of giants.

               RISC-V is behind at the moment. K1 was 2000-level PC e.g. Pentium 3 or PPC G4. K3 is 2010 level Core 2. K5 later this year will I think be around Skylake level. And multiple US companies such as Tenstorrent and Akeana have 2020 Apple M1 level RISC-V architectures taping out as we speak (though they will initially be at slightly lower clock speed).

               Tenstorrent is expecting parity with Arm and x86 in their design for 2028 release. Even if that slips to 2030 the gap will be minimal.

               [1] the SG2042 has a lot of slower cores and a lot of cache and PCIe but significant bugs and performance problems — and much higher price. The UltraRISC UR-DP1000 is not bad, but lacks RVA23 and RVV support and, like the K3, has been announced and orders are being taken, but has not shipped yet.

            6. I wish your predictions resist the assaults of time, but I’m less optimistic. This platform is extremely fragmented, resulting in a difficult choice for software integrator regarding what should constitute the common base to be supported. Arm has known that at the armv4/v5 era. Most software vendors would consider the ubiquitous arm926ej-s as the base, but when armv7 arrived (and was compatible with that one), software was totally sub-optimal (not using floats nor various extensions). Even at the armv7 era, not all would enable Neon (e.g. Marvell’s PJ1/PJ4/PJ4B didn’t have it and had a limited vfp3-d16 instead), but they had the precious integer divide instruction that many other lacked. In the end portable software used only the common base and was totally sub-optimal. Arm improved the situation later by enforcing mandatory features in architecture levels. Nowadays if you build for armv8.1-a you have neon, divide, crc32, LSE atomics etc, so it’s much easier to benefit from most new features at once because you know that all compliant chips will be compatible with your code. At the moment, RISC-V is even worse than what armv5 was, it has more extensions than letters in the alphabet, and the common base (rv64gc) is just not great yet IMHO. One just has to count the number of instructions for a given function and compare it to generic armv8 code, it’s between +20 and +50% instructions count depending on the code.

            7. There is no such RISC-V fragmentation.

               If you are making software for an embedded device then you choose the CPU/chip with the features you need, you know what you chose, and you tell your compiler exactly what extensions it has. Easy.

               If you are making software for the mass-market then you build it for RVA23 which is an excellent baseline roughly equal to x86_64-v3(Haswell/Excavator) or ARMv9.0-A. That’s what essentially all new SBCs will support from this year on (with very few exceptions, such as the Milk-V Titan), certainly by next year, as well as Android, laptops, set top boxes, servers, whatever. It will be in everything with Haswell/Skylake or better performance (and the Core2 performance of K3).

               Optional: you could consider making an RV64GV version for the at most few tens of thousands of low performance SBCs out there. Test for RVV at runtime if you want and use that for functions that will benefit, but that’s really only the K1, or add in the C906&C910 chips if you want to include an RVV draft 0.7 version too.

               That’s **it**.

            8. The K3 supports RVA23. It will be the RISC-V standard for years. It has roughly the same feature set as ARMv9 or X86-64v4. As the first RVA23 in the market, this is literally the chip that makes your comment obsolete.

            9. > As the first RVA23 in the market, this is literally the chip that makes your comment obsolete.

               And when will it become the default one supported by all active distros ? Because that’s what conditions a vendor’s ability to support their products for such a platform. On x86_64, you can just build for opteron/haswell and it simply works *everywhere*, benefiting from newer CPUs’ optimizations. A few arch-specific optimizations are handled by the libc (use of SSE/AVX for memcpy for example). In the ARM world, you target A53 and it just works everywhere, albeit not optimally if you heavily use threads since newer armv8.1 cores (A76 and above as well as A55) support LSE atomics. But even then, gcc-10+ provide the outline atomics which automatically switch to the best one. Thus again, for the vast majority of applications you just don’t care and you emit portable code for armv8-a. For RISC-V, you’re saying “target RVA23”. OK, but it will not work on currently supported distros nor hardware, but only on *new* hardware (and it’s still not even supported by any released version of gcc as far as I can tell).

               That’s just not yet usable for new applications but will be in 2-3 years when new operating systems ship with support for it by default. And maybe by then RVA23 will be considered ridiculously old like RV64GC currently looks like while a year ago or two it was still considered as a reasonably portable common target. This is what I’m explaining about fragmentation.

               If RVA23 turns out to be as complete as (say) Skylake, most likely it will remain a reasonable common target for many years to come. Just like RV64GC currently is to some extents.

            10. What is this claim that Arm is not fragmented. Even to this day that’s simply not true. Just look at the software support for current consumer-level hardware. Even for that brand new Nvidia Spark it’s not feasible to take standard Ubuntu and install without some hackery of replacing mainline kernel with Nvdia’s binary-only version. Forget attempting Debian on an Apple M5 or Qualcomm laptop to say the least. What about taking Raspberry OS image for the Pi 500+ keyboard computer and using it for a Thelia Astra Ampere computer from System76. Surprise, it does NOT work! Go look at Armbian’s download list. It spans pages because there are different images for each device. All at different levels of usability from each other.
                Add in Arm phones and tablets to the mix, as well as server-class cpu like Gravitron, Cobolt, Axion and you have the land of fragmentation. How are all these proof of a supposedly standardized Arm ecosystem.
                Further to criticize Risc-V and extensions, but not mention that Arm itself allow vendors to customize and add their own incompatible “extensions” is purposely misleading and ignoring the true reality.

            11. You obviously mistake ISA fragmentation to system fragmentation.

            12. Hmmm, so Apple being able to add some x86 instructions into their own silicon to bolster poor Rosetta software performance as one example. That is not deviating from the standard? With ARM’s permission?

6. Sipeed is also taking pre-orders for the exact same board, SoM, and devkit.
   https://sipeed.com/k3

   Reply

   1. Banana Pi calls it the BPI-SM10 SoM/Core board https://docs.banana-pi.org/en/BPI-SM10/BananaPi_BPI-SM10

      I’m not sure whether getting so many distributors will help or just bring confusion.

      Reply

7. OpenGL 3.0 –> OpenCL 3.0

   Reply

8. we need an AI benchmark. CPU wise is worst than RK3588 for sure

   Reply

Leave a Reply

Connect with:

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

Comment *

Name *

Email *

Website