Yes, that’s SPECjvm, not SPECint. Is there a good JITting JVM for RISC-V yet? AFAIK, Hotspot isn’t there and isn’t coming. Java and Javascript (unrelated) have both been long poles for RISC-V with most everything else being well supported.
You can send the files over with SSH
cat u-boot-spl.bin.normal.out | ssh root@192.168.1.XXX "cat > ~/u-boot-spl.bin.normal.out"
Replacing the IP with the correct one of course.
1 Like
At least one Java JVM (probably Hotspot) has supported RISC-V JIT for years now, and releases of it have been in the latest Ubuntu version for a little bit. Unfortunately, Debian is still stuck with Zero (interpreted) so I had to use the bespoke JIT test build from shipilev.net to get JIT on Debian.
1 Like
Just as a note, before running sudo /sbin/resize2fs /dev/mmcblk1p3 you’ll want to run the following:
sudo parted /dev/mmcblk1
GNU Parted 3.5
Using /dev/mmcblk1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) resizepart 3 100%
Warning: Partition /dev/mmcblk1p3 is being used. Are you sure you want to continue?
Yes/No? Yes
(parted) q
Information: You may need to update /etc/fstab.
Cheers!
-Zzyzx
You’re off a year. V1.0 was ratified in December of '21. RISC-V Vector Processing is Taking Off | SiFive - RISC-V International.
T-Head/Alibaba is the one that keeps pushing silicon (D1, BL808) that supports the INCOMPATIBLE 0.7.1 snapshot that differs from the released version in small, but important ways. The binaries are NOT compatible.
This is going to make a mess of binary compatibility in vector support for systems like Linux where the normal use of Vector is inside the application. An application needing V will have to be provided in both 0.7.1 and 1.0 formats. Some scheme somewhere is going to have to handle the case where V is used in system libraries to allow binaries to link to the correctly compiled runtimes. It’s going to get super messy when your app needs 1.0 and your precompiled libraries are a mix. There needs to be a way (soon) to mark how binaries are built so that linkers can reject/use objects and link time, whether dynamic or static.
The hope that 0.7.1 would die quietly doesn’t seem to be happening as BL808 uses it. Tool providers have rejected 0.7.1 support, so V support on these pre-release parts requires special vendor toolchains.
It’s going to be a huge mess for distributions and apps. Chip vendors can’t come around with 1.0 devices quickly enough and forget about the 0.7.1 mess, IMO.
3 Likes
good news is t-head is switching to rvv1.0 in c908 core(Used in cannan’s K230)
3 Likes
Good. Now that the specs have been frozen and have had plenty of air time in low-volume silicon, it’s time for everyone to get on board with STANDARD ways of using Vector, PTE mapping attributes, and so on. We can’t let fragmentation hold us back while we’re just getting to the launch pad of high-volume, high performance parts.
I was bummed to learn that BL808 was a D1 at hart. It’s definitely V0.7.1 and just started shipping a few weeks ago. 
3 Likes
actually d1 is even worse than bl808. Older version of c906 inside d1 uses their in-house debug spec, but newer revision switches to RV debug spec 0.13 in bl808
1 Like
Is there anything that supports it other than the Linux/Windows-only Chinese binary that has to run as root?
I looked at Segger and Openocd and failed to find a way to debug these on MacOS without virtual machines running binaries inside a container because setuid root binaries just don’t play well for me.
WCH has almost this same trait.
about t-head, I heard that they are working on openocd support. about wch, just forget about them
Regarding step 3, how do you get the ip address from the VF2 while it’s running sdcard.img when there’s no hdmi output? Both my pc and VF2 are connected to a switch, and I do see activity on the VF2 ethernet port. However, arp -a in the terminal on my PC doesn’t show the VF2 mac or ip. Thank you!
You’ll need a DHCP server that can show you all the leases. In my case, I have a MikroTik RB4011 which gleefully provides a list of all the addresses it’s leased out sorted by order of lease time remaining.
I’m lazy, I would ping the broadcast address for 1-2 seconds. And then do your “arp -a” (But I would only ever do that on a home network). ping is a command that, in the wrong hands, can do really bad things.
The first 6 digits of the MAC address you are looking for starts with 6C:CF:39
IEEE OUI registration confirms that:
6C-CF-39 (hex) Guangdong Starfive Technology Co., Ltd.
6CCF39 (base 16) Guangdong Starfive Technology Co., Ltd.
1 Like
While those will “work” – they are unfortunately likely using the ZeroVM (interpreted mode only) and probably feel not only sluggish, but you sort of feel really let down by the VF2.
I wasn’t able to find any optimized builds of the JDK for riscv64 (that specifically don’t use the “Zero VM”), so I went ahead and built one for folks to use.
While debian/ubuntu provide openjdk packages, they are built with the interpreted-only Zero VM. However, JDK 19+, offer native riscv64 optimized HotSpot server VMs, if it’s built with that feature. That’s what my build does – it supports GLIBC 2.5+, so its more compatible with various ubuntu and debian versions. You can check it out here: GitHub - fizzed/nitro: Alternative OpenJDK builds for architectures such as riscv64
It has roughly 4-8 x’ed the performance of the JVM on my VF2 and it’s currently beating my RPi4 in many tests. Would love to know what you think or if there’s any other optimizations folks can think of.
4 Likes
Yeah, I found that out too, it’s a huge hassle because there’s no easy way to get the files onto the device. The wget that’s part of busybox doesn’t do HTTPS but only HTTP and github helpfully rewrites an HTTP URL to an HTTPS one because security so that doesn’t work either. There’s no FTP present (although wget will do at a pinch), and no sftp either.
However, there is a uudecode, which is what I’m currently looking at using…
1 Like
Did you try the -O flag as mentioned later?
Here’s my version of the HOWTO notes, based on the latest release, these also correct things that don’t quite work as described in the docs.
Check latest release at Releases · starfive-tech/VisionFive2 · GitHub, currently 2.6.0 for which $releasepath is https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.6.0/ so download https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.6.0/sdcard.img
Download $release-path/sdcard.img (ca.800MB), flash to micro SD card and insert. This isn’t the full image but a stripped-down one to allow firmware flashing so doesn’t need the usual SSH-enabling hack.
Plug an ethernet cable into the left ethernet port, the right one doesn’t give you a DHCP address, and power up. The boot process may take awhile.
ssh to the device which will appear on the LAN as ‘buildroot’, user = root, password = starfive. In theory you should now do:
releasepath="https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.6.0"
wget $releasepath/u-boot-spl.bin.normal.out
wget $releasepath/visionfive2_fw_payload.img
however the Busybox wget doesn’t understand HTTPS so you need to download it on another machine:
https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.6.0/u-boot-spl.bin.normal.out
https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.6.0/visionfive2_fw_payload.img
uuencode it, paste it into an SSH session (this may take awhile, the VisionFive will appear to hang as it catches up on the pasted stream), uudecode it on the VisionFive, and then check it with md5sum, which if you’re using a Windows machine that doesn’t have it needs to be done with:
certutil -hashfile u-boot-spl.bin.normal.out md5
md5sum u-boot-spl.bin.normal.out
certutil -hashfile visionfive2_fw_payload.img md5
md5sum visionfive2_fw_payload.img
This is to make sure that nothing went wrong in the binary → text → paste → binary translation. Finally, reflash:
flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
flashcp -v visionfive2_fw_payload.img /dev/mtd1
shutdown -h now
Unplug the power to fully shut down.
Download the latest image from the Google Cloud link at https://debian.starfivetech.com/, current direct link Engineering Release - Google 云端硬盘, this is a 6GB image. Note that this will require retrying the download over and over again until it stops failing, once you get past the endless “Failed” or “Failed: Network error” problems it downloads in a few minutes.
bunzip2 starfive-jh7110-VF2*
This takes around fifteen minutes since it’s a single-threaded decompress of 16 GB of data. Write to SD card (if this had sdcard.img flashed to it earlier it’ll contain multiple partitions that may appear as odd drives, may need to delete these first and unplug and re-plug to de-confuse the OS), which also takes around 15 minutes. Finally plug into the device, wait some time for it to boot and it’ll appear on the LAN as ‘starfive’. SSH in with user = user (not root), password = starfive.
Next, fix up some missing stuff:
sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server
sudo apt install unzip
sudo apt install mtd-utils
sudo apt install usbutils
sudo apt install clang
sudo apt install make
At this point you’ve got a basic dev system up and running.
Finally, to compensate for all the junk you’ve just dumped on there in the previous set of commands:
sudo apt purge --auto-remove libx11-6 libwayland-client0
This gets rid of the GUI bloat.
5 Likes
I used a USB stick. You can mount it manually and work from there.
You can also try to mount the SD card on another machine and copy the files, before booting on the VF2.
3 Likes
What, you mean actually get up and walk across the room to plug in a USB stick when I can just sit here typing? :-).
Good point, USB stick would probably have been quicker.
1 Like