If I remember correctly, of the 5 or 6 Earlybird SBCs I have ordered so far, none could boot from NVME when delivered.
I often fall asleep during podcasts in which a developer shows for 4 hours how he analyses and fixes a bug in the firmware, so I like to order SBC as Earlybird. I can look over the developers’ shoulders, try to solve the problems myself at the same time, or read what solutions other users find and learn more than if I buy a fully developed version of the board later.
Thanks all, my board arrived today and I was able to piece together the steps to get it going. I found the description a bit too terse, so here’s my longer version … argh, can’t post that because it references the same link that Michael Zhu used.
I already saw solutions to upgrade firmware by using buildroot sdcardimage, but I did not noticed that so I will provide how I have solved this problem. It still may be usefull for others even it is quite builky I would say (but does not require to reflash SD card atleast :D)
Note: I have done everything mentione bellow by accesing u-boot from serial console , as well as using Linux machine, not Windows.
First stage (temporary boot debian 69 with old firmware):
Mount sd card boot partition (partition 2) to your PC:
sdc 8:32 1 29,8G 0 disk
├─sdc1 8:33 1 16M 0 part ├─sdc2 8:34 1 100M 0 part
└─sdc3 8:35 1 29,6G 0 part
Copy device tree for correct naming: cp {mount_point}/boot/dtbs/starfive/jh7110-visionfive-v2.dtb {mount_point}/boot/dtbs/starfive/starfive_visionfive2.dtb
This should help with Failed to load /boot/dtbs/starfive/starfive_visionfive2.dtb error
put SD to device and boot, wait till it fails to boot, because of: kernel_comp_addr_r or kernel_comp_size is not provided! (or stop boot manually)
Now set kernel address and size: setenv kernel_comp_addr_r 0x50000000 setenv kernel_comp_size 0x1000000
Boot again (now it should boot to login prompt): run bootcmd
This looks super promising, thank you for sharing! At step 3 currently. Not sure whether or not the green activity LED should be blinking, as I’m still not seeing anything but the red. Been waiting for about 5 minutes now- is the “wait til it fails to boot” supposed to take this long? Should there still be no HDMI output? Thank you again!!
edit: Never saw anything, so went to try this on img-55 for the hell of it but dev/mtd0 and dev/mtd1 don’t exist on there. Ah well, worth a shot!
@Maztitos, I am not sure about HDMI, I have used serial console only.
And in this step it will not boot, because you still need to set kernel_comp_addr_r and kernel_comp_size, this is why only RED light is present.
If you are not able to use serial console probably it is not possible to enter u-boot commands.
Anyway, I have tried to flash old firmware to reproduce issue and try to fix with buildroot image.
There is advantage that you do not need to use serial console but instead ssh to client instead so maybe it is easier!
From newest SDK (atm 2.6.0) assets download: sdcard.img u-boot-spl.bin.normal.out visionfive2_fw_payload.img
Flash sdcard.img to your SD CARD with balena etcher or so
copy u-boot-spl.bin.normal.out and visionfive2_fw_payload.img. (wget in buildroot is built without TLS support, so you can not download files directly):
OPTION 1: Mount this SD CARD to your computer and copy to root homepath location sudo cp u-boot-spl.bin.normal.out visionfive2_fw_payload.img /media/{user}/rootfs/root/ OPTION 2: use SCP to copy files after device boots and connects to network
Now Board should boot successfully (and green light should blink as well)
ssh to board after some time: ssh root@{boad_local_ip_address}
Password: starfive
now you can flash new firmware from this build: flashcp -v u-boot-spl.bin.normal.out /dev/mtd0 flashcp -v visionfive2_fw_payload.img /dev/mtd1
Flash Debian image to your SD card again and it will boot successfully this time.
for the u-boot and opensbi update the following guide:
for the kernel upgrade:
I use a separate debian maschine to CROSS build the custom linux-*.deb packages.
You can use the prepare steps from this guide and for the build is the following command:
make ARCH=riscv CROSS_COMPILE=riscv64-linux- -j4 bindeb-pkg
In less than 10 minutes, you’ll have built everything you need:
building u-boot: 1min
building opensbi: 10s
building spl: 1s
kernel: 7.5 minutes !!! I’m not used to short kernel builds so this was a pleasant surprise.
I’ts pretty straight forward, clone the repo, build the image, run the scripts one by one. I’ve updated the readme to include the clone/build.
Have a look inside the script to see what they’re doing, basically slightly modified commands from the technical reference manual.
The order is the same as in the readme, and the manual.
Regarding docker installation I’m afraid I have to point you to your distro’s instructions or official install guide. I have a short description in another project but ymmv.
The actual image that the dockerfile pulls in is ubuntu:bionic, the same as in the manual. This is completely separate from the host OS. It should also allow for other arches as well, not only x86.
If you just run the shell you can play around in the container:
I prefer the first approach, but sometimes if you feel overwhelmed with all these missing keys, the second approach is definitely more convenient at the risk of introducing malware, but if your repo is simply debian I would place a high-level of confidence there is no malware. The other convenience is that iirc there would be an updated developer keys package that updates the public keyring with the newer developer public keys on your behalf. Similar stuff like this occurs on Fedora as well.
gpg --keyserver keyring.debian.org --recv-key E852514F5DF312F6
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0