So I’ve been running with the upstream branch on github and I’ve been wondering how many people here do the same, and what issues they run into.
Most things work “good enough” for me: both ethernet cards work, GPIO pins work, I run headless so I don’t care about graphics.
The nvme mostly works, but, as I mentioned in the NVME QID timeout thread, there are timeout issues which I do not have with 5.15.
Other than that, I have the following issues currently:
The crypto engine doesn’t seem to work. I get this dmesg entry at boot time:
starfive-crypto 16000000.crypto: error -ENXIO: IRQ index 0 not found
Could this be because there’s no interrupt list in the current dtb’s crypto entry? There are in the 5.15 device tree.
In the 5.15 wayland kernel image it seems to “do something”, HOWEVER:
- The sha256sum hashing speed gain is insignificant: The userspace
sha256sum
tool which is not using AF_ALG sockets is actually a bit faster.
- Hashing a large file causes wrong hashes. It works for small ones, so I’m
assuming there’s some mixup with update vs finalize operations. The same
C code runs fine on an intel workstation (and on the kernel where the crypto
engine fails to initialize)
The SPI flash doesn’t work
I can read/write it in the 5.15 kernel, but with the 6.4.0rc1 upstream kernel
it fails and I’m seeing the following errors in dmesg:
kernel: cadence-qspi 13010000.spi: QSPI is still busy after 500ms timeout.
kernel: spi-nor spi0.0: operation failed with -110
5 Likes
Have a look at JH7110 Upstream Status | RVspace to see what is already upstreamed. What you’re reporting is currently not.
Kind regards,
Lars
2 Likes
I’m also having issues with an NVMe drive - once initialized in U-Boot, it won’t show up when booted in Linux, so the drive can’t be used as a boot drive.
Also, does cpufreq work for you on the upstream branch? It seems to me that the CPU runs at a low frequency, and there is no way to check or change it.
$ ls -al /sys/devices/system/cpu/cpufreq
total 0
drwxr-xr-x 2 root root 0 May 20 17:39 .
drwxr-xr-x 11 root root 0 Feb 15 21:22 ..
$ ls -al /sys/devices/system/cpu/cpu0
total 0
drwxr-xr-x 6 root root 0 Feb 15 21:22 .
drwxr-xr-x 11 root root 0 Feb 15 21:22 ..
drwxr-xr-x 5 root root 0 May 20 17:42 cache
-r--r--r-- 1 root root 4096 May 20 17:42 cpu_capacity
drwxr-xr-x 2 root root 0 May 20 17:42 hotplug
lrwxrwxrwx 1 root root 0 May 20 17:42 node0 -> ../../node/node0
lrwxrwxrwx 1 root root 0 May 20 17:42 of_node -> ../../../../firmware/devicetree/base/cpus/cpu@2
-rw-r--r-- 1 root root 4096 May 17 18:46 online
drwxr-xr-x 2 root root 0 May 20 17:42 power
lrwxrwxrwx 1 root root 0 Feb 15 21:22 subsystem -> ../../../../bus/cpu
drwxr-xr-x 2 root root 0 May 20 17:42 topology
-rw-r--r-- 1 root root 4096 Feb 15 21:22 uevent
$ zcat /proc/config.gz | grep -i freq
# CPU Frequency scaling
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ATTR_SET=y
CONFIG_CPU_FREQ_GOV_COMMON=y
# CONFIG_CPU_FREQ_STAT is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
# CPU frequency scaling drivers
CONFIG_CPUFREQ_DT=y
CONFIG_CPUFREQ_DT_PLATDEV=y
# end of CPU Frequency scaling
# CONFIG_DEVFREQ_THERMAL is not set
CONFIG_PM_DEVFREQ=y
# DEVFREQ Governors
CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=m
CONFIG_DEVFREQ_GOV_PERFORMANCE=m
CONFIG_DEVFREQ_GOV_POWERSAVE=m
CONFIG_DEVFREQ_GOV_USERSPACE=m
CONFIG_DEVFREQ_GOV_PASSIVE=m
# DEVFREQ Drivers
CONFIG_ARM_SUN8I_A33_MBUS_DEVFREQ=m
# CONFIG_PM_DEVFREQ_EVENT is not set
# Frequency Synthesizers DDS/PLL
# Phase-Locked Loop (PLL) frequency synthesizers
# end of Phase-Locked Loop (PLL) frequency synthesizers
# end of Frequency Synthesizers DDS/PLL
$ uname -a
Linux nixos 6.4.0-rc2 #1-NixOS SMP Tue Jan 1 00:00:00 UTC 1980 riscv64 GNU/Linux
Kernel is built from this commit.
2 Likes
Yeah I had not thought of that when I was writing this. And indeed, cpufreq seems to not be working.
However, this might be fixable by adding an equivalent to this device tree node to the jh7110.dtsi file, as the compatibility entry is there in drivers/cpufreq/cpufreq-dt-platdev.c in the way it was done in this 5.15 devel commit.
I might give it a shot. I think the clock line would have to be adapted to <&syscrg JH7110_SYSCLK_CPU_CORE> and the clock-names to just "cpu", but I’m rather new to device tree stuff.
I also noticed that the SPI entries have some different settings, most notably the spi-max-frequency in the upstream branch is 12000000 while it is 100000000 in the devel branch (that’s an additional digit there) - I wonder if that might be the reason it cannot be accessed.
3 Likes
Update: Hah, it’s never so simple 
The cpufreq-dt part seems to also depend on the operating-point-v2 bindings and it looks like it’s all there, just not working. 
Don’t have much more time for this right now.
1 Like
Crypro irq issue is because dts lacks irq attribute:
interrupts = <28>;
This exists in upstream patch series, but not exist in this branch.
4 Likes
Thanks, that fixed it. Now I even get correct hashes. But it’s still not actually hashing faster than the sha256sum userspace tool 
(faster than the kernel’s software implementation though, so in-kernel stuff should be faster). Gonna have to benchmark other algorithms as well some time.
Besides, crypto driver in upstream branch seems older since newest patches needs 6.4 rc + this patch Maybe newest driver would have better performance.
1 Like
Also, SF has updated their upstream branch, but I saw some OOPS in my testing and QSPI also fail to work.
So I dug more into the cpufreq issue, and I just had to enable the regulator and MFD for it:
CONFIG_MFD_AXP20X=y
CONFIG_MFD_AXP20X_I2C=y
CONFIG_REGULATOR_AXP20X=y
(I wonder if the nvme timeouts also just need some kind of irq/regulator/something enabled to be fixed… )
Nope, AXP15060 driver isn’t fully accepted in mainline. Still waiting for regulator stuff, and currently merged code is not correct (Should be based on axp313a series but actually not)
3 Likes
Well, it’s enough for the sysfs cpufreq/ dir to get populated, might not do much else, but I assume those config options will still be required later on, so they’re there to find - then again, I’m assuming it’ll also end up in the vf2 defconfig once it’s working.
But yeah, I saw some more patches on lore.kernel.org touching the AXP15060 and 313a portions which are still missing. I just can’t wait for mainline to get better, and it’s so much nicer here than with all the ARM boards I’ve dealt with in the past… by orders of magnitude… 
3 Likes
The cpufreq-dt part seems to also depend on the operating-point-v2 bindings and it looks like it’s all there, just not working. 
Don’t have much more time for this right now.
(faster than the kernel’s software implementation though, so in-kernel stuff should be faster). Gonna have to benchmark other algorithms as well some time.