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.
Yeah that’s what I’ve done. The start traces I’ve posted above is with both switches back to the right (as per image below) after flashing via xmodem (when they were both to the left)
Curiouser and curiouser … The printenv output on my system has just two entries - one for an ipaddr and one for netmask. I cannot update any of the ones that it’s complaining about (I get the same error, but other network related values e.g. serverip and gatewayip CAN be set and they are persistent across restarts after using saveenv). I wonder what’s making it accept some values and not others … I feel there’s a solution to my board’s problems here somewhere.
Once today when I was playing with settings and restarting it came up with all the correct values set. I’m not aware of anything I did that would have made it work this one time. Unfortunately I didn’t have an SD card in at the time so I’ve no idea if it would have booted at that point, but I’ll past in the values here so that I have a record of them:
Just had a quick look at uboot sources and how it does validate the data. Something is clearly wrong in your board as flag “i” is supposed to be for a variable that can only accept IP address.
The flag should not be set to ‘i’ when running the command by hand.
Looking at uboot again, some variable name can be linked with a pre-determined type, but if you look in /include/env_flags.h
bootmode for example do not have a pre-determined type, so from this function here: /env/flags.c#L331
It should default to string and not to IP.
Something is clearly fishy in you setup, and my gut feeling here is potentially a problem with the DRAM, I don’t have y VF2 at hand, but does the compiled uboot come with the mem test tool?
If yes I would run it to make sure that the DRAM is working properly.
Something is clearly fishy in you setup, and my gut feeling here is potentially a problem with the DRAM, I don’t have y VF2 at hand, but does the compiled uboot come with the mem test tool?
If yes I would run it to make sure that the DRAM is working properly.
Hmmm that’s definitely a possibility. It has a random command and that seems to give me this when I run it (seemingly regardless of start value)
It does occasionally come up with that when I try to boot it normally - maybe 1/20 times.
As a note to the previous points I’ve just reflashed with the older 2.4.4 and it doesn’t give me the flags type check failure messages but I guess the checks might have been added in a later version. It still doesn’t start from the SD card though and leaves me at thge Starfive# prompt again
Yes the flag check is not enabled by default, and as far as I can see in the default VF2 config is it not enabled, at least in the defconfig file for the visionfive.
Not sure why it was enabled in this build and why it is not in the default config.
