Symbiflow shows Unable to detect GNU compiler type

[mamuneeb]

Hii I am facing an issue while setting up environment for CFU Playground.

While running make prog TARGET=digilent_arty USE_SYMBIFLOW=1

i am getting this

meson /home/mamuneeb/CFU-Playground/third_party/python/pythondata-software-picolibc/pythondata_software_picolibc/data -Dmultilib=false -Dpicocrt=false -Datomic-ungetc=false -Dthread-local-storage=false -Dio-long-long=true -Dformat-default=integer -Dincludedir=picolibc/riscv64-unknown-elf/include -Dlibdir=picolibc/riscv64-unknown-elf/lib --cross-file cross.txt WARNING: Unknown CPU family riscv, please report this at https://github.com/mesonbuild/meson/issues/new The Meson build system Version: 0.63.99 Source dir: /home/mamuneeb/CFU-Playground/third_party/python/pythondata-software-picolibc/pythondata_software_picolibc/data Build dir: /home/mamuneeb/CFU-Playground/soc/build/digilent_arty.proj_template/software/libc Build type: cross build Project name: picolibc Project version: 1.7.7

../../../../../third_party/python/pythondata-software-picolibc/pythondata_software_picolibc/data/meson.build:35:0: ERROR: Unable to detect GNU compiler type: Compiler stdout:

Compiler stderr: riscv64-unknown-elf-gcc: fatal error: cannot execute 'cc1': execvp: No such file or directory compilation terminated.

A full log can be found at /home/mamuneeb/CFU-Playground/soc/build/digilent_arty.proj_template/software/libc/meson-logs/meson-log.txt make[6]: [/home/mamuneeb/CFU-Playground/third_party/python/litex/litex/soc/software/libc/Makefile:43: __libc.a] Error 1 make[6]: Leaving directory '/home/mamuneeb/CFU-Playground/soc/build/digilent_arty.proj_template/software/libc' Traceback (most recent call last): File "./common_soc.py", line 57, in main() File "./common_soc.py", line 53, in main workflow.run() File "/home/mamuneeb/CFU-Playground/soc/board_specific_workflows/general.py", line 125, in run soc_builder = self.build_soc(soc) File "/home/mamuneeb/CFU-Playground/soc/board_specific_workflows/digilent_arty.py", line 73, in build_soc return super().build_soc(soc, kwargs) File "/home/mamuneeb/CFU-Playground/soc/board_specific_workflows/general.py", line 102, in build_soc soc_builder.build(run=self.args.build, kwargs) File "/home/mamuneeb/CFU-Playground/third_party/python/litex/litex/soc/integration/builder.py", line 344, in build self._generate_rom_software(compile_bios=use_bios) File "/home/mamuneeb/CFU-Playground/third_party/python/litex/litex/soc/integration/builder.py", line 281, in _generate_rom_software subprocess.check_call(["make", "-C", dst_dir, "-f", makefile]) File "/home/mamuneeb/CFU-Playground/env/conda/envs/cfu-symbiflow/lib/python3.7/subprocess.py", line 363, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['make', '-C', '/home/mamuneeb/CFU-Playground/soc/build/digilent_arty.proj_template/software/libc', '-f', '/home/mamuneeb/CFU-Playground/third_party/python/litex/litex/soc/software/libc/Makefile']' returned non-zero exit status 2. make[5]: [/home/mamuneeb/CFU-Playground/soc/common_soc.mk:115: build/digilent_arty.proj_template/gateware/digilent_arty.bit] Error 1 make[5]: Leaving directory '/home/mamuneeb/CFU-Playground/soc' make[4]: *** [../proj.mk:312: prog] Error 2 make[4]: Leaving directory '/home/mamuneeb/CFU-Playground/proj/proj_template`

It says unable to detect GNU compiler type. Please help.

[tcal-x]

Hi @mamuneeb , thank you for the report. I don't recall seeing that exact error, but it seems to be an installation issue. Do you have your own SymbiFlow installation, or did you do the make install-sf and make enter-sf way of getting SymbiFlow using Conda (instructions)? Also, on which OS are you running?

[mamuneeb]

Hii Thank you sir for your response. Sir i did the make install-sf and make enter-sf . I am using Ubuntu 22.04 OS.

[tcal-x]

Hmm, I don't think I've tried Ubuntu 22.04. I'll see if I can access that on a cloud VM or in Github Actions. Thanks again for your report!

[mamuneeb]

Sir may i know on which Ubuntu version this works fine.

[tcal-x]

Ubuntu 20.04 is the best tested, but we also use Ubuntu 18.04 since that is the only OS available in Google Colabs.

But I am trying to reproduce your issue on Ubuntu 22. It might not have anything to do with the OS version.

[tcal-x]

I'm currently running make USE_SYMBIFLOW=1 prog on a 22.04 VM and it's progressing fine. When it finishes the bitstream, I'll try making the software target.

Oh, I may see your problem. Your log mentions riscv64-unknown-elf-gcc. The toolchain in Conda is all riscv32. So the build may be attempting to mix and match different compilers.

I suggest you try removing the riscv64 toolchain from your path (or if it's a personal installation, just make the directory unreadable) so that all parts of the build use the included riscv32 toolchain.

[mamuneeb]

Sir could you please help me with the command or proper steps to do that ? I dont see any 64bit RISC V Toolchain in path in the .bashrc file

[tcal-x]

Sir could you please help me with the command or proper steps to do that ? I dont see any 64bit RISC V Toolchain in path in the .bashrc file

Try:

which riscv64-unknown-elf-gcc

and / or

locate riscv64-unknown-elf-gcc

[mamuneeb]

Yes sir, i got the files using the locate riscv64-unknown-elf-gcc How to delete this files. I tried them deleting but its not getting deleted

[tcal-x]

I would not recommend deleting system files. Find the executable that the build found --- did which riscv64-unknown-elf-gcc turn up anything? Or else, try this to find the actual executable, and then remove the path from your $PATH (unless it's a common directory that you need).

locate riscv64-unknown-elf-gcc | grep riscv64-unknown-elf-gcc$

Or perhaps you installed the Ubuntu package? If you're not using it for other projects, you could try uninstalling the package. To find if any riscv64 packages are installed, run apt list -i | grep riscv64.

[mamuneeb]

Sir when i run which riscv64-unknown-elf-gcc it shows /bin/riscv64-unknown-elf-gcc

also after doing locate riscv64-unknown-elf-gcc | grep riscv64-unknown-elf-gcc$ I am getting /riscv/bin/riscv64-unknown-elf-gcc /tools/riscv-newlib/bin/riscv64-unknown-elf-gcc /usr/bin/riscv64-unknown-elf-gcc /usr/lib/ccache/riscv64-unknown-elf-gcc

[mamuneeb]

Hii @tcal-x Sir The issue was with the earlier installed 64-bit tool chain. I had used a VM now and this issue is solved. Thanks a lot for your help. Closing this.

[haaslukas]

I just started to test the CFU Playground following the setup guide. I'm using an Ubuntu 22.04 (on a UTM/Qemu VM) along with a FOMU FPGA. The make prog TARGET=kosagi_fomu USE_SYMBIFLOW=1 works fine and seems to produce the bitstream. However, make load TTY=/dev/ttyAMA0 BUILD_JOBS=1 TARGET=kosagi_fomu results in an error: riscv64-unknown-elf-gcc: No such file or directory

Did I miss something in the installation step? Any help is appreciated

By the way, locate riscv64-unknown-elf-gcc and apt list -i | grep riscv64 both show nothing

[tcal-x]

Hello @haaslukas , admittedly the alternative installation paths are a bit confusing.

• If you are using the Conda installation (make env, make enter), then the riscv GCC toolchain is provided; the main issue that comes up in this case is that there may be a conflict if you already have a different riscv GCC toolchain installed in your system.
• If you are NOT using the Conda installation, then you must download and install a riscv GCC toolchain and put it in your path (your $PATH environment variable). This is the recommended tarball from SiFive: https://static.dev.sifive.com/dev-tools/freedom-tools/v2020.08/riscv64-unknown-elf-gcc-10.1.0-2020.08.2-x86_64-linux-ubuntu14.tar.gz

If you are not able to resolve the issue, please include the complete log from your build attempt.

[tcal-x]

@haaslukas also, I have not tested CFU Playground with UTM/Qemu VM and Fomu before. We should make sure the USB will work. If you're in the Conda env, you should have dfu-util. Try running this with the Fomu plugged in:

dfu-util -l

(that's lower-case L for "list") and let me know what you see.

[haaslukas]

dfu-util -l works fine within the VM, though I haven't testet it in the conda environment, because somehow I can't create it (yet). make envresults in the following error:

source /home/username/CFU-Playground/env/conda/bin/activate && conda env update --name cfu-common --file /home/username/CFU-Playground/conf/environment.yml
Collecting package metadata (repodata.json): done
Solving environment: failed

ResolvePackageNotFound: 
  - litex-hub::verilator
  - litex-hub::yosys
  - litex-hub::flterm
  - litex-hub::iceprog
  - litex-hub::dfu-util
  - litex-hub::symbiflow-yosys-plugins
  - litex-hub::nextpnr-nexus
  - litex-hub::openocd
  - litex-hub::gcc-riscv32-elf-newlib
  - litex-hub::nextpnr-ice40
  - litex-hub::nextpnr-ecp5

make: *** [third_party/make-env/conda.mk:145: /home/username/CFU-Playground/env/conda/envs/cfu-common/bin/python] Error 1

This irritates me a little bit, because i actually have the tools (at least I though so and did use them for some FOMU workshop parts). The history in my console tells me

wget https://raw.githubusercontent.com/enjoy-digital/litex/master/litex_setup.py
python3 litex_setup.py init
python3 litex_setup.py install

Could it be a version issue then?

[tcal-x]

@haaslukas , you can try to use a local installation of the tools (and not use the Conda env at all), but the tool versions from either the Fomu workshop tar or from apt install are very old. In particular, I know that the older version of Yosys available from the Fomu workshop can't handle the CFU in our keyword spotting project since that CFU is written in System Verilog. So if you want to go the non-conda route, I'd suggest cloning the repos, building, and installing for both yosys and nextpnr-ice40 according to the instructions at their repositories.

Also, always start a new shell that is not mixed up with your pure LiteX installation (litex_setup.py) (which typically recommends you install it in a Python virtual env). Even though we have LiteX repos as a submodule dependency, we access them a different way (they're not installed in our conda env). So definitely do not run litex_setup.py in CFU Playground.

I don't recall seeing that error output from Conda that you show above, although I notice something -- is your username in the VM actually username? If not, there may be a variable substitution issue.

Can you also see what you get from which conda? If you're using a system conda and not the one that's downloaded, that could be an issue.