VisionFive 2 refuses to boot any image other than sdcard.img

This may help:

grafik

SDIO3.0
Boot mode SDIO3.0

eMMC
Boot mode eMMC

3 Likes

The TL;DR is to follow what’s written the mask on the board, and ignore what is the mask on the switch module.

1 Like

Think in terms of them being pull downs. Off is high, on is low. Once you understand this, you only need to refer to the silkscreen on the board to know what to set- 1 being “off”, 0 being “on” for the dipswitch.

It’s a re-do of their documentation. Which is and isn’t helpful.

Normally, a vendor will describe things in terms of the on/off states on the switches instead of the confusing thing done here. The map you present is a description of the signal lines…and the switches are pull-downs. So in one way it sensibly describes the state of affairs- while omitting the detail that the switches are reverse of the sense you’d normally think of them. X-D

1 Like

Now, all the explanations of the dip-switch settings aside (Which are helpful for people coming in late to this discussion so they know if they’ve not made the epiphany I had out of the box) we still seem to have a state of affairs that the silly thing won’t boot either the Buildroot or the Debian images on target off of SD. I’ve got it booted via TFTP, but that’s not…well…useful… It helps on debug builds…sorta. And, yes, I did follow the instructions on loading the firmware via U-Boot and TFTP.

So, reading the thread, I guess I’ll try DietPI next and see if that even works.

This is one of the more frustrating bring-ups I’ve had on a board like this. Well documented in some places that matter…later on… And poorly documented/explained in the crucial ones for getting it to boot right off of an SD, even if you’re using the SPI to leverage that functionality.

see my post : recover visionfive 2

@remid @Aragubas This figure may help you understand the boot mode settings. Plz let me know if this helps :innocent:

10 Likes

it does! thanks x3

2 Likes

This chart should be in the official doc, or at minimum stickied in this forum.

I understand what’s being said about pull-down states, but nowhere in the doc does it say that’s what’s being referenced, instead you’ve got a chart that references 0/1 and silkscreens that reference L/H and “ON”

Common sense would say that the chart should use the same labels as the silkscreen.

If the chart referenced ON/OFF or L/H instead of (or in addition to) 0/1 there would be no confusion

3 Likes

Sure, we will add this chart in the doc later. Thanks for advise.

7 Likes

Which is why it’s not obvious. They just labeled it 1 and 0 and all…and in MOST places, 1’s ON not OFF, which if you’re following the switch sense instead of a pulldown sense (e.g. on is 0, not 1) then you get confused as hell.

Most of us got lost there. Once I looked at their docs, I said a few choice words and it became clear.

2 Likes

This really is the doc we need on here. It clearly illustrates the actual behaviors.

2 Likes

Thanks for your advice, we have added this chart in our document below, and hope this can help you guys. @remid @Aragubas @alb

5 Likes

Now on to getting Yocto to produce consistent, clean bootable baseline images…

Got a first boot with a bit of handholding and tuning work on meta-runit to make it boot clean and nice, verified with multiple targets other than a VisionFive 2. Will be pinging StarFive’s people later today on a Twitter DM for clarification on image production rules. Will share on here for everyone trying to make a Distro work on the device via pure SD boot.

2 Likes

In the new picture, UART should be H/H, not H/L.

3 Likes

I cant help but think, reading all this, that I wish StarFive had just put a pair of pinheaders and jumpers in there; they take more space & cost more; but are much clearer to set and describe:
image
…mind you, I also wish for world peace and I don’t expect to get that either :frowning:

Thankyou @EVoyage for the really clear chart :+1:

4 Likes

tks for pointing out

5 Likes

There is a problem that firmware has to be updated for compatibility with different OS images.

We need firmware which works for any OS on SD, EMMC, NVME and in the future USB.
Any differences should be handled externally by /boot/uEnv.txt and extlinux/extlinux.conf.
Unfortunately discovery is bypassed and variables are hard-coded.
In Mar 24 u-boot, nvme scripts have been returned, but not included in the targets.

I am avoiding Visionfive’s images in favour of Armbian and looking at Ubuntu for the 6.2 kernel.
I have applied modifications bringing u-boot in line with standard and bypassing the hacks,
nearly every image works on SD, NVME, EMMC interfaces with flash boot.

4 Likes

Can you post an obsessively detailed HOWTO somewhere?

2 Likes

Upstream really should fix this, get rid of hardcoded crap.

1 Like