I am developing a small Kernel for the Hifive1, for studying purposes, but I am wondering about the bootloader since the starting guide specifies the Hifive1 Rev-B board ships with a minimal bootloader, can I then just start developing the Kernel without having to worry about the booting process? I see there are a few user-mode examples in the Freedom E SDK, so I wonder how should I handle these when I need to be in kernel mode.
Hopefully, my question makes sense.
Thanks in advanced.
As far as I understand it the bootloader code just resets everything to sane defaults and gives you a “press to stop” 1s interval in case your user (as in your code, not user mode) program brakes something in a way as to stop the CPU from receiving a new one.
In other words it resets peripherals and jumps to 0x20010000 where the “user” program is supposed to start. SiFive never gave a good explanation why this isn’t handled properly in hardware (as in a h/w button/start sequence for example) tho.
You can technically just wipe the bootloader by writing your kernel to 0x20000000 directly, but then you risk bricking it, at least according to what SiFive says. The bootloader doesn’t do any magic setup that you couldn’t do in your code, apart from the fact that Wifi and BT aren’t properly documented and AFAIK nobody got them working yet.
Yes, the bootloader is basically double_tap_dontboot example from freedom-e-sdk. On HiFive1 RevB it contains additional code for WiFi initialization (sets up SPI and sends four AT-commands over it).
But in general you should be aware of this process if the peripheral state is important for your kernel. Additionally, don’t forget about code chunks in Mask ROM and OTP, they also alter the peripheral state.
@Disasm, great. Thanks for the information, I will take the process into consideration and the chunks too.
Has there been any minimal bootloader which has been ported to the Hifive1-RevB with the exception of Coreboot?
I don’t think you really need any. It’s more of a safety cushion than a real “bootloader”. E.g. if you write your code/binary directly to 0x20000000 it’ll just work as long as your peripherals weren’t somehow persisted in some funky state from previous powerups.
I had basic LED blink programs run like this before realizing I wiped the thing.