3 ms·

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 boo

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.

sylware 4y ago
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.
- brucehoult 4y ago
  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)
  - sylware 4y ago
    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...).

sylware 4y ago

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.

brucehoult 4y ago
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)
- sylware 4y ago
  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...).