Help for broken VF2? "Error inserting "<>" variable, errno=1"

sxa · February 9, 2023, 4:55pm

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?

--------EEPROM INFO--------
Vendor : StarFive Technology Co., Ltd.
Product full SN: VF7110A1-2250-D008E000-00000966
data version: 0x2
PCB revision: 0xa1
BOM revision: A
Ethernet MAC0 address: 6c:cf:39:00:24:d7
Ethernet MAC1 address: 6c:cf:39:00:24:d8
--------EEPROM INFO--------

followed by:

In:    serial@10000000
Out:   serial@10000000
Err:   serial@10000000
## Error: flags type check failure for "stdin" <= "serial@10000000" (type: i)
## Error inserting "stdin" variable, errno=1
## Error: flags type check failure for "stdout" <= "serial@10000000" (type: i)
## Error inserting "stdout" variable, errno=1
## Error: flags type check failure for "stderr" <= "serial@10000000" (type: i)
## Error inserting "stderr" variable, errno=1
Model: StarFive VisionFive V2
## Error: flags type check failure for "eth0addr" <= "6c:cf:39:6c:de:ad" (type: i)
## Error inserting "eth0addr" variable, errno=1

For completeness if it’s useful in the analysis, immediately on powering on the board after doing the reflash I’m getting this:

U-Boot SPL 2021.10 (Jan 19 2023 - 04:09:41 +0800)
DDR version: dc2e84f0.
Trying to boot from SPI

OpenSBI v1.2
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name             : StarFive VisionFive V2
Platform Features         : medeleg
Platform HART Count       : 5
Platform IPI Device       : aclint-mswi
Platform Timer Device     : aclint-mtimer @ 4000000Hz
Platform Console Device   : uart8250
Platform HSM Device       : jh7110-hsm
Platform PMU Device       : ---
Platform Reboot Device    : pm-reset
Platform Shutdown Device  : pm-reset
Firmware Base             : 0x40000000
Firmware Size             : 288 KB
Runtime SBI Version       : 1.0

Domain0 Name              : root
Domain0 Boot HART         : 1
Domain0 HARTs             : 0*,1*,2*,3*,4*
Domain0 Region00          : 0x0000000002000000-0x000000000200ffff (I)
Domain0 Region01          : 0x0000000040000000-0x000000004007ffff ()
Domain0 Region02          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address      : 0x0000000040200000
Domain0 Next Arg1         : 0x0000000042200000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes

Boot HART ID              : 1
Boot HART Domain          : root
Boot HART Priv Version    : v1.11
Boot HART Base ISA        : rv64imafdcbx
Boot HART ISA Extensions  : none
Boot HART PMP Count       : 8
Boot HART PMP Granularity : 4096
Boot HART PMP Address Bits: 34
Boot HART MHPM Count      : 2
Boot HART MIDELEG         : 0x0000000000000222
Boot HART MEDELEG         : 0x000000000000b109


U-Boot 2021.10 (Jan 19 2023 - 04:09:41 +0800), Build: jenkins-github_visionfive2-6

CPU:   rv64imacu
Model: StarFive VisionFive V2
DRAM:  8 GiB
MMC:   sdio0@16010000: 0, sdio1@16020000: 1
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

## Error: flags type check failure for "bootargs" <= "console=ttyS0,115200  debug rootwait  earlycon=sbi" (type: i)
himport_r: can't insert "bootargs=console=ttyS0,115200  debug rootwait  earlycon=sbi" into hash table
## Error: flags type check failure for "bootcmd" <= "run load_vf2_env;run importbootenv;run load_distro_uenv;run boot2;run distro_bootcmd" (type: i)
himport_r: can't insert "bootcmd=run load_vf2_env;run importbootenv;run load_distro_uenv;run boot2;run distro_bootcmd" into hash table
## Error: flags type check failure for "bootdelay" <= "2" (type: i)
himport_r: can't insert "bootdelay=2" into hash table
## Error: flags type check failure for "baudrate" <= "115200" (type: i)
himport_r: can't insert "baudrate=115200" into hash table
## Error: flags type check failure for "preboot" <= "run chipa_set_uboot;run mmcbootenv" (type: i)
himport_r: can't insert "preboot=run chipa_set_uboot;run mmcbootenv" into hash table

If anyone can offer any tips they’d be gratefully received.

Thanks,

Stewart…

tommythorn · February 9, 2023, 5:35pm

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.

sxa · February 9, 2023, 5:52pm

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…

mzs · February 9, 2023, 7:25pm

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.

tommythorn · February 9, 2023, 7:47pm

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.

sxa · February 9, 2023, 8:56pm

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)

sxa · February 10, 2023, 9:54am

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)

omac777 · February 10, 2023, 12:36pm

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.

github.com/starfive-tech/VisionFive2

Unable to recovery U-boot

opened 01:41AM - 22 Dec 22 UTC

closed 03:23PM - 22 Dec 22 UTC

agreenbhm

I built U-boot following the instructions on Github and everything seemed to com…pile properly but after flashing it seems it was a bad build. I’m trying to recover the firmware using the instructions on Github and in the quick-start guide (https://doc-en.rvspace.org/VisionFive2/PDF/VisionFive2_QSG.pdf). I have my jumpers set to 1,1, and when I boot the device I get UART output of “CCCCCCCC” (which is what I understand it should be). However, I’m unable to send the recovery firmware file successfully. I have tried two different USB-serial cables, each that seem fine. I have tried using minicom, picocom, and screen to send the file via xmodem, but no luck with anything. Using picocom (my preferred console app), I get the following: ``` CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC *** file: jh7110-recovery-20221205.bin $ sx -avO jh7110-recovery-20221205.bin Sending jh7110-recovery-20221205.bin, 1291 blocks: Give your local XMODEM receive command now. Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: NAK on sector Retry 0: Retry Count Exceeded Transfer incomplete *** exit status: 128 *** Error ``` I’ve tried resetting the device with both power and the reset button while transferring, and leaving it as is. I’ve tried with MacOS and with Kali (Kali is a VM, if that makes a difference). Still no luck though. Can someone post step-by-step instructions for what to run software-wise? Everything I’ve seen says “send the file via xmodem” but there are many possibilities of how to do that, so I’d appreciate if someone can tell me how they’ve done it.

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.

sxa · February 10, 2023, 2:31pm

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)

sxa · February 10, 2023, 2:54pm

I’ll just include the full current output when starting the board after the new reflash:

U-Boot SPL 2021.10 (Jan 19 2023 - 04:09:41 +0800)
DDR version: dc2e84f0.
Trying to boot from SPI

OpenSBI v1.2
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name             : StarFive VisionFive V2
Platform Features         : medeleg
Platform HART Count       : 5
Platform IPI Device       : aclint-mswi
Platform Timer Device     : aclint-mtimer @ 4000000Hz
Platform Console Device   : uart8250
Platform HSM Device       : jh7110-hsm
Platform PMU Device       : ---
Platform Reboot Device    : pm-reset
Platform Shutdown Device  : pm-reset
Firmware Base             : 0x40000000
Firmware Size             : 288 KB
Runtime SBI Version       : 1.0

Domain0 Name              : root
Domain0 Boot HART         : 1
Domain0 HARTs             : 0*,1*,2*,3*,4*
Domain0 Region00          : 0x0000000002000000-0x000000000200ffff (I)
Domain0 Region01          : 0x0000000040000000-0x000000004007ffff ()
Domain0 Region02          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address      : 0x0000000040200000
Domain0 Next Arg1         : 0x0000000042200000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes

Boot HART ID              : 1
Boot HART Domain          : root
Boot HART Priv Version    : v1.11
Boot HART Base ISA        : rv64imafdcbx
Boot HART ISA Extensions  : none
Boot HART PMP Count       : 8
Boot HART PMP Granularity : 4096
Boot HART PMP Address Bits: 34
Boot HART MHPM Count      : 2
Boot HART MIDELEG         : 0x0000000000000222
Boot HART MEDELEG         : 0x000000000000b109


U-Boot 2021.10 (Jan 19 2023 - 04:09:41 +0800), Build: jenkins-github_visionfive2-6

CPU:   rv64imacu
Model: StarFive VisionFive V2
DRAM:  8 GiB
MMC:   sdio0@16010000: 0, sdio1@16020000: 1
Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
## Error: flags type check failure for "fdtcontroladdr" <= "fffc6aa0" (type: i)
## Error inserting "fdtcontroladdr" variable, errno=1
## Error: flags type check failure for "eth0addr" <= "6c:cf:39:00:24:d7" (type: i)
## Error inserting "eth0addr" variable, errno=1
## Error: flags type check failure for "eth1addr" <= "6c:cf:39:00:24:d8" (type: i)
## Error inserting "eth1addr" variable, errno=1
## Error: flags type check failure for "serial#" <= "VF7110A1-2250-D008E000-00000966" (type: i)
## Error inserting "serial#" variable, errno=1
StarFive EEPROM format v2

--------EEPROM INFO--------
Vendor : StarFive Technology Co., Ltd.
Product full SN: VF7110A1-2250-D008E000-00000966
data version: 0x2
PCB revision: 0xa1
BOM revision: A
Ethernet MAC0 address: 6c:cf:39:00:24:d7
Ethernet MAC1 address: 6c:cf:39:00:24:d8
--------EEPROM INFO--------

In:    serial@10000000
Out:   serial@10000000
Err:   serial@10000000
## Error: flags type check failure for "stdin" <= "serial@10000000" (type: i)
## Error inserting "stdin" variable, errno=1
## Error: flags type check failure for "stdout" <= "serial@10000000" (type: i)
## Error inserting "stdout" variable, errno=1
## Error: flags type check failure for "stderr" <= "serial@10000000" (type: i)
## Error inserting "stderr" variable, errno=1
Model: StarFive VisionFive V2
## Error: flags type check failure for "eth0addr" <= "6c:cf:39:6c:de:ad" (type: i)
## Error inserting "eth0addr" variable, errno=1
## Error: flags type check failure for "eth1addr" <= "6c:cf:39:7c:ae:5d" (type: i)
## Error inserting "eth1addr" variable, errno=1
## Error: flags type check failure for "chip_vision" <= "A" (type: i)
## Error inserting "chip_vision" variable, errno=1
## Error: flags type check failure for "uboot_fdt_addr" <= "0xfffc6aa0" (type: i)
## Error inserting "uboot_fdt_addr" variable, errno=1
## Error: flags type check failure for "bootmode" <= "flash" (type: i)
## Error inserting "bootmode" variable, errno=1
## Error: flags type check failure for "devnum" <= "1" (type: i)
## Error inserting "devnum" variable, errno=1
## Error: flags type check failure for "chip_vision" <= "A" (type: i)
## Error inserting "chip_vision" variable, errno=1
## Error: flags type check failure for "memory_addr" <= "40000000" (type: i)
## Error inserting "memory_addr" variable, errno=1
## Error: flags type check failure for "memory_size" <= "200000000" (type: i)
## Error inserting "memory_size" variable, errno=1
Net:   
Warning: ethernet@16030000 (eth0) using random MAC address - 1a:65:71:f0:9e:86
eth0: ethernet@16030000
Warning: ethernet@16040000 (eth1) using random MAC address - b6:de:a5:ef:dc:c7
, eth1: ethernet@16040000
## Error: flags type check failure for "ver" <= "U-Boot 2021.10 (Jan 19 2023 - 04:09:41 +0800)" (type: i)
## Error inserting "ver" variable, errno=1
StarFive # mmcinfo
Card did not respond to voltage select! : -110
StarFive #

omac777 · February 10, 2023, 4:03pm

I’m starting to think your power supply isn’t adequate.
What kind of power supply have you got?

mzs · February 10, 2023, 4:48pm

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

mzs · February 10, 2023, 5:26pm

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).

(For VF2_v2.8.0)

filename: u-boot-spl.bin.normal.out 
filesize: 130688 bytes 
CRC-32: ca14da8e
MD5: c44036b3a07ec93a165b76ec3df0704e
SHA-1: 316c7be84eabbe8ab440dcd1ba4d4ac70d0ae817

filename: visionfive2_fw_payload.img 
filesize: 2797189 bytes 
CRC-32: 34d1ba5b
MD5: 21ae1a326e9ab5c52a7502da059d7bc5
SHA-1: 78b6a1526bec26b7d9d1d50c7c3001cf581003d8

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 ?

sxa · February 10, 2023, 6:00pm

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.

mzs · February 10, 2023, 6:07pm

That is me out of ideas.

sxa · February 10, 2023, 6:36pm

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)

omac777 · February 10, 2023, 11:08pm

I don’t have mmc list in the debian sid I’m running.

 # dmesg | grep mmc
[    5.473706] dwmmc_starfive 16010000.sdio0: IDMAC supports 32-bit address mode.
[    5.481053] dwmmc_starfive 16010000.sdio0: Using internal DMA controller.
[    5.487886] dwmmc_starfive 16010000.sdio0: Version ID is 290a
[    5.493691] dwmmc_starfive 16010000.sdio0: DW MMC controller at irq 29,32 bit host data width,32 deep fifo
[    5.502186] dwmmc_starfive 16020000.sdio1: IDMAC supports 32-bit address mode.
[    5.511332] mmc_host mmc0: card is non-removable.
[    5.518584] dwmmc_starfive 16020000.sdio1: Using internal DMA controller.
[    5.530137] dwmmc_starfive 16020000.sdio1: Version ID is 290a
[    5.541939] dwmmc_starfive 16020000.sdio1: DW MMC controller at irq 30,32 bit host data width,32 deep fifo
[    5.556059] mmc_host mmc1: card is polling.
[    5.750791] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 400000Hz, actual 399193HZ div = 248)
[    5.807563] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req 400000Hz, actual 399193HZ div = 248)
[    6.083515] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req 50000000Hz, actual 49500000HZ div = 2)
[    6.093564] mmc1: new high speed SDHC card at address b368
[    6.105010] mmcblk1: mmc1:b368 LX32G 29.5 GiB 
[    6.120209]  mmcblk1: p1 p2 p3
[    6.207637] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 300000Hz, actual 300000HZ div = 330)
[    6.647655] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 200000Hz, actual 200000HZ div = 495)
[    7.097676] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 100000Hz, actual 100000HZ div = 990)
[    8.887372] BTRFS: device label rootpart devid 1 transid 6203 /dev/mmcblk1p3 scanned by systemd-udevd (220)
[   39.564017] BTRFS info (device mmcblk1p3): flagging fs with big metadata feature
[   39.571489] BTRFS info (device mmcblk1p3): using free space tree
[   39.577519] BTRFS info (device mmcblk1p3): has skinny extents
[   39.615761] BTRFS info (device mmcblk1p3): enabling ssd optimizations
[   41.914658] BTRFS info (device mmcblk1p3): force zstd compression, level 3
[   41.921861] BTRFS info (device mmcblk1p3): using free space tree
[   44.656384] FAT-fs (mmcblk1p2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

It’s a good thing I tried this for you. I found out my /boot might be corrupt.

With the following:

cd /boot
touch /forcefsck

On my next shutdown and power on it will be checked.

tommythorn · February 11, 2023, 1:15am

StarFive # mmc list
sdio0@16010000: 0
sdio1@16020000: 1 (SD)
StarFive # mmc info
Device: sdio1@16020000
Manufacturer ID: 1b
OEM: 534d
Name: GE8QT 
Bus Speed: 50000000
Mode: SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 238.5 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
StarFive # mmc dev 1
switch to partitions #0, OK
mmc1 is current device
StarFive # mmc info
Device: sdio1@16020000
Manufacturer ID: 1b
OEM: 534d
Name: GE8QT 
Bus Speed: 50000000
Mode: SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 238.5 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
StarFive #

Add: even accounting for the fact I have an SDcard in there it seems to look very different for me. I’ll retry without an SDcard. Stay tuned.

tommythorn · February 11, 2023, 1:20am

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).

omac777 · February 11, 2023, 11:05am

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.

I hope this clarifies things a bit.