Visionfive 2 won't boot or broken?

VisionFive 2 （English Forum)
, ,
1

I recently purchased a Starfive Visionfive 2 from a 3rd party seller. It was listed as, ‘for parts or not working.’ It was very inexpensive, so I figured, if it is broken, no big loss, if it isn’t and I can fix it / get it to work: great!

Anyway, it doesn’t seem to want to boot. I’ve tried several SDcard images, all the way back to the 55 early release. The board version is 1.2A.

Now, when UART is connected to minicom, when trying to boot (from SDcard), it will output the SPL version, but then, it quits, no more output.

So, I’ve been trying the recover the bootloader guide(s)?

I tried following the guide here → Board died randomly - #6 by omac777

after using minicom + xmodem and successfully sending the recovery image I get the following output after pressing enter

JH7110 secondboot version: 230322-c514da9
CPU freq: 1250MHz
idcode: 0x1860C8
[[[No more output at this point]]]

There is no more ouput after that, so I am unable to flash spl and firmware subsequently.

If I try booting from just an sd card, no matter the image (earliest 55) to later versions, I end up with the following UART output

U-Boot SPL 2021.10 (Jan 08 2023 - 18:04:54 +0800)

[or something of that nature depending on the image, nothing more]

it stops there (regardless of image)

I thought perhaps my AC-to-DC adapter wasn’t delivering enough power, so, bought a proper PD 2.0 45w usb-c power adapter, and gave all that a try again: still no luck. It doesn’t seem to be a power issue.

Other than that, my only guess is that the previous owner blew the OTP fuses in recovery mode? (Of which I don’t know much about, is that reversible if that is the case?)
I have no idea what that would do, what it means, etc…

It seems odd, in that, clearly something is working, I can get the CCCC from UART boot mode and transfer via xmodem the recovery image, but after that, no menu displays for further delivery of SPL and firmware.

I get at least one line of output in SDIO mode…

However, beyond that… This board won’t boot anything / boot at all.
I haven’t a clue at this point.

Perhaps it’s an irreversible hardware issue (damage or something)?

I also have an external chip flasher, that I could possibly use to hardware flash the (QSPI?), if that would possibly help. I wouldn’t know where to get a dump of a good image though, if there even are any.

Any ideas? Thnx!

2

yeah the dip switches are important to use as well. you are using the sdcard for now imagine.
Please note the dip switch settings to uart flash the vf2 board are different from the dip switch settings to boot from the sdcard.
You got the CCCCC from the UART so you definitely did set the dip switch settings to uart flash.
Afterwards, there is an explicit dip switch setting for explicitly booting from SD card. Use that as a last resort, but the default manufacturer settings should be good as well.

To give you more context how I screwed up my VF2,

These two files are built and customized for fedora.
NOTICE the second file is even named u-boot.itb
Not only Fedora Linux, but Arch Linux as well uses that filename u-boot.itb
Why? mainline u-boot(Fedora Linux/Arch Linux) is different from starfive u-boot.
That’s why it’s so important to flash BOTH FILES that come from the specific distro you are using be it Starfive Debian, Arch Linux or Fedora Linux.
After flashing those two files, set the dip switch settings to default or sdcard but don’t forget to do these env commands right after you power up the board in the uart serial terminal:

# Boot configuration on VisionFive 2
Hit space once you reach the `Hit any key to stop autoboot` prompt.
env default -f -a
env save

Irrelevant to the starfive debian sdcard image,
I became more aware of the existence of these commands env and eficonfig.

Having better documentation about these commands specifically for the VF2 would be very helpful for everybody. Especially when our Debian sdcard/nvme no longer boots up.

3

I understand the Dip Switches For Boot Modes

When booting in UART mode with a TTL to USB to Serial Converter and following the Bootloader Recovery no menu appears in minicom after transferring the Recover Binary :

    H7110 secondboot version: 230322-c514da9
    CPU freq: 1250MHz
    idcode: 0x1860C8
>    [[[No more output at this point]]]

According to the Recovery Documentation A menu should appear automatically; from this point one should be able to transfer an SPL (Secondary Program Loader (For Loading U-Boot)) [Option 0] and then transfer the firmware (A copy of U-Boot (if I understand correctly?)) [option 2]. At anyrate, I can’t seem to get to this point.

My minicom settings are set as described here.

I guess further questions I must answer are:
1: Does the VisionFive2 boot directly from the SD card? As in, ROM → SDcard’s (SPL) → u-boot → kernel? It seems that is the case.

Anyway, just writing this up for posterity mostly, at this point. Perhaps there is more I am unaware of / don’t understand.

The issues remain: unable to complete the recover the bootloader process (to update/alter the SPL + u-boot on the onboard flash ROM), and no official images seem to boot from the SDcard, and I’m uncertain as to why.

Thank-you for your time @omac777 . I’m not certain building an Arch or Fedora Linux image would be the route to go at this point. Pardon any errors in my understanding, if any.

4

Please be patient when you uart upload both relevant files to the VF2.
After each uart upload is successful, there is a delay in printing any output to the console yes it’s true it looks like nothing printed out…BUT YOU MUST BE PATIENT. WAIT A FEW MINUTES IF YOU MUST…there should be some output like “…” or something…then for a while again nothing and then finally a loud BEEP sound and a menu. There really is a BEEP SOUND and menu…the beep sound indicates it really uploaded successfully and both the beep sound and the menu appears after both uploads are done. If you don’t wait for the beep and menu to appear, that implies you didn’t successfully upload both binaries. Please try again and be patient. I recall it taking roughly 30 minutes for the entire process for both files to be uploaded.

1 Like
5

Still no go.

It’s possible there is physical damage to the board as well, in my circumstance; as I still haven’t made any progress.

vf2-0
vf2-01362×837 400 KB

In the red there, it seems possible a component (resistor?) was dislodged from it’s pads. There are a few undisturbed, unpopulated pads on the board, as well; that likely being intentional. However, for those two pads, it seems like something may have been there before. The picture isn’t the greatest. Not quite sure what resistor belongs there, if there is one missing. I’ll have to dig further, and perhaps continue this puzzle, or throw in the towel at some point.

Thnx!

6

I honestly don’t think there are issues with the board.
I would think it’s a step that was a mistakenly done.
Power off the board.
BOARD DIP SWITCHES set to UART MODE.

First uart upload the recovery bin file to the board:
This is the most recent: Tools/recovery/jh7110-devkits-recovery-20230918.bin at master · starfive-tech/Tools · GitHub
Use that one.

THEN
image
Within the starfive onedrive 202405 directory, there is a flash directory holding the board files you need to uart upload…
It needs to be these ones for the respective sdcard image to boot.
Then dd the .img file in the sdcard directory onto the sdcard.

dip switches set back to the default.

slip the sdcard into the board.

power up the board, IT SHOULD WORK.

I just did this today for the second time. It does really work.

I even did this afterwards:
cat /etc/apt/sources.list

deb https://snapshot.debian.org/archive/debian-ports/20221225T084846Z unstable main

deb Index of /debian sid main

apt-get update
apt-get upgrade

it will ask about some files to be replaced concerning the boot…USE THE MAINTAINER’S VERSION. Yes it booted up successfully.
The desktop is dead slow afterwards LOL, but the non-gui stuff is working and reboots successfully so that’s progress. There was a time it wasn’t booting after an upgrade to full sid.

7

recovery
recovery781×338 26.3 KB

That is as far as things go after transferring the recovery binary. It stops there (and I have waited 30+ mins for further output).

If anyone has or would care to share a dump of their main 16MB flash chip (with details of spl/u-boot version it contains), I could try to flash that (with an external programmer) to the chip and then see if a corresponding image will boot. In theory I should be able to rule out a hardware issue this way.

Otherwise, I’m stumped! heh. Thnx.

1 Like
8

yes，There should be have a resistor.
but i dont know if it will effect boot.

1 Like
9

hello, I consulted my hardware friends，he said it dose not matter.
it is a C2161

10

I have the exact same issue as yours @g1000, do you have any updates?

I posted about my experiences but I just stumbled upon this and found out that we have the same problem.

1 Like
11

I gave up some time ago.

@kira, above, pointed out C2161, which is missing on my board. I believe? that component is present on the first revision, but, is not there on the second board revision?

Eitherway, my electrical engineering skills are next to zero, so, haven’t been able to pin-down the part (capicitor?) to try and solder it in place and give it a go.

I wouldn’t mind flashing the 16MiB flash chip with a known good image, but I couldn’t source one.

So as far as I can tell; the problem is either user error, which I seem to have ruled out, a missing capicitor, or something else.

For me, recovery flashing seems to work, the image starts going down the pipes, but, nothing happens after that.

1 Like
12

However, nothing on my board seems to be missing, it is in perfect condition and notthing has bee nknocked off. I cannot source a 16mib flash chip dump aswell. I dont think anybody is willing to dump it.

It could not be user error, i have the same problem and my vf2 is brand new. it has to be something on starfive’s end or something similar. Oh well, I’ll see if i can return it.

1 Like
13

I just checked the side profile for my board, are my chips seriously not soldered on properly???

https://imgur.com/a/4bflVoq

The thing boots somewhat, i.e. it shows bare symptoms of life but again,bootloader recovery fails. Any soldering experts? @g1000 @kira @omac777 ?

14

You need a hot air station.

1 Like
15

does this imply incorrect soldering?

keen on knowing

16

possibly:

  • your uart adapter pins not properly seated into the SBC
  • the usb connector to your computer not properly seated
  • uart adapter within it the pins there might not be properly seated

It’s not your board by the looks of it. The output seems correct until it stops.

17

You have to recall sending the file down the pipes yes, but did you send it to the correct partition/mtd device? If you sent it to the wrong device it might behave this way.

then remember after flashing…when you power off and power on again, make sure you do the env stuff.

18

the UART adapter was seated. correctly. the USB was seated. the adapter was seated. I tried, no joke, over 10 times in one day.

I didnt even get to the MTD point. during the CCCCCCCCCCCCCCC I transfered the file via xmodem, and thats when it hangs.

For context, I cant boot into the u-boot shell, I cant boot into any OS, and bootloader rfecovery doesnt work with

JH7110 secondboot version <version>
CPU freq: 1250MHz
idcode: <something>