HiFive1 RevB Bootloader Question


(Penguin) #1

In past experience, the jtag/debugger has been done completely in hardware or handled offchip. When I learned that the HiFive1 RevB has a bootloader that is necessary for using jlink, I became confused. I tried looking into it, but I’m still confused. Isn’t the point of an embedded debugger, or a jtag/debugger at all, is so you can debug the board and program it without any overhead? If it requires a bootloader to use, why even use jlink at all? Why not just use some bootloader like arduino does and remove the chip?

Note: I’m not trying to ask this like “uhh this was a stupid decision, whyd u do it fam”. I might even be wrong about the bootloader part being required for jlink. I’m just looking into writing a bootloader myself and am wondering why I need to keep the default bootloader around, or if I even do.


#2

I don’t think it is required for J-Link, seems like its main purpose is the same as on previous revision: an way to unbrick your board if something goes wrong in your main firmware.
I hope that in future we will use MSEL for this.


(Penguin) #3

Gotcha. If I were to wipe the memory clean, including the bootloader, would there be no other way to unbrick it if something were to go wrong? I want to wipe it clean, but am sorta afraid to do so.


#4

Well, I tried to wipe flash on my board and it works. However, with flash wiped JLinkGDBServer connects to the board successfully one time out of three, I don’t know why.


#5

Also you can use some soldering skills and SOIC clip to update your flash (as an emergency measure).


(Liviu Ionescu) #6

It may be totally unrelated, but it also may not. With the first release of HiFive1, on my macOS and with the current OpenOCD, most of the times after power up it took 2, some times 3, attempts to connect and run a successful debug session.


(Bruce Hoult) #7

If the flash is completely wiped, that’s fine. It’ll be filled with 1s, so when the on-chip boot code jumps to that it will get an illegal instruction trap and the trap handler won’t be set up and it will loop like that. The debugger should be able to connect.

The danger is buggy code in the flash that very quickly after boot puts the board into a bad state, for excample turns off all the clocks, or sets the clock to 500 MHz or something.

On a RISC-V CPU there are some things a JTAG debugger can do directly, such as reading registers, but many things require downloading a small RISC-V program into a dedicated few bytes of RAM and then running it. This requires the CPU to be working.

See the RISC-V Debug Specification if you’re interested https://riscv.org/specifications/debug-specification/