Debian Images for Duo256/DuoS

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:

  1. RNDIS or Serial port on the USB connection.
  2. uses systemd to manage how the USB port is configured. (Eg, the usb.sh probe commands are now systemd unit files)
  3. changes the leds to use the Linux led driver instead of poking at memory that was used in the blink.sh on buildroot)
  4. fixes the CPU frequency scaling when the CPU is overheating. (It wasn’t configured correctly in the buildroot)
  5. 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)
  6. 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:

  1. mainline kernel - a lot of patches are flowing into the kernel currently that we could have a semi useful mainline kernel.
  2. DuoS EMMC support (the SD image may work for EMMC version but it’s not tested.
  3. Bluetooth support on the DuoS isn’t functional right now.

More info and the images are available here: GitHub - Fishwaldo/sophgo-sg200x-debian: Debian Image for SG200x based boards such as Milk Duo256/DuoS and Sipeed LicheeRVNano

7 Likes

Thank you will have a look but might prefer Debian Bookworm not debian:sid (will look at chaning it in Dockerfile)

I have run into a strange stability issue so will test your image soon (running meshtastic Lora)

Using the official Ubuntu 22.04 AllWinner Nezha rootfs with the buildroot kernel vs another OS builder (debootrap)

The board crashes after an hour or so on the built OS
Using the offical rootfs of the AllWinner Nezha no issue

3 Likes

Hi @Fishwaldo please keep us updated on progress. I have my own builds using mainline U-Boot and Linux, but both have omissions preventing boot-up.

1 Like

Awesome work mate, that’s greatly appreciated!

I’ll be using and showing it in a video some time.

Cheers, P

4 Likes

Hi!

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.

4 Likes

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.

1 Like

@willy could you explain step by step how to do this? Is this preventing the DuoS from booting?

1 Like

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:

  1. 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.
  2. type “printenv” to dump the whole environment
  3. copy-paste that environment into a local text file, trimming what’s before the first line and after the last one.
  4. 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”
  5. 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
  6. boot your board again. If you no error in front of “Loading Environment from…” it means its OK.
  7. Then you can edit your text file and change any variable you want using any text editor, save it and rerun step 5 above.

Hoping this helps!

3 Likes

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).

4 Likes

Cool, thank you!

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!

1 Like

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.

1 Like

For WiFi - it’s in the readme. Just use the nmtui command - activate network.

I’ll look into the conflict on the kernel. That should be easy easy to solve.

1 Like

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.
Screenshot_20240506-085519976 (1)

1 Like

Can you upload a copy of dmesg output to a pastebin service and send a link?

This is DuoS without EMMC right?

1 Like

I have the same issue. In NTMUI the WIFI hardware is missing. APT en WGET via ETH is working fine.

1 Like

Same response as above. I need to see the dmesg output.

1 Like

I’ve just pushed some new images out

  • Fixes wifi for the Duo (Typo in the github actions that generated the images)
  • Bluetooth Support on DuoS
  • loading and saving uboot enviroment to the SD card
  • Fixes the initrd load address.
2 Likes

@Fishwaldo

Also kindly look at the github issues on your Repo

1 Like

In the new image i can activate the wifi connection.

2 Likes

Sorry for the late response, I just generated the dmesg but I see now that it’s fixed. Thanks!

Your images are awesome, everything seems to work.

2 Likes