How Genode came to RISC-V | Hacker News Reader

How Genode came to RISC-V

genode.org

54 pointscarey19 comments

Wow, this is really great.

Here at Berkeley Architecture Research and our spin-off company SiFive, we are working on finalizing version 1.9 of the privileged ISA, which includes a lot of useful features for operating system implementers. This includes a standardized way of performing memory-mapped IO, debug port, and possibility of standalone boot.

I say push as hard as possible to get actual boards out there. It's not going anywhere if nobody can use them. My suggestion is a clone of something like Pi that preferrably is compatible with its addon boards and such. Drop in replacement.

The lowRISC team at Cambridge are working on exactly that. However, there's a lot that needs to be finalized in the privileged ISA before it can be implemented in a board. Manufacturing a bunch of boards that require a non-standard toolchain wouldn't be very useful.

That being said, you can already use a RISC-V processor by programming the RTL onto an FPGA board. The Zedboard and ZC706 are both officially supported. Though both of these boards are pretty expensive.

I more or less agree with both of your sentiments. I also suspect that if you can get anywhere near the tinkerer's market first, it becomes that much more likely that you can get another foothold, and that much more likely that the next thing to draw further interest will come from somewhere you can take advantage of.

That's exactly my point. The tinkerers are buying ARM systems to learn. So, if they learn ASM or ecosystems, it's going to be ARM's. They'll contribute back to ARM's, as well. Same with various microcontroller CPU's from 8-bit sector. So, needs to be something to work with for RISC-V just to get people scratching an itch coding up stuff for it.

> The lowRISC team at Cambridge are working on exactly that.

When (roughly estimated) can we expect the first actual boards?

> The Zedboard and ZC706 are both officially supported. Though both of these boards are pretty expensive.

How long will these boards be supported in later versions of Risc-V / ISA? It makes no sense to purchase an expensive board unless it can be used for a long time in upcoming RTL versions.

It's great to see free and open hardware finally arriving.

I've known of RISC-V for a while, and just learned of IBM's efforts to open up their Power Architecture: https://en.wikipedia.org/wiki/OpenPOWER_Foundation

Does anyone know of any other free and open processor architectures? I hope we'll see a GPU one soon.

VERY unlikely you'll see an open GPU - they're all too worried about lawsuits because so much of their architectures are the same.

Sparc is also open and has been for quite some time.

That in of itself isn't true.

If you make GPUs like NVidia, AMD, and Intel do, you may be sued.

However, nothing stops you from just spamming extremely simple cores attached to a standardized bus architecture that talks to a singular extremely wide and fast memory controller.

Largely, this is slowly what GPUs are turning into.

Like this?

http://hwacha.org/

Yeah, that's a lot like what I'm thinking, or at least, they're going in the right direction.

RISC-V based GPUs (think: Xeon Phi / Knights Landing) is the current vogue for research in RISC-V space. A good chunk of the talks at the last RISC-V workshop were on this topic.

Nyuzi open GPU focused on GPGPU programming: https://github.com/jbush001/NyuziProcessor

J Core is the opened version of SuperH, and thus already has good OS and compiler support: http://0pf.org/j-core.html

J Core is perhaps the main ‘competitor’ to RISC-V: they're both fully open, unencumbered, well-designed architectures suitable for both embedded devices and full systems.

Their comment about the address space identifier field in the MMU setup is absolutely golden. We need to get more practical experience using the architecture to help inform the design from other perspectives.

I don't really understand how it could be that problematic. It would only be an issue if there was a memory access in between the time the ptbr changes and the asid changes. But the instructions for manipulating CSRs don't access memory. If you had the instructions for changing these two registers one after another, there should be no intervening memory access. This might be broken if the CPU takes an interrupt, but interrupts are generally disabled during the context switch routine.

In principle, the two instructions could cross a page boundary. Its a narrow corner case, but it is there.

Oh yeah. Didn't think of that. Actually, just crossing a cache block boundary might be enough to trigger bad behavior.

I wonder what will be the performance for manupilating big numbers with RISC V (cryptography) for example, the performance will likely be very low..

Very informative! Thanks for sharing.

Reply on news.ycombinator.com