I noticed the current freedom unleashed config disables the FPU, but the freedom-u-sdk build assumes the FPU is enabled (the bbl image dies in fp_init in minit.c if I run the current config.) I tried a few different -msoft-float, -mno-float, -march CFLAGS, and the --disable-float configure option but I still get linker errors for mixing hard-float and soft-float. Is there some trivial option I am missing? If not I can include the FPU and alter my design to lower the clock frequency.
You’re mistaken. The freedom-u-sdk DISABLES the FPU. Are you sure you have the correct submodule version of riscv-pk? Your risc-pk/Makefile.in should contain:
CFLAGS := @CFLAGS@ $(CFLAGS) -DBBL_PAYLOAD="$(bbl_payload)" -msoft-float
… this is assuming you are building freedom-u-sdk/master.
I just cloned a fresh master of freedom-u-sdk, and riscv-pk 423f0b6c3b2f0360a5ceebfae5ee75c61ba7b6ee Makefile.in contains:
CFLAGS := @CFLAGS@ $(CFLAGS) -DBBL_PAYLOAD="$(bbl_payload)" -mno-float
I tried spike --isa=RV64IMAC ./bbl after running make and I still get:
…/machine/minit.c:59: FPU not found; recompile pk with -msoft-float
Perhaps there is a discrepancy between the riscv-gnu-toolchain and riscv-pk pointed to by freedom-u-sdk with regards to the usage of -mno-float versus -msoft-float?
There was a change to gcc at some point where it went from no-float to soft-float. Both are now obsolete and the correct option is -mabi=lp64 -march=rv64imac. freedom-u-sdk includes a toolchain that should expect -mno-float or -msoft-float… I’m not sure any more which. If your RISCV environment variable is set, though, it will use your installed toolchain which may expect a different compile option.
This gcc transition was kind of a mess. Hopefully now that gcc is upstreamed, the next time we update freedom-u-sdk/master people won’t run into this any more.