still same … boot ok, but network is connecting a while, then gives up
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 6c:cf:39:00:20:79 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 6c:cf:39:00:20:7a brd ff:ff:ff:ff:ff:ff
root@starfive:~# cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
#setup network for starfive end0
allow-hotplug end0
#iface end0 inet dhcp
#setup network for starfive end1
allow-hotplug end1
#iface end1 inet dhcp
flipping Ethernet ports …
[ 619.357900] starfive-dwmac 16030000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 689.036060] starfive-dwmac 16030000.ethernet eth0: Link is Down
[ 690.157173] starfive-dwmac 16040000.ethernet eth1: Link is Up - 100Mbps/Full - flow control off
I found the problems，your spl and uboot is not latest. The latest one is about May.
Please use the spl and uboot of JH7110_VF2_6.6_v5.12.0.tar.bz2
（The spl and uboot is in the v5.12.0.tar.gz）
oh my god — as this time the bundle is in different format, i used the last one, where the uboot/spl was visible in the assets … silly me, i used the previous one to flashing …
downloading and flashing now
I’m using cwt’s latest Arch image, but the way I understand it’s the same as the Debian dev system, except minimal, so it makes it relevant?
I had the torched my previous installation, and flashed it from SD to NVME.
This time I want no garbles or stutters, I’m thinking, so no X11 anywhere as much as possible. For the login manager, I chose a TUI login manager called Lemurs which now boots me into Swayvm. It’s bloody fast, except the system still sometimes does the usual cwt Arch thing of randomly waiting after boot, so I still can’t show it off.
I ran a few tests. A cough nameless 3D game compiled for the system, glxgears, supertuxkart. And supposedly since I did not explicitly tell systemd to boot me into graphical target, they came up garbled, line by line, like an X11 icon-heavy app in Wayland.
So I ran the suggested es2gears_wayland app non-synced. Wow 1500 fps etc. Looks flawless.
Wayland, eh?
I then tried again, but placed SDL_VIDEODRIVER=wayland in front of the app in foot terminal. Presto, it worked. I tried it with supertuxkart from the repo. It reported the IMX hardware enabled and running.
To put simply, the acceleration is there, somehow, somewhere. Just it looks like whenever X11 is involved, stuff tends to break.
Official Debian from debian.org does not currently support the RISC-V architecture (it will not officially until Trixie) , so why would it support the the Imagination Technology Ltd GPU IP inside the JH7110. Imagination Technology Ltd are working on open source Linux drivers for the GPU IP that they sell, but that is not ready yet because it is a full redesign from the ground up. So currently the only OS’s that are supported are the ones that match the kernel versions supported by the binaries released by Starfive. They can not release the source code because they do not own it. So for now, at least until there is official driver source code from Imagination Technology Ltd., the GPU support is binary only linked to specific kernel versions. It is what it is
So these are the patches you need to apply to mesa3d?
The confusing part to me is why they release a distribution that does not even use the GPU. I mean nobody is going to use this board until the GPU works. It’s the only USP this SoC has Risc-V + GPU and passive cooling.
NVMe has no practical use case until the GPU driver works. The priority is a bit upside down, if you want a server don’t use a chip with a GPU?
It would be much better to release a linux with broken driver enabled than what we get now!?
Hold on, don’t get the wrong idea; it’s not all fun and games on the Arch version either. Stuff that uses GLES will likely work. Super Tux Kart’s Antarctica engine is just that fast and the other 3D game I mentioned is just built to use GLES I guess. When I tried something more substantial, it ran slow and un-accelerated under X11 back when I had it installed, and under wayland reports missing eglContext(), which just means it expects proper OpenGL from what I gather.
Oh, and normal glxgears no longer work for me. They are a garbled mess. Only es2gears_wayland displays properly.
I suppose one could use gl4es at this point…? But that stuff is sorcery to me.
There is OpenMW in arch repo…which is just a huge tease at this moment as it gets like seconds-per-frame quality. Oh well.
My point was that the acceleration is there, somewhere. Have you tried the es2gears_wayland stuff on the Debian distro?