I'd like to take a moment here and appreciate how far this industry has come, that we can talk about a computer performing two _billion_ math operations per second and call it _slow._
Or complain about data transfer speeds of 150 MB/s. I still remember spending an afternoon backing up the 5 MB hard drive on our first IBM PC to 360K floppies.
@@JustinEmlay I don't think it's modern software that's holding back a return to the moon, the calculations really are quite basic, it's not magic. Money and rocket designs are a bigger issue.
I see RISC-V dominating the cheap (and maybe not so cheap) microcontroller space way, way before the compute space simply because the license fees are going to be a higher percentage with micros, and almost an afterthought for desktop class chips.
I can definitely see it eventually taking over in a big way on the low end. Where performance, and even power efficiency, are not that big of a deal, and you need something a touch more capable than a RP2040 from the Pico, but without the costs of an ARM license. Hopefully it won't get stuck in that niche, and instead it can slowly grow into other spaces as it matures.
@@FieryPouncer Milk-V announced recently that in 9 months they are going to release Oasis computer with SG2380 SoC with 16 P670 + 8 x280 SiFive cores, although the latter ones should be mostly used as a NPU and not OS scheduling. Whole mobo costs around 100$ with pre-order coupon and in my opinion it's shockingly spectacular, now we as a community need to develop a nice software ecosystem not to let RISC-V die out
Afaik there is just one MCU with decent market share using a risc v architecture, ESP32 S3 I believe. But I don't think RISC-V will break the ARM dominance in this space. Toolchain, Certification (especially safety) and experience is miles ahead and gets better every year for arm
@@pawe460 Google announced they are working hard to make RISC-V a first tier architecture for Android (next to ARM and X86). And I'm even surprised how many things on Linux already work on RISC-V. I recently tested SimpleScreenRecorder on a VisionFive 2 RISC-V SBC, and I'm pretty sure the author never had RISC-V support in mind.
Anything but to trust google supporting risc v? Yeah sure, google is the one who destroyed android by making it less open source, nowadays android is such a joke os, it almost restricted as iOS. Android being open source is just a scam or pr stunts, not real open source.
It's exciting to see more and more RISC-V based SBC's being developed. As with most of these boards, the hardware looks promising but developers leave a lot of the software development to the community - which is just too small to make meaningful progress at the moment.
More than just boards and hardware, software support is essential. There needs to be community and developer passion. It'll be hard to unseat raspberry pis with their primacy and established reputation. I used my rpi4 as a primary desktop computer for about two years before going back to x86 because the software support just wasn't there, yet.
If there is anything that RISC-V has in spades it's passion. ARM being shady and that the ISA is open (don't know if any open-source RISC-V cores have actually been fabbed yet), means that you have fanboys everywhere. There just needs to be enough boards put out there for the critical mass to start snowballing.
The Pi 5 is facing an uphill battle. If it really has only HEVC hardware decoding and no other decoders, that's not nice for a desktop experience. On the other hand, we are still waiting for a proper driver from Imagination Technologies for the RISC-V SBCs. It looks like we can test Vulkan soon on the VisionFive 2 RISC-V SBC. Not sure when we get access to all the hardware video codecs.
Support will never be the same when it comes to commercial software on Linux. Imagine having to support your program on a couple different kernels, several different display servers and audio architectures, half a dozen desktop environments on dozens of distributions, often with 3-4 different release schedules to choose from, it's an absolute nightmare.
Linux devs are embracing RISC-V in a big way. As long as you can run Linux on it, it doesn't really matter what the ISA is. From there, if somebody's able to make a decent profit off of making chips for data centers or SBCs or whatever else, and the potential is definitely there since they don't have to license the ISA, you will see widespread industry and hobbyist adoption. Some big companies are embracing RISC-V for microcontrollers and AI stuff. Apple's been hiring RISC-V people either to work at Apple Silicon or possibly work on porting over their software on somebody else's dev boards. I think we'll see a transition period soon where there are comparable RISC-V and ARM SBCs being sold side-by-side from a number of companies, and then one or the other will eventually achieve dominance. RISC-V likely has the price advantage at the low end, which means we could see more expensive ARM SBCs and less expensive RISC-V SBCs for a while before companies just decide to switch over to RISC-V at the high end too, assuming the performance and efficiency can scale right. This is an area of technology where the low end drives the trajectory since eventually low end chips become good enough for a lot of tasks and most purchasers in the market are very price-conscious.
RISC-V is A LOT of fun. I am making my own cpu design with a logic simulator. Its a five stage pipeline, but i started reading about out of order execution and have some ideas about instruction queues. MMU and caching still seems like magic, but its not quite as arcane as I learn more.
Cool, wish you have luck! I’m making my own cpu too. At the moment, I will won’t use pipeline method. For the actual model that I’m in development, my method is using positive trigger of the clock, to decode instructions and activate the control unit. Then negative trigger of clock is used to storage/complete. In my next model, pipeline will be implemented for practice, improvements and get abilities.
I had lots of problems getting my RISC-V starfive board running, I'm optimistic that RISC-V will close the gap by making use of already researched techniques from arm and others. Not sure when but probably in time. Playing catchup with notes is a little easier then trail blazing. Anyways would love to see the 64c monster you mentioned at the end of your video.
I don't know why. Download Image-55 (from December '22), burn it to an SD card, insert card, turn it on. That's all I had to do on mine. With more recent OS images you also need to flip one DIP switch of the pair (the one closest to the middle of the board) to the other position. That's again all. There were a couple of images released early this year where you had to do a complicated thing with also re-flashing the onboard eMMC, but either the original Image-55 or a recent one avoids that.
@@JeffGeerlingconsidering that the old cm4 had 2 dsi and 2 CSI porta and the cm5 has only 2 hybrid ones it might mean that they have some pins free for the piece X1 bus
Totally would love to see your opinion on the milk v pioneer. Mainly I appreciate your honest and knowledgeable review of the current progress of all things risc v.
The initial core RISC-V hardware market target is cheap embedded along the border between microcontrollers and SOCs capable of an operating system. On the software side we just need a bit more well developed general purpose IDE and compiling for RISC-V, and get companies shifted over to using the open/third party dev kit rather than the old proprietary mindset. Pre Risc-V every chip maker had to make its own tool chain compatible with its own ISA leading to some rather janky barebones options. x86 was the main exception(mainly as a side effect of the 3 decade old Intel-AMD contract).
I am glad someone has good luck with the RiSC-V, I got a StarFive 2 and it came where I couldn't boot. I been trying to update the SPI, but no luck. I hoping one day I can use it. having good luck with the Banana-Pi CM4, and the Orange-Pi CM4, though it has more pins that RPi CM4. Thanks Jeff, I never hear of Mars Board until this video. I have to check them out.
As someone who is part of the industry that is actively designing and building RISC-V processors, I do agree that RISC-V is a very young ISA and needs a ton of work and time from enthusiastic developers. They are offering tons of software suites (Android, GNU etc.) for devs to pick it up and develop tools and applications for RISC-V systems. I do disagree with RISC-V systems not being on par with equivalent ARM systems, not too sure about the board you got but the RV systems we build take on ARM's offerings in price, performance and power consumption. Although, I do see you point; it's not wide-spread yet but it's promising! Great video!
@@fakecubed truly, for now most RISC-V startups are focusing on low-power, embedded usecases. Baremetal stuff on RV makes a ton of sense at this stage. But I can see it getting into the Android space too eventually
@@suhaskv There's also the Ventana Veyron which aims to provide high performance data center compute. I think we'll see the big three cloud providers offering it before too long like how ARM recently started to be embraced in the cloud. It's apparently competitive with existing hardware using other ISAs, including performance per watt in V1, and V2 will be another leap in performance to hopefully match or better many near-future hardware offerings. The big three can afford to throw enough money to get their custom tech stacks working on it. If Ventana can keep things going like that, RISC-V could be a major player in the cloud.
Just like ARM isn't killing x86 (yet) - but Apple proved, it has the potential to do that. And when you look a bit deeper into the design of the RISC-V instruction set and it's philosophy, you can see that it has the potential to kill ARM in the future, as its design is more sound, just like the design of ARM is way more sound than the design of x86 . Some people are not happy with certain trade-offs that were made but you always have to do trade-offs, there is no ISA that doesn't have any trade-offs. I studied pretty much all CPU architectures in the past and just based on that I made predictions like PPC not having any real future, since its architecture seemed flawed to me, so when PPC struggled with 64 bit CPUs and Apple finally gave up on it, that didn't came to me as a surprise at all. What did came as surprise to me was the Xbox360 switching to PPC but I guess that was the last time we saw PPC for the mass market. I also wasn't that surprised when Apple went all ARM, yet I didn't expect them to have the guts to truly pull that off, as it once again set off their machines completely from the Windows PC market (and I'm still sad to have lost VirtualBox support on Mac). But not only has RISC-V the potential to reach ARM performance, it has the potential to reach it at lower power consumption. And once again it's Apple, who hired a lot of RISC-V experts in the recent past. I wouldn't be too surprised, if one day Apple announces that the Apple Watch now has a RISC-V CPU and this will give that architecture a huge leap forward, as they have the money and man power to push that ISA quickly forward, to the point where it could actually compete with ARM at least in the low range sector. And the big advantage for Apple would be: No more license costs for their own RISC-V CPUs and also no license restrictions whatsoever.
You've got me curious, now. What were the flaws in PPC that you saw? I do agree with you that Apple is probably going to end up switching to RISC-V down the line. They will probably (and maybe already have been) start with small RISC-V based chips on their boards controlling batteries and the like, and just not tell people. So much of Apple's hardware is a black box anyway. They could work their way up from there to watches, phones, etc.
@@fakecubedPosting a detailed analysis of the PPC architecture in a UA-cam comment would probably go to far and UA-cam does not like external links (each time I post a link, no matter what link, no matter what destination, other than UA-cam itself, my comment vanishes within a few minutes). But in a nutshell: PPC basically tried to make everything different than existing architectures of that time and that's rarely ever a good approach, since the only reason to make everything different is when everything sucked but that's never the case. Architectures may have flaws but they are not 100% flawed, as then they would be useless. If you change everything about cars, you end up with a sailboat, which is not a useless product but it is useless if your goal was to design a better car. A GPU is also a useful piece of electronics but it's no replacement for a CPU and incapable of running standard software; at least it could never do so efficiently (of course, you could emulate an entire general purpose CPU within shaders, that would work but would also be very slow). The instruction set of PPC is not designed for normal computer tasks. It's a bit like IA64 (Itanium), which I saw for the very first time and immediately thought "How will a normal, modern UI application ever be able to fully utilize that instruction format or somehow even benefit from it?" I cannot explain that in detail here, but just look at some numbers: ARM has 19 different instruction formats (actually just 18, one is just a special case of all the other ones), PPC has 15 different base formats, with almost each of them have 2 to 4 sub-formats, sometimes 7, yet one has 35 sub-formats. Sure, x86 has more, but x86 is a CISC instruction format, not RISC. The ARM instructions are dense and a single one can combine a condition, a math operation and a logic operation, all in 32 bits; so very common source code constructs will result in a single ARM instruction. On PPC you need 3-6 instructions to achieve the same outcome, again, each 32 bits. RISC-V has only 4 base formats, with 2 extra ones that are just variants of two already in the base set. It's less densely packed than ARM when it comes to function but more densely when it comes to working with data (e.g. intermediates) and RISC-V allows for way more instructions in total, so it doesn't have to stay RISC all the way, it can do things like adding a single instructions that performs a complex operation that would otherwise require plenty of instructions if that should ever be required or vastly beneficial. Also while x86 and ARM both offer 3 different kinds of memory barriers, PPC only has one. This makes it easy to "not pick the wrong one" but it also means that a lot more synchronization must take place than would strictly be necessary, which is an issue if go multi core and want to keep increasing the number of cores. RISC-V has two and both reserve bitfields for future use to make them even more fine grained, if required to increase scalability. There are other things that make it way harder to scale PPC and x86 core-wise than it is for ARM or will be for RISC-V. And even if you can scale the number of cores, there is always the question how often will one core slow down another core which is also ISA dependent, as that prevents a huge number of cores from reaching their full potential. For decades speeding up CPUs mainly meant increasing the clock rate but that isn't the case anymore for over a decade. Today adding more cores is often way simpler to do and here ARM performs really well, as it is very simple to add more cores without requiring a super complex or ultra-fast inter-CPU bus system, that is almost as complex as a CPU itself or is very power consuming. Just compare the CPU bus of x86 server CPUs (with plenty of cores) to the one of x86 consumer CPUs (with way less cores) and you will see what I mean by "complex bus system". And being super relaxed at the memory model surely helps PPC, just as it helps ARM and RISC-V, yet you cannot always be relaxed, you need fences, atomic operations and explicit ordering and here I see PPC struggling more than other RISC architectures; well, Alpha would have performed even worse, but that's a different story. And don't get me wrong, every architecture allows scaling the number of cores, this was just about how much effort that is, how costly it is, how much it will add to power consumption, etc.
Regarding power measurements: Using a kill a watt is nice from a practical standpoint for effective power consumption. But that includes the losses of the power supply and the efficiency of the power supply might not be linear. For performance measurements I would probably try using a bench power supply which also shows the wattage directly if you get a nicer one. For USB get an USB tester like the fnirsi fnb42. Thanks for all you do and sharing everything in an organized way, allowing people to contribute. It makes it so much easier since we all would have to solve the same problems getting something to run. Also gives confidence the features like pcie in this example really work. Thank you so much
Jeff Geerling has transcended the roles of maker, hobbyist and enthusiast, and has become an authoratative voice for those communiries that the manufacturers and software developers trust and respect. It's an impressive achievement, and all the more so because he seems to be such a decent, thoughtful and likeable guy.
Love your content bro, keep it up! When I saw you had to resize the disk, that hit me hard because I'm studying for my RHCSA in the next few days, and have been drilling away at automount, network storage, and disk resizing like crazy. Last thing I'm working on are containers; Damn you and your long command!
Great video Jeff, and you pointed out that the support just isn't there. Pumping out new RISC boards is neat, but without support, or a solid community, they're going to stay niche. Watching the Raspberry Pi community grow was impressive, but took some time. Hopefully RISC can get the same love.
The community is pretty solid and continuing to grow. There's a lot of enthusiasm for this technology among both industry and hobbyists. In the hobby space it's just very niche and will take a while for the hardcore nerds to provide enough feedback to companies and work out the bugs. From there, we'll get more chips and more SBCs. Major industry partners will adopt it more and more. A few companies will emerge as RISC-V leaders. And then we'll see. I can imagine a company like Apple eventually switching to RISC-V somewhere down the line just to avoid paying for ARM. They've already hired RISC-V specialists, and I'm sure Apple's looking at their nine-figure ARM licensing bill wondering if they might be able to save some of that money. That won't be in five years, but maybe 10 or 15. RISC-V so far is on a much accelerated timeline compared to ARM. We're already seeing it pop up in all sorts of special applications like AI.
0:00: 📦 Mars CM은 Raspberry Pi Compute Module 4의 대체 옵션으로 작은 컴퓨터로, 4K 지원, 블루투스, Wi-Fi, 기가비트 이더넷과 같은 기능을 제공합니다. 1:54: 📦 설정 중 문제 3:55: 🔧 PCIe 인터페이스는 작동하지만 프로세서의 성능으로 인해 제한되며 초당 150에서 250 메가바이트의 속도를 달성 5:52: 📊 Mars CM은 현대 ARM 프로세서와 비교하여 효율성이 낮습니다. 7:46: 🔍 Pine64 SoQuartz는 Raspberry Pi Compute Module 4의 잠재적인 대안이지만 특정 기능과 호환성이 부족합니다.
Great video Jeff. Man I remember reading about RISC-V and how its going to take over in high school. Its been a long time especially in the tech world, and it still far behind the competitors.
It may yet, but on the timescale of decades. Arm has been around for years and years, but really only started taking off when mobile became the dominant form of personal computing.
I really want to give MilkV the benefit of the doubt that they aren't just pushing out products without testing or finalizing development and hoping the community will do exactly what you did and do all that work for free, but I've seen too many Chinese companies in the tech space pull this.
I think that it IS really good that MilkV is pushing its products out early. So that we can play with them test them and as long as MilkV takes the feedback then the community benefits which will help lift RiscV up. Jeff seemed to be having fun. And we got a cool video as a result.
@@jamesboulton2722 I agree, but I've seen it where someone who wants a RPi equivalent for a project and isn't super-in-depth will likely hit a skill/patience gap getting something like this to work. Granted, until this video, this product would likely have been unknown to those exact users, so it's kinda a chicken-egg problem. As long as those promoting the products do what Jeff did here and lay out the process to get it "functional" then I think it's not a bad idea to crowd source bleeding edge products. But I've seen consumer-grade products in big-box stores that get abandoned by developers and so anyone buying them are left with either a mountain of technical work to get it to a base working state or trying to return an open electronic to a retailer who likely doesn't care they're selling dead goods.
Thanx for the video, very informative and yes the RISC-V architecture is not mainstream yet, but we need more choice in this sector. In my country everything is expensive, so cheaper alternatives are a plus. I only managed to purchase a RPi4 this year after losing out in 2020 with the Coolermaster case kickstarter mess. Yes, the Pi community is great, but RISC-V will get there. Just look at how far the Rock chip boards have come!
RISC V won't kill ARM just like ARM won't kill x86. The only reason x86 killed MIPS, DEC Alpha, 68K and PowerPC is because it was tied to an industry standard open hardware and software platform which allowed for greater flexibility and low cost through economies of scale. Neither RISC V or ARM have such a standard. At least not yet. That said, I think it's important to have a CPU architecture which is freely available to anyone just like open source software.
This doesn’t have to be a zero sum game. The more options for low power, low cost computing the better. The more we can do to encourage this and future generations of SBCs the better. SBCs like this feel our last refuge in the on going war on general computing.
It took ARM 20+ years to get an out of order design. RISCV did that years ago. From OoO to competing with x86 has been 15 years if we count X4 as competitive. RISCV is on track to do that in just 4-5 years which is literally the bare minimum to design a new microarchitecture. While there’s overhypers out there, is also true that we will have high performance chips in the next couple years.
The main problem is uprooting comparability. ARM filled a needed niche, and by all accounts an "empty" niche. The reason why we won't see x86 fall is due to the last 30yrs of development and the largest amount of focus. Arm has done that for its niche in the mobile phone market and even in the Microcontroller market. Though I would agree in the super small Microcontroller (like remotes), it could have a place due to the lower costs ($0.001 off is a lot for something that costs $0.01 in bulk order) and the lack of legacy need.
I'm afraid you're one of the overhypers. You try to hold it against Arm that it took over 20 years to see an OoO chip, but that's actually just because the first two decades of Arm were the 1980s and the 1990s. In the 80s literally nobody was selling single-chip OoO microprocessors. That began to be a thing in the 90s, but it was far too expensive for a tiny company like Arm. Next, we have to talk about actual ages of the Arm and RISC-V ISAs. RISC-V derives a lot of things from older RISC ISAs, and modern Arm is technically only about 10 years old (counting from first commercial chip). You see, the 64-bit Arm ISA was a complete do-over. You can design dual-mode 32/64-bit Arm cores, but the Arm chips making waves right now (such as Apple's A and M series, and Qualcomm's new Oryon) are 64-bit only. The first commercially available 64-bit Arm was Apple's A7, which shipped in the fall 2013 iPhone refresh. (It was OoO, by the way, so 64-bit Arm went from zero to OoO in one step. Doesn't really mean anything, but you seem to think it's important.) The big problem for anyone who wants to believe RISC-V will inevitably overtake Arm64 is that Arm64 is a very well designed ISA and RISC-V is not. None of the mistakes in RISC-V's design are fatal, they just make it harder to create high performance RISC-V chips, and possibly may result in extra power and/or die area.
I work at Renesas, we have tried the RISCV route on a couple of products. In the end for a similar core, RISCV is more expensive than ARM. In addition, there is next to zero interest in the market for RISCV. Maybe one day customer will become more interested!
Like many new tech things, I think it's partly chicken-and-egg. As more devices come, slowly more software will be ported, and more people will be willing to dip the toes in the water. But that won't mean much on SBCs at least, until there are more competitive RISC-V cores on the market.
thank you for your work, it's true that we often forget that there's more than just arm, x86/x64 architectures. don't forget that risc-v architectures are often architectures with specific bricks, often used for video encoding, mathematical calculation, they are less modular than ARM. i'd like to know what the 64 bits are worth, i'd like to set up a setup to do benchmarks.
Fantastic video. In 10 mins from zero knowledge about RISC-V , now i have some basic understanding, the current state of it, i know how does it compare to current ARM based solutions and I know that while it may be not there yet, it is a promising technology.
It's like the ln command, or tar... you do it a thousand times but you still have to look back because it's just not intuitive (at least not to my brain!).
@@JeffGeerling If you are referring to the order of arguments, think ln as cp and imagine you are copying a file. That helped me to finally remember it. cp original.txt copy.txt ln -s original.txt fake_copy_hahaha.txt
Thanks for your time and effort. Great video! As expected, the software side still has a long way to go. In the old day, there are Alpha, Power, RISC, MIPS, i960.... Now, the IBM z16 is powered by Samsung 7nm...
it's pretty early for risc-v to start getting a piece of the SBC market, it still needs manufacturers support and funds for R&D and software. but it is making a small but steady step in the microcontroller market with a few fairly nice little boards.
There's a few good boards already, and in the next couple years there's going to be a lot more on the market. They may not be the absolute best, but nerdy folks will buy them to tinker around with, and that will fuel more R&D budgets and more boards. The idea of RISC-V has excitement attached to it that ARM can't hope to match, for the types of people who like to buy these boards. At the same time, the AI market is embracing RISC-V, and lots of big companies are buying in for all sorts of embedded apps. Lots of real world uneasiness is also driving interest in RISC-V (or rather, driving people away from ARM) at those big companies that want to hedge their bets.
Thanks Jeff, totally agree with you, even ARM still not take over the x86 market so RISC-V is just the beginning, also the complex (for novice) to use really not ready for the average Joe.
Even with the road ahead of us, I am so excited to live in a time that I can purchase RISC-V hardware that's in the desktop realm of things. I got my Star64 the other day, I'd love to see the people at Pine64 make a compute module of it.
I have the Turing Pi 2 with several CM4 carrier boards so this will be a cool thing to try it on. RISC-V still have some ways to go before it reaches critical mass but it's getting there.
What CM4 board have you tested that worked with Turing Pi 2 apart from. RPI CM4? I can't seem to find any general info of other brands working on it apart from RK1, Nvidia's.
Love the Video you are 1/2 correct on the Licening on the RISC-V. RISC-V is Opensouce and there are no Roaylties. It's important to note that while the RISC-V ISA is open, the actual processor implementations (e.g., CPU cores) developed by companies may have their own licensing I am sure you knew that but it came off that RISC-V is pretty much the same as ARM that that isn't correct at all. People would rather pay someone for their design than doing their own.
@@AndrewRoberts11 Very true. Also, a note that not all RISC-V designs will work 100% with each other. The one thing ARM does have is that it has to be compatible to some level. RISC-V has a future, but it's still a long way off.
@@AndrewRoberts11 You probably can, but you won't be able to call it RISC-V. Similar things happened with MIPS, meaning that there is an implementation called XBurst which is practically identical to certain MIPS architecture versions. The company responsible later licensed the relevant MIPS technologies, meaning that later products can advertise MIPS compatibility, although they do still use XBurst in their promotional materials. One practical consequence was that they appear to have adopted the official MIPS vector extensions alongside the ones they had devised themselves.
Well ~ I am looking forward Qualcomm RISC-V. Your testing SoC is MiC. I tested their VisionFive 2 single board computer ... it is more OS support ad optimization !!! Loooooooong way to go ~
I would love to see you put that 64-core RISC-V Milk-V pioneer through its paces. I know it wont beat anything reasonable right now but I just want to see how far RISC-V has come at the top end.
While I realize the PI Pico isn't a fair comparison (a fraction of the RAM/Storage, can't run full-fat Linux), it does make me wish one of the benchmarks ran there too. I'd expect less than Pi 1 performance on the Pico, but I'd like to actually see it. 😋 Tangentially, comparing the Risc-V board to even earlier Pi models (1 and 2) is probably a more fair comparison.
At 49, I’ve watched as PA-RISC, MIPS, PPC, i860, AlphaAXP, SPARC, and other RISC architectures wither into irrelevance (along with MC680x0, IA64, and others). It’s neat that RISC-V is a largely open ISA and platform, but in a time when ISA’s are heavily decoupled from their micro-architectural implementations, and those implementation details represent the bulk of IP and institutional knowledge for major semiconductor companies, RISC-V simply doesn’t have anything close to the muscle backing the ARM and x86 ecosystems. Furthermore, working in the dev tools space, where I still have to fry my brain with assembler exposure, current-era ARM and x86 both have huge instruction sets; for example, ARM’s base instruction count is around 400, and the current full instruction set documentation is thousands of pages (in contrast the MC68000 was around ~ 80 instructions total and 6502 has 56).The ever expanding SIMD extensions on both ARM and x86 are truly headache inducing (and ARM is especially irritating because of the restaurant-menu approach to what might be in a given licensed core implementation). Someone’s going to have to make a pretty compelling RISC-V product for me to knuckle down and learn yet another ISA. Maybe I’m just a curmudgeon, but I just don’t see RISC-V expanding much beyond its current state. But it’d be kinda neat to be wrong on this (even if it melts my brain).
I actually just picked up a Mango PI Pro that is sporting a single core RISC V processor for about 30 bucks US. Right now many of the RISC V boards out there are priced over the RPI but they are damn close. I grabbed this board because it was very cheep and I wanted to mess around with RISC based CPU stuff.
It's good for us nerds to grab some of these low end boards and just see what we can do with them, find issues, hopefully find solutions, and get that information out there to the wider community. Things will improve, but it's up to us to make RISC-V popular enough with hobbyists so more devs find it worth their time. The high end market will be taken care of by industry, it seems that AI in particular is really embracing RISC-V. And RISC-V is becoming very popular in microcontrollers. There will be trickle down R&D from all of that. But getting RISC-V to dominate the SBC space seems like a really important goal long-term. We should really not want to be dependent on ARM licensing.
Not sure how much the 64 core cpu will cost, but I'd be interested in seeing it compared to a ppc64 system like the talos. Power is typically the ISA you go to if you want open source hardware and high performance and it'd be neat to see how risc v is catching up
I really hope this means they finally start shipping the mars. I ordered the normal mars and 6 duo's what feels like a eternity ago from arace and can't wait to dinally get the shipping notification.
Mostly for time nerds, but it's one use the CM4 has been very nice for. There are some other examples (like camera and embedded display setups) that are also better suited for a CM4 or a board with a more thoroughly supported MIPI interface.
The only logical business case I have come across for PTP is time tracking between clusters of systems that were processing financial transactions. The requirement was nanosecond time sync between about 80 systems. Its actually hard to implement between systems. You need to have complete support throughout your networking infra (which mostly only datacenter grade gear support and rarely out of the box) and often need to factor in cable lengths. The only use case I have seen @JeffGeerling use was for his LTX rig which was single system. Practically speaking its not useful because its just syncing to a directly attached stratum1. I think the useful part of @JeffGeerling comment in this video is that a commonly available kernel module isn't avaialbe for this system. I would assume its solely due to the network driver not supporting the correct time stamping. Again, because it expects you to be syncing over the network with slaves or being a master.
We're using RISC-V in a product we're launching soon, and unfortunately, I have to agree. RISC-V is great! We love it, we're using it specifically to support open-source, for right-to-repair. Not that it's more repairable per se, it's just an ideological thing. But, support all around kind of sucks. The number of things we're having to roll ourselves leaves *much* to be desired, before I can really see wide-spread adoption of RISC-V in devices. It will happen, just not yet.
Awesome video! I checked your Geekbench score submission in detail and compared it against the one you submitted for the Raspberry Pi 5 and it seems like a lot of performance is being lost in graphics related tasks. Even thought the overall single core score of the Pi 5 is 10x the overall single core score of the Mars CM certain tasks like Navigation are off by only 2x whereas others like background blur are off by 100x! Wonder how much of this is down to software optimization and how much of it is being held back by actual hardware capability.
A little bit of both; note that the graphics stuff is all rendering on CPU still, it's not hitting the Pi's GPU, so there could be some instructions better optimized for Arm, but it's not making the majority of the difference on Geekbench. YMMV though, all benchmarks are imperfect reflections of actual work :)
@@JeffGeerling yup -I'd assumed that everything in the bench is running on the CPU. As far as optimized instructions I believe SIMD stuff on Arm might be helping? Not sure if the Geekbench stuff uses the Neon instructions. If it does and this specific RISC-V chip does not have the vector extensions or ML stuff like matrix instructions (for tasks like image classification) it would be a strong hardware limit on the achievable performance. Super interested in seeing how this evolves over time. I'll also go lookup the full specs of the RISC-V cores in this to see what extensions are supported.
@@Xankill3r The tough thing is Geekbench's tests are a little vague in how they're represented technically (that's their proprietary mix), so there's no easy way to know what extensions they're using (especially as their suite gets updated). Thus I like to benchmark a bunch of other stuff too. The nice thing is Geekbench is easy, spits out a digestible number, and works on darn near everything without annoying compilation bugs.
RISC V is an open source ISA but anybody who designs a core or processor etc that reaches fab is going to be expecting to be paid for their IP. The cost per unit for ARM licensing is very small. I also expect RISC V to fork with different extensions.
The main benefit from ARM licensing is the mature and reliable test and verification system you get with that licensing. ARM have spent decades putting their system together and it makes verifying a design easy and fast for a licensee. RISC-V will never have that because it's open source nature means it will always remain fragmented and there will never be enough money in it for any company to produce such a verification process as an open standard.
The forking not so much. There is a huge cost to forking the ISA, and I just don't see anyone having enough to benefit from doing it to justify that cost. You're creating compiler support for it, you're maintaining that compiler support, if it's a general purpose instruction at all, you're operating the compiler farm for whatever Linux distributions you want to support, because otherwise nothing will run on your chip, or at least nothing will run that actually uses those spiffy new instructions. None of that is cheap.
Could you please do a video on "boot standards" for ARM platforms ? i mean... for x86 there is BIOS or UEFI. Any OS supporting one of them can be easily used on any BIOS/UEFI enabled hardware. how is that on ARM based hardware with all these "Cores" and versions on SOCs. Is there a Standard in place? Can one simply download ANY plain linux distro for "some arm" and install it to just any arm sbc with a USB / DVD Drive or something?
There is a standard (SystemReady), and some Arm systems do have UEFI, like the Ampere system I've done a few videos on (one just last week!). You can download Ubuntu, Debian, Windows, etc (Arm64 build) and run it, no proprietary overlays or specialty images required :)
I have an Odroid C1+. I tried various dietpis of recent build. It turns out only the (testing) Trixie release seems to have HDMI out. Other than that they all work but I have never got a video signal out of them. They just don't seem to have what they need in them.
I'd be interested in seeing the 64-core machine! (Hate to say I can already guess performance is probably underwhelming vs what one would expect with that many cores... Especially single-core performance is probably still kinda bad.) But anyway, it's still very exciting to see RISC-V start becoming more real. Every few months it feels like it makes a lot of inroads to shipping products, which is a pretty good validation IMO. It might not take over everything, but the embedded uses seem to have convinced some manufacturers already! And there's always room for more.)
Right now I see it used as a soft core processor in FPGA designs to allow portability between manufacturers. However, free RISC-V cores are not really that great, but paying a moderate amount can get you plenty of performance. It mostly needs a little more time to spin up and get going. What we need is an alternative to ARM for price competition and RISC-V is not there yet.
thanks for your review, benchmark. For me, it's too early to consider performance or watt consumtion. ARM is being developed strongly but it cannot beat x86. AMD might stronger Intel but it often has some software issue. My old AMD x6 1055T and Gigabyte mainboard can't work seamlessly with HDMI cable/monitor. I have to always choose resolution/orientation manually with the combo. For best user experience, I still choose Intel
This will be great as machine where speed is not necessary but functionality is, like monitoring a 3D print. I didn't noticed any HDMI or display out test in the video, doesn't it work with the provided OS?
I had trouble getting my monitor to display anything. Some people had better luck, so it may just have been my older HP monitor not being as compatible... not sure
Risc V remains mostly an attractive idea. It's possible it could be disruptive in the Christiansen sense - it appears to be taking a large share of the microcontroller market, and that's consistent with a technology thats disruptive. But it's early days yet. The Chinese govt is apparently a big backer, which makes sense, bc it means they can avoid dependence on ARM or Intel/AMD. Risc V seems just a little late to benefit from what seems to be x86 hitting its limit. There's a significant move towards ARM as a more efficient alternative, whether Apple or for servers or now by Qualcomm. I am mildly surprised that, eg Nvidia or some other big player hasn't yet put big money behind Risc V as a way of ensuring independence from ARM.
Well, Apple has hired RISC-V engineers. I wouldn't be surprised if they aren't already using small RISC-V controllers in their product lines already, or will very soon. Maybe not for their SoCs yet, but potentially down the line. Google apparently wants to move Android to RISC-V, or at least have that be an option. I think ARM showed the way, but RISC-V will be what capitalizes on the transition away from x86. RISC-V is also apparently seeing wide adoption in AI, and possibly automotive.
More of us nerds need to do this, share our findings and fixes, and build the community up. There is a lot of enthusiasm for RISC-V, but not as many people actually tinkering around with boards. I'm currently working on a ARM-based cluster project, but I've already decided that my next project will be something with RISC-V. There's some upcoming boards I'm keeping an eye on, that hopefully I can get and do something fun with. Haven't settled yet on exactly what the project will be, but I've got a few ideas.
@@fakecubed I've been desperately looking for an excuse to learn assembly for RISC machines, and I think RISC-V is finally my chance to dig into it, not knowing what my project is going to be either though is a challenge at effectively learning the language though lol. Good luck on your project! I hope it turns out well
@@junebug9320 Very cool. Learning assembly is definitely worthwhile. I had to learn MIPS in college, as a required course. It's important to understand things at a very low level. This can help you design and write better code at a higher level. Best of luck to you as well.
I'll be happy when these small SBCs start coming with multi GB ethernet ports standard. Everyone could use a low cost firewall. I include power in that equation.
PTP timestamping is such a weird specific to point out. Google had some explanations of what it is and how it can synchronize multiple devices to sub-microsecond precision, but not really anything in terms of practical examples. What hobby project would I need it for?
I would have loved to see that future talked about last year with the pi shortage where risc-v overtakes arm and even x86 systems. Seems like an important area of computing to focus on with how much runaway there is between the two areas.
It sounds like a big part of the problem is a lack of software that is optimized for the platform. Which is not surprising for a wholly new machine architecture, but it‘s the kind of thing that can get better over time. Maybe Jeff addressed that and I wasn‘t paying close enough attention (always a possibility), but atm it‘s not clear to me whether there are other more fundamental problems, not so easily rectified, that keep RISC-V out of the ballpark of other SBCs and CMs. (Not that updating gobs of software for a novel architecture is easy, but if there‘s also a weakness in the hardware that‘s keeping it back, gobs of better software won‘t make that go away.)
From what I can tell, it's all just software. Or at least, it is if we assume the manufacturers aren't cutting corners in the hardware, which some of the more sketchier companies might be doing. It's kind of a wild west right now. There's a handful of good development boards out now, and more are coming soon, and the software libraries will improve from there. There's lots of interest from developers in RISC-V, and the pace of development is frankly unprecedented. But it'll still be a while before all the gaps get closed in software, and for reputable manufacturers to get firmly established. But even just getting 80% of the way there solves a lot of real world problems for real customers, even if the remaining edge cases take years to resolve.
The Pioneer is quite interesting (I mention it right at the end)-I really would love to see more Arm chip designs between 32-64 cores, Ampere has a few Altra models like that but the chips are pretty massive and don't target efficiency at the low end, only all-out. There's no equivalent to the consumer X86 chips right now on the Arm side, outside of Apple and _maaaaybe_ Qualcomm, but I'll keep holding my breath for them to release their new chip.
RISC-V is interesting, but there are a few concerns I have regarding how performance competitive it can be (relative to 64-bit ARM). Namely: It lacks indexed load/store operations, only supporting constant displacement. Indexed load/store (Clarificatrion: register offset, or scaled-register index; ARM docs seemingly use "indexed" for auto-increment) is not exactly rare (typically the 2nd most common addressing mode, often around 30% of the total load/store operations), and needing to fake this using a multi-instruction sequence is a pretty big hit (it wouldn't be hard to add this as an extension, but many in RISC-V land seem opposed to this). I don't personally have much faith that "opcode fusion" can solve this issue in practice. Another (similar) issue is related to large constants, where, anything larger than 12 bits becomes a multi-instruction sequence, and anything larger than 32 bits is much worse (bad enough that one is better off falling back to using a memory load for 64-bit constants). This is also bad, but not such an easy fix. ADD: ARM64 allows loading constants 16 bits at a time, with a 4-op sequence able to load any arbitrary 64-bit constant (though, there are other possible ways to approach this). There are some other issues, but these are the major ones. Granted, the ISA wasn't really designed for performance, as far as I can see (was designed more to be easy to implement for EE students). But, it is an open ISA, which is still a big advantage versus ARM.
@@Hornet135 ARM is king if you ignore desktops and big servers, but ARM is taking over in servers, and Apple's doing their thing with computers, and most people do everything on ARM-based mobile devices now.
I dread seeing this channel in my recommended because I know I won't ever get ahold of whatever he is talking about. This product is not only in pre-order (despite him holding one), but the page is out of stock on all pre-orders. This channel is gradually becoming a good heuristic for products to ignore.
Sadly... it looks like they shipped their first batch already (it was in preorder when I ordered, but they shipped the final production unit to me. I bought it as anyone else could via ARACE, when I heard about it through CNX Software. It's more a sign of how hardware is, sadly when something gets any popularity these days it just goes out of stock until more are made. And I'm guessing this is a lower volume item, so I'm not sure how many Milk-V are making (or making available in Europe/NA).
I’d be interested in how the 64 core model performs. I have a test suite which doesn’t do much per test, but it has hundreds of tests which can run in parallel. It makes me wonder if a stack of 64 core risk-v SBC could give me a portable mini cluster to offload the testing to during development :)
I did, sorta-I went to 2-3 videos per month instead of 1-2 per week. I'm back on 1 per week at this point, but hope to get back to 1-2 per week once I finish the office buildout.
Progress speed of riscv is still much faster than competition. Its interesting that docs were not that good - I am very happy with milkv duo and find it totally capable of real embedded usage with niche market WITH good docs it came too. So was surprised docs were not good for you, but maybe you were much earlier to this than I were to milkv duo. Also don't underestimate being in stock with riscv is not just "oh currently there is stock" but in my experience chinese manufactured things like these are ALWAYS in stock while I totally have fear from raspberries... Last year I nearly had a project where I would need to buy like 50 zero boards and oh man.... I am so happy I did not sign the contract because a week later literally all zero boards went out of stock that I had access to and people were rushing to buy them like crazy. So yes.... CURRENTLY there is not so huge shortage of raspberries as it was before BUT! I saw there is can so easily happen!!! I do not want that. Already thinkikng about moving a project from pi zero to milkv duo for example because its not just cheaper and well documented, but totally is enough for my use case AND is always easy to buy in bulk if really needed.
I was thinking about the Pioneer right before you mentioned it, so yes. I'm really looking forward to seeing how they perform next month and have been for a while. I'm even tempted to get one myself, but it's really expensive for what would be a toy. The software is what makes or breaks all hardware. It's unfortunate a lot of SBC mfgs don't seem to realize that, especially the ones that won't open source their drivers. You either open them up or have to stay on top of updates religiously.
I want to be optimistic and I think RISC-V will win, for some definition of winning. As you say, it's already making waves in the microcontroller world, and with it being much more open I think we'll see more experimental or otherwise out-there tweaks on the design because it is cheaper for companies to gamble a little if they don't have to pay a licence fee. Whether it will win out entirely and we'll have RISC-V phones and computers any time soon, I don't know, and the patriotism I feel of ARM being a British company makes me hope they stick around, but I welcome RISC-V and I hope it finds a strong foothold.
I just bought a Milk V Duo board. It's a nice little linux board that is more similar to an MCU than an MPU . The web page and guides are way better than those of the Mars but yet they lack a lot of the fun stuff.
RISCV is definitely cool due to how open it is, but without wider industry support, it'll take a bit before it has a substantial base of software that runs on it. I for one am honestly fine with that. It's definitely a cool experience to explore a new architecture like this.
RISC - V is old. Never heard of PowePC? RISC stands for “Reduced Instruction Set Computing”, and it’s the base of multiple architectures such as PowerPC and ARM
Hi, your videos are very interesting. I hope you will show new devices in the future. Especially if you will make light pages in web and dark terminal less contrast. Good luck!
Performance is not an issue for many use cases (as long as it has a certain minimal performance). It definitely can replace RPi *for some*. But the incomplete and buggy toolchain is a very big issue. We need better Linux distro and board support to make a dent in the hobbyist market.
I love how far and fast RiscV is coming. As more tweakers get it and mature it's drivers/os offerings, and with companies in China looking to make stronger offerings, Arm doing so well and Intel wanting to trim x86 to 64 bit only and removal of other legacy code.... things will be interesting in the next ten years.
I'd like to take a moment here and appreciate how far this industry has come, that we can talk about a computer performing two _billion_ math operations per second and call it _slow._
Got to the moon with a calculator. Couldn't get there now if we wanted, too complicated. Go figure that one.
Or complain about data transfer speeds of 150 MB/s. I still remember spending an afternoon backing up the 5 MB hard drive on our first IBM PC to 360K floppies.
@@JustinEmlay It's easier than ever, if you got money. Apollo missions were glorified PR stunts to one up the USSR.
@@JustinEmlaynah its easy..they just didnt want to spend too much money on it..
@@JustinEmlay I don't think it's modern software that's holding back a return to the moon, the calculations really are quite basic, it's not magic. Money and rocket designs are a bigger issue.
I see RISC-V dominating the cheap (and maybe not so cheap) microcontroller space way, way before the compute space simply because the license fees are going to be a higher percentage with micros, and almost an afterthought for desktop class chips.
I can definitely see it eventually taking over in a big way on the low end. Where performance, and even power efficiency, are not that big of a deal, and you need something a touch more capable than a RP2040 from the Pico, but without the costs of an ARM license.
Hopefully it won't get stuck in that niche, and instead it can slowly grow into other spaces as it matures.
@@FieryPouncer Milk-V announced recently that in 9 months they are going to release Oasis computer with SG2380 SoC with 16 P670 + 8 x280 SiFive cores, although the latter ones should be mostly used as a NPU and not OS scheduling. Whole mobo costs around 100$ with pre-order coupon and in my opinion it's shockingly spectacular, now we as a community need to develop a nice software ecosystem not to let RISC-V die out
Afaik there is just one MCU with decent market share using a risc v architecture, ESP32 S3 I believe.
But I don't think RISC-V will break the ARM dominance in this space. Toolchain, Certification (especially safety) and experience is miles ahead and gets better every year for arm
@@pawe460 Google announced they are working hard to make RISC-V a first tier architecture for Android (next to ARM and X86).
And I'm even surprised how many things on Linux already work on RISC-V. I recently tested SimpleScreenRecorder on a VisionFive 2 RISC-V SBC, and I'm pretty sure the author never had RISC-V support in mind.
Then its prolly gonna work its way up tbh.
But for now its just gonna be micros and Raspberry pi-like stuff
For historical perspective, in 1985 the Cray-2 scored 1.95 Gflops on the LINPACK benchmark while using 150-200 kW
Damn, this industry made a lot of efforts in almost 40 years
The Cray at least had ECC memory and could be trusted with nuclear weapons design
@@shanent5793 You could run 3 of those and compare results instead. More reliable than ECC and still cheaper.
@@meneldal how do you do those comparisons? If it's over gigabit ethernet you'd be lucky to get a couple megaflops
@@shanent5793you compare the final results not every step. It's not like memory is likely to fail several times within a minute or so.
Maybe RISC-V isn't killing ARM just yet, but Jeff Geerling is killin it with his vids lately.
RISC-V needs #RedShirtJeff to optimize errant drivers.
😂😂😂😂😂
I'm still excited for Risc-V. Google announced Risc-5 "Android tools" coming 2024.
Anything but to trust google supporting risc v? Yeah sure, google is the one who destroyed android by making it less open source, nowadays android is such a joke os, it almost restricted as iOS. Android being open source is just a scam or pr stunts, not real open source.
It's exciting to see more and more RISC-V based SBC's being developed. As with most of these boards, the hardware looks promising but developers leave a lot of the software development to the community - which is just too small to make meaningful progress at the moment.
Yep :(
And nice job on that GPU Pi :D
One of these days we'll get a Pi to work with the GPU... and have it mounted in the cooling shroud!
@@JeffGeerling thanks! I'm looking forward to seeing a Pi working with a GPU!
More than just boards and hardware, software support is essential. There needs to be community and developer passion. It'll be hard to unseat raspberry pis with their primacy and established reputation. I used my rpi4 as a primary desktop computer for about two years before going back to x86 because the software support just wasn't there, yet.
If there is anything that RISC-V has in spades it's passion. ARM being shady and that the ISA is open (don't know if any open-source RISC-V cores have actually been fabbed yet), means that you have fanboys everywhere. There just needs to be enough boards put out there for the critical mass to start snowballing.
The Pi 5 is facing an uphill battle. If it really has only HEVC hardware decoding and no other decoders, that's not nice for a desktop experience.
On the other hand, we are still waiting for a proper driver from Imagination Technologies for the RISC-V SBCs. It looks like we can test Vulkan soon on the VisionFive 2 RISC-V SBC. Not sure when we get access to all the hardware video codecs.
Support will never be the same when it comes to commercial software on Linux. Imagine having to support your program on a couple different kernels, several different display servers and audio architectures, half a dozen desktop environments on dozens of distributions, often with 3-4 different release schedules to choose from, it's an absolute nightmare.
@@LivingLinuxUphill battle as it ages maybe, but right now the RPi 5 has a months long waitlist for backorders.
Linux devs are embracing RISC-V in a big way. As long as you can run Linux on it, it doesn't really matter what the ISA is. From there, if somebody's able to make a decent profit off of making chips for data centers or SBCs or whatever else, and the potential is definitely there since they don't have to license the ISA, you will see widespread industry and hobbyist adoption. Some big companies are embracing RISC-V for microcontrollers and AI stuff. Apple's been hiring RISC-V people either to work at Apple Silicon or possibly work on porting over their software on somebody else's dev boards. I think we'll see a transition period soon where there are comparable RISC-V and ARM SBCs being sold side-by-side from a number of companies, and then one or the other will eventually achieve dominance. RISC-V likely has the price advantage at the low end, which means we could see more expensive ARM SBCs and less expensive RISC-V SBCs for a while before companies just decide to switch over to RISC-V at the high end too, assuming the performance and efficiency can scale right. This is an area of technology where the low end drives the trajectory since eventually low end chips become good enough for a lot of tasks and most purchasers in the market are very price-conscious.
RISC-V is A LOT of fun. I am making my own cpu design with a logic simulator. Its a five stage pipeline, but i started reading about out of order execution and have some ideas about instruction queues. MMU and caching still seems like magic, but its not quite as arcane as I learn more.
Cool, wish you have luck! I’m making my own cpu too. At the moment, I will won’t use pipeline method.
For the actual model that I’m in development, my method is using positive trigger of the clock, to decode instructions and activate the control unit. Then negative trigger of clock is used to storage/complete.
In my next model, pipeline will be implemented for practice, improvements and get abilities.
I forget to tell you that my computer architecture is based on:
RISC, Princeton arch, SISD execution.
This is so cool and I really like how you document and engage the community around the SBC!
I had lots of problems getting my RISC-V starfive board running, I'm optimistic that RISC-V will close the gap by making use of already researched techniques from arm and others. Not sure when but probably in time. Playing catchup with notes is a little easier then trail blazing. Anyways would love to see the 64c monster you mentioned at the end of your video.
*easier than (comparative)
I don't know why. Download Image-55 (from December '22), burn it to an SD card, insert card, turn it on. That's all I had to do on mine. With more recent OS images you also need to flip one DIP switch of the pair (the one closest to the middle of the board) to the other position. That's again all. There were a couple of images released early this year where you had to do a complicated thing with also re-flashing the onboard eMMC, but either the original Image-55 or a recent one avoids that.
Hopefully the CM5 will release soon and be readily available.
I would looooooove it if they found a way to get CM5 to be same form factor. So much more fun to be had if I had a stable working PCIe Gen 3 lane...
@@JeffGeerlingconsidering that the old cm4 had 2 dsi and 2 CSI porta and the cm5 has only 2 hybrid ones it might mean that they have some pins free for the piece X1 bus
Totally would love to see your opinion on the milk v pioneer. Mainly I appreciate your honest and knowledgeable review of the current progress of all things risc v.
Yes pls!
I would love to see you get your hands on the 64 core RISC-V pioneer.
The initial core RISC-V hardware market target is cheap embedded along the border between microcontrollers and SOCs capable of an operating system. On the software side we just need a bit more well developed general purpose IDE and compiling for RISC-V, and get companies shifted over to using the open/third party dev kit rather than the old proprietary mindset. Pre Risc-V every chip maker had to make its own tool chain compatible with its own ISA leading to some rather janky barebones options. x86 was the main exception(mainly as a side effect of the 3 decade old Intel-AMD contract).
I am glad someone has good luck with the RiSC-V, I got a StarFive 2 and it came where I couldn't boot. I been trying to update the SPI, but no luck. I hoping one day I can use it. having good luck with the Banana-Pi CM4, and the Orange-Pi CM4, though it has more pins that RPi CM4.
Thanks Jeff, I never hear of Mars Board until this video. I have to check them out.
Did you set the dip switches correctly?
Just wanted to show my appreciation for the captions. Makes it so much more enjoyable and it doesn't go unnoticed
As someone who is part of the industry that is actively designing and building RISC-V processors, I do agree that RISC-V is a very young ISA and needs a ton of work and time from enthusiastic developers. They are offering tons of software suites (Android, GNU etc.) for devs to pick it up and develop tools and applications for RISC-V systems. I do disagree with RISC-V systems not being on par with equivalent ARM systems, not too sure about the board you got but the RV systems we build take on ARM's offerings in price, performance and power consumption. Although, I do see you point; it's not wide-spread yet but it's promising! Great video!
It will really depend on what markets get targeted. Eventually, all of them will be and I think RISC-V will be very competitive.
@@fakecubed truly, for now most RISC-V startups are focusing on low-power, embedded usecases. Baremetal stuff on RV makes a ton of sense at this stage. But I can see it getting into the Android space too eventually
@@suhaskv There's also the Ventana Veyron which aims to provide high performance data center compute. I think we'll see the big three cloud providers offering it before too long like how ARM recently started to be embraced in the cloud. It's apparently competitive with existing hardware using other ISAs, including performance per watt in V1, and V2 will be another leap in performance to hopefully match or better many near-future hardware offerings. The big three can afford to throw enough money to get their custom tech stacks working on it. If Ventana can keep things going like that, RISC-V could be a major player in the cloud.
Thanks man. This is really well packed, very useful info on risc-v and this product. Even years into it, your videos keep getting better.
Just like ARM isn't killing x86 (yet) - but Apple proved, it has the potential to do that. And when you look a bit deeper into the design of the RISC-V instruction set and it's philosophy, you can see that it has the potential to kill ARM in the future, as its design is more sound, just like the design of ARM is way more sound than the design of x86 . Some people are not happy with certain trade-offs that were made but you always have to do trade-offs, there is no ISA that doesn't have any trade-offs. I studied pretty much all CPU architectures in the past and just based on that I made predictions like PPC not having any real future, since its architecture seemed flawed to me, so when PPC struggled with 64 bit CPUs and Apple finally gave up on it, that didn't came to me as a surprise at all. What did came as surprise to me was the Xbox360 switching to PPC but I guess that was the last time we saw PPC for the mass market. I also wasn't that surprised when Apple went all ARM, yet I didn't expect them to have the guts to truly pull that off, as it once again set off their machines completely from the Windows PC market (and I'm still sad to have lost VirtualBox support on Mac). But not only has RISC-V the potential to reach ARM performance, it has the potential to reach it at lower power consumption. And once again it's Apple, who hired a lot of RISC-V experts in the recent past. I wouldn't be too surprised, if one day Apple announces that the Apple Watch now has a RISC-V CPU and this will give that architecture a huge leap forward, as they have the money and man power to push that ISA quickly forward, to the point where it could actually compete with ARM at least in the low range sector. And the big advantage for Apple would be: No more license costs for their own RISC-V CPUs and also no license restrictions whatsoever.
You've got me curious, now. What were the flaws in PPC that you saw?
I do agree with you that Apple is probably going to end up switching to RISC-V down the line. They will probably (and maybe already have been) start with small RISC-V based chips on their boards controlling batteries and the like, and just not tell people. So much of Apple's hardware is a black box anyway. They could work their way up from there to watches, phones, etc.
@@fakecubedPosting a detailed analysis of the PPC architecture in a UA-cam comment would probably go to far and UA-cam does not like external links (each time I post a link, no matter what link, no matter what destination, other than UA-cam itself, my comment vanishes within a few minutes).
But in a nutshell: PPC basically tried to make everything different than existing architectures of that time and that's rarely ever a good approach, since the only reason to make everything different is when everything sucked but that's never the case. Architectures may have flaws but they are not 100% flawed, as then they would be useless. If you change everything about cars, you end up with a sailboat, which is not a useless product but it is useless if your goal was to design a better car. A GPU is also a useful piece of electronics but it's no replacement for a CPU and incapable of running standard software; at least it could never do so efficiently (of course, you could emulate an entire general purpose CPU within shaders, that would work but would also be very slow).
The instruction set of PPC is not designed for normal computer tasks. It's a bit like IA64 (Itanium), which I saw for the very first time and immediately thought "How will a normal, modern UI application ever be able to fully utilize that instruction format or somehow even benefit from it?" I cannot explain that in detail here, but just look at some numbers:
ARM has 19 different instruction formats (actually just 18, one is just a special case of all the other ones), PPC has 15 different base formats, with almost each of them have 2 to 4 sub-formats, sometimes 7, yet one has 35 sub-formats. Sure, x86 has more, but x86 is a CISC instruction format, not RISC. The ARM instructions are dense and a single one can combine a condition, a math operation and a logic operation, all in 32 bits; so very common source code constructs will result in a single ARM instruction. On PPC you need 3-6 instructions to achieve the same outcome, again, each 32 bits. RISC-V has only 4 base formats, with 2 extra ones that are just variants of two already in the base set. It's less densely packed than ARM when it comes to function but more densely when it comes to working with data (e.g. intermediates) and RISC-V allows for way more instructions in total, so it doesn't have to stay RISC all the way, it can do things like adding a single instructions that performs a complex operation that would otherwise require plenty of instructions if that should ever be required or vastly beneficial.
Also while x86 and ARM both offer 3 different kinds of memory barriers, PPC only has one. This makes it easy to "not pick the wrong one" but it also means that a lot more synchronization must take place than would strictly be necessary, which is an issue if go multi core and want to keep increasing the number of cores. RISC-V has two and both reserve bitfields for future use to make them even more fine grained, if required to increase scalability. There are other things that make it way harder to scale PPC and x86 core-wise than it is for ARM or will be for RISC-V. And even if you can scale the number of cores, there is always the question how often will one core slow down another core which is also ISA dependent, as that prevents a huge number of cores from reaching their full potential. For decades speeding up CPUs mainly meant increasing the clock rate but that isn't the case anymore for over a decade. Today adding more cores is often way simpler to do and here ARM performs really well, as it is very simple to add more cores without requiring a super complex or ultra-fast inter-CPU bus system, that is almost as complex as a CPU itself or is very power consuming. Just compare the CPU bus of x86 server CPUs (with plenty of cores) to the one of x86 consumer CPUs (with way less cores) and you will see what I mean by "complex bus system". And being super relaxed at the memory model surely helps PPC, just as it helps ARM and RISC-V, yet you cannot always be relaxed, you need fences, atomic operations and explicit ordering and here I see PPC struggling more than other RISC architectures; well, Alpha would have performed even worse, but that's a different story. And don't get me wrong, every architecture allows scaling the number of cores, this was just about how much effort that is, how costly it is, how much it will add to power consumption, etc.
Regarding power measurements: Using a kill a watt is nice from a practical standpoint for effective power consumption.
But that includes the losses of the power supply and the efficiency of the power supply might not be linear.
For performance measurements I would probably try using a bench power supply which also shows the wattage directly if you get a nicer one.
For USB get an USB tester like the fnirsi fnb42.
Thanks for all you do and sharing everything in an organized way, allowing people to contribute.
It makes it so much easier since we all would have to solve the same problems getting something to run.
Also gives confidence the features like pcie in this example really work.
Thank you so much
Jeff Geerling has transcended the roles of maker, hobbyist and enthusiast, and has become an authoratative voice for those communiries that the manufacturers and software developers trust and respect. It's an impressive achievement, and all the more so because he seems to be such a decent, thoughtful and likeable guy.
Love your content bro, keep it up! When I saw you had to resize the disk, that hit me hard because I'm studying for my RHCSA in the next few days, and have been drilling away at automount, network storage, and disk resizing like crazy. Last thing I'm working on are containers; Damn you and your long command!
Great video Jeff, and you pointed out that the support just isn't there. Pumping out new RISC boards is neat, but without support, or a solid community, they're going to stay niche. Watching the Raspberry Pi community grow was impressive, but took some time. Hopefully RISC can get the same love.
The community is pretty solid and continuing to grow. There's a lot of enthusiasm for this technology among both industry and hobbyists. In the hobby space it's just very niche and will take a while for the hardcore nerds to provide enough feedback to companies and work out the bugs. From there, we'll get more chips and more SBCs. Major industry partners will adopt it more and more. A few companies will emerge as RISC-V leaders. And then we'll see. I can imagine a company like Apple eventually switching to RISC-V somewhere down the line just to avoid paying for ARM. They've already hired RISC-V specialists, and I'm sure Apple's looking at their nine-figure ARM licensing bill wondering if they might be able to save some of that money. That won't be in five years, but maybe 10 or 15. RISC-V so far is on a much accelerated timeline compared to ARM. We're already seeing it pop up in all sorts of special applications like AI.
0:00: 📦 Mars CM은 Raspberry Pi Compute Module 4의 대체 옵션으로 작은 컴퓨터로, 4K 지원, 블루투스, Wi-Fi, 기가비트 이더넷과 같은 기능을 제공합니다.
1:54: 📦 설정 중 문제
3:55: 🔧 PCIe 인터페이스는 작동하지만 프로세서의 성능으로 인해 제한되며 초당 150에서 250 메가바이트의 속도를 달성
5:52: 📊 Mars CM은 현대 ARM 프로세서와 비교하여 효율성이 낮습니다.
7:46: 🔍 Pine64 SoQuartz는 Raspberry Pi Compute Module 4의 잠재적인 대안이지만 특정 기능과 호환성이 부족합니다.
Great video Jeff. Man I remember reading about RISC-V and how its going to take over in high school. Its been a long time especially in the tech world, and it still far behind the competitors.
It may yet, but on the timescale of decades. Arm has been around for years and years, but really only started taking off when mobile became the dominant form of personal computing.
X86 has been around since the 70's and ARM, 1985.. super fast processor designs with full software support don't appear overnight.
I really want to give MilkV the benefit of the doubt that they aren't just pushing out products without testing or finalizing development and hoping the community will do exactly what you did and do all that work for free, but I've seen too many Chinese companies in the tech space pull this.
I think that it IS really good that MilkV is pushing its products out early. So that we can play with them test them and as long as MilkV takes the feedback then the community benefits which will help lift RiscV up. Jeff seemed to be having fun. And we got a cool video as a result.
@@jamesboulton2722 True but it sucks that Jeff ended up with a product that didn't even have a quick start guide up for it yet
Not just Chinese companies. They all put out products prematurely. But that's not always a bad thing, as the other comment here says.
@@jamesboulton2722 I agree, but I've seen it where someone who wants a RPi equivalent for a project and isn't super-in-depth will likely hit a skill/patience gap getting something like this to work. Granted, until this video, this product would likely have been unknown to those exact users, so it's kinda a chicken-egg problem. As long as those promoting the products do what Jeff did here and lay out the process to get it "functional" then I think it's not a bad idea to crowd source bleeding edge products. But I've seen consumer-grade products in big-box stores that get abandoned by developers and so anyone buying them are left with either a mountain of technical work to get it to a base working state or trying to return an open electronic to a retailer who likely doesn't care they're selling dead goods.
I'd sooner support western companies, so I'll stick with the Raspberry Pi products. We've lost enough tech companies as it is.
Thanx for the video, very informative and yes the RISC-V architecture is not mainstream yet, but we need more choice in this sector. In my country everything is expensive, so cheaper alternatives are a plus. I only managed to purchase a RPi4 this year after losing out in 2020 with the Coolermaster case kickstarter mess. Yes, the Pi community is great, but RISC-V will get there. Just look at how far the Rock chip boards have come!
RISC V won't kill ARM just like ARM won't kill x86. The only reason x86 killed MIPS, DEC Alpha, 68K and PowerPC is because it was tied to an industry standard open hardware and software platform which allowed for greater flexibility and low cost through economies of scale. Neither RISC V or ARM have such a standard. At least not yet. That said, I think it's important to have a CPU architecture which is freely available to anyone just like open source software.
This doesn’t have to be a zero sum game. The more options for low power, low cost computing the better. The more we can do to encourage this and future generations of SBCs the better. SBCs like this feel our last refuge in the on going war on general computing.
It took ARM 20+ years to get an out of order design. RISCV did that years ago. From OoO to competing with x86 has been 15 years if we count X4 as competitive. RISCV is on track to do that in just 4-5 years which is literally the bare minimum to design a new microarchitecture.
While there’s overhypers out there, is also true that we will have high performance chips in the next couple years.
The main problem is uprooting comparability. ARM filled a needed niche, and by all accounts an "empty" niche. The reason why we won't see x86 fall is due to the last 30yrs of development and the largest amount of focus. Arm has done that for its niche in the mobile phone market and even in the Microcontroller market.
Though I would agree in the super small Microcontroller (like remotes), it could have a place due to the lower costs ($0.001 off is a lot for something that costs $0.01 in bulk order) and the lack of legacy need.
I'm afraid you're one of the overhypers. You try to hold it against Arm that it took over 20 years to see an OoO chip, but that's actually just because the first two decades of Arm were the 1980s and the 1990s. In the 80s literally nobody was selling single-chip OoO microprocessors. That began to be a thing in the 90s, but it was far too expensive for a tiny company like Arm.
Next, we have to talk about actual ages of the Arm and RISC-V ISAs. RISC-V derives a lot of things from older RISC ISAs, and modern Arm is technically only about 10 years old (counting from first commercial chip). You see, the 64-bit Arm ISA was a complete do-over. You can design dual-mode 32/64-bit Arm cores, but the Arm chips making waves right now (such as Apple's A and M series, and Qualcomm's new Oryon) are 64-bit only. The first commercially available 64-bit Arm was Apple's A7, which shipped in the fall 2013 iPhone refresh. (It was OoO, by the way, so 64-bit Arm went from zero to OoO in one step. Doesn't really mean anything, but you seem to think it's important.)
The big problem for anyone who wants to believe RISC-V will inevitably overtake Arm64 is that Arm64 is a very well designed ISA and RISC-V is not. None of the mistakes in RISC-V's design are fatal, they just make it harder to create high performance RISC-V chips, and possibly may result in extra power and/or die area.
It is almost as if multiple people can work on an open standard and take it farther because of that
Very interesting, Jeff! Appreciate your honest reviews and all of the other cool stuff you do!
I work at Renesas, we have tried the RISCV route on a couple of products. In the end for a similar core, RISCV is more expensive than ARM. In addition, there is next to zero interest in the market for RISCV. Maybe one day customer will become more interested!
Like many new tech things, I think it's partly chicken-and-egg. As more devices come, slowly more software will be ported, and more people will be willing to dip the toes in the water.
But that won't mean much on SBCs at least, until there are more competitive RISC-V cores on the market.
thank you for your work, it's true that we often forget that there's more than just arm, x86/x64 architectures.
don't forget that risc-v architectures are often architectures with specific bricks, often used for video encoding, mathematical calculation, they are less modular than ARM.
i'd like to know what the 64 bits are worth, i'd like to set up a setup to do benchmarks.
Fantastic video. In 10 mins from zero knowledge about RISC-V , now i have some basic understanding, the current state of it, i know how does it compare to current ARM based solutions and I know that while it may be not there yet, it is a promising technology.
Partition resizing is a lot more common in the VMWare world - I've done that enough that it's normal but I still have a cheat sheet for doing it.
It's like the ln command, or tar... you do it a thousand times but you still have to look back because it's just not intuitive (at least not to my brain!).
@@JeffGeerling If you are referring to the order of arguments, think ln as cp and imagine you are copying a file. That helped me to finally remember it.
cp original.txt copy.txt
ln -s original.txt fake_copy_hahaha.txt
I saw this online too! It is very cool!
FYI, 14 is probably just the designation of the person on the assembly line that did QC control on that board.
Well then good job, number 14!
No problem with the repetitions.
Yes, I read the captions.
Good job, Jeff! Exactly what I was looking for.
Thanks for your time and effort. Great video!
As expected, the software side still has a long way to go.
In the old day, there are Alpha, Power, RISC, MIPS, i960....
Now, the IBM z16 is powered by Samsung 7nm...
Thank you for your honest review 😊
it's pretty early for risc-v to start getting a piece of the SBC market, it still needs manufacturers support and funds for R&D and software. but it is making a small but steady step in the microcontroller market with a few fairly nice little boards.
There's a few good boards already, and in the next couple years there's going to be a lot more on the market. They may not be the absolute best, but nerdy folks will buy them to tinker around with, and that will fuel more R&D budgets and more boards. The idea of RISC-V has excitement attached to it that ARM can't hope to match, for the types of people who like to buy these boards. At the same time, the AI market is embracing RISC-V, and lots of big companies are buying in for all sorts of embedded apps. Lots of real world uneasiness is also driving interest in RISC-V (or rather, driving people away from ARM) at those big companies that want to hedge their bets.
Thanks Jeff, totally agree with you, even ARM still not take over the x86 market so RISC-V is just the beginning, also the complex (for novice) to use really not ready for the average Joe.
Great video, love the prospect of these risc v boards
Oh God, those issues just simply getting output from the device are the most frustrating for me. Thanks Jeff for adding some forum resources.
I was surprised to find a RISC-V microcontroller in a WiFi LED controller I disassembled recently. Pretty cool to see!
RISC-V is rapidly taking over in those sorts of microcontroller applications.
Considering SiFive purged 20% of it's engineering staff last week, things might be slowing rather than speeding up.
Qualcomm also laid off a lot of people. So did Intel this year. Looks like bad times are coming for the chips industry in general.
@@LivingLinux Economy in general?
Diversity hires purged
Yeah, been a rough year... though the past few years were also a bit insane with hiring rates and funny money.
Even with the road ahead of us, I am so excited to live in a time that I can purchase RISC-V hardware that's in the desktop realm of things. I got my Star64 the other day, I'd love to see the people at Pine64 make a compute module of it.
I have the Turing Pi 2 with several CM4 carrier boards so this will be a cool thing to try it on. RISC-V still have some ways to go before it reaches critical mass but it's getting there.
What CM4 board have you tested that worked with Turing Pi 2 apart from. RPI CM4? I can't seem to find any general info of other brands working on it apart from RK1, Nvidia's.
resize2fs is actually a really chill tool. Works on mounted partitions and can automatically fill the unused space.
Love the Video you are 1/2 correct on the Licening on the RISC-V. RISC-V is Opensouce and there are no Roaylties. It's important to note that while the RISC-V ISA is open, the actual processor implementations (e.g., CPU cores) developed by companies may have their own licensing I am sure you knew that but it came off that RISC-V is pretty much the same as ARM that that isn't correct at all. People would rather pay someone for their design than doing their own.
You forgot to mention the RISC-V annual membership and certification fees, without which you can't sell a RISC-V device.
@@AndrewRoberts11 Very true. Also, a note that not all RISC-V designs will work 100% with each other. The one thing ARM does have is that it has to be compatible to some level. RISC-V has a future, but it's still a long way off.
@@AndrewRoberts11 You probably can, but you won't be able to call it RISC-V. Similar things happened with MIPS, meaning that there is an implementation called XBurst which is practically identical to certain MIPS architecture versions. The company responsible later licensed the relevant MIPS technologies, meaning that later products can advertise MIPS compatibility, although they do still use XBurst in their promotional materials. One practical consequence was that they appear to have adopted the official MIPS vector extensions alongside the ones they had devised themselves.
Well ~ I am looking forward Qualcomm RISC-V. Your testing SoC is MiC. I tested their VisionFive 2 single board computer ... it is more OS support ad optimization !!! Loooooooong way to go ~
I would love to see you put that 64-core RISC-V Milk-V pioneer through its paces. I know it wont beat anything reasonable right now but I just want to see how far RISC-V has come at the top end.
While I realize the PI Pico isn't a fair comparison (a fraction of the RAM/Storage, can't run full-fat Linux), it does make me wish one of the benchmarks ran there too. I'd expect less than Pi 1 performance on the Pico, but I'd like to actually see it. 😋
Tangentially, comparing the Risc-V board to even earlier Pi models (1 and 2) is probably a more fair comparison.
This is happening fast! I’d bet five years from now, these boards are going to be mature and competitive.
At 49, I’ve watched as PA-RISC, MIPS, PPC, i860, AlphaAXP, SPARC, and other RISC architectures wither into irrelevance (along with MC680x0, IA64, and others). It’s neat that RISC-V is a largely open ISA and platform, but in a time when ISA’s are heavily decoupled from their micro-architectural implementations, and those implementation details represent the bulk of IP and institutional knowledge for major semiconductor companies, RISC-V simply doesn’t have anything close to the muscle backing the ARM and x86 ecosystems.
Furthermore, working in the dev tools space, where I still have to fry my brain with assembler exposure, current-era ARM and x86 both have huge instruction sets; for example, ARM’s base instruction count is around 400, and the current full instruction set documentation is thousands of pages (in contrast the MC68000 was around ~ 80 instructions total and 6502 has 56).The ever expanding SIMD extensions on both ARM and x86 are truly headache inducing (and ARM is especially irritating because of the restaurant-menu approach to what might be in a given licensed core implementation). Someone’s going to have to make a pretty compelling RISC-V product for me to knuckle down and learn yet another ISA.
Maybe I’m just a curmudgeon, but I just don’t see RISC-V expanding much beyond its current state. But it’d be kinda neat to be wrong on this (even if it melts my brain).
Thanks for the great stuff. Just reading your interview in the latest issue of HackSpace magazine. Keep up the work.
No..., THANK YOU for making the caption😊😊😊
Risc-V is finally getting the love it deserves
I actually just picked up a Mango PI Pro that is sporting a single core RISC V processor for about 30 bucks US. Right now many of the RISC V boards out there are priced over the RPI but they are damn close. I grabbed this board because it was very cheep and I wanted to mess around with RISC based CPU stuff.
It's good for us nerds to grab some of these low end boards and just see what we can do with them, find issues, hopefully find solutions, and get that information out there to the wider community. Things will improve, but it's up to us to make RISC-V popular enough with hobbyists so more devs find it worth their time. The high end market will be taken care of by industry, it seems that AI in particular is really embracing RISC-V. And RISC-V is becoming very popular in microcontrollers. There will be trickle down R&D from all of that. But getting RISC-V to dominate the SBC space seems like a really important goal long-term. We should really not want to be dependent on ARM licensing.
Not sure how much the 64 core cpu will cost, but I'd be interested in seeing it compared to a ppc64 system like the talos. Power is typically the ISA you go to if you want open source hardware and high performance and it'd be neat to see how risc v is catching up
I would love to see a review of the monster. Great video, as usual.
You know you finally got good content to enjoy when Jeff drops a video
I really hope this means they finally start shipping the mars. I ordered the normal mars and 6 duo's what feels like a eternity ago from arace and can't wait to dinally get the shipping notification.
Hopefully! I haven't heard from many others with boards yet.
*an eternity (because "eternity" starts with a vowel sound)
*finally
Just wondering: what is the importance of PTP timestamping?
For time applications
Mostly for time nerds, but it's one use the CM4 has been very nice for. There are some other examples (like camera and embedded display setups) that are also better suited for a CM4 or a board with a more thoroughly supported MIPI interface.
The only logical business case I have come across for PTP is time tracking between clusters of systems that were processing financial transactions. The requirement was nanosecond time sync between about 80 systems. Its actually hard to implement between systems. You need to have complete support throughout your networking infra (which mostly only datacenter grade gear support and rarely out of the box) and often need to factor in cable lengths. The only use case I have seen @JeffGeerling use was for his LTX rig which was single system. Practically speaking its not useful because its just syncing to a directly attached stratum1. I think the useful part of @JeffGeerling comment in this video is that a commonly available kernel module isn't avaialbe for this system. I would assume its solely due to the network driver not supporting the correct time stamping. Again, because it expects you to be syncing over the network with slaves or being a master.
@@JeffGeerling "Time nerds" I love it.
We're using RISC-V in a product we're launching soon, and unfortunately, I have to agree. RISC-V is great! We love it, we're using it specifically to support open-source, for right-to-repair. Not that it's more repairable per se, it's just an ideological thing. But, support all around kind of sucks. The number of things we're having to roll ourselves leaves *much* to be desired, before I can really see wide-spread adoption of RISC-V in devices. It will happen, just not yet.
Awesome video! I checked your Geekbench score submission in detail and compared it against the one you submitted for the Raspberry Pi 5 and it seems like a lot of performance is being lost in graphics related tasks. Even thought the overall single core score of the Pi 5 is 10x the overall single core score of the Mars CM certain tasks like Navigation are off by only 2x whereas others like background blur are off by 100x! Wonder how much of this is down to software optimization and how much of it is being held back by actual hardware capability.
A little bit of both; note that the graphics stuff is all rendering on CPU still, it's not hitting the Pi's GPU, so there could be some instructions better optimized for Arm, but it's not making the majority of the difference on Geekbench.
YMMV though, all benchmarks are imperfect reflections of actual work :)
@@JeffGeerling yup -I'd assumed that everything in the bench is running on the CPU. As far as optimized instructions I believe SIMD stuff on Arm might be helping? Not sure if the Geekbench stuff uses the Neon instructions. If it does and this specific RISC-V chip does not have the vector extensions or ML stuff like matrix instructions (for tasks like image classification) it would be a strong hardware limit on the achievable performance. Super interested in seeing how this evolves over time. I'll also go lookup the full specs of the RISC-V cores in this to see what extensions are supported.
@@Xankill3r The tough thing is Geekbench's tests are a little vague in how they're represented technically (that's their proprietary mix), so there's no easy way to know what extensions they're using (especially as their suite gets updated).
Thus I like to benchmark a bunch of other stuff too. The nice thing is Geekbench is easy, spits out a digestible number, and works on darn near everything without annoying compilation bugs.
RISC V is an open source ISA but anybody who designs a core or processor etc that reaches fab is going to be expecting to be paid for their IP. The cost per unit for ARM licensing is very small.
I also expect RISC V to fork with different extensions.
The main benefit from ARM licensing is the mature and reliable test and verification system you get with that licensing. ARM have spent decades putting their system together and it makes verifying a design easy and fast for a licensee. RISC-V will never have that because it's open source nature means it will always remain fragmented and there will never be enough money in it for any company to produce such a verification process as an open standard.
The forking not so much. There is a huge cost to forking the ISA, and I just don't see anyone having enough to benefit from doing it to justify that cost.
You're creating compiler support for it, you're maintaining that compiler support, if it's a general purpose instruction at all, you're operating the compiler farm for whatever Linux distributions you want to support, because otherwise nothing will run on your chip, or at least nothing will run that actually uses those spiffy new instructions.
None of that is cheap.
@@FieryPouncer extensions for dedicated purposes intended to give a competitive advantage.
The guy who left the sticker on the board: "Ahhh SH!T!"
Could you please do a video on "boot standards" for ARM platforms ? i mean... for x86 there is BIOS or UEFI. Any OS supporting one of them can be easily used on any BIOS/UEFI enabled hardware. how is that on ARM based hardware with all these "Cores" and versions on SOCs. Is there a Standard in place? Can one simply download ANY plain linux distro for "some arm" and install it to just any arm sbc with a USB / DVD Drive or something?
There is a standard (SystemReady), and some Arm systems do have UEFI, like the Ampere system I've done a few videos on (one just last week!).
You can download Ubuntu, Debian, Windows, etc (Arm64 build) and run it, no proprietary overlays or specialty images required :)
Yes please, I would love to see the other „Monster„!
I have an Odroid C1+. I tried various dietpis of recent build. It turns out only the (testing) Trixie release seems to have HDMI out. Other than that they all work but I have never got a video signal out of them. They just don't seem to have what they need in them.
I'd be interested in seeing the 64-core machine!
(Hate to say I can already guess performance is probably underwhelming vs what one would expect with that many cores... Especially single-core performance is probably still kinda bad.)
But anyway, it's still very exciting to see RISC-V start becoming more real. Every few months it feels like it makes a lot of inroads to shipping products, which is a pretty good validation IMO. It might not take over everything, but the embedded uses seem to have convinced some manufacturers already! And there's always room for more.)
Right now I see it used as a soft core processor in FPGA designs to allow portability between manufacturers. However, free RISC-V cores are not really that great, but paying a moderate amount can get you plenty of performance. It mostly needs a little more time to spin up and get going. What we need is an alternative to ARM for price competition and RISC-V is not there yet.
good！身为一个中国人，能够在海外视频平台上看到带有中文的产品，我很自豪，感谢你的视频。very good！
thanks for your review, benchmark. For me, it's too early to consider performance or watt consumtion. ARM is being developed strongly but it cannot beat x86. AMD might stronger Intel but it often has some software issue. My old AMD x6 1055T and Gigabyte mainboard can't work seamlessly with HDMI cable/monitor. I have to always choose resolution/orientation manually with the combo. For best user experience, I still choose Intel
This will be great as machine where speed is not necessary but functionality is, like monitoring a 3D print. I didn't noticed any HDMI or display out test in the video, doesn't it work with the provided OS?
I had trouble getting my monitor to display anything. Some people had better luck, so it may just have been my older HP monitor not being as compatible... not sure
Looks like a cool alternative to the CM4. With a little more work this will be a viable machine. 👍
Risc V remains mostly an attractive idea. It's possible it could be disruptive in the Christiansen sense - it appears to be taking a large share of the microcontroller market, and that's consistent with a technology thats disruptive. But it's early days yet.
The Chinese govt is apparently a big backer, which makes sense, bc it means they can avoid dependence on ARM or Intel/AMD.
Risc V seems just a little late to benefit from what seems to be x86 hitting its limit. There's a significant move towards ARM as a more efficient alternative, whether Apple or for servers or now by Qualcomm.
I am mildly surprised that, eg Nvidia or some other big player hasn't yet put big money behind Risc V as a way of ensuring independence from ARM.
Well, Apple has hired RISC-V engineers. I wouldn't be surprised if they aren't already using small RISC-V controllers in their product lines already, or will very soon. Maybe not for their SoCs yet, but potentially down the line. Google apparently wants to move Android to RISC-V, or at least have that be an option. I think ARM showed the way, but RISC-V will be what capitalizes on the transition away from x86. RISC-V is also apparently seeing wide adoption in AI, and possibly automotive.
great vid. I've learned that I want this... not to be productive or build things that work, but rather to get my hands in the gorey guts of some sbcs
This is the way!
More of us nerds need to do this, share our findings and fixes, and build the community up. There is a lot of enthusiasm for RISC-V, but not as many people actually tinkering around with boards. I'm currently working on a ARM-based cluster project, but I've already decided that my next project will be something with RISC-V. There's some upcoming boards I'm keeping an eye on, that hopefully I can get and do something fun with. Haven't settled yet on exactly what the project will be, but I've got a few ideas.
@@fakecubed I've been desperately looking for an excuse to learn assembly for RISC machines, and I think RISC-V is finally my chance to dig into it, not knowing what my project is going to be either though is a challenge at effectively learning the language though lol.
Good luck on your project! I hope it turns out well
@@junebug9320 Very cool. Learning assembly is definitely worthwhile. I had to learn MIPS in college, as a required course. It's important to understand things at a very low level. This can help you design and write better code at a higher level. Best of luck to you as well.
Great insightful video! New subscriber!
I would Definitely recommend checking that 64 core risc v machine
I'll be happy when these small SBCs start coming with multi GB ethernet ports standard. Everyone could use a low cost firewall. I include power in that equation.
Amen!
PTP timestamping is such a weird specific to point out. Google had some explanations of what it is and how it can synchronize multiple devices to sub-microsecond precision, but not really anything in terms of practical examples. What hobby project would I need it for?
I would have loved to see that future talked about last year with the pi shortage where risc-v overtakes arm and even x86 systems. Seems like an important area of computing to focus on with how much runaway there is between the two areas.
It sounds like a big part of the problem is a lack of software that is optimized for the platform. Which is not surprising for a wholly new machine architecture, but it‘s the kind of thing that can get better over time. Maybe Jeff addressed that and I wasn‘t paying close enough attention (always a possibility), but atm it‘s not clear to me whether there are other more fundamental problems, not so easily rectified, that keep RISC-V out of the ballpark of other SBCs and CMs. (Not that updating gobs of software for a novel architecture is easy, but if there‘s also a weakness in the hardware that‘s keeping it back, gobs of better software won‘t make that go away.)
From what I can tell, it's all just software. Or at least, it is if we assume the manufacturers aren't cutting corners in the hardware, which some of the more sketchier companies might be doing. It's kind of a wild west right now. There's a handful of good development boards out now, and more are coming soon, and the software libraries will improve from there. There's lots of interest from developers in RISC-V, and the pace of development is frankly unprecedented. But it'll still be a while before all the gaps get closed in software, and for reputable manufacturers to get firmly established. But even just getting 80% of the way there solves a lot of real world problems for real customers, even if the remaining edge cases take years to resolve.
We'll see what kind of answer ARM has against the MILK-V Pioneer (64-core RISC-V desktop). Expected at the end of this year.
The Pioneer is quite interesting (I mention it right at the end)-I really would love to see more Arm chip designs between 32-64 cores, Ampere has a few Altra models like that but the chips are pretty massive and don't target efficiency at the low end, only all-out.
There's no equivalent to the consumer X86 chips right now on the Arm side, outside of Apple and _maaaaybe_ Qualcomm, but I'll keep holding my breath for them to release their new chip.
Hello. :)
RISC-V is interesting, but there are a few concerns I have regarding how performance competitive it can be (relative to 64-bit ARM).
Namely:
It lacks indexed load/store operations, only supporting constant displacement. Indexed load/store (Clarificatrion: register offset, or scaled-register index; ARM docs seemingly use "indexed" for auto-increment) is not exactly rare (typically the 2nd most common addressing mode, often around 30% of the total load/store operations), and needing to fake this using a multi-instruction sequence is a pretty big hit (it wouldn't be hard to add this as an extension, but many in RISC-V land seem opposed to this). I don't personally have much faith that "opcode fusion" can solve this issue in practice.
Another (similar) issue is related to large constants, where, anything larger than 12 bits becomes a multi-instruction sequence, and anything larger than 32 bits is much worse (bad enough that one is better off falling back to using a memory load for 64-bit constants). This is also bad, but not such an easy fix. ADD: ARM64 allows loading constants 16 bits at a time, with a 4-op sequence able to load any arbitrary 64-bit constant (though, there are other possible ways to approach this).
There are some other issues, but these are the major ones.
Granted, the ISA wasn't really designed for performance, as far as I can see (was designed more to be easy to implement for EE students).
But, it is an open ISA, which is still a big advantage versus ARM.
This guy assembles.
What a time to be alive when ARM is king and new technology like RISC-V is on the come up!
ARM isn’t king yet, though.
@@Hornet135 ARM is king if you ignore desktops and big servers, but ARM is taking over in servers, and Apple's doing their thing with computers, and most people do everything on ARM-based mobile devices now.
I dread seeing this channel in my recommended because I know I won't ever get ahold of whatever he is talking about. This product is not only in pre-order (despite him holding one), but the page is out of stock on all pre-orders. This channel is gradually becoming a good heuristic for products to ignore.
Sadly... it looks like they shipped their first batch already (it was in preorder when I ordered, but they shipped the final production unit to me. I bought it as anyone else could via ARACE, when I heard about it through CNX Software.
It's more a sign of how hardware is, sadly when something gets any popularity these days it just goes out of stock until more are made. And I'm guessing this is a lower volume item, so I'm not sure how many Milk-V are making (or making available in Europe/NA).
I’d be interested in how the 64 core model performs.
I have a test suite which doesn’t do much per test, but it has hundreds of tests which can run in parallel. It makes me wonder if a stack of 64 core risk-v SBC could give me a portable mini cluster to offload the testing to during development :)
아직 나에게는 조금 어려운 부분이지만 라즈베리파이의 경쟁 제품이 나왔다는거는 소비자로서 반가운 소식이군요!
I remember when you said you needed to take a break form UA-cam. I am glad you didn't, just don't burn yourself out Jeff! :)
I did, sorta-I went to 2-3 videos per month instead of 1-2 per week. I'm back on 1 per week at this point, but hope to get back to 1-2 per week once I finish the office buildout.
Progress speed of riscv is still much faster than competition. Its interesting that docs were not that good - I am very happy with milkv duo and find it totally capable of real embedded usage with niche market WITH good docs it came too. So was surprised docs were not good for you, but maybe you were much earlier to this than I were to milkv duo.
Also don't underestimate being in stock with riscv is not just "oh currently there is stock" but in my experience chinese manufactured things like these are ALWAYS in stock while I totally have fear from raspberries... Last year I nearly had a project where I would need to buy like 50 zero boards and oh man.... I am so happy I did not sign the contract because a week later literally all zero boards went out of stock that I had access to and people were rushing to buy them like crazy.
So yes.... CURRENTLY there is not so huge shortage of raspberries as it was before BUT! I saw there is can so easily happen!!! I do not want that. Already thinkikng about moving a project from pi zero to milkv duo for example because its not just cheaper and well documented, but totally is enough for my use case AND is always easy to buy in bulk if really needed.
I was thinking about the Pioneer right before you mentioned it, so yes. I'm really looking forward to seeing how they perform next month and have been for a while. I'm even tempted to get one myself, but it's really expensive for what would be a toy. The software is what makes or breaks all hardware. It's unfortunate a lot of SBC mfgs don't seem to realize that, especially the ones that won't open source their drivers. You either open them up or have to stay on top of updates religiously.
I want to be optimistic and I think RISC-V will win, for some definition of winning. As you say, it's already making waves in the microcontroller world, and with it being much more open I think we'll see more experimental or otherwise out-there tweaks on the design because it is cheaper for companies to gamble a little if they don't have to pay a licence fee. Whether it will win out entirely and we'll have RISC-V phones and computers any time soon, I don't know, and the patriotism I feel of ARM being a British company makes me hope they stick around, but I welcome RISC-V and I hope it finds a strong foothold.
I just bought a Milk V Duo board. It's a nice little linux board that is more similar to an MCU than an MPU . The web page and guides are way better than those of the Mars but yet they lack a lot of the fun stuff.
RISCV is definitely cool due to how open it is, but without wider industry support, it'll take a bit before it has a substantial base of software that runs on it. I for one am honestly fine with that. It's definitely a cool experience to explore a new architecture like this.
RISC - V is old. Never heard of PowePC? RISC stands for “Reduced Instruction Set Computing”, and it’s the base of multiple architectures such as PowerPC and ARM
RISC is a strange thing: it has reduced instructions
Hi, your videos are very interesting. I hope you will show new devices in the future. Especially if you will make light pages in web and dark terminal less contrast. Good luck!
Performance is not an issue for many use cases (as long as it has a certain minimal performance). It definitely can replace RPi *for some*. But the incomplete and buggy toolchain is a very big issue. We need better Linux distro and board support to make a dent in the hobbyist market.
I love how far and fast RiscV is coming. As more tweakers get it and mature it's drivers/os offerings, and with companies in China looking to make stronger offerings, Arm doing so well and Intel wanting to trim x86 to 64 bit only and removal of other legacy code.... things will be interesting in the next ten years.