Bootloader recovery

The GitHub - starfive-tech/bootloader_recovery needs a special compiler.

The linked releases are for cross compilation on x86.

How to do it natively on the VisionFive 2?

Do I need to build a risc v toolchain in order to get the riscv64-unknown-elf-gcc ?

1 Like

Hello rpx,

this are my steps on a debian box to build u-boot and obensbi
You have to clone all the required source and then adapt the path and it should work

cd u-boot/
make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- -j8
cd ../Tools/spl_tool/
./create_sbl /home/admin/u-boot/spl/u-boot-spl.bin 0x01010101
cd /home/admin/opensbi
make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- PLATFORM=generic FW_PAYLOAD_PATH=/home/admin/u-boot/u-boot.bin FW_FDT_PATH=/home/admin/u-boot/arch/riscv/dts/starfive_visionfive2.dtb FW_TEXT_START=0x40000000
cd ../Tools/uboot_its/
cp /home/admin/opensbi/build/platform/generic/firmware/fw_payload.bin ./
/home/admin/u-boot/tools/mkimage -f visionfive2-uboot-fit-image.its -A riscv -O u-boot -T firmware visionfive2_fw_payload.img

Thanks for comment.

Which part of your instructions build the recovery_bootloader ?

Moreover why you do cross compile when you are on the VisionFive 2?

Many thanks.

Hello @rpx,

the recovery bootloader you can download from github.

My instruction are to build the own u-boot and opensbi.
I build the u-boot and opensbi on a separet X86 Debian system.

Best regards


this repo is for VisionFive 1 based on JH7100, It doesn’t work for VisionFive 2

Thank you Michael, indeed it’s listed in the appendix for VisionFive 2.

How do you do it for the VisionFive 2 ?



this repo is for VisionFive 2 including spl tool and recovery boot, and readme has inform the steps how to recover it

BTW, the recovery mode is just for the case that data in flash has been damaged

Hm. I thought I could build the jh7110-recovery-20221205.bin from source by the code in the bootloader_recovery repo which you said is for V1 only.

So no source for the V2 recovery bin file?

1 Like

I know but it is interesting to study.

1 Like

The format of the file has changed from JH7100’s. As far as I can tell, the entrypoint is at 0x400, and if the file is modified above 0x400, it gets refused with a CRC Error.

But that wasn’t going to stop me from trying.

The length of the checksum would be from 0x400 to the end of the file, or the same thing, the file length minus 0x400.

That value comes up twice in the file, at 0x288 and 0x2d4. The former is interesting, because it is followed by what looks like a checksum. It happens to match crc32 of 0x400 to end of file. Bingo.

#!/usr/bin/env python3
from Crc import Crc
import struct
cksumofft = 0x290
def main():
    path = "rescue.bin"
    crc = Crc(model="CRC-32/ISO-HDLC")
    with open(path, "rb") as fh:
    cksum = crc.crc(data[0x400:])
    print(f'checksum is {hex(cksum)} {cksum}')
    stsum = struct.unpack("<I", data[cksumofft:cksumofft+4])[0]
    print(f'stored   is {hex(stsum)} {stsum}')
    if cksum != stsum:
        print("Checksum does not match. Patching file...")
        with open(path, "r+b") as fh:
            fh.write(struct.pack("<I", cksum))
if __name__ == "__main__":

This much is sufficient to get past the checksum problem. Enabling this:


Note that the Crc import is the one from pyamigadebug/ at master · rvalles/pyamigadebug · GitHub.

Screenshot is of course from pybbsterm, my own terminal. I used the chance to add XMODEM to it.

Knowing that I can upload and run arbitrary code is enough, so I will leave it at that and go do something else now.

I am still hopeful we will get source code proper as we did for JH7100’s rescue image.


Great comments. Thank you!

1 Like