Is it possible to write simple programs for the lofive boards w/o the full RISC-V gnu toolchain?
Could I connect via serial and program simple algorithms or I’ll need to full gnu risc-v toolchain?
Please note the LoFive is not our product and we can’t support things such as how to load programs on to it.
Our HiFive1 board has a USB-to-JTAG (and serial) FTDI chip for programming the FE310 SoC. As I understand it, the LoFive doesn’t have this, so you have to provide and understand how to use your own JTAG interface. I believe a suitable one based on the FTDI chip was offered in the GroupGets campaign, but if you have an Olimex or other JTAG programmer then that would probably work too.
We don’t have instructions for how to do this, because our HiFive1 board has the USB-to-JTAG interface built in.
As for the toolchain, if you are using our freedom-e-sdk then the program upload script expects to find an elf file containing the program. You need to create that somehow, and using at least the gnu linker and/or assembler is by far the easiest way to do it. Using the C compiler as well is usually a much better idea.
If you understand RISC-V binary code you could in theory connect to the board using OpenOCD and use gdb to poke binary code directly into scratchpad RAM and then run it. I’ve had to work like this in the past (for example on the Apple ][ in 1980, and original Macintosh in 1984, both using “poke” commands from BASIC) but it’s not very enjoyable to do more than one time if there is an alternative.
Hi Bruce
Thanks for the feedback, I’ll be sure to figure out how to get connected to the lowFive board but that’s not the main concern at the moment.
It’s mostly around the toolchain; the GNU toolchain is a bit inconvenient so I’d like to avoid that route if at all possible.
Manually compiling c and connecting to the board might be the most straight forward way for me to proceed.
You said you’ve done it, could you give me a high level overview of the major steps involved?
You can go into as much details as you see fit, I’d just like to get an idea of the process so that I can do the same.
Working at this level, I don’t think I should be afraid of complexity but a few guide posts along the way can help.
Best.
I don’t know how you’re going to “manually compile C” without the toolchain. That’s what the toolchain is: C compiler, assembler, linker…
The only way I’ve programmed a RISC-V board is using the toolchain and SDK we provide. That’s why we provide them. They are free and easy to use.
The only reason I’ve ever done things the hard way on other products in the past was because a toolchain was not available for them, or cost thousands of dollars. When it’s free and you can download it from github there’s absolutely no reason not to use it and that’s what we support. If you want to do something else that’s up to you, but you’ll need to figure it out yourself.
RISC-V is a UC Berkeley project but the UC Berkeley OS isn’t fully supported on GNU. I’m working to fix that but until then The toolchain isn’t available on this platform.
Would you like to go into details on doing things the hard way or you’d prefer not to?
Ok, but you won’t like it. Here’s how I did things the hard way on the first computer I used. Everything here is from memory from 40 years ago, so sorry if I make errors. But it’s more or less fried into my brain.
Here’s how you could write a program to print “HELLO\r”
a9 c8 20 ed fd # lda 'H'; jsr cout
a9 c5 20 ed fd
a9 cc 20 ed fd
a9 cc 20 ed fd
a9 cf 20 ed fd
a9 8d 20 ed fd
60
Convert to BASIC:
10 DATA 169,200,32,237,253,169,197,32,237,253,169,204,32,237,253
20 DATA 169,204,32,237,253,169,207,32,237,253,169,141,32,237,253,96
30 FOR I=0 TO 30:READ V:POKE 768+I,V:NEXT I
40 CALL 768
RUN
Once you have OpenOCD and gdb working to a LoFive or HiFive1 you could do the same thing using hand assembled RISC-V code stored starting at 0x80000000 using gdb commands scripted from bash or python or whatever.
I have no intention of ever doing this or working out the exact details. It’s painful for tiny programs and ridiculous for large ones. We have a perfectly good toolchain that works perfectly well on Linux, Windows, and Mac and probably other *nix as well. At an absolute minimum I’d use the gnu (or other) assembler and generate a motorola or intel hex file. But it’s really much easier just to use gcc/as/ld as we provide them to you.
3 Likes
This reminded me the good old mainframes times. If you remember, the front panels used to have lots of switches and lights (not even LEDs). Only by manipulating those switches and inspecting the lights, knowledgeable system engineers were able to control a room size computer by entering hex words directly into memory and executing them. I guess the term toolchain was not even coined by then…
bonus points to bruce for posting a BASIC program in 2018.
3 Likes
Hi bluebee, I wrote a little «starting up» on my blog.
http://www.fabienm.eu/wordpress/?p=1162
It’s in french but maybe it can help you.
Looks like fun!
I’ll see if I can find a jtag adaptor to connect to OpenOCD and i’ll try not to go insane.
How hard can it be to write a Phase Locked Loop algorithm in assembly?
You might also like to check out my blog on an open Arty RISC-V computer I’m developing called the ‘ArtyRV board’ (see http://lavaworkshop.tumblr.com).
The project includes an interactive RISC-V disassembler, which is built right in to the ‘RVStudio’ IDE. Currently the disassembler loads in and disassembles RV32I binary and coe files, but will soon handle Intel hex (and probably elf) files as well. There are some screencaps in the blog (see part 7) showing the output of the RISC-V disassembler.
In addition to ASM and C, I’m toying with integrating a tiny BASIC and extending it with real-time features (a 1 second ticker with independent ‘tasks’), so users can write simple home automation programs, for example. Another possibility is to offer Lua support by changing over to the RISC-V ‘Bonfire Processor’ created by Thomas Hornschuh (https://bonfirecpu.eu/).
I’m planning to implement some console commands for dumping memory contents to the terminal (as ASCII and hex), dumping disassembled code to the terminal, uploading intel hex files, jump to address, etc (these will be wrapped into the IDE as well). So you basically have real hardware (implemented in the Arty FPGA) and tools to help explore that hardware. I myself prefer real hardware (I’m an electronics design engineer, as well as a software developer).
I’d like to adapt it to support the LoFive board as well, though I haven’t begun experimenting with that yet (I haven’t got a sample LoFive board to work with). My intent is to use the UART for everything, to make things as simple and universal as possible, so it may/should work with the LoFive.
If you have any questions, please feel free to message or email me.
Blog sections include:
- Summary
- Introduction
- Finding a RISC-V core for the Arty
- Getting the RISC-V core running
- Designing a VGA video controller
- The beauty of bare metal RISC-V
- An interactive RISC-V disassembler
- Programming the ArtyRV board in C
- RVStudio gets a powerful IDE
- Where do we go from here?
1 Like
I love projects like these and this is a great example of what makes RISC-V such a great platform to learn.
Thanks for sharing your work!
Wishing I could send this post back in time to 8-year-old me playing around on my TRS-80 CoCo2! New programs were distributed in programming books, which contained BASIC listings you would type out by hand. (This was before I got a “tape drive”, which was literally a cassette player with the audio feed hooked up to a modem.) The code was punctuated by seemingly random PEEK and POKE commands scattered about to perform tasks that couldn’t be done using the interpreted language.
@teadotjay unfortunately there weren’t any home computers available when I was eight, so that was 17-year old me playing with an Apple ][. I used a CoCo just a little a couple of years later, when I’d already built a wire-wrapped 6809 computer designed by myself and a couple of friends. The stuff inside the CoCo was pretty cool … and the 6809 was a great 8 bit CPU, but just a little bit late as 16 bit was already hitting.
From my point of view the CoCo (and Commodore and Atari stuff) was frustrating because however good the electronic design they were saddled with cheap and nasty cases, keyboards, mass storage (cassette!), and poor quality video displays. Apple (and later IBM of course) did that side of things so much better that they were (to me) worth the extra money. I guess the same applied to the other (Z80) Tandy computers too.
An Apple ][+ with two floppy disk drives was actually a pretty practical computer, especially with the UCSD Pascal system.
Careful Bruce. I may have the time to publish my HiFive TINY BASIC someday. Then we’ll all be in trouble.
I’d rather see a Lisp – maybe LOGO, which just has more friendly syntax. With all that flash you should be able to support a very sophisticated environment on the HiFIve1. Heap size is the main issue, but with dynamic JIT-and-write-to-flash you could support huge amounts of user code.
I’m still deep in the books for both the E310 and RISC-V, but I’m thinking my first real program would be a RISC-V assembler that runs native on the E310. Reading in an ASCII text assembler ‘data file’ from the external flash and writing out machine code to a second ‘data file’ on the external flash. I’ve done this for the Hack CPU and I ‘imagine’ it should be just about the same for the E310. It certainly won’t be the most efficient assembler to be sure, but a starting point.
I’ve not written a ‘C’ compiler, but the same course had us write a JACK compiler (like JAVA) with two stage compile through a stack based VM where simple code optimization could be done.
The idea of assembling and compiling on the E310 is probably only interesting in an academic sort of way, but I think it would make for a neat alternative tool chain, where you don’t have to have a proprietary closed source x86 machine around just to make the E310 do something useful. 
1 Like