Flashing a bin to Hifive1 without SDK

HiFive1 Rev B
1

(This is with regard to the original HiFive1, not Rev B)

Just want to double check with you guys before I accidentally brick it… :wink:

I’m thinking about demoing running a program from my ~100 line assembler on real hardware.

I understand the OTP boot sequence and how it jumps to flash at 0x20000000. The original Freedom-E-SDK (branch v1_0) has the double_tap_dontboot bootloader code placed there which ultimately jumps to user code at 0x20400000. That much we learned on RISCY BUSINESS (shameless plug ;O).

Given that I want to use the double_tap_dontboot code already on the board, is it safe for me to simply do:

openocd -f hifive1.cfg -c "program demo.bin exit 0x20400000"

where hifive1.cfg is the appropriate openocd cfg for the hifive1 board (pulled from the Freedom-E-SDK) and demo.bin holds the raw machine code & data for my demo?

Also how do the original Freedom-E-SDK v1_0 hifive1 openocd cfg and the current Freedom-E-SDK hifive1 openocd cfg compare (should I use the newer one?)

2

Also how do the original Freedom-E-SDK v1_0 hifive1 openocd cfg and the current Freedom-E-SDK hifive1 openocd cfg compare (should I use the newer one?)

It looks like the main difference, concerning flash, is whether flash is unprotected at the end. On master there is this line:

flash protect 0 64 last off

For v1_0 this line is commented out. It doesn’t matter because the same unprotect command is issued through gdb’s monitor in either case, on master’s scripts/upload:

export GDB_PORT=3333
$openocd -f $cfg &
$gdb $elf --batch -ex "set remotetimeout 240" -ex "target extended-remote localhost:${GDB_PORT}" -ex "monitor reset halt" -ex "monitor flash protect 0 64 last off" -ex "thread apply all set \$pc=_enter" -ex "load" -ex "monitor resume" -ex "monitor shutdown" -ex "quit"
kill %1

In v1_0 this happens through a Makefile:

…
GDB_UPLOAD_CMDS += -ex "monitor flash protect 0 64 last off"
…

I’ve never tried flashing without gdb. But as you say, if you make sure you flash from 0x20400000 (never 0x20000000) I would assume it is safe because the binaries produced by the SDK start there as well.

1 Like