OTP wipes backup1 on reset?


Is the OTP code for hifive1-revB available somewhere? It seems it wipes the backup1 register when the reset button is pressed for some reason.

Given that the backup registers should be usable by the “main” software I find this perplexing. Why is this done? Also it only seems to happen on the revB, original hifive1 doesn’t seem to have this issue.

(Jim Sughrue) #2

Hi Almindor,

I’m guessing that backup memory is used for boot recovery mechanism but I need to confirm this.

The OTP code is available in section 5.1 of the FE310-G002 datasheet: https://sifive.cdn.prismic.io/sifive%2F3d777659-a0dd-49ed-a011-5bebba17aecf_fe310-g002-ds.pdf

This backup memory may be used for the boot recovery mechanism described in section 9.1 of the HiFive1 rev B Getting Started Guide? https://sifive.cdn.prismic.io/sifive%2F4f5a7851-1b52-463b-a293-f352036bc809_hifive1b-getting-started-guide_v1.1.pdf

Also note that the HiFive1 rev B firmware binaries are downloadable here: https://sifive.cdn.prismic.io/sifive%2Fcb1c11a9-08ed-4688-b4fe-954030f7c7b7_hifive_revb_bootloader.zip

(Ken Rabold) #3

Can the source for the HiFive1 Rev B bootloader be posted to GitHub? Binaries are good for reflashing, but it would be useful to know what that bootloader is doing.

The source for bootloader of the first rev of the HiFive1 is here:

so why isn’t the rev B bootloader available too?


No it’s not, at least if you’re referring to the bootloader code on 0x20000000 then that one has been wiped by me and replaced with a simpler version since I noticed it interefered with PMU operation as well.

The reason why I even noticed this was because @Disasm disassembled the OTP (to an extend) and found out it did something fishy with backup1 which I then confirmed with my PMU sleeper/counter program. It simply resets backup1 to 0 if the reset condition is set to button. We just have no idea why, and why this is so only on the revB.

  1. OTP code in the FE310-G002 datasheet is wrong: in my chip it jumps to 00020010 in OTP and executes a lot of code. This code checks first flash memory bytes and pmucause register. In some conditions this code uses backup1 as a counter.
  2. This section is about bootloader in Flash, not OTP

(Jim Sughrue) #6

Thanks for reporting the additional information.

I’ve confirmed that that the OTP code is incorrectly documented in the datasheet. I’ve opened an internal ticket to track and resolve this document update.

I’ve located the source of the OTP code that’s programmed on production FE310-G002 devices. This code is in a private repo. I can confirm that it does use backup1 reg as you’ve observed. I’ve asked about publishing the source code and one concern is that it uses proprietary libraries which are not published so it would take effort to port this OTP code to the public freedom-e-sdk.

I wanted to circle back to the original question of “Why is this done?”. This write to backup1 reg appears to be a SPI flash recovery mechanism counter tracking the recovery attempts to read the SPI flash ID. After the fifth failure to read SPI flash ID after power cycling the program will enter a tight loop.