My VisionFive 2 is misbehaving to the point where it won’t boot properly. I’ve attempted to reflash both over tftp and by sending the files over xmodem and both seemed to go ok but the system isn’t working and I can’t determine what’s failing. Before reflashing I was getting various differnet issues during the boot sequence but it’s more consistent now.
Does anyone recognise these messages and know what I might be able to do to recover my system?
Sorry I’m not able to help but just wanted to point out that
may not be the issue as I have always gotten this on my [AFAICT] working VF2.
The messages suggests that the DTB is corrupted or at least have issues. U-boot may have commands to help you inspect the contents of the various flash regions.
Could it be a defective SPI flash? If so, they aren’t too hard to replace.
Yeah I spotted in one of the guides that the bad CRC message was listed in there so I wasn’t too worried about that as such. At this point it could be anything so looking for opinions as much as anything else. Defective SPI flash may be a possibility and is the sort of thing I was hoping would not be the source of the problem but sine the reflash hasn’t worked it’s increasingly likely - do you have any tips on replacing one of those if it’s fairly straightforward? I’ll take a look and see if U-boot can offer any sort of inspecting of the flash the board tomorrow…
I read that warning message different, that it was trying to load the das u-boot environmental variables from the QSPI NOR FLASH, succeeded in reading the data, but because it was blank (and therefore did not have the correct CRC indicating that the stored data was valid) on the very first boot it defaulted all das u-boot environmental variables to whatever was specified at compile time. “env save” would make that particular warning message vanish.
To be clear, I wouldn’t attempt this without clear evidence that the SPI flash is malfunctioning. To me it still seems most likely that we don’t have the correct bits in place.
FWIW, I never used YMODEM to update anything. I was able to boot from the rescue buildroot image and use flashcp commands (as described in the guide), but I take it you can’t do that.
Correct … Unfortunately it isn’t able to boot successfully from any of the OS images at three moment so reflashing from the running OS isn’t an option. (Not an issue with the SD card as I’ve tried now than one)
env save followed by a reset didn’t seem to make a difference to the errors unfortunately although the command did succeed:
Net:
Warning: ethernet@16030000 (eth0) using random MAC address - da:02:06:2d:31
eth0: ethernet@16030000
Warning: ethernet@16040000 (eth1) using random MAC address - 3a:19:ea:7c:93
, eth1: ethernet@16040000
## Error: flags type check failure for "ver" <= "U-Boot 2021.10 (Jan 19 20)
## Error inserting "ver" variable, errno=1
StarFive # env save
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flashe
OK
StarFive #
There are valid MAC addresses in the EEPROM INFO output earlier (those are definitely the ones associated with the hardware), but despite that it’s throwing a warning about using a random MAC address for some reason. It’s almost as though it’s not pulling out the existing information properly, or not able to write it somewhere else.
I may have a shot and just flashing a different/older firmware image on it to see if that makes any difference (I don’t expect it to, but I’m running out of things to try)
You’re lucky to be able to still talk to the sbc with the serial cable.
MAKE SURE THERE IS NO SDCARD in your SBC when you do this
Pay attention to jumper settings before and after using minicom/xmodem.
It’s not the default manufacturer settings as received when the SBC was shipped to you.
Use the bootloader recovery to get everything back to defaults.
Before using minicom/xmodem, SET THESE BOOT MODE SWITCHES ON THE SBC:
Notice the H on the SBC means HIGH(ON) and the L means LOW(OFF).
ON OFF
RGPIO_0 = 1'b RGPIO_0 | x | |
RGPIO_1 = 1'b RGPIO_1 | x | |
H________________L
Since you are already in minicom/xmodem and the BOOT MODE SWITCHES are set,
you’ll upload all three:
jh7110-recovery-20221205.bin
u-boot-spl.bin.normal.out
visionfive2_fw_payload.img
wget https://github.com/starfive-tech/Tools/blob/master/recovery/jh7110-recovery-20221205.bin?raw=true
sync
wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.8.0/u-boot-spl.bin.normal.out
sync
wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.8.0/visionfive2_fw_payload.img
sync
##sync'ing is important to written these binaries to the storage device.
##Otherwise you'll be half a firmware and you don't want that.
##I think this kind of thing may have been the source of the issue.
AFTER THE UART UPLOAD, SET THESE BOOT MODE SWITCHES BACK TO THE DEFAULTS ON THE SBC:
ON OFF
RGPIO_0 = 0'b RGPIO_0 | | x |
RGPIO_1 = 0'b RGPIO_1 | | x |
H_______________L
Afterwards you’re going to want to get the debian 69 minimal onto an sdcard
Make sure to always wipefs your sdcard before dd’ing any images on it. Don’t wipefs when the sdcard is mounted. make sure it’s unmounted before doing the wipefs.
That’s the process that I tried earlier doing the upload of all three of those over xmodem from minicom. I’ve tried again and got the same symptoms. Here’s the log from the update session (Removed a few lines of ..... from the final upload for brevity):
(C)StarFive
CCCCCCCCCCCCC
JH7110 secondboot version: 221205-74596a9
CPU freq: 1250MHz
idcode: 0x1860C8
ddr 0x00000000, 4M test
ddr 0x00400000, 8M test
DDR clk 2133M, size 8GB
*********************************************************
****************** JH7110 program tool ******************
*********************************************************
0: update 2ndboot/SPL in flash
1: update 2ndboot/SPL in emmc
2: update fw_verif/uboot in flash
3: update fw_verif/uboot in emmc
4: update otp, caution!!!!
5: exit
NOTE: current xmodem receive buff = 0x40000000, 'load 0x********' to change.
select the function to test: 0
send file by xmodem
CCCCCCCCCCCCCCCCCCCCCCCCCCCCC.
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
..............................................................updata backup section
.
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
..............................................................updata success
*********************************************************
****************** JH7110 program tool ******************
*********************************************************
0: update 2ndboot/SPL in flash
1: update 2ndboot/SPL in emmc
2: update fw_verif/uboot in flash
3: update fw_verif/uboot in emmc
4: update otp, caution!!!!
5: exit
NOTE: current xmodem receive buff = 0x40000000, 'load 0x********' to change.
select the function to test: 2
send file by xmodem
CCCCCCCCCCCCCCCCCCCCCCCCCC.
................................................................
................................................................
..............................................updata success
*********************************************************
****************** JH7110 program tool ******************
*********************************************************
0: update 2ndboot/SPL in flash
1: update 2ndboot/SPL in emmc
2: update fw_verif/uboot in flash
3: update fw_verif/uboot in emmc
4: update otp, caution!!!!
5: exit
NOTE: current xmodem receive buff = 0x40000000, 'load 0x********' to change.
select the function to test: 5
END OF SECONDBOOT
It’s just dumping me at the Starfive # prompt after those messages and isn’t even starting to boot from the image on the SD card now. I’ve also just realised that if I run mmcinfo (tried on two different cards) it’s giving me this which may be a bad sign:
StarFive # mmcinfo
Card did not respond to voltage select! : -110
StarFive #
I haven’t changed the default ‘protect’ options.
(NOTE: I haven’t adjusted any of the protect options from the Starfive # prompt)
It confirms that your FLASH chip (IC U2; 16MiB QSPI NOR FLASH; GD25LQ128EWIGR) is working, that it is probably not the source of the problem. Since you have written new data to it and been able to read data back from it.
Before:
Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
After:
Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
Is it possible that you have reset the board before the flash was fully written. There are two parts to it, the serial transfer into RAM which takes a while even at 115200bps, and then the contents of RAM being written to FLASH, which also takes a while because each sector/block of Flash need to be erased before new data can be written (typically each 4K/32K/64K takes 0.07/0.16/0.3 seconds respectively - individually insignificant, but it adds up fast).
It will take about ~22 times longer to write the much larger u-boot+sbi+dtb payload image fully to flash than the u-boot second program loader. And some of the error messages you are seeing, in my mind anyhow, might be consistent with the dtb’s being truncated. Also validate the file sizes and checksums, it might be possible that your download was truncated maybe ?
It will take about ~22 times longer to write the much larger u-boot+sbi+dtb payload image
Yeah although the messages after flashing suggest it had completed successfully (Also with it transferring over serial at 115200 I doubt the writing is the limiting factor and as per the earlier log in spend a while transferring the payload before declaring updata success (as mentioned the number of dots shown in the message isn’t representative as I cut them out but it took as long as you’d expect at 115200 baud). The checksums are good and consistent with what you have in the previous message. I can certainly do it again and leave it after the completion message but I can’t imagine that would make a difference.
I’m starting to think your power supply isn’t adequate.
What kind of power supply have you got?
So far I’ve been using it with a couple of different ones including a Xiaomi quick charger and the one for my laptop, both if which should be capable of giving a good amount and it was ok with those before this started happening.
OK Here’s another one … Can someone with a working board run mmc list on it from the Starfive prompt? It looks like it’s defaulting to the “wrong” device somehow, which may just be a side effect of the board failing to remember any of its settings …
StarFive # mmc list
sdio0@16010000: 0
sdio1@16020000: 1
StarFive # mmc info
Card did not respond to voltage select! : -110
StarFive # mmc dev 1
switch to partitions #0, OK
mmc1 is current device
StarFive # mmc info
Device: sdio1@16020000
Manufacturer ID: 3
OEM: 5344
Name: SC128
Bus Speed: 50000000
Mode: SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 119.1 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
Running boot after that doesn’t help - it just does nothing - but at least it’s found the card again…
Does anyone know what the correct values of the protect command are (There’s no obvious way to show the current values, only to set them)
StarFive # mmc list
sdio0@16010000: 0
sdio1@16020000: 1
StarFive # mmc info
Card did not respond to voltage select! : -110
StarFive # mmc dev 1
Card did not respond to voltage select! : -110
StarFive # mmc info
Card did not respond to voltage select! : -110
I have to ask; what’s your dip switches set like? With the Ethernet ports facing me, both mine are pushed to the right (which is how it came from the factory).
I marked the area of interest about the jumper settings in green.
Notice the H(high on) in blue on the board.
HIGH/ON positions are to the left in RED.
Notice the L(low off) in blue on the board.
LOW/OFF positions are to the right in BABY BLUE.
GPIO_1 in Purple is on top.
GPIO_0 in Yellow is on the bottom.
This picture shows you the default manufacturer settings.
As you stated. The switches are both flipped to the right hand side meaning off.
To do the uart upload, these switches both need to be flipped to the left hand side meaning on.
Ensure you have taken out the sdcard before powering up the board to upload.
After the uard upload, these switches both need to be flipped back to the right hand side meaning off.