cpu.freq 750 MHz ? That seems bogus. AFAIK, it’s 1.5 GHz.
I’m doing a build release of the rust tide project.
sudo apt-get install libssl-dev
git clone https://github.com/http-rs/tide.git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
git clone https://github.com/rust-lang/rust-mode.git rust-mode
emacs -nw --color=no .emacs
emacs -nw --color=no .bashrc
cd tide/
rustup toolchain list
nightly-riscv64gc-unknown-linux-gnu (default)
time cargo build --release
Compiling tide v0.17.0-beta.1 (/home/linux/tide)
Finished release [optimized] target(s) in 6m 23s
warning: the following packages contain code that will be rejected by a future version of Rust: nom v5.1.2
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`
My specific sdcard performance:
- throughput
dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.0563 s, 89.1 MB/s
- latency
dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 7.67565 s, 66.7 kB/s
thanks for trying the image … i think it is far from perfect and also one of the reasones why starfive based their image on a snapshot is the unstable nature of debian unstable for riscv64 i guess as depending on the day some things might break or work again
besides that it seems to be useable, although performance seems to be slightly lower than with the starfive image (estimated via “7z b”) - i assume its as the starfive toolchain maybe is optimizing better for the jh7110 already
i was also fighting with the debian key issues and my workaround to make it work at all for me was imagebuilder/sidriscv-riscv64-sources.list at main · hexdump0815/imagebuilder · GitHub which is definitely not the best solution (as it can be compromised worst case) but it works - it should be replaced with something better as soon as it is clear what else works as good in a cleaner way
best wishes and enjoy playing around with it - hexdump
I’m still using your image, did apt-get update/upgrade a few times with it. no issues.
I noticed I was still using v2.6.0 firmware so I went ahead again and updated to VF_v2.8.0 firmware from vf2-sid.
Here are all my steps:
cd /root/
apt-get install mtd-utils
wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.8.0/visionfive2_fw_payload.img
sync
wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.8.0/u-boot-spl.bin.normal.out
sync
cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
mtd_debug info /dev/mtd0
mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_NORFLASH
mtd.size = 131072 (128K)
mtd.erasesize = 4096 (4K)
mtd.writesize = 1
mtd.oobsize = 0
regions = 0
flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 32/32 (100%)
Writing data: 127k/127k (100%)
Verifying data: 127k/127k (100%)
flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 683/683 (100%)
Writing data: 2731k/2731k (100%)
Verifying data: 2731k/2731k (100%)
sync
exit
exit
shutdown -h now
@omac777 - thanks a lot for the feedback and i’m very happy to hear that it seems to work for others quite ok as well
myFirstVF2UartOutput15Feb2023.txt (50.6 KB)
I just got my uart-usb dongle from aliexpress.
Yey! It works. Here’s my first dump after powering up the VF2.
Yes, this is the output from the experimental debian sid image and not from the official 55 nor official 69 image.
This is so great! Your image even supports 4K resolution in X out of the box! Going to explore it in more detail tomorrow since it is already 03:47 in the morning here (Europe/Germany). Btw. I am the guy who asked you for that Odroid U2 server image a while ago.
regards,
Lars
@IOOI-SqAR - i’m happy the image works good for you and nice to meet you here again - you always meet at least twice in life
Thanks much for this – glad to have HDMI back.
I was unaware of resize2fs alike command for btrfs
btrfs filesystem resize max /
Tried to move root partition to an nvme partition via btrfs replace /src /dest /mountpoint, but booting failed afterwards, due to io-error. Is it a better way to migrate root filesystem?
The other method for the original starfive image using dd worked like charm, but i would like a sid image.
Install the ports keyring package:
apt install debian-ports-archive-keyring
thanks a lot - i’ll give it a try for the next image i’m going to build
Hi @hexdump0815
As you are using btrfs for your image and unstable/experimental sources, could you please consider adding this handy tool for btrfs snapshots? It could save a lot of time if upgrade goes wrong.
Hi @hexdump0815 does this release of your image support the latest firmware v2.10.4? If not, will you release a newer version of your image?
Thanks,
Lars
If I’m not mistaken, it won’t boot with latest SPI bootloader, since that one requires the boot FAT partition as 3rd now. The first two partitions are intended for SPL and U-Boot image, separated now, but of course not required if the SPI bootloader is valid.
However, @hexdump0815 actually the system boots with a single ext4 partition as well. The bootloader first fails to load uEnv.txt
etc from the non-existing 3rd FAT partition, but then falls back to loading extlinux from any partition it finds. As it does not load uEnv.txt
then, and the RAM addresses for compressed kernel extraction are still not set in the latest SPI bootloader, the kernel image however needs to be extracted for this to work.
@lampra - i’ll take a note and will have a look at it, but i cannot promise anything short term … in general i prefer to only use btrfs only without any fancy features as that seems to be rock solid - from what i read there seem to be quite a few bugs in it if one is doing advanced stuff with snapshots and raid …
@IOOI-SqAR - i did not get yet to testing it, but in case it breaks with the new firmware i’ll for sure create a new image working with it again - it just might take a week or two until i get it done and tested in that case … so any feedback if it works with the new firmware or not would be very welcome.
@MichaIng - thanks a lot for this info - looks like i’ll have to look into it then … i’ll most probably then also create an image with u-boot and sbi on it, so that it can then even boot in sd card mode … not sure if i’ll get to it this weekend or next one maybe
Hi @hexdump0815 , I hesitate to upgrade my firmware to version 2.10.4 yet, since I fear to lock myself out of the machine: there seems to be no sshd in the new Debian image and I only have a 4K screen available which the current image still doesn’t support, so no way for me to log in to it and install sshd …
kind regards,
Lars
no problem - i’ll have a look at it, it just might take a few days until i get there …