Hi All,
I unexpectedly received a DuoS board from sophgo yesterday, so to repay their kind gesture I’ve updated my Debian images to support the DuoS and Duo256. (Previously I had the sipeed LicheeRvNano)
These images don’t support any of the Camera or MIPi display functionality but otherwise are fully featured:
RNDIS or Serial port on the USB connection.
uses systemd to manage how the USB port is configured. (Eg, the usb.sh probe commands are now systemd unit files)
changes the leds to use the Linux led driver instead of poking at memory that was used in the blink.sh on buildroot)
fixes the CPU frequency scaling when the CPU is overheating. (It wasn’t configured correctly in the buildroot)
supports remoteproc to load binaries onto the small core (and shortly I’ll release patches for ardunio/freertos to provide networking and virtual serial ports to applications running on the small core)
as none of the camera or video processing is enabled, you get the full 256/512mb of memory allocated.
You can build your own images in a preconfigured docker container or download prebuilt images from GitHub.
On my todo list for these images is:
mainline kernel - a lot of patches are flowing into the kernel currently that we could have a semi useful mainline kernel.
DuoS EMMC support (the SD image may work for EMMC version but it’s not tested.
Bluetooth support on the DuoS isn’t functional right now.
Thanks for your work, your image helped me as I wanted to work with an extlinux.conf instead of the hard-coded kernel image names. I also found that you fixed the 850 MHz clock and that it’s now 1.05 GHz.
On my side, I was still quite irritated with Sophgo’s irresponsibly outdated 5.10.4 kernel that was literally lacking 25000 fixes, and spent the week-end rebasing (and testing) it on top of latest 5.10, which currently is 5.10.215. It now works fine and feels much safer and way more reliable. Also, 5.10 moves a bit less in the areas of concern nowadays, as I noticed via the fact that almost every early version would cause rejects while around one out of 20 in the latest ones would fail. I’ve uploaded it here https://github.com/wtarreau/sophgo-linux-5.10/tree/sophgo-rebased-5.10.215 and sent Sophgo a PR (Sophgo cv18xx-v4.1.x rebased on 5.10.215 (for e.g. LicheeRV-Nano) by wtarreau · Pull Request #1 · sophgo/linux_5.10 · GitHub) in case they’re interested in hosting that branch in their repository.
I don’t know how difficult it would be to port this to newer LTS branches (5.15, 6.1, 6.6) but honestly, given that Sophgo is currently trying to upstream many parts, I don’t think it’s worth the effort. I’d rather see them focus their efforts on upstreaming their port and just offer and older-but-stable branch that allows to regularly merge new stable updates for the 2.5 years that are left for 5.10 to be maintained.
By the way, I noticed a small issue with the boot loader. The initrd is loaded only 2MB below the kernel decompression address, which means that any initrd larger than 2MB is corrupted. I managed to work around this by dumping all the environment to uboot.env with the ramdisk_addr_r set to 0x84000000 so that it’s above not below the kernel (40 MB above as-is so there’s room). For 64MB machines probably that a more careful choice of addresses would be desirable, but in general u-boot recommends to load the initrd above the kernel since the kernel is generally smaller than any rootfs. We could for example reserve 16MB for the kernel and start the initrd above that, it should be plenty.
It depends. In my case, I’m loading a 17MB squashfs image that contains the whole operating system, and it did not work.
I noticed that u-boot did not accept to save its environment, and after digging I figured it was able to load it from the “uboot.env” file located on the first partition (FAT). I didn’t know the expected size however, but after multiple boot attempts I figured it was 128kB. So the proper way to proceed is:
interrupt the boot of your board by pressing enter very early when it invites you to press a key to stop the boot, so that it stops in the boot loader.
type “printenv” to dump the whole environment
copy-paste that environment into a local text file, trimming what’s before the first line and after the last one.
take your board’s SD card, and place a copy of that printenv output on the first partition into a file called “uboot-env.txt”
use the mkenvimage utility from uboot-tools, to create uboot.env from that text file: the uboot.env file has a u-boot header describing its type, size and CRC, that’s why you can’t just use the txt flie:
mkenvimage -s 131072 -o /path/to/sdcard/uboot.env /path/to/sdcard/uboot-env.txt
boot your board again. If you no error in front of “Loading Environment from…” it means its OK.
Then you can edit your text file and change any variable you want using any text editor, save it and rerun step 5 above.
Hi - I personally don’t want to work too much on the kernel given we are close to having a reasonably functional mainline kernel around 6.10 (given the rate that patches are flowing in). So I won’t be spending a lot of time on the 5.10 kernel beyond what I need for my own personal projects.
Good catch on the initrd address - I never tested that but I’ll update the uboot address in the next push (as well as fix up the uboot saveenv function so you don’t have to play games in the boot partition).
Actually I didn’t want to spend time on the kernel either, but it’s so pathetic a state that I thought the least effort to have something basically working was at least to update it in its own branch. Nobody wants to put anything sensitive availability-wise, data-wise nor security-wise on 5.10.4! I initially thought about building a remote-controlled power distribution controller for my SBCs and that I don’t even trust it enough for such a simple task!
I installed the image and it’s awesome I can use apt on this little thing. I managed to compile box64 on the device and emulate amd64 (no reason other than curiosity). X11 forwarding over ssh also works!
It seems that only Debian sid has the riscv64 packages right now.
There’s one problem - how to get WiFi to work? Is the driver even installed? Here’s some output of trying to connect:
sudo wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf
Successfully initialized wpa_supplicant
Could not read interface wlan0 flags: No such device
nl80211: Driver does not support authentication/association or connect commands
nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Could not read interface wlan0 flags: No such device
wlan0: Failed to initialize driver interface
wlan0: CTRL-EVENT-DSCP-POLICY clear_all
I also think that some debian packages conflict with the kernel. For example, when trying to install wireguard, it wanted to install the vanilla Linux image. It might not be a problem in the future when the board is mainlined but now it could make it unbootable.
Thanks, I tried network manager already and the WiFi seems to be down or missing a driver. I cannot activate a connection even after adding it in nmtui. Here’s what the Radio tab shows.
