@Rayman said:
I noticed this RISCV fpga project that uses a bootloader to let it work with the Arduino IDE: http://www.nxlab.fer.hr/fpgarduino/
Out of curiosity, would that be possible with this?
The riscvp2 compiler approach could work with any RISC-V toolchain, including the one you linked to. Getting the Arduino IDE to work with it is a bigger problem: you'd need to write an Arduino-compatible loader for the P2, and port a bunch of libraries. In theory it should all be quite do-able, but someone would have to spend some time to do it.
The most obvious requirement to run the Linux kernel is XMM mode. The kernel and initrd uses 2.9MB, far larger than the P2's 512kB hub memory. A less obvious requirement but perhaps even more important is interrupts. I haven't really thought about the details of that yet. I still think that XMM for riscvp2 might be a useful project.
Linux kernel load/store operation count
Load Store
This is based on the instructions found in a disassembly of the kernel binary and may not match actual runtime operation.
The JIT compiler won't be doing instruction reads and data operations on the external memory at the same time. The JIT engine maintains a cache of the compiled instruction in hub ram or the LUT. The instruction fetching of the raw riscv instructions would still benefit from a simple prefetch scheme. The next long requested is almost always the next one in memory. Most of the data read/write operations appear to be saving and restoring registers on the stack. Quite annoyingly the stack operations run in descending order. I don't think psram has a reverse burst mode. Neither does the P2 hub. Eric is well aware of this and put a lot of effort into the OPTIMIZE_SETQ_RDLONG feature. I think this could be reworked to combine operations into a single psram burst for stack operations. Writing a simple cache controller to speed up the stack operations shouldn't be too hard.
Have you tried ucLinux (a bit old by now, but most likely MUCH easier to get up an running). And another nice looking small unix variant: fuzix, which seems much more promising to get running.
I started looking into fuzix, when work started to slow down, but that lasted only for a week (my main curse since 2020, working 10+ hours as I'm WFH in Europe and projects are all in Asia. not really feeling to do anything after work hours)
Having a code-only XMM mode for riscvp2 (that is, execute in place out of flash, or something similar) would be straightforward -- we'd just fill the instruction cache from the external memory. Storing data in external memory would be quite a bit more effort, and significantly complicate memory accesses.
I wonder if a better approach might be to port a smaller Unix that Linux. The original Unix ran on a PDP-11 with less memory than a P2, IIRC, so something like https://github.com/robertlipe/riscv7 might not require any external memory at all.
Comments
It worked for me on Windows (under Cygwin). Thank you again for YAAT (yet another amazing tool).
I may have to try this out too.
Seems like it might be the only way to get complex C++ programs to run on P2 at the moment.
Great! Thanks for the feedback, I'm glad you were able to get it working.
Regards,
Eric
I noticed this RISCV fpga project that uses a bootloader to let it work with the Arduino IDE:
http://www.nxlab.fer.hr/fpgarduino/
Out of curiosity, would that be possible with this?
The riscvp2 compiler approach could work with any RISC-V toolchain, including the one you linked to. Getting the Arduino IDE to work with it is a bigger problem: you'd need to write an Arduino-compatible loader for the P2, and port a bunch of libraries. In theory it should all be quite do-able, but someone would have to spend some time to do it.
The most obvious requirement to run the Linux kernel is XMM mode. The kernel and initrd uses 2.9MB, far larger than the P2's 512kB hub memory. A less obvious requirement but perhaps even more important is interrupts. I haven't really thought about the details of that yet. I still think that XMM for riscvp2 might be a useful project.
Linux kernel load/store operation count
Load Store
int8 2604 1764
int16 869 413
int32 74265 54634
int32(sp) 34141 34403
This is based on the instructions found in a disassembly of the kernel binary and may not match actual runtime operation.
The JIT compiler won't be doing instruction reads and data operations on the external memory at the same time. The JIT engine maintains a cache of the compiled instruction in hub ram or the LUT. The instruction fetching of the raw riscv instructions would still benefit from a simple prefetch scheme. The next long requested is almost always the next one in memory. Most of the data read/write operations appear to be saving and restoring registers on the stack. Quite annoyingly the stack operations run in descending order. I don't think psram has a reverse burst mode. Neither does the P2 hub. Eric is well aware of this and put a lot of effort into the OPTIMIZE_SETQ_RDLONG feature. I think this could be reworked to combine operations into a single psram burst for stack operations. Writing a simple cache controller to speed up the stack operations shouldn't be too hard.
Have you tried ucLinux (a bit old by now, but most likely MUCH easier to get up an running). And another nice looking small unix variant: fuzix, which seems much more promising to get running.
(my main curse since 2020, working 10+ hours as I'm WFH in Europe and projects are all in Asia. not really feeling to do anything after work hours)
I started looking into fuzix, when work started to slow down, but that lasted only for a week
Having a code-only XMM mode for riscvp2 (that is, execute in place out of flash, or something similar) would be straightforward -- we'd just fill the instruction cache from the external memory. Storing data in external memory would be quite a bit more effort, and significantly complicate memory accesses.
I wonder if a better approach might be to port a smaller Unix that Linux. The original Unix ran on a PDP-11 with less memory than a P2, IIRC, so something like https://github.com/robertlipe/riscv7 might not require any external memory at all.