I have Debian Image 69 full, and it comes with the 5.15.0-starfive kernel. However, the GUI is fairly unstable, it has crashed on me many times in one day of usage. I’m also having troubles getting the display output to work on my monitors. I was wondering if perhaps there was a kernel update available that could help out with this. I see that 5.18.0 is available with apt, but it doesn’t end with “-starfive” (I think it’s from Debian), so I don’t know if it’s compatible.
1 Like
If you use any kernel other than 5.15.0-starfive kernel, pretty much everything that you would want to work probably will not work (yet). What most companies do is take a baseline kernel and a baseline tool set and a baseline development environment and stick to that until a major release, and then rinse and repeat until your working and debugged submissions have been accepted into the Linux kernel. Otherwise you never know if problems are from changes you made or from upstream changes by others, and you spend more time trying to track down why things break or work than actually getting them to work. It is easier to board a stationary train, than one that is travelling at maximum speed when you are still learning to walk.
4 Likes
Which is why the SBC market has such a poor general history of mainlining anything until hardware is so old, nobody needs it…
Please won’t someone reconsider this lunacy.
The only reason Raspberry Pi is so successful is they had hardware mostly supported upstream and relentlessly pushed it, ignoring that everyone else was doing a bad job. If SiFive and RISC want anything like that success, they are going to need to adopt customer-focused practices.
1 Like
Except for they did not, and mostly still do not because of the oddball GPU blob booting and custom RPI hardware quirk workarounds that are never upstreamed to the Linux kernel. Raspberry Pi did not push upstream they forked the kernel and update their own copy with the required kludges, quirks and quick fixes to keep the RPi hardware happy.
Here is a locked thread on the subject: https://forums.raspberrypi.com/viewtopic.php?t=183990
2 Likes
Raspberry pi has upstreamed a lot, kludges and all to the kernel and is a lot more tightly integrated than most other SBC’s I’ve seen. Including this one running 5.x kernels while rpi et-al enjoy 6.x
Latest Raspberry Pi OS Release Brings Linux Kernel 6.1 LTS, Chromium 113, and More - 9to5Linux.
The biggest change in the Raspberry Pi OS 2023-05-03 release is the kernel bump from the long-term supported Linux 5.15 LTS to the long-term supported Linux 6.1 LTS . Of course, this should translate to better performance for your Raspberry Pi computer.
I’m trying to let you know, that this is currently AFAIK the gold-standard among SBC’s. While I appreciate VisionFive 2 is not for end-consumers yet, the claims made and marketing does not match up to what we are seeing.
Community supported, is not the same as integrated developed. armbian supports many newer kernels for Arm boards. But that says nothing about the manufacturer and I view as rather unfortunate where Armbian [and any community source] is doing a better job than manufacturers [for a consistent period of time].
2 Likes
The problem as I see it is the GPU, and the timetable for that is fully under the control of Imagination Technologies. Until enough source code, and documentation, is released to make use of it with any OS or distribution, it will be a problem. Everything else to do with the JH7110 has always improved with each new StarFive release. And almost everything that can be pushed upstream is being pushed upstream. The next longterm kernel should be selected sometime between October and December, hopefully before then enough has been upstreamed to enable many Linux distributions to support the VF2 boards.
And comparing StarFive today with Raspberry Pi foundation today is one ridiculous comparison. You should be comparing StarFive today with the RPi foundation when they released their RPi2 boards, which never upstreamed anything.
5 Likes
I’m comparing them to 2012 (so over a decade ago) rPi foundation, which shipped with a kernel in the release range 3.x which was the mainline release. I’ve never had this instability with a product. Don’t pretend like I’ve not been doing this for a very long time. you’re being entrenched and I don’t know why. You linked to a page stating
6.1 Greg Kroah-Hartman & Sasha Levin 2022-12-11
The 6.1 kernel, not 5.x is the longterm kernel since December 2022. My Gripe is not that they didn’t launch with 6, it’s that there is no visible window on when 6.x will be supported. I Don’t care if it’s only 6.1 supported; but it should be 6 and not below 6.1.
You do know that adding support for the JH7110 SoC began long before December 2022 (When 6.1 was selected by the Linux kernel team as a long term support kernel).
git log --reverse --grep=jh7110
Returns:
Merge: 1af825817c7a 8bb7eca972ad
Author: yanhong.wang
Date: Wed Nov 17 17:34:12 2021 +0800
Merge branch 'worklym' into jh7110_dev_5.15
Showing that work to add support for the JH7110 SoC started at least 13 months (probably longer) before 6.1 was selected as a long term support kernel. So even if they wanted to refactor the code and forward port all the patches from the 5.15 kernel to 6.1, that would have added a very significant delay and poor use of limited resources before work could resume on adding support for the desired features of the JH7110 (e.g. NVMe) and upstreaming patches could resume.
I personally feel that StarFive made a very sensible decision by sticking to their baseline. Short term pain for longterm gain.
Now if YOU want longterm 6.1 kernel support now, maybe fork the kernel.org 6.1 longterm kernel. Diff the patched StarFive 5.15 kernel with the kernel.org longterm 5.15 kernel and generate a list of patched files and seek like minded developers to port each and every patch one at a time to the 6.1 kernel. And/or backport the 6.5-rc5 patches to the longterm 6.1 kernel.
4 Likes
Who-What do you mean by “RISC” in the above? I think of it as a set of ideas about computer architecture, which wouldn’t be able to adopt anything.
1 Like
Raspberry Pi Linux 6.1 LTS
It is much easier to have good support in 6.1 when your board launched back in 2019, and hasn’t changed all that much since 2011.
The only reason Raspberry Pi is so successful is they had hardware mostly supported upstream and relentlessly pushed it
How is this effort not good enough?
4 Likes
Long before. The 7110 didn’t just fall from the sky. We’ve had U74’s in a couple of different (low-volume) devices, each capable of running multiple desktop class OSes. Rev 1 of VisionFive started with the 7100 processor. That processor appeared on expensive PC-style motherboards and hundreds of boards distributed to developers as part of the BeagleV project, which resulted in a flurry of actual development (not just mindless rebuilding and shuffling that happens so much here) of patches to the mix. When the first R2’s started shipping there were about 120 patches from THAT era that were brought along and shuffled into the sheet mentioned earlier.
Would it be awesome if Linux had a stable set of interfaces developers could program to? Don’t even answer that - they will set fire to your village upon mention of it. Would it be great if patched could be reviewed and accepted before they were obsoleted and had to be rebased? Certainly. The paths to those green squares were often a hell of a hazing ritual, but they stuck to it.
I really think that StarFive is doing all the right things here. Compare that to other chips that hit the market at about the same time like D1. It wasn’t Allwinner that got patches into review; it was end-users. They were a little later, but we sure don’t see Bouffalo pushing that for BL808. CV1800B still has a closed SDK. Companies can definitely do worse than StarFive has here.
4 Likes
I think that the Debian-202308 image is ok in certain ways, but the starfive-5.15.0 kernels lacking support for the nftables kernel firewall really sucks. What is see here is that there is quite some conspiration going on to kill RISCV64 in the same way like Raspberry Pi OS 64 does not support DRM management and other essential things. The Raspberry Pi OS kernel even lacks package routing support, though the nftables firewall is working as i know. In the case of the starfive-5.15.0 kernel even the nftables firewall support is not there. Otherwise the kernel included in the debian-202308 image boots nicely.
There is a new branch in github for 6.1 https://github.com/starfive-tech/linux/tree/JH7110_VisionFive2_6.1.y_devel
4 Likes
This branch is closer to the main line.
2 Likes
Not sure every post needs to end with ‘nftables’ - just get a working config and compile your own. Or use ubuntu 23.10 nightly with it.
Really think you are missing the point of the debian build. Its a development platform for quick iterations and testing features that the starfive guys are working on, with view to getting code mainlined. Not a complete OS that should be a replacement to Fedora etc.
However, that 6.1 branch sounds awesome, hopefully makes it into the next debian release.
5 Likes
So, for you developing a kernel based on a development kernel incapable to provide basic kernel firewall features is civilized, or a non-war situation for your kind consideration? nftables firewall is an established linux kernel subsystem since kernel 3.13 from 2014 (nftables - Wikipedia). Thus, your attitude is equivalent to say that being a Vision Five 2 kernel and platform developer is being a kind of martyr. I guess, that is not what most (kernel) developers have in their mind, when they do their job, or at least they should not. (Kernel) development should be fun, not illegal punishment and toxic magic…
No, they aren’t ‘developing a kernel’ - they are making a min viable linux kernel and distro to prove they have working hardware to upstream to mainline. They aren’t here to prove that nftables works with riscv, they are here to get drivers working for their hardware.
I know what nftables is, and if you need it, crack on and compile a kernel yourself and re-add it, or use ubuntu or any other distro that is trying to provide a working server distro. Because, simply put, thats not the goal of the debian image.
5 Likes
Nftables is largely independent of the architecture the kernel is running on. According to my experience nftables is by default included in kernel compile configs as would be reasonable for an essential kernel subsystem. Why to take it out in the first place even or specifically for the Vision Five 2 kernel in the debian images provided by StarFive for the Vision Five 2?