I got a couple DeepComputing mainboards the other day and got one of them setup in a chasis, and the following are things that I’ve run into or found so far:
First and foremost, the board WILL NOT SHOW SIGNS OF LIFE (i.e. the screen will not turn on) unless an SD card is installed with an appropriate image flashed to it. At first I thought I would just use the microsd expansion card for boot, to use it kind of like a raspberry pi, however that appears to not be supported.
You must ensure that the SD card is inserted properly. Examples of how to and not to insert the card was posted here a couple days ago.
As has been previously reported, this board isn’t really meant for general usage, as it’s nowhere near the performance of the “regular” mainboards. Phoronix benchmarked this same CPU on the HiFive Unmatched board back in 2023, and it has in general about a third of the performance of a Raspberry Pi 400.
You can download sd card images here. Note that the image DOES NOT automatically resize the root partition after transfering the image to an SD card; you’ll need to do that yourself.
The image supplied by DeepComputing uses GNOME, which as you can imagine isn’t a great experience given the benchmark numbers. You’ll want to install something that is more conservative with system resources such as XFCE or LXDE.
You’ll want to remove the linux-image-generic package along with any already installed linux 6.8 kernel images as, when updating, grub will get updated to use those images over the stock custom 6.6 image, resulting in a black screen on boot after GRUB.
The Intel BE200 is NOT SUPPORTED; it will boot with it installed, unlike AMD boards, however just doesn’t show up at all. At first I thought this was due to having an older kernel, however it doesn’t even show up in lspci.
The AX210 does show up in lspci, however there appears to be some issue loading the firmware. Will have to do more investigating on this one…
Hi.
It is great to hear people already using the RISC-V board.
As you have found upstream kernels don’t yet work with it.
That is one of the main reasons for making the board.
In order to get the needed patches upstream so that any kernel will boot on the RISC-V board.
Also, things like getting PCIe devices working with it.
There are multiple problems getting PCIe devices working on ARM platforms, mainly due to cache coherency problems.
It would be good to see what the problems are with PCIe devices on RISC-V that could then be fed back to future chip designs.
If you add this to the linux boot command line it will tell you, in the boot logs, what filenames it is looking for for the firmware for the ax210. dyndbg="file drivers/base/firmware_loader/main.c +fmp
That dyndbg command doesn’t appear to have done anything, but here’s what iwlwifi is trying to load:
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: enabling device (0000 -> 0002)
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Detected crf-id 0x400410, cnv-id 0x400410 wfpm id 0x80000000
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: PCI dev 2725/0024, rev=0x420, rfid=0x10d000
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-83.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-82.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-81.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-80.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-79.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-78.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-77.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-76.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-75.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-74.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-73.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-72.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-71.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-70.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-69.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-68.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-67.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-66.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-65.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-64.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-63.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-62.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-61.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-60.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-59.ucode failed with error -2
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: no suitable firmware found!
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: minimum version required: iwlwifi-ty-a0-gf-a0-59
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: maximum version supported: iwlwifi-ty-a0-gf-a0-83
Oct 18 01:15:17 StarFive kernel: iwlwifi 0001:01:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
…and the firmware in /lib/firmware:
-rw-r--r-- 1 root root 504272 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-59.ucode.zst
-rw-r--r-- 1 root root 533796 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-66.ucode.zst
-rw-r--r-- 1 root root 1499284 Dec 9 18:23 /lib/firmware/iwlwifi-ty-a0-gf-a0-72.ucode
-rw-r--r-- 1 root root 544119 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-72.ucode.zst
-rw-r--r-- 1 root root 545410 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-73.ucode.zst
-rw-r--r-- 1 root root 561263 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-74.ucode.zst
-rw-r--r-- 1 root root 568930 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-77.ucode.zst
-rw-r--r-- 1 root root 574893 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-78.ucode.zst
-rw-r--r-- 1 root root 574867 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-79.ucode.zst
-rw-r--r-- 1 root root 577400 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-81.ucode.zst
-rw-r--r-- 1 root root 1683076 Dec 9 18:23 /lib/firmware/iwlwifi-ty-a0-gf-a0-83.ucode
-rw-r--r-- 1 root root 581973 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-83.ucode.zst
-rw-r--r-- 1 root root 583579 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-84.ucode.zst
-rw-r--r-- 1 root root 589433 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0-86.ucode.zst
-rw-r--r-- 1 root root 41876 Dec 9 18:23 /lib/firmware/iwlwifi-ty-a0-gf-a0.pnvm
-rw-r--r-- 1 root root 7152 Dec 20 22:48 /lib/firmware/iwlwifi-ty-a0-gf-a0.pnvm.zst
It looks like it can find the firmware, it just can’t load it for some reason.
P.S. While I am a software engineer I’m not a kernel developer; I just like to tinker, so this is really just for my own curiosity rather than to attempt to get mainline kernels working. Though I found in the framework repository there appear to be instructions on getting a newer kernel working, so I may attempt that at some point.
Well the error -2 is: #define ENOENT 2 /* No such file or directory */
So, it is simply not finding the file it needs.
Are you using an initrd image at boot? If so, the firmware probably needs to be in there.
Another way to test, is to login “sudo rmmod iwlwifi” and then “sudo modprobe iwlwifi” it again. This will cause it to look for the firmware in /lib/firmware and not the initrd.
If that works, all you need to get sorted is getting the firmware into the initrd.
Well unfortunately the iwlwifi module is built-in to the supplied 6.6 kernel. On top of that the DeepComputing image is using dracut for some reason; nevertheless I did a rebuild on that and it didn’t include the firmware. I’m sure there’s a way to tell dracut include it but I’d rather spend time/effort trying to get it working with a normal kernel with a normal configuration just with the deep computing stuff added on top.
How do you manage the risc-v tag when DeepComputing or another 3rd-partner company will release another RISC-V architecture CPU mainboard in the future?
it’s possible to update the existing tags in this case we would update the existing tag and add a new one! hope we can have more risc-v mainboards in the future!
EDIT: I was mistakenly flashing the generic RISC-V image from Fedora, rather than the actual DeepComputing Fedora image. After flashing the correct image to the SD card, everything seems to be working now.
Anyone managed to get it working standalone? I’ve gotten it to power on, but I don’t seem to be getting any video output.
According to the specs, there’s two ports that support power, and one of those does video output. Only the top/back two ports seem to accept power, so video output should be on one of those. But with the official Fedora image dd’ed to the SD card, it still doesn’t seem to output any video from a USB-C to HDMI adapter plugged into either.
I got the board running and displaying on the framework laptop shell.
I am 80% sure the back LEFT port (when board is installed in the laptop and screen is facing you) is the one that supports hdmi (from the console logs) but I havent got my external monitor to work yet. I’ll report back when I do.
Got it working. USB-C monitor did not work but the HDMI adapter did on the back left port. The usb-c hub from the monitor (with power delivery) works fine on the back right port as well. Both are pictured. Running Fedora btw.
Is that the standard HDMI module? I received my board today, running it (well, hoping to) in the cooler master case, but can’t get any display when trying to use USB for both power and picture.
Stupidly didn’t order the HDMI module at the time, I’ve ordered one now but would love to find a way to make it work with the USB display so I don’t have to wait for UK shipping.
Well, that was less painful than I expected, it looks like I’m off to the races with USB-C display, and the monitor also providing power over the one cable.
In my case it feels like it was a bad SD image, I was trying with Fedora before but switched to the Ubuntu image from Github and reflashed and it booted right up. I just taped the case switch down temporarily while I was messing around with the SD to make that less of a PITA.
Maybe worth noting that the only USB I’ve tried this with is the top-left, which I believe might be the only one that supports this.
I haven’t had the time to go back and look at it. The problem is that the iwlwifi module is built-in to the kernel (vs being a module) and the firmware isn’t included in the initramfs. If either iwlwifi was a module or the firmware was included in the initramfs, it would likely work.
Configuring Dracut to include the firmware is likely the easiest solution, but again I haven’t had the time to dig into it any more. If anyone is wanting to try with the Ubuntu image, it looks like you could follow this man page and add either the fw_dir or install_items directive to a custom configuration file to add the firmware to the initramfs.
Also yes, Dracut is being used in Ubuntu for some reason rather than the regular Debian stuff… which is a bit odd.
It could also be a kernel config issue with regards to compressed firmware, this is the issue I first experienced when starting to work with the more mainline DC-linux kernel. By default compressed firmware support was not enabled I had to enable it myself.
But I am not sure if that is already used by the kernel that is in these images. Check if there is some hint as what the config of the kernel is you are running
in this case we would update the existing tag and add a new one! hope we can have more risc-v mainboards in the future!
