Arch Linux Image for VisionFive 2

@cwt I hade to change the ownership of the /home/user because it was owned by root and it was also to much opened (755 instead of 700).

1 Like

Oh! Will fix it in the next image.

And for cross compiling, I tried it on my PC which was faster but not much. Building the kernel in VF2 itself took around 1 - 1.5 hours I can’t remember the exact time, but I didn’t feel it was too long.


I have seen on the bash history of root account all your commands.
You may probably purge it.



I am currently in the process of uploading a new image with a kernel that was built on VF2 Arch Linux with gcc12. This image also includes a patch to enable framebuffer, which allows for the display of text console on HDMI. I will edit and update my post once the uploading is completed.


If you wish to upgrade the kernel only (e.g. you have already made significant progress on the cwt4 image), you can download the kernel file from my Google Drive or Naver MyBox. Ensure that the sha256sum is correct before proceeding.


And then run the following command as root:

# cd /
# tar jxvf /[path to the file]/Kernel-VF2_515_v2.6.0-cwt5.tar.bz2

The patch files will be extracted to /home/user/VisionFive2/patches/. You can patch the existing kernel source on cwt4 image if needed.

Finally, you will need to edit /boot/boot/extlinux/extlinux.conf to add a new boot menu and set it as the default option.

1 Like

If I’m not wrong, the tar file is based on relative path not on absolute path so it will not go to the correct folder.
One way to fix it could be to add -C / at the end of the command.

BTW, thanks for the update ! I will try it soon.

1 Like

You are right about relative path, that why I cd / first, it’s just my habbit. However, the Kernel-*.tarbz2 file contains binary kernel, initrd, binary modules, and the source patches. You need source patches to patch the existing kernel source in cwt4 if you need to rebuild the kernel or compile 3rd party module.


It would be helpful to provide a tarball of the filesystem root, in addition to the disk image.

Alongside some minimal instructions on setting up the boot process.

1 Like

I was not able to boot from it: I was stuck on the cwt4 version.
So, I’ve re-flashed the TF card with cwt5 and it works well :star_struck:: the output is working (thanks to framebuffer patch) !


cwt6 should be around next week based on 2.8.0



I am a newbie on installng images for FV2.

I downloaded ArchLinux-VF2_515_v2.6.0-cwt5.img.bz2 and burnt it on a microsd-card.

But it does not boot.

What am I doing wrong?

The original Debian Image boots fine on my VF2.

Help apreciated!

Just to be sure, did you extract the bz2 file?
In other words writing the file ArchLinux-VF2_515_v2.6.0-cwt5.img.bz2 to a micro SD card won’t work.

The original Debian Image boots fine on my VF2.

You mean debian image 69?

If you can boot from that image, you should be able to boot my image. Or do you mean the debian image 55? In that case, you need to flash newer u-boot and SPL first.


I am also not able to boot from the sdcard (I am able to boot the debian image 69 otherwise).

The image results in a sdcard with 3 partitions; the third one (I expect the root partition) has 2 folders (I suppose subvolumes?): /home and /arch-minimal.

I did notice /arch-minimal/etc/fstab includes an entry for the nvme partition; I do have a NVME disk plugged, but it does not have the listed btrfs partition. Maybe that’s causing issues? Trying to boot with this entry commented out does not work either.

Could you screenshot your serial console for me?

Ha ha well of course the moment I plugged my USB-ttl, it booted fine <_<

Thanks for all your work! <3


There is something strange about my image. As you experienced, once you attached a USB-TTL to the board, it booted properly. I just encountered this too. I think I never encountered this before because I never powered off my other computer that monitors the serial console. Today, I shut it down and rebooted my board, but it wouldn’t boot. Then, I remembered your response here and tried attaching the USB end of my USB-TTL to the available port on the VF2 itself. My image just booted!

EDIT: I tried it again, but I can’t reproduce. May be I enabled something that shouldn’t be enabled yet, something that is a WIP.


Just a random though, I’ve seen something like this before on a different device, the boot process waits for input from something, the minute you plug in anything whose presence is acknowledged, the boot process can continue.

Diagnosing this is a huge headache because plugging in something to monitor what’s going on also makes the problem go away.


Good idea, I think it could even be the opposite, the unconnected receiving some electrical noise from the dry northern hemisphere winter air, and mistakes it for some input, interrupting the boot process.

If someone has their hardware handy and has had this problem, maybe try connecting only TX on the board and see what’s going on?