Used `dd` on the /dev/mtd firmware, was damage done, any way to recover?

A friend of mine accidentally used dd to flash the latest firmware files, which did not fit, when we tried again with flashcp it said they were too big. When we use flashcp to flash the firmware for 2023-02 and try to boot the 2023-02 image it does not boot. It does not boot with the switches in the default configuration or the SDIO configuration. However, sdcard.img still boots, so we can still potentially recover.

Did we accidentally overwrite something important and wreck the board by using dd? Did it overwrite part of /dev/mtd2 aka data? Is there any way we can recover from this? Where can we find the bits that are supposed to be in /dev/mtd2?

This should be what you need:

The image to copy is in that repo, in the /recovery' folder. Make sure you get the latest version:
https://github.com/starfive-tech/Tools/blob/master/recovery/jh7110-recovery-20230322.bin?raw=true

Edit: also noted here: https://doc-en.rvspace.org/VisionFive2/PDF/VisionFive2_QSG.pdf
You need a serial adaptor and serial terminal software that can send files via XMODEM (they seem to be using TerraTerm on Windows)

4 Likes

I shamelessly stole these instructions from @Michael.Zhu changed is the sdcard.img (from VF2_v2.5.0) to be the very latest revision (at the time of writing VF2_v2.11.5) and added a little bit more detail:

  1. flash the very latest sdcard.img (~800MB) into tf card;
  2. Manually change the boot switches to load the very latest first two stage bootloaders directly from the SD card (SDIO3.0) instead of the default position of the onboard flash (1-bit QSPI Nor Flash).
  3. power on and login system(user/password: root/starfive);
  4. transfer the latest uboot/spl files into board by USB or Ethernet**;
  5. flashcp command to update;
  6. re-insert the debian tf card and reboot;

** For example

# /usr/bin/wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.11.5/u-boot-spl.bin.normal.out
# /usr/bin/wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.11.5/visionfive2_fw_payload.img
# /usr/bin/sha256sum u-boot-spl.bin.normal.out visionfive2_fw_payload.img
a08455fe07679bda86ee2afa7aea35a84bf82f30ced085395058c3145a3ac74d  u-boot-spl.bin.normal.out
205fdfd84d37652f5653350e317409e9ab183b86abf9bd5b498000f0cd001f8a  visionfive2_fw_payload.img
# /usr/sbin/flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
# /usr/sbin/flashcp -v visionfive2_fw_payload.img  /dev/mtd1

In my mind you should be able to do the above using a Debian image, but for various reasons you can not. Maybe it will be fixed in some future release. Oh and instead of needing to download/transfer the first two bootloaders from the internet, when there is a perfectly valid local copy sitting on the SD card (the first 2 partitions), maybe they could just be copied from the working SD card (you did just boot using them), have their checksums/hashes validated, and written to the onboard flash.

1 Like

Easiest might be to boot from that sdcard, stop u-boot’s autoboot, and follow these instructions.

1 Like