problem to build riscv-pk after patch

[riazcseiu]

Thank you for the very useful repo. I'm new in RISC-V and I want to use rocc interface to evaluate my research. basically, I make a prototype for decimal multiplication that needs to evaluate through rocket accelerator. after study found your repo is an example using rocc interface. I follow your instruction and upto Bare Metal tests run directly on the emulator its okay if I execute the command

`This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1. Listening on port 43783 PASSED Completed after 105192 cycles

real 0m8.390s user 0m8.288s sys 0m0.096s`

but after patch, if I want to build riscv-pk it shows the following error :

riscv64-unknown-elf-gcc -MMD -MP -Wall -Werror -D__NO_INLINE__ -mcmodel=medany -O2 -std=gnu99 -Wno-unused -Wno-attributes -fno-delete-null-pointer-checks -DBBL_PAYLOAD=\"bbl_payload\" -DBBL_LOGO_FILE=\"bbl_logo_file\" -I. -I../pk -I../bbl -I../softfloat -I../dummy_payload -I../machine -I../util -c ../machine/minit.c riscv64-unknown-elf-ar rcv libmachine.a fdt.o mtrap.o minit.o htif.o emulation.o muldiv_emulation.o fp_emulation.o fp_ldst.o uart.o finisher.o misaligned_ldst.o mentry.o fp_asm.o r - fdt.o r - mtrap.o r - minit.o r - htif.o r - emulation.o r - muldiv_emulation.o r - fp_emulation.o r - fp_ldst.o r - uart.o r - finisher.o r - misaligned_ldst.o r - mentry.o r - fp_asm.o riscv64-unknown-elf-ranlib libmachine.a riscv64-unknown-elf-gcc -nostartfiles -nostdlib -static -o pk pk.o -L. -lpk -lmachine -lsoftfloat -lutil -lgcc -T ../pk/pk.lds /path/to/install/riscv/toolchain/lib/gcc/riscv64-unknown-elf/7.2.0/../../../../riscv64-unknown-elf/bin/ld: ./libmachine.a(minit.o): can't link hard-float modules with soft-float modules /path/to/install/riscv/toolchain/lib/gcc/riscv64-unknown-elf/7.2.0/../../../../riscv64-unknown-elf/bin/ld: failed to merge target specific data of file ./libmachine.a(minit.o) collect2: error: ld returned 1 exit status Makefile:302: recipe for target 'pk' failed make: *** [pk] Error 1 please help me to complete the porcess Thanks

[seldridge]

Thanks for checking out this repo.

Couple of things:

1. It looks like you're using the riscv-tools repo. This repo was originally developed when using riscv-tools was the norm. However, this is now highly ill advised as riscv-tools is a major pain to build correctly. This repo likely needs to be updated with instructions to avoid the pseudo-dependency on having a riscv-tools install (which is really only because it needs riscv-tests headers).
2. This looks like a problem related specifically to building something with a soft float compiler and then trying to link against hard float modules. See: https://github.com/riscv/riscv-gnu-toolchain/issues/356
3. You've got a weird choice of path /path/to/install/riscv/toolchain for installing the toolchain that shouldn't matter, but is odd.

Summarily, this repo likely needs to be refactored to avoid a riscv-tests false dependency. However, the issue appears to be related to the toolchain you have.

Can you build riscv-pk without the patch just fine?

[riazcseiu]

Many many thanks for the reply. Currently, I'm trying to use RISC-V Project Template RISC-V Project Template repo. What I actually want is to make custom accelerator for decimal multiplication. To do that I tried to understand how rocc interface works through your example.
I'm not sure how to start to make accelerator and how to test/ simulate and modify RISC-V Project Template this part . using emmulator . I'm stak in this point and please kindly suggest me in this regards.

Yes, the risv-test already configured before patch . it shows the following error if I want to run.

This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1. Listening on port 35441 [INFO] Write R[1] = 0xdead z 0000000000000000 ra 000000000001024c sp 000000000fee9aa0 gp 0000000000020918 tp 0000000000000000 t0 0000000000010720 t1 000000000fee9960 t2 0000000000000000 s0 000000000fee9af0 s1 0000000000000000 a0 000000000000001b a1 000000000000dead a2 0000000000000001 a3 0000000000000000 a4 0000000000000000 a5 0000000000000001 a6 000000000000001f a7 0000000000000040 s2 0000000000000000 s3 0000000000000000 s4 0000000000000000 s5 0000000000000000 s6 0000000000000000 s7 0000000000000000 s8 0000000000000000 s9 0000000000000000 sA 0000000000000000 sB 0000000000000000 t3 000000000000000a t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 pc 000000000001025c va 0000000000c5f50b insn 00c5f50b sr 8000000200046020 An illegal instruction was executed! FAILED via dtm (code = -1, seed 1546599555) after 3728908 cycles

real 4m22.767s user 4m22.232s sys 0m0.532s

[riazcseiu]

This is a very good repo to understand rocc. Finally I execute and give some flow that can understandabe to new user.

about the opcode bellow information could be helpfull

Thanks @seldridge for this ropo

[seldridge]

Sorry, I didn't have a chance to loop back to this. The error above is acting like the instruction at 000000000001025c is an illegal instruction. This, assumedly though not certainly, is one of the XCustom instructions. You can get this in a number of ways, but it's possible that one of the following happened:

1. The Rocket Chip emulator was not built to include support for XCustom instructions (if you include a RoCC this shouldn't be the case)
2. The MSTATUS_XS bits are set to zero for that thread
3. Something else...

The way in which the situation for (2) is resolved is different for bare metal programs and for the Proxy Kernel (or anything that is like an operating system). The bare metal program can just set the XS bits directly when in machine mode, drop to user mode, and then things will work. For the Proxy Kernel, the XS bits should match how the FS (floating point status) bits work. These should be enabled on a process-by-process basis based on whether or not that process should be allowed to access the custom extension. The reason for these bits existing is that they encode whether or not there is state in the extension hardware that the OS needs to manage. Analogously, the FS bits, if non-zero, indicate on a context switch that the OS may need to do something with the floating point registers (like save them with the process context).

For (3), Rocket Chip is a moving target and sometimes things get out of date. Currently Rocket Chip regressions only test that the example RoCCs are built, but there are no tests that are run here (I think). This situation could be improved if either these tests were included in those regressions of if these repository was setup to run nightly regressions with Rocket Chip. This is low priority on my end, but I may be able to get back to it if there's interest or I'll always take a PR.