@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.
@ersmith Finally got around to trying this...
The instructions are pretty good and I downloaded the Windows release.
Added the bin folder to the path and tried this:
@Rayman said:
Other PC still slow after reboot. Very strange.
Wondering if WSL2 is interfering somehow or something...
Try turning off real-time protection in Windows "Virus and Threat Protection" settings. It slows down gcc dramatically. One might begin to think it was deliberate!
I turn it off whenever I have to recompile Catalina.
@RossH said:
Try turning off real-time protection in Windows "Virus and Threat Protection" settings. It slows down gcc dramatically. One might begin to think it was deliberate!
So true. I use MinGW to compile my CNC software. We had to go back to an old release because all programs compiled with the latest version frequently trigger virus warnings on customer's PCs. And it's not just a warning at installation time you could simply ignore and click away. Some windows versions are so aggressive that they delete our executable without asking the user!
@ersmith Think I'm seeing that in order to compile a .c file, it has to be in a subfolder inside the riscvp2 folder, is this right?
Trying now with Ubuntu... Added the "bin" folder to the path, but that's it...
It complains about not being able to find cc1 otherwise...
@ersmith The custom assembly for rdpin() doesn't seem to work... Getting illegal instruction messages. I think it must work somehow though.
What am I doing wrong here?
I'm actually amazed that this thing still works after all this time . Congratulations on getting it going.
@Rayman said:
@ersmith Think I'm seeing that in order to compile a .c file, it has to be in a subfolder inside the riscvp2 folder, is this right?
Trying now with Ubuntu... Added the "bin" folder to the path, but that's it...
It complains about not being able to find cc1 otherwise...
I think it's enough to make sure the gcc program is in the PATH environment variable. I haven't really tried it much on Windows though, so I may be misremembering.
@ersmith The custom assembly for rdpin() doesn't seem to work... Getting illegal instruction messages. I think it must work somehow though.
What am I doing wrong here?
What message are you getting? It compiles OK for me on Linux. I'm afraid I don't have a Windows setup right now to test on.
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.
@ersmith Finally got around to trying this...
The instructions are pretty good and I downloaded the Windows release.
Added the bin folder to the path and tried this:
E:\Parallax\Prop2\RiscV\riscvp2-master\riscvp2-master>riscv-none-embed-gcc -T riscvp2.ld -Os -o hello.elf hello.c
It seems like it's doing something, but still no output after 5 minutes.
Assuming that means something is broke?
Looks like it worked eventually.
Was able to load the P2 with the .elf and have terminal output and blinking LEDs on Eval board.
Funny that it's so slow on Windows; on Linux, at least, it runs quickly (like, a second or so). Is your Windows machine low on memory?
@ersmith Don't think so. Good to know it's fast on Linux though. ~10 min. to compile hello world is not viable...
Tried it on another PC and it was instantaneous....
Very strange... Think need to reboot the other one....
Other PC still slow after reboot. Very strange.
Wondering if WSL2 is interfering somehow or something...
Try turning off real-time protection in Windows "Virus and Threat Protection" settings. It slows down gcc dramatically. One might begin to think it was deliberate!
I turn it off whenever I have to recompile Catalina.
Ross.
So true. I use MinGW to compile my CNC software. We had to go back to an old release because all programs compiled with the latest version frequently trigger virus warnings on customer's PCs.
And it's not just a warning at installation time you could simply ignore and click away. Some windows versions are so aggressive that they delete our executable without asking the user!
@RossH That does appear to be the issue, thanks!
Now have to check that other machine... Not sure why it'd be turned off there...
So strange... Other machine has real time protection turned on, yet doesn't have this issue...
BTW: Turned real time back on slow machine and it's slow again, so that is definitely a switch.
Adding RiscV tools folder as an exclusion doesn't help. Nor does running CMD prompt as administrator.
But, adding exclusion for entire RiscV folder that includes the hello.c file does work. Found a solution!
The best Antivirus program for Windows is Linux.
You can have both at the same time with WSL2
@ersmith Think I'm seeing that in order to compile a .c file, it has to be in a subfolder inside the riscvp2 folder, is this right?
Trying now with Ubuntu... Added the "bin" folder to the path, but that's it...
It complains about not being able to find cc1 otherwise...
@ersmith The custom assembly for rdpin() doesn't seem to work... Getting illegal instruction messages. I think it must work somehow though.
What am I doing wrong here?
I'm actually amazed that this thing still works after all this time
. Congratulations on getting it going.
I think it's enough to make sure the gcc program is in the PATH environment variable. I haven't really tried it much on Windows though, so I may be misremembering.
What message are you getting? It compiles OK for me on Linux. I'm afraid I don't have a Windows setup right now to test on.
@ersmith Switched to Ubuntu after couldn’t get it in Windows.
Does the hello_rdpin.c work for you?
For me, it compiles but rdpin gives illegal instruction error message