Please share with us what you’re doing with your board! We’re looking forward to seeing them in action!
2 Likes
Hi Jack,
I see a typo in the hifive1-getting-started-guide: The vendor ID for the Olimex debugger is 15ba, and NOT 1b5a as listed.
The colour-coded pinout on the last page of the Getting Started Guide is a really nice touch.
Thanks for reporting the typo. I’ve fixed the guide to use the correct vendor ID.
Congratulations on the release!
Best,
D
Glad you like it! It’s based on https://github.com/Bouni/Arduino-Pinout. I realized it’s missing the critical information of which pin goes to each of the R,G,B LEDs! Will add.
1 Like
Hi,
I received a shipment notice for my HiFiave1 board. I am checking USPS.com every day but it still says “Pre-Shipment Info Sent to USPS, USPS Awaiting Item”. I can’t wait…
I started preparing the SDK toolchain following to the Getting Started Guide.
Here are what I did. I hope this helps for other readers.
download Ubuntu 16.04 VMware image from http://www.osboxes.org/ubuntu/
In addition to packages described in https://riscv.org/software-tools/;
sudo apt-get install autoconf automake autotools-dev curl libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc
I had to;
sudo apt-get install zit zlib1g-dev libusb-1.0
Compiling the SDK toolchain and demo_gpio works fine, but I got link error for dhrystone.
By checking Makefiles I found that I had to
make software_clean PROGRAM=demo_gpio
or
rm bsp/env/freedom-e300-hifive1/init.o
before making dhrystone.
The init.o is compiled with "-DUSE_PLIC -DUSE_M_TIME" and the init.o calls interrupt-handling functions which are defined in demo_gpio.c.
You may add some descriptions about this in the document (or to modify Makefiles to put init.o under working directories).
BTW how can I build a binary using “C” Standard Extension for Compressed Instructions?
I checked https://riscv.org/software-tools/risc-v-gnu-compiler-toolchain/ but found no clue.
1 Like
Thanks for all your feedback and reports for making it easier for other users! All the HiFive1 Founders Edition & Early Access have been shipped out, so hopefully your tracking is updated soon.
To compile with ‘C’ extension, you will want to modify the Makefile. Look for the part where it specifies the arch:
--with-arch=rv32ima
Change it to:
--with-arch=rv32imac
We have it disabled by default because GDB gets confused by mis-aligned instructions.
Thank you for your prompt reply!
It seems that Santa is working under US time. He cannot come to me by the Christmas night in Japan:-)
I see that I have to rebuild whole toolchain with the rv32imac option. It makes sense.
Does this mean that the current GDB cannot handle mis-aligned instructions for RISC-V with the C extension yet?
Right… it mostly works (like you can step through code, examine registers, etc). The main issue is that you can’t set a breakpoint on an instruction which isn’t at a 32-bit aligned address. You can see this issue here with a note on how you can hack GDB to work (but then it won’t work if your core is not C-capable):
I could build dhrystone with rv32imac toolchain.
freedom-e-sdk$ toolchain/bin/riscv32-unknown-elf-size software/dhrystone/dhrystone
text data bss dec hex filename
14416 1076 12296 27788 6c8c software/dhrystone/dhrystone
freedom-e-sdk-rv32imac$ toolchain/bin/riscv32-unknown-elf-size software/dhrystone/dhrystone
text data bss dec hex filename
10892 1076 12296 24264 5ec8 software/dhrystone/dhrystone
Really great…
If I understand correctly, I can.
The issue is that if we replace a 16-bit instruction with a 32-bit ebreak instruction, a branch to the following instruction does not work.
FYI
I found a way for gcc to select RISC-V architecture by -march=XXX command-line option .
According to the source code, https://github.com/riscv/riscv-gcc/blob/riscv-gcc-6.1.0/gcc/common/config/riscv/riscv-common.c, XXX can be;
rv{32|64}g[c] or rv{32|64}i[mafd]*[c]
I am getting a 404 when trying to look at the code link on page 15 (http://github.com/sifive/cinco)
Hi,
I finally got HiFIve1 on the New Years’ Eve.
I can access to the board from VMware by just connecting “Future Devices Dual RS232-HS” using pull down menu.
By creating /etc/udev/rules.d/99-openocd.rules as documented, screen works without sudo.
But "make upload" still needs sudo. I don’t know why.
$ groups
osboxes adm cdrom sudo dip plugdev lpadmin sambashare
$ ls -l /dev/ttyUSB*
crw-rw-r-- 1 root plugdev 188, 1 Jan 1 13:26 /dev/ttyUSB1
osboxes@osboxes:~/Work/riscv/sifive/freedom-e-sdk-rv32imac$ make upload PROGRAM=dhrystone BOARD=freedom-e300-hifive1
/home/osboxes/Work/riscv/sifive/freedom-e-sdk-rv32imac/bsp/tools/openocd_upload.sh /home/osboxes/Work/riscv/sifive/freedom-e-sdk-rv32imac/software/dhrystone/dhrystone /home/osboxes/Work/riscv/sifive/freedom-e-sdk-rv32imac/bsp/env/freedom-e300-hifive1/openocd.cfg
+ openocd -f /home/osboxes/Work/riscv/sifive/freedom-e-sdk-rv32imac/bsp/env/freedom-e300-hifive1/openocd.cfg -c 'flash protect 0 64 last off; program /home/osboxes/Work/riscv/sifive/freedom-e-sdk-rv32imac/software/dhrystone/dhrystone; resume 0x20400000; exit'
+ tee openocd_upload.log
Open On-Chip Debugger 0.10.0-dev-gb474c22 (2016-12-24-09:29)
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: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description 'Dual RS232-HS', serial '*' at bus location '*'
$
I hope this helps users who only have Windows machine.
Anyway I can upload a program by using sudo.
Here is the dhrystone numbers w/o and w/ the C extension.
rv32ima:
Microseconds for one run through Dhrystone: 1344.0
Dhrystones per Second: 744.0
rv32imac:
Microseconds for one run through Dhrystone: 1448.0
Dhrystones per Second: 690.6The dhrystone numbers above was wrong. See Poor Dhrystone performance for details and the correct numbers.
Yes, this repo is still private as I mentioned. We will resolve it soon.
I’ve got my board up and running. A few notes:
-
When you set up the udev rules to allow ‘screen’ to run as a non-root user you more than likely need to remove and re-attach the board to have the device file’s permissions update. Pretty obvious but will trip somebody up.
-
the making “software_clean” between making the different demo apps to avoid linkage errors is, um, a bit obscure. It would be worthwhile to add it to the README file
-
If you use Windows on your PC, use the HiFive1 from a VirtualBox VM running Ubuntu with minimal issues. This is working very well for me.
1 Like