On 10.07.2016 12:59, Reinoud Zandijk wrote: Hi Reinoud, I read the proposal and try to associate it with what is going on for RISC-V run-control debugging. Did you consider Tim's debug ROM proposal as part of your proposal? Unfortuantely, I have a few problems putting stuff together in my head. Do you by chance have some figures that can be used as reference? Cheers, Stefan

Hi Stefan, thanks for reading my proposal. Its still draft of course! On Sun, Jul 10, 2016 at 06:20:05PM +0200, Stefan Wallentowitz wrote: I didn't read Tims debug ROM proposal prior to this since the v5 of the proposal started at the RISC-V conference at CERN. Reading it now, there is some overlap but also some structural differences. Both proposals allow a CPU to be externally investigated but Tims idea significantly extends a core IMHO without allowing fast context switching. Tims proposal even demands a (possibly shared?) piece of ROM placed in the global address space and a piece of RAM per processor. Both could of course only be visible when in debug mode of course but still, this has address space issues. Running code on a halted CPU is asking for potential side effects even though its in flat-memory in debug mode. I haven't found (yet) if it can take exceptions and how it deals with it; is it just returning 0 then? As for JTAG support, I'm not that into the spec, so I take that for granted :) So in short, I think I agree more with Adreas Trabers critique in separating the debugged core entirely and not adding yet-another mode. Adding that might sprinkle quite some extra logic around where as some minor extra logic and MUX around the register banks would suffice. Corner cases in my design are cases like single step debugging or tracing a userland program in an OS or the case when debugging with just one Application CPU available need to be adressed but are not that complex, but could be considered part of the hypervisor Minions exporting a debug device for the domain. I'll try to create some diagrams to clarify the various parts; if possible in ASCII art :) but maybe a SVG might be more suited, we'll see. Does this answer your questions a bit? All the best, Reinoud

Hi Alex! On Wed, Jul 20, 2016 at 11:47:35AM +0100, Alex Bradbury wrote: Traditional hypervisor context switching or Tims debug ROM needs code to run on the actual CPU itself; that I try to avoid all together since this will always hinge on assumptions of behaviour and does have security issue too. The actual speed of switching depends of course on how much help the hypervisor Minion gets with bits that indicate what registers are dirty or if there is even a lazy load possible. In the worst case scenario it shouldn't matter much in speed. Well between domains that are normally OSes yes but could also be an encryption device or some other `soft' hardware like an emulated or multiplexed display or whatever that runs outside the OS. I haven't dug into the PLIC design yet enough to answer this in detail. From memory, the PLIC would then be hypervisor Minion only since each OS/domain would otherwise need to have its own emulated PLIC since they are not aware of other users. My current proposal allows up to (at least) 64 interrupt levels. Each OS/domain can place a device at the level it wants them and ignore lower ones by using the masking. Some hardware support might be handy though to ensure that the CPUs with the lowest interrupt level takes the hit but otherwise the masks will allow for each CPU to have a interrupt level. Interrupt routing and handling is of course not trivial and is still kind of a work in progress. It would be good if it would be possible to tweak the mechanism on a finished SoC. If some mechanism indeed turns out to be preferable and some hardware support is handy, the interface won't change; only the code of the hypervisor Minion needs tweaking to cater for the extra hardware support. I agree that code reuse is a good thing but at what cost? We're trying to design something that will last for a long time with multiple generations right? Things change a lot in say 10 or 20 years. Entire devices families come and go, CPUs architectures and busses even come and go. Nothing is as volatile as code, configuration methods, boot methods like LILO, grub, grub2, uBoot, multiboot, PXE etc. Most of the current code base for devices of say Linux or one of the BSDs hasn't been around for that long. Its extended every day and at times rototilled even. A quick bring up is more dependent on ease of programming by a good design and good specs than on using `standard' chips inside. Lots of ARM SoCs for example have a kind of `standard' USB controller; but there are dozens of variations of it that are JUST that bit different, just that connected different, with just that few power and codec setup differences that makes it doesn't work. Thats bringing up a port so difficult and time consuming. Sure, I'd love to. It shouldn't be that hard in Spike; provided that I can create subclasses for say Application CPUs and Minion CPUs. I could also just emulate everything outside the Application CPUs, with some timed delays even ;) Talking about gcc, Spike and Chissel, are they now OK to build and run on a 32 bit platform? How is the state of LLVM? Can it finally compile stuff on its own now i.e. be used without dependencies on gcc tools or libraries? All the best, Reinoud