Arch Linux and the HiFive1

[neo_ar]

I received my HiFive1 Founders edition today. I managed to find a usb to micro-usb cable but I don’t seem to be able to connect to the board out-of-the-box on my arch linux machine.

The device appears to power on fine and the green 5V indicator led lights up. However, it does not show up under lsusb for me and I have no /dev/ttyUSB*

I checked dmesg, here are the logs from plugging the HiFive1 in: https://gist.github.com/miotatsu/02e87537e8ed82ac6f1b188104442a10

One thought I had is that it could be an issue with no kernel module being loaded to handle serial usb communication, but modprobe usbserial didn’t seem to help.

Any advice on getting my HiFive1 talking to my Arch Linux machine would be greatly appreciated.

[ahthomas]

Move the IOREF jumper from 3.3v to 5.0v …
sudo screen /dev/ttyUSB1 115200 worked fine for me after that …
(actually my Hi51 showed up on ttyUSB2 since I was already using ttyUSB1)

[dgrubb (Dave)]

@neo_ar

One thought I had is that it could be an issue with no kernel module being loaded to handle serial usb communication, but modprobe usbserial didn’t seem to help.

It looks like it’s not even getting that far with the host controller driver (xhci_hcd) failing to handle it correctly. What’s your physical arrangement like? Hubs? Lots of devices on the same bus? etc etc …

N.B: I’ve tried it on two different machines with both ehci_hcd and xhci_hcd drivers without problems (sorry, I know how unhelpful the obligatory “it works for me” comments are ) but a good first step would be to find out what those error codes mean.

[mwachs5 (Megan A. Wachs)]

Sanity check: your board should be executing a program which changes the RGB LED (in addition to both the power LEDs).

Do you have any other machine lying around? You could plug in to see if the board is recognized (e.g. If macOS or Windows can find the FTDI device automatically).

[scottj (Scott Johnson)]

I once wasted an hour trying to use a cable that was only designed for power, not data.

Have you successfully used this cable for data before (e.g. syncing an Android phone)?

[neo_ar]

@ahthomas I’ll try switching the IOREF jumper to 5v today.

@dgrubb I figured that might be the case from the errors. I’m using one of the USB ports on the case of my PC, all of which are in use. I know that the port works. I’ll research the error codes today if switching the IOREF jumper to 5v doesn’t fix the problem

@mwachs5 When I plug the board in I only have the green LED lit, the demo program does not seem to be executing, should it execute without being recognized by the PC? I don’t have a Windows or macOS machine on hand.

@scottj The cable I found was from a steam controller, so it should be designed for both power and data. The cable works fine with the controller

[mwachs5 (Megan A. Wachs)]

Hmmm the demo program should run with just power. And you should have two power LEDs on, not just one. Can you upload a short video of what your board looks like when you plug it in?

[neo_ar]

I solved it on my stream today:

The problem was with the ports on my PC’s case. Plugging in to the ports on my machines mobo solved the issue. The demo program now runs and I am able to connect and communicate with the device.

Next question: Is anyone else using the HiFive1 with arch linux, and if so is anyone interested in maintaining packages for the sdk in the AUR, or should I do it?

[nonerkao (Quey-Liang Kao)]

As an Arch user who should get the board soon, I will really appreciate the AUR package if you make it. I was planning to do the AUR package myself, but now I don’t even have the board yet.

I’m looking forward to it!

[neo_ar]

I’m planning on packaging it for the AUR tonight

EDIT: nevermind, looks like @nonerkao beat me to it
https://aur.archlinux.org/packages/hifive1-sdk-git/

[nonerkao (Quey-Liang Kao)]

@neo_ar
Although you might not expect it, thank you for giving me (who still not get the board yet ) the chance and motivation to play with the SDK and finish the package. Would you like to help improve the package as a co-maintainer ?

BTW, I enjoy your video, which are clear and comprehensive. They will help me seamlessly setup the demos after I get the board.

[neo_ar]

I’d love to help improve/co-maintain it
And thanks, I’m glad to hear you enjoy my videos!

[rvense]

I get this:

make[4]: Entering directory '/home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/work/riscv32-gnu-toolchain/build-binutils-newlib/binutils'
/bin/sh /home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/../ylwrap /home/niklas/code/hifive1-sdk-git/src/fre
edom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/arparse.y y.tab.c arparse.c y.tab.h arparse.h y.output arparse.output -- bison -y  -d
updating arparse.h
/bin/sh /home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/../ylwrap /home/niklas/code/hifive1-sdk-git/src/fre
edom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/sysinfo.y y.tab.c sysinfo.c y.tab.h sysinfo.h y.output sysinfo.output -- bison -y  -d
/home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/sysinfo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr
]
updating sysinfo.h
if [ -r sysinfo.c ]; then \
  gcc -c -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -I/home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/riscv-gnu-to
olchain/riscv-binutils-gdb/binutils/../zlib -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong  sysinfo.c ; \
else \
  gcc -c -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -I/home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/riscv-gnu-to
olchain/riscv-binutils-gdb/binutils/../zlib -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong  /home/niklas/code/hifive1-sdk-git/src/freedom-e-sd
k/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/sysinfo.c ; \
fi
/bin/sh /home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/../ylwrap /home/niklas/code/hifive1-sdk-git/src/fre
edom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/syslex.l lex.yy.c syslex.c -- flex
gcc -c -I. -I/home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils -W -Wall -Wstrict-prototypes -Wmissing-prototy
pes -Wshadow -Wstack-usage=262144 -I/home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/../zlib -march=x86-64 -
mtune=generic -O2 -pipe -fstack-protector-strong  /home/niklas/code/hifive1-sdk-git/src/freedom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/binutils/syslex_wr
ap.c
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -Wl,-O1,--sort-common,--as-needed,-z,relro -o sysinfo sysinfo.o syslex_wrap.o
syslex_wrap.o: In function `yylex':
syslex_wrap.c:(.text+0xc63): undefined reference to `yywrap'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:1372: sysinfo] Error 1

Arch Linux amd64. gcc 6.2.1-1, binutils 2.27-1, flex 2.6.3-1, bison 3.0.4-2.

[ashleyis (Ashley Towns)]

@rvense

flex 2.6.3-1

It’s an issue with the latest flex i ended up hacking around it by going back to 2.6.1 (here if you want it, its tagged as 2.6.3-2 because im lazy and it was the easiest way to downgrade on my buildserver).

[nonerkao (Quey-Liang Kao)]

Thanks for the report. Before the bug being fixed, we’ll add the dependency check on flex.

JFYI, This is the flex 2.6.1 package from the archive.

[rvense]

Any updates?

[edc (edmond.cote@gmail.com)]

@scottj It happened to me as well, wasted about an hour using the wrong type of cable. Thanks for the tip!

[Miblo (Matt Mascarenhas)]

As far as I can tell, the minimum steps required to get ourselves up and running on Arch are:

1. Install @nonerkao’s hifive1-sdk-git package from the AUR
2. Copy /opt/hifive1-sdk/ to a directory to which we have read/write access
3. Add ourselves to the uucp group
4. Create the following udev rule in /etc/udev/rules.d/99-openocd.rules:

SUBSYSTEM==“tty”, ATTRS{idVendor}==“0403”, ATTRS{idProduct}==“6010”, GROUP=“uucp”`

The main difference from the Getting Started Guide being that we needn’t create (and add ourselves to) a plugdev group, a SUBSYSTEM==“usb” udev rule, or change the access permissions for the SUBSYSTEM==“tty” udev rule. Without setting the group, though, I found myself unable to upload to the board.

[nonerkao (Quey-Liang Kao)]

Thanks for @Miblo’s detailed guide. May I add the steps into the package? so that when other users install it, they will see these steps to setup their environments.

BTW, regarding to step 2, I think that annoying (copying more than 200MB of stuff!) and not conformed to the AUR package guideline. Ideally, I would like to do some patch in Makefiles in the software directory, so that the bsp and tools can have absolute paths rather than relative ones. This allows users to copy software directory only. And, regarding to step 4, I did not setup the udev rules but I can still do development on the board, either in the sdk way or the arduino IDE way.

What do you archers think about the idea? Thanks for all the feedback.

[neo_ar]

I have to apologize for not helping out with the package despite being a co-maintainer, I’ve been focused on my show. You can remove me as a co-maintainer @nonerkao as I’m probably not going to get around to helping out with it to be completely honest. I think patching the Makefiles is a great idea as we’ve discussed in the past. I also did not need the udev rules on my system, not sure why Miblo needed them