Can't get HiFive1 Rev B to work on Arch Linux at all


#1

First off, /dev/ttyACM0 et al are owned by group uucp, of which I am a member. I can access it from a screen session no problem.

So I look at the getting started guide. Apparently I need the toolchain; it’s only available for Ubuntu 14.04 (which is EOL, might I add) but I can make it “work” with ncurses ABI 5 compat libs. I install it, set RISCV_PATH. I then also learn from the freedom-e-sdk I need to download openocd and set RISCV_OPENOCD_PATH. I do that too. Both are set. I recursively clone freedom-e-sdk. I do the following:

$ make BSP=metal PROGRAM=hello target=sifive-hifive1-revb software

Build goes through fine. Wew.

Now I try to upload it:

$ make BSP=metal PROGRAM=hello target=sifive-hifive1-revb upload
scripts/upload --elf /home/fratti/Projekte/freedom-e-sdk/software/hello/debug/hello.elf --openocd     /home/fratti/riscv-openocd-0.10.0-2019.02.0-x86_64-linux-ubuntu14/bin/openocd --gdb /home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb --openocd-config bsp/sifive-hifive1/openocd.cfg
/home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb: /usr/lib/libncurses.so.5: no version information available (required by /home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb)
/home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb: /usr/lib/libncurses.so.5: no version information available (required by /home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb)
/home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb: /usr/lib/libncurses.so.5: no version information available (required by /home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb)
/home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb: /usr/lib/libncurses.so.5: no version information available (required by /home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb)
/home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb: /usr/lib/libncurses.so.5: no version information available (required by /home/fratti/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb)
Open On-Chip Debugger 0.10.0+dev-g672ef66-dirty (2019-03-06-06:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description 'Dual RS232-HS', serial '*' at bus location '*'

localhost:3333: Connection timed out.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

Thanks I love it. No, running it as root doesn’t help either, it’s not a permissions issue.

Here’s the lsusb output:

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2b Intel Corp. 
Bus 001 Device 002: ID 064e:3410 Suyin Corp. 
Bus 001 Device 007: ID 1366:1051 SEGGER 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So a few questions:

  1. Why is the “Getting Started” guide completely omitting OpenOCD?
  2. Why do you only provide toolchains for things that have been released back when Obama was still in office?
  3. Why is this refusing to upload? Even doing the drag and drop thing of the hex onto the board gives a nice FAIL.txt with “Address from datafile not in target flash” as the reason.

#3

I’m currently compiling freedom-tools with a modified Makefile:

diff --git a/Makefile b/Makefile
index df1b2d1..929fb03 100644
--- a/Makefile
+++ b/Makefile
@@ -13,30 +13,8 @@ WIN32  ?= i686-w64-mingw32
 WIN64  ?= x86_64-w64-mingw32
 DARWIN ?= x86_64-apple-darwin
 
-
--include /etc/lsb-release
-ifneq ($(wildcard /etc/redhat-release),)
-NATIVE ?= $(REDHAT)
-all: redhat
-else ifeq ($(DISTRIB_ID),Ubuntu)
-ifeq ($(shell uname -m),x86_64)
 NATIVE ?= $(UBUNTU64)
 all: ubuntu64
-else
-NATIVE ?= $(UBUNTU32)
-all: ubuntu32
-endif
-all: win64
-else ifeq ($(shell uname),Darwin)
-NATIVE ?= $(DARWIN)
-LIBTOOLIZE ?= glibtoolize
-TAR ?= gtar
-SED ?= gsed
-AWK ?= gawk
-all: darwin
-else
-$(error Unknown host)
-endif
 
 LIBTOOLIZE ?= libtoolize
 TAR ?= tar

I’ll let you guys know how it goes, hopefully I’ll end up with a working toolchain build and can upload things to the board, though I’m still not sure whether the toolchain is actually the problem. I’m compiling this on a 2-core 4-thread laptop so it may be a while.


#4

With some hurdles along the way, I’ve managed to build openocd and the toolchain. But alas, I still get the same error:

$ make BSP=metal PROGRAM=hello target=sifive-hifive1-revb upload
scripts/upload --elf /home/fratti/Projekte/freedom-e-sdk/software/hello/debug/hello.elf --openocd /home/fratti/hifive-toolchain/riscv-openocd-0.10.0-2019.02.0-x86_64-linux-ubuntu14/bin/openocd --gdb /home/fratti/hifive-toolchain/riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb --openocd-config bsp/sifive-hifive1/openocd.cfg
Open On-Chip Debugger 0.10.0+dev-gf096c82-dirty (2019-06-05-14:25)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description 'Dual RS232-HS', serial '*' at bus location '*'

localhost:3333: Connection timed out.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

#5

Apparently this error message means “don’t use openocd because we don’t have an openocd config, but our Makefile will still try to use it”. On the bright side, upload with the non-free jlink tool also fails.

Using scripts $ ./upload --hex /foo/freedom-e-sdk/software/hello/debug/hello.hex --jlink /opt/SEGGER/JLink/JLinkExe seems to succeed at first, but actually just seems to reset the board with no changes to the running code.

Has anyone actually successfully programmed this? Ever?


#6

As far as I understand things you’re not supposed to use openOCD but jlink. Make sure to use the development-19.05 branch as it fixes a lot of revB things.

Also make sure your JLink software stack is from SEGGER directly (AUR package works fine here) and you need the riscv gnu toolchain specifically for the unknown target as well.

The upload is handled by “loadfile” command in the JLinkExe after you connect with the right device type and speed settings.


(Jim Wilson) #7

I can comment on the “old” part. If we build a toolchain for Ubuntu 18.04, it will only run on 18.04. If we build a toolchain for Ubuntu 14.04, it will run on 14.04, 16.04, and 18.04. So we maximize the number of people who will be able to use the toolchain by building on the oldest reasonable linux version.

Also, the EDA industry, which includes our primary customers and suppliers, has standards for which linux versions are supported. When you have thousands of employees and millions of dollars of software licenses, upgrading linux turns into an expensive proposition, so they choose a linux version, and then stick with it for 10 years. And because they pick professional linux distros that tend to run 4 years or so behind the bleeding edge, that means we have to support 14 year old tools. This is why CentOS6 is one of the targets we support. See for instance
http://esd-alliance.org/interoperability-committee/
They recently deprecated SLEL11 from 2009, but RHEL6 from 2010 is still supported.

None of this is directly related to the HiFive1 RevB though. And we do provide toolchain sources for those that want to build it themselves.