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

HiFive1 Rev B
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.

1 Like
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.

8

I am on Arch Linux as well and got the freedom-e-sdk (using the v201905-branch) to run by simply installing the SEGGER tools from AUR and using the pre-built RISC-V toolchain from the sifive site. Using a riscv toolchain from the AUR did not work for me (got compilation errors with the hello example).

So far I have followed the “get started”-guide and using their make commands I have managed to flash the “hello”-example to the board (got the message after connecting to the serial console).

9

I am doing this on Ubuntu instead of Arch but am equally frustrated. I downloaded JLink from the Segger site. After much poking around and reading the volumninous manual I found that the supplied JLinkDevices.xml file does not contain an entry for the Hifive1. It does have an entry for something called “E31ARTY” but that specifies a Flash base address of 40000000. I made another entry called “E31Hifive” with the Flash base changed to 20000000. That does actually connect and I can use JLink to dump out sections of both RAM and FLash memory, so it is connected. The trouble is the JLinkDevices.xml file specified a “Loader” as follows:

Loader="Devices/SiFive/SiFive_FE310_ARTYBoard_QSPI.elf"
	LoaderType="FLASH_ALGO_TYPE_OPEN" />

There is no loader other than the ARTYBoard one in the JLink/Devices/SIFive directory. So I bumble on anyway and try to load a file, in this case the Mecrisp Quintus FORTH system:

J-Link>loadfile ../hifive1-rev-b/mecrisp-quintus-hifive1-rev-b.hex 20010000
Downloading file [../hifive1-rev-b/mecrisp-quintus-hifive1-rev-b.hex]...
Comparing flash   [100%] Done.

****** Error: Timeout while preparing target, core does not stop.
   (PC = 0x80000312, X1 = 0x80000314, X2 = 0x800018A8)!
Failed to initialize RAMCode
Timeout while restoring target, core does not stop.
   (PC = 0x20010010, X1 = 0x20011698, X2 = 0x669D3958)
!Timeout while preparing target, core does not stop.
   (PC = 0x80000312, X1 = 0x80000314, X2 = 0x800018A8)!
Failed to initialize RAMCode
Timeout while restoring target, core does not stop.
   (PC = 0x80000316, X1 = 0x80000318, X2 = 0x800018A8)!
Unspecified error -1

Not really helpful. So I ask the same question as above: has anyone gotten this to work, ever?
Oh, dragging a .hex file onto the virtual USB drive does not work either, with various obscure messages like “Connect failure”.

10

Here is how I am doing this. If anyone can see what I am doing wrong, please let me know.

`./JLinkExe usb 979000964 -speed 4000 -si JTAG -device E31Hifive
SEGGER J-Link Commander V6.46i (Compiled Jul 5 2019 16:56:47)
DLL version V6.46i, compiled Jul 5 2019 16:56:36

Connecting to J-Link via USB…O.K.
Firmware: J-Link OB-K22-SiFive compiled May 27 2019 15:39:22
Hardware version: V1.00
S/N: 979000964
VTref=3.300V

Type “connect” to establish a target connection, ‘?’ for help
J-Link>connect
Device position in JTAG chain (IRPre,DRPre) : -1,-1 => Auto-detect
JTAGConf>
Device “E31HIFIVE” selected.

Connecting to target via JTAG
ConfigTargetSettings() start
ConfigTargetSettings() end
TotalIRLen = 5, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x20000913, IRLen: 05, Unknown device
Debug architecture:
RISC-V debug: 0.13
AddrBits: 7
DataBits: 32
IdleClks: 5
Stat: 0
Memory access:
Via system bus: No
Via ProgBuf: Yes (16 ProgBuf entries)
DataBuf: 1 entries
autoexec[0] implemented: Yes
Detected: RV32 core
CSR access via abs. commands: No
Temp. halted CPU for NumHWBP detection
HW BPs: 8
Support set/clr HW BPs while running: No
RISC-V identified.
J-Link>loadfile …/Forth/mecrisp-quintus/mecrisp-quintus-source/hifive1/mecrisp-quintus-hifive1.hex, 20010000
`

11

Thanks to some help on IRC I was able to find the exact standalone JLink command that works properly:

echo -e "loadfile file.hex\nexit\n" | $JLINK usb 979000964 -device FE310 -if JTAG -speed 4000 -si JTAG -jtagconf -1,-1 -autoconnect 1
12

Thought I’d add onto this and say platformio now supports revb and it works flawlessly for me on arch so far.

13

I also use platformio + vscore for hifive1 revb but I can’t upload the program to the board.

“J-Link connection not established yet but required for command.
Connecting to J-Link via USB…FAILED: Cannot connect to J-Link via USB.”

I’m using ubuntu 18.04. Any idea?

14

more complete message is as follows.

Configuring upload protocol…
AVAILABLE: jlink
CURRENT: upload_protocol = jlink
Uploading .pio/build/hifive1-revb/firmware.hex
SEGGER J-Link Commander V6.46g (Compiled Jun 14 2019 19:36:40)
DLL version V6.46g, compiled Jun 14 2019 19:36:30

J-Link Command File read successfully.
Processing script file…

J-Link connection not established yet but required for command.
Connecting to J-Link via USB…FAILED: Cannot connect to J-Link via USB.

J-Link connection not established yet but required for command.
Connecting to J-Link via USB…FAILED: Cannot connect to J-Link via USB.

J-Link connection not established yet but required for command.
Connecting to J-Link via USB…FAILED: Cannot connect to J-Link via USB.

15

Update: See edit 2 for fix. Ignore middle parts.

I’m looking for some possible fixes for you, but my arch partition just broke (the desktop environment just stopped working lol) I will say some possible causes are make sure your user has permissions to read and write to the jlink usb device. Also make sure you’ve added the rules to your /etc/udev/rules.d for jlink. I’ll try and reproduce and report back. Though, with platformio in vscode I didn’t need to do any of this manually. I did for freedomstudio, but not platformio.

Edit:
I’ve removed all prior dependencies in an effort to reproduce your error and I haven’t been able to. I reinstalled platformio inside of vscode and reinstalled sifive platform in it. Only thing I can say to try is to add jlink rules:
sudo vi /etc/udev/rules.d/99-jlink.rules
Insert this:

SUBSYSTEM==“tty”, ATTRS{idVendor}==“1366”, ATTRS{idProduct}==“1051”,MODE=“664”, GROUP=“users”
LABEL=“jlink_rules_end”

This is taken from the getting started guide, but I changed GROUP=“plugdev” (which is in the getting started guide to GROUP=“users” because I don’t have a plugdev group.

Then run

sudo udevadm trigger

If that doesn’t work, try installing the jlink software pack: SEGGER - The Embedded Experts - Downloads - J-Link / J-Trace

For Ubuntu/Debian, Download the package then run:

sudo dpkg -i ~/Downloads/your jlink pkg here

For arch, you’ll need yaourt (at least this is how I did it). Simply run:

yaourt -S jlink-software-and-documentation

But again, none of this should be necessary in platformio. I don’t think this has to do with those dependencies/prereqs

Edit 2: Ok I have replicated this issue. For some reason using the rules given in the getting started guide didn’t work for me (on Arch). I fixed it by using the 99-jlink.rules file included in the Freedom Studio download. For ease, I’ve uploaded it to mega:

If you don’t want to use this download link, simply download the freedom studio ide and extract it somewhere, then run the following:

cp $FREEDOM_STUDIO_LOCATION/SiFive/jlink/*/99-jlink.rules /etc/udev/rules.d/.
sudo udevadm trigger

Then this issue should go away.

16

It turned out that I didn’t do this step believing that the platformio would have automatically installed it (apparently, it didn’t). After I manually installed the jlink deb package, all seems to work fine now.

Thanks.

1 Like