So I recently acquired a RED-V Redboard. I have been trying to get it working.
I have compiled a GCC toolchain with the tuple riscv32-unknown-elf and I have compiled riscv32-unknown-elf-gdb. I also have compiled QEMU to emulate RISCV so I have qemu-system-riscv32 installed.
I have temporarily uploaded by program to github so you can see the code and makefile here https://github.com/EchelonX-Ray/riscv32_testing . The sparkfun-welcome program files are there only as comparison.
Here is the problem. If I setup the linker script to use starting address 0x2040_0000, I can get it to work under QEMU emulation. However, when I use 0x2000_0000 per the SOC datasheet default, on my real hardware, nothing happens and I don’t see any output on the UART or LED. When I compared the addresses against the sparkfun-welcome, I’m pretty sure I’ve blown away the factory bootloader. But that shouldn’t be a problem if I can find where Sparkfun posts the ihex for it so I can reflash it. I have not been able to reflash the sparkfun-welcome program and have it work.
To run it under QEMU, I can use this cmd line: “qemu-system-riscv32 -nographic -kernel ~/devel/git/riscv32_testing/src/prog -M sifive_e” . It’s possible that there is a problem in my conversion to ihex, but I doubt it. I’d appreciate some guidance on what might be wrong and where I can find a copy of the bootloader to reflash it?
I am growing concerned that the bootloader is used as part of the reflashing process and that I might have to use an external SPI flasher to reflash the bootloader back onto the SPI chip to fix it. Please, let me know if this fear is correct or not.
I just wanted to give an update. I still don’t know where I can find a copy of the bootloader that was on it from the factory but it doesn’t really matter. I don’t really know what the purpose of that boot-loader was. Regardless, I have successfully gotten the device working. Flashing still works just fine. My concerns, in my post above, I later found to be unwarranted. The reason that I thought it was broken was because I couldn’t get any observable reaction from the device with my program, but I finally figured out how to get the GPIO to work. The UARTs are more difficult because you have to setup the core clock, use that to then setup the UART frequency divider to target the baud rate that you want, and you have to tell the GPIO controller to allow the UART to control the pins instead. This last part is a particularly difficult problem because it’s not really documented in the FE310-G002 manual. The GPIO controller MIMO register map table is missing the entries where the 2 control registers are located. There is only 1 reference to these registers in a lower paragraph. I figured it out by reading other’s source code. I hope that this is fixed in later revisions of the manual.
This thread can be closed.
If this is anything like with SiFive’s Hifive1-revB (Red-v is more or less a clone) then the “bootloader” is really just a “birck prevention”. Their code just did a double-click timeout thing that’d loop if you did it right after reset (double tap the reset button basically) so you can always recover and flash, since there are apparently states where flashing won’t work anymore.
I’ve written a replacement bootloader that doesn’t clobber one of the always on registers at https://github.com/almindor/hifive1-protector (rust).
I wouldn’t be surprised if it “just worked” for this board as well but of course do take precautions. I did look at the memory of the bootloader section and it was pretty big, it seems the redV bootloader might be bigger.