same here. Please don’t be in a rush cwt. I would just prefer another image to try and test it for you. I can wait. I’m pre-occupied with my 7-year old son anyways.
aha! Totally understand you, mine 4 yo daughter and 1 yo son.
@cwt Thanks for your great work! I’m learning image building. Could you open source your scripts to build this image or point to some reference materials? Thanks!
Guys, I think I found the issue with my cwt6 image. The DTB files saved to /boot/boot/dtbs are reverting to the previous version every time I reboot. I believe my SD card has failed! Please wait while I verify this.
Update: It is verified. I’m switching to a new SD card.
Updat2: Somehow, my dtb file on the new SD also got changed. Something must overwrite my dtb. U-Boot?
@majortom Hi, I do not have a script, I did it almost manually. My initial idea was trying to use the btrfs on Debian Image 69, but then I realized that the Debian image is fixed to a snapshot version of debian which is pretty old. So I tried to use my custom kernel on Arch Linux which already published the rootfs on https://riscv.mirror.pkgbuild.com/.
By the way, there are some more details before the Arch’s rootfs can boot for the first time on VF2. I will document it later on my blog, and will post the link here.
I was told u-boot-update does something with the dtb file.
extlinux.conf is generated by u-boot-update. extlinux.conf points to the dtb file.
I just upload the hot fix cwt6.1 to my Google Drive, and Naver MYBOX.
You can just download the Kernel file and then extract it somewhere, and copy only
boot/* to a flash drive then copy it over your
/boot/ in cwt6 image.
Please post a comment if this fix your ethernet problem.
cwt6.1 fixes the ethernet for me.
Just installed arch to my new m2 ssd.
I partitioned and unpacked arch’s risc-v tarball using starfive’s debian image, then chrooted into it and updated it.
Then I copied and set up cwt’s kernel.
However, my usual encrypted swap setup doesn’t work:
Feb 09 12:51:40 StarFive systemd: Starting Cryptography Setup for swap... Feb 09 12:51:40 StarFive systemd-cryptsetup: Cannot initialize device-mapper. Is dm_mod kernel module loaded? Feb 09 12:51:40 StarFive systemd-cryptsetup: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/nvme0n1p1. Feb 09 12:51:40 StarFive systemd-cryptsetup: Cannot initialize device-mapper. Is dm_mod kernel module loaded? Feb 09 12:51:40 StarFive systemd-cryptsetup: Cannot use device swap, name is invalid or still in use. Feb 09 12:51:40 StarFive systemd-cryptsetup: Failed to activate with key file '/dev/urandom': Operation not supported Feb 09 12:51:40 StarFive systemd: firstname.lastname@example.org: Main process exited, code=exited, status=1/FAILURE Feb 09 12:51:40 StarFive systemd: email@example.com: Failed with result 'exit-code'. Feb 09 12:51:40 StarFive systemd: Failed to start Cryptography Setup for swap.
The kernel seems to have been built w/o device manager support (or something related is broken), and thus I can have no encrypted swap (or encrypted anything).
@cwt could you look into this for new release?
My intent, besides encrypting swap, was to set up LUKS for my /home partition. Any serious use is gated on having this working.
I didn’t enable device manager, I can enable it and build a new kernel.
It’s no hurry, but it’d be nice to have it enabled for the next one
Somehow, I expected X to just work via modesetting or fbdev drivers. But it does not.
What did you do to get X working? I would like to try and do it myself, to understand the steps.
I did get weston working on wayland. I never tried X. I don’t think it will working out of the box without Starfive patches. It may required binary blob too, which I don’t expected it to work because the glibc on Arch is newer than Debian.
xf86-video-fbdev driver wasn’t enough.
Section "Device" Identifier "Screen0" Driver "fbdev" Option "fbdev" "/dev/fb0" EndSection
It needed to be told this much.
So now I have X. Unaccelerated, slow, but X nevertheless.
@rvalles I just uploaded an experimental kernel that I’ve been working on. It’s quite stable and I’ve been using it as my daily driver for a week now (24x7).
DM_CRYPT, and other
DM_* modules are enabled.
The kernel was built with LLVM:
$ make -j4 LLVM=1 CC="clang -mcpu=sifive-u74 -mtune=sifive-7-series"
So if you want to build any external module or driver, please add
LLVM=1 to your make command.
Google Drive: Experimental - Google 云端硬盘
Naver MYBOX: 네이버 MYBOX
Extract them to
/ and then edit your
Grabbed your sources, gave menuconfig a once-over and I’m now building them on the VisionFive 2 itself.
It was about time I tried building a kernel on this thing. We’ll see how it goes.
@cwt The latest image ArchLinux-VF2_515_v2.8.0-cwt6.1.img (not experimental image) has two flaws…
The extracted image is 15GB. Even though most of it is empty,
ddwill still write additional 12-ish GBs to the disk and cause extra wear and tear. It is also very time consuming. Please trim the image down, 15 GB is too much. I guess you can get away with 1200MB only
The device tree is still being corrupted somehow… The
reboot +0command does not work. I can see on UART that the board is stuck and the last kernel message is:
reboot: Restarting system with command '+0'. Edit: The reset button doesn’t work either
Can you share your build scripts? Maybe I can chip in, I too prefer Arch over Debian
It wasn’t ready. Something actually failed.
Now I see why salsa20 was disabled .
I didn’t even write down the image.
With losetup and some parameter, you get subdevices for each partition. I mounted and took what I needed from /boot, and used the official root tarball from the arch risc-v port website.
Disk images are the problem. Just use tarballs instead.
There is no build script, I did everything manually as described in this post.
Unfortunately, the corruption of the DTB file is something beyond my control. I recently discovered that the file was being overwritten by the u-Boot. I hope Starfive will address this issue in future releases of their Debian image.
I am currently waiting for the delivery of the revision B board so that I can test my image on both revisions. Until then, I do not plan on releasing any new images.