Unable to recovery U-boot

[agreenbhm]

I built U-boot following the instructions on Github and everything seemed to compile 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.

[MichaelZhuxx]

@agreenbhm I'm using terminator and minicom on ubuntu, here is example

• Open serial port:(make sure the baudrate is 115200)

  minicom -D /dev/ttyUSB0

• ctrl+a, and press z to enter the config

  

• Config your xmode, select the right sx

  

  

• Send the recovery binary by xmode

  

• Press any key to exit after transmission

  

• Type 0 and press Enter on your keyboard to update SPL binary .

  

• Type 2 and press Enter on your keyboard to update U-Boot binary

  

• Power off and switch jumpers back to Flash mode (RGPIO_1,RGPIO_0: 0,0).

[agreenbhm]

@MichaelZhuxx thanks for the detailed reply. It appears I have been doing the same as you've shown. I just tried again and unfortunately am still having the same issue. Perhaps there's something wrong with my board? Anything else I can try?

[MichaelZhuxx]

what's your operation system, if mac, you need install lrzsz first. e.g. brew install lrzsz, then replace the righ path of sx, like:

[MichaelZhuxx]

if windows, tera term is an option for terminal emulator

[agreenbhm]

@MichaelZhuxx using that Mac screenshot I was able to finally get it to work with my MacOS host, thank you so much! I could have sworn I tried that yesterday (I installed that Homebrew package during my previous attempts) but I must have missed something. My path for lsx was slightly different than the one you have, just in case anyone else is trying to fix the same. On mine it was /usr/local/bin/lsx, which is a symlink to /usr/local/Cellar/lrzsz/0.12.20_1/bin/lsx.

Also wanted to mention that I re-flashed the same files I compiled myself yesterday and now it works :P I guess the binaries were fine, they just had a bad flash.

[omac777]

I would recommend you add a picture of the jumper settings on the SBC board before the uart upload and after the uart upload. I have a hunch sbc users aren't setting the jumpers correctly or misinterpreting them.

[ngreve]

I have the exact same issue and I can not switch to MacOS or any other OS. I am using Arch Linux, and I've also tried to send the file using minicom and picocom, which results in the exact same error as described in the original bug report.

$ minicom -v
minicom version 2.8 (compiled Jan  9 2021)
Copyright (C) Miquel van Smoorenburg.

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version
2 of the License, or (at your option) any later version.

$ rx --version
rx (lrzsz) 0.12.20

$ picocom --help
picocom v3.1

Any updates on this?

Btw @MichaelZhuxx:

Open serial port:(make sure the baudrate is 115000) minicom -D /dev/ttyUSB0

Shouldn't the baudrate be 115200? At least that's what the documentation says on page 32

EDIT: I figured it out, this report gave me the necessary hint: https://github.com/starfive-tech/VisionFive2/issues/40

You have to make sure that only "Software Control Flow" is enabled. This is how you do it using minicom :

After making this changes to the minicom configuration, the file upload worked as expected.

[MichaelZhuxx]

@ngreve yes, my bad, should be 115200 for baudrate. generally, just make sure you disable the hardware flow control and no change on software flow(No as default)

[Dasimaladaima]

@ngreve hello, I've tried the way that you support, but the keyboard can not input. on my arch, it should be "Hardware Flow Control:NO" and "Software Flow Control:NO" it can send file and the keyboard can also input.

[ngreve]

[..] and no change on software flow(No as default)

it should be "Hardware Flow Control:NO" and "Software Flow Control:NO"

For me it also worked with Software Flow Control turned on. But sure, if turning it off works for more people, that's even better. Thanks for the update/correction.

[lilalaunebiber]

Hello, I could not solve my issue. I always get a CRC error. I tried MacOs (ElCapitan) minicom or screen, I tried Windows (11) TeraTerm and played with various serial settings. I see the "CCC", I send the file. The window tells me finished and the terminal shows me CRC, try again.

Does anybody have a hint how to solve this ?

Best wishes Lilalaunebiber

[lilalaunebiber]

After hours of making myself angry about attempts with Windows 10, Windows 11, Mac OS (El Capitane), PL2303, CP2102,... I got it with an old EEE-Laptop, MX-Linux, minicom and lrzsz-Package.

[okias]

@ngreve thank you! setting everything as shown in your screenshot solved the issue!

[AntonReinhard]

I had the same problems on arch. In the end, I managed to get it to work by having hardware flow control and software flow control on "No" and changing the xmodem send command to lrzsz-sx -X -vv since it didn't use xmodem as a protocol by default.