i think there are some improvments for the next Debian Release.
- /boot filesystem isnt more VFAT because of kernel updates. See issue github/linux
- IP v6 Support
- Better wifi support
- boot from nvme
i think there are some improvments for the next Debian Release.
I rebuild my kernel to add IPv6 and btrfs (and also many USB WiFi drivers), and then mount / on NVMe which already formatted to btrfs. So now I can easily snapshot subvolume and test a newer debian snapshot.
Be able to boot from NVMe is a very nice to have, but mounting /boot on SD is also OK for now.
Hello all. I’m a really new on the risc-v topic.
I will start to thank all the ones involved to provide this new SBC and one well-know OS.
But as @dtometzki said they may have some improvements.
According to me, I may ask for the following ones:
I don’t disagree with your points, but I think the VisionFive 2 is not at production level and should not be used like that for now.
Running with a closed source GPU driver (BLOB) has the problem, that it’s not guaranteed to work with newer kernels. That’s why you see that for instance in the ARM world the kernel versions are in sync with Android. Unless there is mainline support and you no longer have to rely on a BLOB.
It was suggestions. Even on ARM, rapsberry pi for instance, you can have a 6.1 kernel with the use of some closed source.
I think you can stay on that current branch (5.15 which is a LTS one) and update openssl/crypto/entropy anyway.
BTW, I missed enable /dev/net/tun in the kernel to enable VPN like (wireguard/tailscale…)
There is a lot of quality of live software missing:
The software is easy to fix
Again, I don’t disagree with the suggestions.
But as far as I know, the distros with a 6.1 kernel for a Pi 4 don’t include the Broadcom GPU driver.
You should try “sudo apt install openssl”
The Debian sid Version: 3.0.3-8 2022-06-22 is 7 months old. And since it is openssl 3.0.3-8 it should probably add access to additional ciphers not present in 1.1.1.
What should be reported back ? For a heavily customised latest longterm kernel, that is running in a custom buildroot that is then probably then Debian(ised) with “debootstrap” and pointed at a static point in time sid risc-v repository that is compatible with the kernel and installed baseline libraries. Because there are no “stable” risc-v Debian releases yet, there are some packages in “Testing” which is a good sign (If it is in Testing it can potentially make it into the next Debian release). But most are currently in Sid (“Unstable”) right now.
I was going to suggest that the time, for now at least, would be better spent testing and debugging drivers/crypto/starfive so that it can be pushed upstream. But it looks like it has been pushed upstream last month, just needs to land in the linux mainline kernel.
The encryption engines of JH7110 has the following features.
I fully agree, but a intermediate option that would help bring the JH7110 closer to having more patches submitted to the upstream Linux kernel would be to supplement the entropy with hardware using the builtin TRNG.
EDIT: They already have
The TRNG module of JH7110 provides the following features. • Ring-oscillator based entropy source • Support LFSR based digital post process • Support self re-seeding • 256-bit random number generation
Technically for the Linux kernel, they are actually using the very latest longterm kernel, looking at the spacing between selected kernels in the past, a new longterm kernel should be selected very soon, it is a bit overdue but probably waiting on a really nice one. Some Linux distributions take it upon themselves to support other kernels longer and backport patches, but picking one distribution and using their LTS kernel for your baseline would not necessarily accelerate getting patches added into the mainline Linux kernel.
One thing to always keep in mind is that developers love stability, a baseline tool-set that does not change every day, a baseline environment that is constant for at least the duration of one full release phase of a project, and a baseline kernel that ideally remains constant for as long as possible. The reason being if everything is constantly changing you have literally have no idea why things are breaking that were working and should still be working, and your time is constantly being wasted going sideways. Did I make a mistake or, is this an intermittent bug, did somebody else in an external organisation change something somewhere that broke the things I was working on. And then you need to waste time trying to workout why and fix that instead of making forward progress. It would be like trying to build a skyscraper while someone else is continuously digging up and replacing sections of the foundation. Everything will still get finished eventually, but it will take a lot longer. The way to look at the current OS is as a stepping stone to get everything to a level where it can all be pushed upstream to the mainline Linux kernel and then added to all Linux distributions. There may be some blobs like for GPU until it is open sourced, which will eventually happen. The other thing is that upgrading the baseline wastes a lot of time. In my mind they are better off sticking with the latest longterm kernel, getting EVERYTHING working, debugged and fully polished only upgrading their baseline when the next longterm kernel is selected.
I would prefer them to ship a smaller image file, you can always add what you personally want later on.
When I first login to a new system I usually do a:
$ apt list --installed > .clean_install_packages.txt
And then if I’m upgrading/replacing a system I can compare the original package baseline to what I have added since I first logged in. To remind me what I added.
sudo apt install unzip
sudo apt install gparted
sudo apt install vim
sudo apt install htop
sudo apt install usbutils
sudo apt install pciutils
sudo apt install xterm
(good Terminal - I’m a sucker for classics)
sudo apt install tcsh
(I guess you could have meant a command line terminal, I don’t like csh too old school, but I do love tcsh)
What exactly do you mean by USB tethering, like do you mean plugging your mobile phone and have it provide internet access for the board (as in “USB Ethernet interface iface usb0 inet static”) or something else ?
Again, I am new to this subject.
My suggestions may not be appropriate for this environment.
I didn’t quite understand how exactly things fit between the Starfive-provided OS and the official Debian repos, perhaps I should have started there, or even the Starfive roadmap.
I may have taken the opportunity offered by this thread too soon to suggest improvements as some things seemed to be missing compared to an OS on other architectures.
As far as Openssl is concerned, I know that you can’t go to version 3.0.x directly without having to rebuild the whole OS (at least rebuild a lot of packages and a lot of non-working cases to deal with). However, in the 1.1.1 branch there was the 1.1.1s version 2 months ago and I don’t think it’s immeasurable.
I’m glad to hear that all these improvements (trng/crypto/etc.) and I hope they will be available soon.
I saw yesterday that the latest patches pushed by Starfive https://firstname.lastname@example.org/ to the kernel regarding hibernation are based on version 6.2-rc3.
So I think they are following kernel development closely.
The only question is how fast it will come to us.
I daily use rolling release OS (Manjaro-unstable on rpi4), so I know it can be a matter of taste… and resources.
By the way, your thoughts seem well-founded and reasonable but do we have an official statement on all this?
I used to work with about a thousand software developers, so you quickly learn what is important to them, and the testers.
what is it. please detail it
Have you tried the minimal image? That should be around 500MB.
Yes that will be updated in the next image.
For the crypto engine, we have enabled the commonly used algo, and will be testing more using userspace applications. You can check /proc/crypto for supported algo.
I’m may have same issue when running Java application in Ubuntu 22.04.x on VisionFive 1. It cost 80+ seconds to just load keystore and private key. But if I switched to openSUSE Tumbleweed, it only cost about 5 seconds (still slow, but acceptable).
I was asking for an official roadmap/strategy.
May I ask for improved kernel /proc and /sys reporting.
/proc/cpuinfo does not give the cpu speed, flags, and cache size for example.
processor : 0
hart : 1
isa : rv64imafdc
mmu : sv39
uarch : sifive,u74-mc
This is helpful for the start, when there is no Wifi or LAN available. As in my case i work in another room where my router is so i have a display and keyboard or i have LAN and SSH acess. As Wifi does not work yet out of the box.
In “normal” Linux kernels i was always able to use my android phone an connect this with and usb cable to the laptop/PC/VisionFive2 and then go into Settings/ Wifi/ Thethering and activate USB-thethering in the phone. This resulted in a shared connection from the phone to the Laptop/Device/VF2. It would share the WIFI of the Phone with the device and is detected by the kernel as ehternet LAN Connection.
Hope this helps.