▲ 3 points
back
7 comments
Amazing video and exactly what I needed.
I was looking for a RV64 USB-C(device) board for my future keyboard controller with my 100% RV64 assembly coded firmware.
This board is completely overkill for this project, but I really wanted to code my firmware using RV64 and not RV32 even though the ISA has provision for RV32/RV64 interop.
Really, REALLY great news.
Look at the Pine64 Ox64 too. $6 or $8 depending on how much flash (4 MB or 16 MB), but always 64 MB of RAM, and three RISC-V cores, two 32 bit and one 64 bit with FPU, MMU, and Vector 0.7.1 (same C906 core as the MQ-Pro, but running at 480 MHz not 1 GHz)
Already did: the RV64 core is actually "on-the-side", and actual programming is done with the RV32.
I'm not sure what you mean by "on the side". All cores have equal access to the RAM, flash, and peripherals.
The 32 bit E907 is hart 0 and runs the initial boot code, but once it sets an initial execution address for the C906 (hart 1), turns on its clock, and resets it you can run code on just the C906, or on both, or whatever you want. Both cores have full access to everything.
This is not what I was told on IRC: the C906 would have some sort of indirect hardware access: the C906 would not be be able to setup properly some parts of the SOC. Because if it boots from the E907, I would just put the code to start the C906 and stop the E907, and that's it, namely forget about the E907.
What would be nice is some "excrutiating minimal" boot code sample for the E907 in an easy to get SDK (noscript/basic (x)html browser friendly). Then some C906 code which properly init the USB hardware(device and not host, there is probably some DMA hardware somewhere), timer, GPIOs, interrupts (if I recall properly, this was one of the issues), etc.
I just got back from a couple of weeks vacation and found two ox64 (and some CH32V003 boards too) waiting for me. Investigating and publishing exactly such a minimal code guide is high on my list, especially using the C906 and RVV 0.7.1. In asm, not Rust :-) (no 'fence to Daniel who does great work)
Well, I am more than interested in your piece of work.
If your are able to use the SOC hardware services (USB(device)/dma, timer interrupts, GPIOs,etc) with the C906 without convolution (aka without E907 involvment which would be shutdown as I said in my previous post), I really want to know.
Is there a place I can check for that?
RISC-V, if successful, is the signal of the start of the "assembly era" (probably with high level interpreters written in assembly, like python/lua/javascript/ruby/gnagna). In this era, we will have to fight SDK complexity, like the abuse of complex macro languages. Personnaly, I currently write x86_64 assembly with a "very cheap" SDK (this is EXTREMELY important): I conservatively use a C preprocessor (currently the one from tinycc) to define an "intel like" syntax which allows me to assemble simple "intel like" syntax source files with fasmg or/and nasm/yasm or/and binutils as. I still use binutils ld though, but I keep in mind I may move away from it so I try to reduce my usage of its comfy complexity as much as I can in a point in time (the real issue is actually ELF...).