Open zhemao opened 9 years ago
Does this fail on Spike?
Spike just exits right away without doing anything. Is there a way to disable the FPU in Spike?
While I've never used this, the help text
palmer palmer-mbp2014 ~ $ spike
usage: spike [host options] <target program> [target options]
Host Options:
-p <n> Simulate <n> processors [default 1]
-m <n> Provide <n> MiB of target memory [default 4096]
-d Interactive debug mode
-g Track histogram of PCs
-h Print this help message
--isa=<name> RISC-V ISA string [default RV64IMAFDC]
--ic=<S>:<W>:<B> Instantiate a cache model with S sets,
--dc=<S>:<W>:<B> W ways, and B-byte blocks (with S and
--l2=<S>:<W>:<B> B both powers of 2).
--extension=<name> Specify RoCC Extension
--extlib=<name> Shared library to load
seems to indicate that you can pass "--isa=RV64IMAC" to get rid of hardware floating point support.
OK, when I do that, spike shows the same behavior as the emulator.
Linux doesn't boot on the FPGA currently, even without the FPU.
The new_privileged_isa branch of riscv-linux does boot on the FPGA w/ FPU.
This resulted from a stack overflow, which is now fixed.
Also, Palmer's -march support broke the -msoft-float flag. Until he fixes it, you might need to use -march=RV64IMA instead of -msoft-float.
On Thu, Jul 23, 2015 at 2:30 PM, Howard Mao notifications@github.com wrote:
The new_privileged_isa branch of riscv-linux does boot on the FPGA w/ FPU.
— Reply to this email directly or view it on GitHub https://github.com/riscv/riscv-pk/issues/10#issuecomment-124245156.
I am having a similar issue while compiling c code and running it on the rocket chip without FPU, If i use the compiler flag "-march=RV64IMA" will it solve my issue.
Trying to run bbl on a rocket core sans FPU. I manually added the "-msoft-float" flag in the Makefile and compiled. BBL starts up and prints the logo, but then hangs after that.
Inspecting the instruction stream, bbl seems to be hanging while acquiring the spinlock in frontend syscall.
https://github.com/riscv/riscv-pk/blob/master/pk/frontend.c#L30
Since there was only a single core, the lock shouldn't have been taken at that point. My guess is that frontend_syscall gets interrupted before it releases the lock. The interrupt handler then calls frontend_syscall itself (presumably to send a console message) and thus hangs while trying to take the lock.