This may help:
SDIO3.0
eMMC
This may help:
SDIO3.0
eMMC
The TL;DR is to follow what’s written the mask on the board, and ignore what is the mask on the switch module.
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
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.
@remid @Aragubas This figure may help you understand the boot mode settings. Plz let me know if this helps
it does! thanks x3
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
Sure, we will add this chart in the doc later. Thanks for advise.
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.
This really is the doc we need on here. It clearly illustrates the actual behaviors.
Thanks for your advice, we have added this chart in our document below, and hope this can help you guys. @remid @Aragubas @alb
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.
In the new picture, UART should be H/H, not H/L.
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:
…mind you, I also wish for world peace and I don’t expect to get that either
Thankyou @EVoyage for the really clear chart
tks for pointing out
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.
Can you post an obsessively detailed HOWTO somewhere?
Upstream really should fix this, get rid of hardcoded crap.