That’s great!
Is there a break point for the run above which the manufacturer would charge less? Or is 100 it?
I stupidly assumed that I could use the Sparfun FTDI Basic ( https://www.sparkfun.com/products/9716 )
As it’s the same chip as the FTDI breakout you have… but alas… I’m stymied.
Thoughts?
Otherwise guess it’s time to look at the STLink…
I do have a few of the pocket beagles… would be interested in your success to date…
I’m curious, what is the problem you encounter with the FTDI basic? Perhaps it’s just a matter of a few config file tweaks.
Yes possibly. I’m not near it at the moment (at work), but I wasn’t getting CLK signal on CTS
I’ll retry tonight, and document my config…
Appreciated.
I have gotten the programming to work using the PocketBeagle.
First you have to compile the RISC-V OpenOCD on the PocketBeagle. When you compile, remember to enable the sysfsgpio support.
git clone https://github.com/riscv/riscv-openocd.git
cd riscv-openocd
./configure --enable-sysfsgpio
make
After it compiles you will need to create an OpenOCD configuration file.
interface sysfsgpio
transport select jtag
sysfsgpio_jtag_nums 60 58 59 57
sysfsgpio_trst_num 52
set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x10e31913
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME
$_TARGETNAME configure -work-area-phys 0x80000000 -work-area-size 10000 -work-ar ea-backup 1
flash bank onboard_spi_flash fespi 0x20000000 0 0 0 $_TARGETNAME
init
#reset -- This type of reset is not implemented yet
if {[ info exists pulse_srst]} {
#ftdi_set_signal nSRST 0
#ftdi_set_signal nSRST z
#Wait for the reset stretcher
#It will work without this, but
#will incur lots of delays for later commands.
sleep 1500
}
halt
Set the GPIO numbers according to the ones that you connect to the various JTAG lines.
Once this is done start openocd with this new configuration file.
On your host PC tweak the Makefile to use the OpenOCD instance on the PocketBeagle.
Check the following tweets for screenshots of it working:
I have also gotten the entire Freedom-E SDK to run on the PocketBeagle but it takes a very long time to compile.
Looks like the FTDI basic only brings out 4 lines so you won’t be able to drive the reset.
You should make sure the the reset input is pulled up to 3.3V.
THIS, I’m looking forward to!
Thank you Michael and Megan both.
I’m at the wrong end of a learning curve 
I want to program a LoFive using a JTAG programmer I have to hand. It’s a BlackMagicProbe [1]. The people at BlackMagic started looking at adding functionality for the riscv E310 [2], but unluckily there are silicone bugs in the JTAG interface of the E310, so you can not execute the ‘run’ and ‘stop’ commands, see comments in [2]. As a result of those bugs development stopped.
Whilst not having ‘run’ and ‘stop’ is a bummer it should still be possible to use the BlackMagicProbe (BMP) to program the flash of the E310, so I can use it as my programming device. There’s a bit I have to do but first off I have to get an idea of the program flash of the E310. I think that the Flash chip being used is [3]. So now to add flash definition for the E310 to the BMP I need to follow these instructions [4]. E310 don’t have onboard flash, its flash is hanging off an SPI interface. So from what I’ve learned so far, I’ll need a piece of code to upload to E310 RAM which when executed will write to the SPI based flash. That code would be located in the BMP firmware source in the flashstub directory [5]
It’s starting to feel like an awful lot to chew! But hold on a moment the text book programming method is the FTDI FT2232 [6]
I don’t think that the FTDI chip is doing JTAG programming and uploading flash writing code to the E310 so there must be an In Curcuit Serial Programming interface which is simpler then all the JTAG. However I can’t see any mention of it in the datasheet. Having said that it was a brisk read through, my eyes may well have glazed over.
The simple solution would be FTDI but I’m thinking I might learn something is I get the BMP’s ‘load’ command working.
[1] 1BitSquared - Black Magic Probe V2.3
[2] RISC-V support by gsmcmullin · Pull Request #292 · blackmagic-debug/blackmagic · GitHub
[3] Page Not Found
[4] Tips for Cortex M Target Implementors · blackmagic-debug/blackmagic Wiki · GitHub
[5] github.com/blacksphere/blackmagic/tree/master/src/target/flashstub
[6] http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_FT2232H-56Q_Mini_Module.pdf
The FTDI FT2232 actually is emulating the JTAG interface for programming the device.
You will see here the connections used:
Once connected via JTAG, the OpenOCD flash command is used to program the device:
https://github.com/mwelling/freedom-e-sdk/blob/master/bsp/env/freedom-e300-lofive/openocd.cfg#L23
This requires a special patched version of OpenOCD which is delivered with the Freedom-E SDK:
Here is the OpenOCD driver for the FE310 SPI flash interface for reference:
Actually there’s another question - The readme file for the https://github.com/mwelling/freedom-e-sdk repo lists the install process as:
make tools [BOARD=freedom-e300-lofive]
make help lists that “tools” target as “Install compilation & debugging tools to target your desired board.” but no tools seem to be installed by that target. There is not “install” target in the makefile.
Maybe I’m misunderstanding the term “install” I’d have expected that the compiler and other tools would have been installed into my $PATH somewhere so that they could be executed from the command line, or other Makefiles?
The makefile actually lists the install directory as “work/install” but that make command listed doesn’t create that directory, so it doesn’t exist.
I want to program a LoFive using a JTAG programmer I have to hand. It’s a BlackMagicProbe [1]
I’ll reach out to the Black Magic Probe folks and see if we can help them out.
I don’t think that the FTDI chip is doing JTAG programming and uploading flash writing code to the E310 so there must be an In Curcuit Serial Programming interface which is simpler then all the JTAG. However I can’t see any mention of it in the datasheet. Having said that it was a brisk read through, my eyes may well have glazed over.
This is not correct, as i think you have already figured out. The OpenOCD code uses JTAG (via the FTDI) to load a programing algorithm into the E310 DTIM. It then transfers the program over piece by piece for the algorithm to program into the external SPI Flash. The code for this is linked in @m_w’s reply and in my reply in the other thread.
On a side note, if you have a Raspeberry Pi available, it is possible to compile OpenOCD on it and use it’s GPIO for OpenOCD. I haven’t tested it with the LoFive, but it works great on the Arty… Much faster than FTDI, and it works over wifi 
The toolchain gets installed into
work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin
That might be a 32 instead of a 64 depending on which board you are building for. Similarly with openocd. Yes, this is a little odd. I don’t know why it is done this way.
Usually, dirs in $PATH are not writable by the user, so I would not expect an install by default into one of those, But installing into something like work/install/bin would be friendlier, and easier to find.
Thanks for all that. I’m talking to the BlackMagicProbe people on gitter. I think that they sort of lost interest when they found a bug in the silicone which meant that the gdb ‘run’ and ‘stop’ commands wouldn’t work. I guess they didn’t think there was much point in a GDB device with those constraints.
Yes it turns out the FTDI chip is emulating JTAG, didn’t expect that, I’ve ordered one up so before the end of the week I’ll be flashing the device one way or another.
Yes to the RPi I’ve a few kicking about and I’ll use that. I’ve not got a Wifi dongle which makes moving files between a dev machine and the programmer a bit of a pain. The FTDI 2232 board looks fairly painful as well with its two rows of double headers. Not very breadboard compatible. I might have mis-interpreted the picture though.
Still like the BlackMagicProbe as it’s so small and portable. It was a learning exercise as much as anything else to get used to tool chains etc etc.
Ok that’s where I’m using it from but I thought that couldn’t be correct. Just a question of communicating makefiles and the like to people. Nothing would be portable as everything would be Dependant on a local install of the toolchain.
I’m not an authority but I’m more used to just using “make” for that style of local build and then “sudo make install” if you wanted a system wide install to somewhere on the $PATH
So my quest for a programmer to flash some code into the LoFive has brought me to the RPi. I decided that since the LoFive version of the freedom-e-sdk includes OpenOCD I’d install that. It might take a long time to actually build the cross compiler on a lowly RPi, but I’m not going to be compiling large project for the moment. That was the idea but it’s not working out at all. When I execute the make command:
make tools [BOARD=freedom-e300-lofive]
That command has worked on my laptop, but on the RPi it give me the error message:
/bin/sh:1 /home/pi/riscv/freedom-e-sdk/riscv-gnu-toolchain/configure: not found
I’m happy with that error message. That file is certainly not there. I’m not finding anything relevant on the Internet, obviously not many have attempted this on an RPi. If anybody has done this and know what the trick is I’d be very grateful
Thank You Jim Wilson for your help through that senior moment. I’m so used to entering a simple git clone command that I completely missed the recursion in the operation.
I’m restricted to number of posts in a thread so have to edit the previous post. Sorry for that noise
Did you use the --recursive option when you git cloned the tree as mentioned in the README file? If not, then you need to do
git submodule update --init --recursive
after the git clone. This is mentioned in other places, like the riscv-gnu-toolchain README, but doesn’t seem to be mentioned in the freedom-e-sdk README.
You dont have to build the entirety of Freedom-E-SDK on the RPi, though that is certainly an option.
I only built OpenOCD on the Pi, and then use my host computer for building RISC-V applications and debugging them using GDB to connect over a TCP connection to OpenOCD running on the PI.
Once your Pi is up and running, you can use the following commands on the Pi to clone the OpenOCD repo and build with support for the Pi’s GPIO pins:
cd riscv-openocd
./bootstrap
./configure --disable-werror --prefix=/opt/riscv --enable-sysfsgpio --enable-bcm2835gpio
make -j 4
make install
Takes about 10 minutes. The result is an OpenOCD binary in your /opt/riscv/bin directory.
From there I created 2 OpenOCD config files: openocd.cfg and raspberrypi3-native-jtag.cfg
openocd@piopenocd:~ $ cat openocd.cfg
source raspberrypi3-native-jtag.cfg
transport select jtag
adapter_khz 1000
source [find board/sifive-e31arty.cfg]
You will want to replace sifive-e31arty.cfg with sifive-hifive1.cfg for it to work with the LoFive… and remove all the ftdi references in that file (located in /opt/riscv/share/openocd/scripts/boards).
raspberrypi3-native-jtag.cfg is based off the raspberrypi2-native.cfg included with OpenOCD, but I altered it to include the proper speed values for the Pi3, and to use JTAG:
openocd@piopenocd:~ $ cat raspberrypi3-native-jtag.cfg
#
# Config for using Raspberry Pi's expansion header
#
# This is best used with a fast enough buffer but also
# is suitable for direct connection if the target voltage
# matches RPi's 3.3V and the cable is short enough.
#
# Do not forget the GND connection, pin 6 of the expansion header.
#
interface bcm2835gpio
bcm2835gpio_peripheral_base 0x3F000000
# Transition delay calculation: SPEED_COEFF/khz - SPEED_OFFSET
# These depend on system clock, calibrated for stock 700MHz
# bcm2835gpio_speed SPEED_COEFF SPEED_OFFSET
#rpi 1 (700MHz)
#bcm2835gpio_speed_coeffs 113714 28
#rpi 1 (900MHz)
#bcm2835gpio_speed_coeffs 146203 36
#rpi 3 (1200MHz)
bcm2835gpio_speed_coeffs 194938 48
# Each of the JTAG lines need a gpio number set: tck tms tdi tdo
# Header pin numbers: 23 22 19 21
bcm2835gpio_jtag_nums 11 25 10 9
# or if you have both connected,
# reset_config trst_and_srst srst_push_pull
# Each of the SWD lines need a gpio number set: swclk swdio
# Header pin numbers: 22 18
#bcm2835gpio_swd_nums 25 24
# If you define trst or srst, use appropriate reset_config
# Header pin numbers: TRST - 26, SRST - 18
bcm2835gpio_trst_num 7
#reset_config trst_only
bcm2835gpio_srst_num 18
#reset_config srst_only srst_push_pull
# or if you have both connected,
reset_config trst_and_srst srst_push_pull
Now connect the GPIOs defined in the config file to the appropriate pins on the LoFive, and start OpenOCD from the same directory as openocd.cfg.
With luck you will get a good read out from OpenOCD stating that it found the device and is waiting for a connection. From your host computer, in Freedom-E-SDK, just replace localhost in the Makefile with the host name of you Pi or it’s IP address. You can also connect remotely over Freedom Studio.
This all worked surprising well for me, and the performance is lightyears better than FTDI (even over wifi)… not to mention foregoing all the driver headaches those devices bring.
I’m hoping to write a blog about this soon. Who knows maybe we will ditch FTDI for OpenOCD running on one of our own boards 
3 Likes
Thanks a million @DrewatSiFive for that detailed post on the subject. It was invaluable when I got back to it, but I went down a different direction from yours initially. I had other things to do so was happy enough to build the whole LoFive version of the Freedom-E SDK onto a RaspberryPi 2, I had sitting around. God knows how long that took I just started it and walked away.
I don’t think it’s possible to Fork a github wiki, if I could do that I’d add another RPi specific page, to the LoFive wiki, with what I’ve found on getting this working on the RPi. At present that single wiki page only deals with the FTDI 2232H board. That’s fine but there’s not a lot of info out there on getting the LoFive working with the RPi and OpenOCD, so I’m sure this will come up again, there’s probably a lot more RPi’s out there then FTDI FT2232H boards.
What I’ve found building the LoFive Freedom-E SDK on a RPi-2 is that when you attempt to execute that version of OpenOCD you get the error message:
Error: The specified debug interface was not found (bcm2835gpio)
From your instructions it’s easy to see the reason for that, the build configuration line:
./configure --disable-werror --prefix=/opt/riscv --enable-sysfsgpio --enable-bcm2835gpio
So the OpenOCD configuration in the build of LoFive Freedom-E SDK doesn’t include the RPi stuff. I’ve gone back to the LoFive Freedom-E SDK version of openocd and built it using your instructions, installing to /opt and it’s up and running. I connected up the LoFive and kicked off openocd getting promising results:
pi@raspberrypi:~/riscv $ sudo /opt/riscv/bin/openocd
Open On-Chip Debugger 0.10.0+dev (2018-01-11-16:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdo = 9
BCM2835 GPIO config: trst = 7
trst_only separate trst_push_pull
adapter speed: 1000 kHz
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG only mode enabled (specify swclk and swdio gpio to add SWD mode)
Info : clock speed 1001 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (SiFive, Inc.), part: 0x0e31, ver: 0x1)
Info : Examined RISCV core; XLEN=32, misa=0x40001105
Info : Listening on port 3333 for gdb connections
Info : [0] Found 2 triggers
halted at 0x0 due to debug interrupt
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
I had to “sudo” it, as there’s a permission error when executed as normal user, not a big swing.
There was of course a problem but it might be my understanding of gdb and openocd. When I try to connect to the server with the command:
./freedom-e-sdk/work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin/riscv64-unknown-elf-gdb ./freedom-e-sdk/software/demo_gpio/demo_gpio
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x00000000 in ?? ()
(gdb) load
Error erasing flash with vFlashErase packet
I’m ssh’d into the RPi so I’m using localhost at the moment. It’s very promising it appears to recognise that it’s talking to a riscv. I’ve never used OpenOCD before so I’ll just go have a look at the User Manual, trace down the reason for the erase problem. It has to be read now anyhow 
Thanks a million again for your instructions, like i say invaluable.