RISC-V

94 Articles

256-Core RISC-V Megacluster

May 7, 2024 by 16 Comments

Supercomputers are always an impressive sight to behold, but also completely unobtainable for the ordinary person. But what if that wasn’t the case? [bitluni] shows us how it’s done with his 256-core RISC-V megacluster.

While the CH32V family of microcontrollers it’s based on aren’t nearly as powerful as what you’d traditionally find in a supercomputer, [bitluni] does use them to demonstrate a property of supercomputers: many, many cores doing the same task in parallel.

To recap our previous coverage, a single “supercluster” is made from 16 CH32V003 microcontrollers connected to each other with an 8-bit bus, with an LED on each and the remaining pins to an I/O expander. The megacluster is in turn made from 16 of these superclusters, which are put in pairs on 8 “blades” with a CH32V203 per square as a bridge between the supercluster and the main 8-bit bus of the megacluster, controlled by one last CH32V203.

[bitluni] goes into detail about designing PCBs that break KiCad, managing an overcrowded bus with 16 participants, culminating in a mesmerizing showcase of blinking LEDs showing that RC oscillators aren’t all that accurate.

Continue reading “256-Core RISC-V Megacluster” →

Google Removes RISC-V Support From Android

May 3, 2024 by 20 Comments

Last year the introduction of  RISC-V support to the Android-specific, Linux-derived Android Common Kernel (ACK) made it seem that before long Android devices might be using SoCs based around the RISC-V ISA, but it would seem that these hopes are now dashed. As reported by Android Authority, with a series of recently accepted patches this RISC-V support was stripped again from the ACK. While this doesn’t mean that Android cannot be made to work on RISC-V, any company interested would have to do all of the heavy lifting themselves, which might include Qualcomm with their recently announced RISC-V-based smartwatch Snapdragon SoC.

No reason was provided by Google for this change, and the official statement from Google to Android Authority says that Google is not ready to provide a single supported Android Generic Kernel Image (GKI), but that ‘Android will continue to support RISC-V’. This change however, removes RISC-V kernel support from the ACK, and since Google only certifies Android builds which ship with a GKI featuring an ACK, this effectively means that RISC-V is not supported at this point, and likely won’t be for the foreseeable future.

As discussed on Hacker News, a potential reason might be the very fragmentary nature of the RISC-V ISA, which makes a standard RISC-V kernel very complicated if you want to support more than a (barebones) profile. This is also supported by a RISC-V mailing list thread, where ‘expensive maintenance’ is mentioned for why Google doesn’t want to support RISC-V.

Chip Mystery: The Case Of The Purloined Pin

April 25, 2024 by 29 Comments

Let’s face it — electronics are hard. Difficult concepts, tiny parts, inscrutable datasheets, and a hundred other factors make it easy to screw up in new and exciting ways. Sometimes the Magic Smoke is released, but more often things just don’t work even though they absolutely should, and no amount of banging your head on the bench seems to change things.

It’s at times like this that one questions their sanity, as [Gili Yankovitch] probably did when he discovered that not all CH32V003s are created equal. In an attempt to recreate the Linux-on-a-microcontroller project, [Gili] decided to go with the A4M6 variant of the dirt-cheap RISC-V microcontroller. This variant lives in a SOP16 package, which makes soldering a bit easier than either of the 20-pin versions, which come in either QFN or TSSOP packages.

Wisely checking the datasheet before proceeding, [Gili] was surprised and alarmed that the clock line for the SPI interface didn’t appear to be bonded out to a pin. Not believing his eyes, he turned to the ultimate source of truth and knowledge, where pretty much everyone came to the same conclusion: the vendor done screwed up.

Now, is this a bug, or is this a feature? Opinions will vary, of course. We assume that the company will claim it’s intentional to provide only two of the three pins needed to support a critical interface, while every end user who gets tripped up by this will certainly consider it a mistake. But forewarned is forearmed, as they say, and hats off to [Gili] for taking one for the team and letting the community know.

Espressif’s ESP32-P4 Application Processor: Details Begin To Emerge

April 2, 2024 by 55 Comments

Every now and then there’s a part that comes along which is hotly anticipated, but which understandably its manufacturer remains tight-lipped about in order to preserve maximum impact surrounding its launch. Right now that’s Espressif’s ESP32-P4: a powerful application processor with dual-core 400 MHz and a single-core low power 40 MHz RISC-V processors. Interestingly it doesn’t appear to have the radios which have been a feature of previous ESP parts, but it makes up for those with a much more comprehensive array of peripherals.

Some details are beginning to emerge, whether from leaks or in preparation for launch, including the first signs of support in their JTAG tool, and a glimpse in a video from another Chinese company of a development board. We got our hopes up a little when we saw the P4 appearing in some Espressif documentation, but on closer examination there’s nothing there yet about the interesting new peripherals.

Looking at the dev board and the video we can see some of what the thing is capable of as it drives a large touchscreen and a camera. There are two MIPI DSI/CSI ports on  the PCB, as well as three USB ports and a sound codec. A more run-of-the-mill ESP32-C3 is present we think to provide wireless networking, and there’s a fourth USB port which we are fairly certain is in fact only for serial communications via a what our best blurry photograph reading tells us is a Silicon Labs USB-to-serial chip. Finally there’s large Raspberry Pi-style header which appears to carry all the GPIOs and other pins. We’ve placed the video below the break, if you see anything we’ve missed please tell us in the comments.

We first covered this chip back in January, and then as now we’re looking forward to seeing what our community does with it.

Continue reading “Espressif’s ESP32-P4 Application Processor: Details Begin To Emerge” →

Why X86 Needs To Die

March 21, 2024 by 207 Comments

As I’m sure many of you know, x86 architecture has been around for quite some time. It has its roots in Intel’s early 8086 processor, the first in the family. Indeed, even the original 8086 inherits a small amount of architectural structure from Intel’s 8-bit predecessors, dating all the way back to the 8008. But the 8086 evolved into the 186, 286, 386, 486, and then they got names: Pentium would have been the 586.

Along the way, new instructions were added, but the core of the x86 instruction set was retained. And a lot of effort was spent making the same instructions faster and faster. This has become so extreme that, even though the 8086 and modern Xeon processors can both run a common subset of code, the two CPUs architecturally look about as far apart as they possibly could.

So here we are today, with even the highest-end x86 CPUs still supporting the archaic 8086 real mode, where the CPU can address memory directly, without any redirection. Having this level of backwards compatibility can cause problems, especially with respect to multitasking and memory protection, but it was a feature of previous chips, so it’s a feature of current x86 designs. And there’s more!

I think it’s time to put a lot of the legacy of the 8086 to rest, and let the modern processors run free. Continue reading “Why X86 Needs To Die” →

a CH32V003 Linux-bearing PCB, single-sided, hand-etched, lovely

Bring Linux To CH32V003 Through, Yes, RISC-V Emulation

March 3, 2024 by 14 Comments

Like playing around with Linux on low-power devices? You’d be hard pressed to find a better example than the [tvlad1234]’s linux-ch32v003 project. It’s not just a one-off — it’s something you could build right now, since it requires hardly any extra parts.

With help of a 8 MB PSRAM chip for RAM supplementation purposes and an SD card, plus some careful tailoring of the Linux .config parameters, you get Linux on a chip never meant to even come close to handling this much power. The five minutes it takes to boot up to a prompt is part of the experience.

As usual with [tvlad1234]’s projects, there’s a fun twist to it! Running Linux on this chip is only possible thanks to [chlohr]’s mini-rv32ima project, which, as you might remember, is a RISC-V emulator. Yes, this runs Linux by running a RISC-V emulator on a RISC-V chip. The main reason for that is because the MCU can’t map the PSRAM chip into RAM, but if you use an emulator, memory mapping is only a matter of software. Having applied a fair amount of elbow grease, [tvlad1234] brings us buildroot and mainline Linux kernel configs you can compile to play with this — as well as a single-layer-ready KiCad board project on GitHub. Yep, you could literally etch a PCB for this project from single-sided copper-clad FR4 with a bit of FeCl3.

While the CH32V003 is undoubtedly a more impressive target for Linux, the RP2040 Linux project might be more approachable in terms of having most of the parts in your parts box. At least, up until we start valuing the CH32V003 for all the cool stuff it can do!

Compute The Mandelbrot Set With A Custom RISC-V CPU

January 17, 2024 by 9 Comments

When faced with an FPGA, some people might use it to visualize the Mandelbrot set. Others might use it to make CPUs. But what happens if you combine the two? [Michael Kohn] shows us what happens with his RISC-V CPU with an instruction specially made for computing the Mandelbrot set.

[Michael] takes us through the unusual process of turning his 8008 into a RISC-V CPU. Re-using bits of logic here and replacing other logic there leaves him with a functional RISC-V core. Not finished, [Michael] takes it upon himself to also create a custom instruction just for computing a point for the Mandelbrot set, accelerating the demo from twenty-three seconds to merely one!

Still not finished, [Michael] also creates an implementation of the long gone F100-L CPU, once again with added Mandelbrot set flair, simultaneously with the RISC-V project. Finally, he ports his “Java Grinder” Java bytecode compiler to both RISC-V and the F100-L, because Java runs on 1 Billion devicesTM.

Continue reading “Compute The Mandelbrot Set With A Custom RISC-V CPU” →