Can also confirm: my DevTerm now has a uConsole trackball in it and my uConsole has a EVQWJN007.

(I’ve been using my DevTerm basically every day for a year, so the trackball eventually wore, and while waiting for the replacement to arrive, I switched it with the trackball from the uConsole. I use the mouse way less on the uConsole. Just got a replacement EVQWJN007 today and put that into the uConsole and it is a perfect fit. They’re available on Amazon as well. I could not find one on Digikey but did find the original part: COM-09308 SparkFun Electronics | Switches | DigiKey .)

This is wonderful and extremely thorough. Greatly appreciated, thanks for putting in the work!

Definite bummer. One other thing that comes to mind, some of the models are a little finicky; I have some older (but new, fresh from the box) 8GB microSDs that won’t boot, but the same image on one of the SanDisk ones boots fine.

Maybe unlikely, but probably worth trying, since it might take a while to get a replacement.

I don’t know about the A04, but for the A06, the first boot is insanely slow. Give it several minutes. It won’t be too slow after the first time, but the first one is really slow.

If that doesn’t work, you can try connecting to the serial console (check the micro USB port under where the printer is mounted), but you might have to clip a couple of resistors off the board to get it to work properly.

Ah, dang, I checked back on this thread just to see if you had gotten yours yet. Here’s hoping it’s soon.

Kernel relocation is normal. (I haven’t said anything in the thread because I don’t know the answer; apologies.)

I have an A06 DevTerm, gqrx runs great. I run dump1090 on it, too. gqrx is qt5 so it probably copes better with the uConsole’s screen dimensions but I haven’t tried playing with it on the uConsole yet.

Fortunately, that is normal for USB devices. (Maybe not normal per se but it’s not a problem. It happens on busy machines.)

X Server is falling back to an older method for detecting framebuffer devices

Oh, that’s not a problem, either.

This looks like all Xorg logs and it looks fine. It looks like it detects the display and even gets the EDID, so maybe it’s just that the backlight wouldn’t come on. If you try to ssh in and turn the backlight on from the shell, that might work.

That was the idea, but if you have verified that it’s up and running, maybe a better idea would be to ssh into it and try to tweak the backlight yourself.

If turning the backlight on manually via ssh fixes it, then maybe setting a cron job or tacking something onto the end of the init code would work. It might be the case that the display (or something between the board and the display) is a little balky after enough time and it isn’t ready when asked to turn on.

May I ask what programs you are running in those screenshots?

Sure.

The first status monitor (upper-right in the first screenshot) is gkrellm, using the config that that comes with the cpi user in the official image (and in this one), though I tweaked the font. It’s nice, it’s even got a network mode so that you can monitor remote systems with it (gkrellmd and gkrellm -s $other_machine). The one on the right side of the second screenshot is conky. conky is a little strange and takes a minute to configure, but it is more flexible overall (and since it draws to the root window, it plays a little nicer with ratpoison). I’m using it on the DevTerms/uConsole because it’s a little easier to incorporate random shell scripts in them, so I can call a script that gives the battery info or backlight level. The terminal emulators are all urxvt.

The stuff running on the left in the second screenshot is all Plan 9 stuff, the window is a drawterm window talking the a Plan 9 box. stats is pretty similar to gkrellm (and is monitoring the Plan 9 machine rather than the DevTerm), ip/gping in the lower-left is just a graphical ping that I was using to fill the screenshot. The P9P stuff included in the image has a port of stats, but it looks like some of the text is a little glitchy. (Maybe a P9P bug, maybe a portability bug, no telling.) Here’s a screenshot with an oversized stats window on the left (stats -lmEsi, though the syscall counter doesn’t work on Linux), netsurf-gtk2 viewing an on-device wiki in the upper right (I have been running AwkiAwki on the DevTerm because it’s very fast, so it’s easy for taking notes and then sharing them with anyone on the LAN), and then nethack in the lower-right. gping isn’t included in P9P, but you need root to make ICMP packets in Linux anyway.

A lot of the stuff I do with the DevTerm is remote: either drawterm to talk to Plan 9 or ssh to talk to a Linux machine. Ironically, because a regular browser is nearly impossible to cope with on the R01, the R01 feels like a bigger world than the A06.

Is there anything in the X logs?

R01 ordered. OK, I already had one, but it is in my uConsole…

Ah, cool. I ordered a uConsole with an R01 and then swapped it into the DevTerm and put the CM4 into the uConsole.

Thanks for the screenshots! So pretty in orange.

Oh, thanks, it felt very nostalgic for me when I first booted the R01 and saw the orange.

Do you have a more precise breakdown of your procedure, so that it could be reused for uConsole?

So, I tried swapping microSD cards around and except specialized stuff for the Ext boards (printer or 4G modem) and the framebuffer rotation args set in the bootloader, the images are nearly the same. That is, this image should boot in a uConsole but the screen will be turned around.

That having been said, the process was nothing complicated: I used dd iflags=fullblock bs=1M count=256 to copy the initial 256MB from the official R01 image so that the bootloader would require no changes. (The partition layout is a little strange on the R01 image: Create DevTerm R01 OS image from scratch · clockworkpi/DevTerm Wiki · GitHub . I don’t know if there is a reason, but I wanted to debug as few things as possible. There’s also an offset required, like the init code looks at a fixed offset into the SD card, so you have to avoid putting a partition there.)

After that, I deleted and recreated the fourth partition, then unpacked the slarm64 installer and chrooted. I had no luck getting the installer to accept what I was doing, so I just did installpkg --root /mnt on the packages that I wanted to install (dependencies were guessed at, which is why a couple of them were missing), and then rsync’d the /lib/modules from the official image, because I was using the official kernel. (Since the dd had already covered the “lead-in” and the first two partitions, the kernel in /boot was the same.)

After that it was more or less like setting up any other system: tweaks to /etc/fstab, things like that. Then setting up the DevTerm-specific stuff, and eventually tried to boot it. Luckily it worked on the first try.

Oh, I took a couple of screenshots. I don’t know if it is something in slarm64 or if it’s because I kept the kernel from the official image, but neofetch seems to think it’s Armbian.

ratpoison is a really great fit for the DevTerm: no wasted space. (I usually just do one window instead of splitting like in the screenshots, so just what I am working on plus conky.) Anyway, I should be able to repackage the DevTerm-specific bits soon, including, e.g., yatli’s graphics acceleration patch.

Oh, really? That’s very cool!

The R01 is really fun so far. I love ARM, and I’ve been using it for a very long time, but I got a really nice feeling after I started playing with the R01 a bit.

The ClockworkPi code (audio patch, printer daemon, etc.) was coalesced into a single Slackware package.

…Which I appear to have left off the image. Learning experience.

I will upload a fix tonight when I’m done for the day, or probably tomorrow.

[Edit 2023-11-10: See below for extra packages.]

This is nothing special: I just used the slarm64 nezha packages to build the image. I wanted a clean(-ish) starting point for the CRUX image I am doing next. It boots, it rotates the framebuffer correctly, drivers and all the CPi-specific bits are included, everything seems to work fine. [Edit: see the edit at the bottom: it requires a bit of tweaking before it works fine, depending on your definition of “fine”.]

A summary of things that differ from vanilla Slackware:

• The ClockworkPi code (audio patch, printer daemon, etc.) was coalesced into a single Slackware package.
• init scripts ported from systemd to sysvinit.
• /usr/src/DevTerm has the contents of the git repo, so the code is all available if I messed anything up. There’s a handful of stuff in /usr/src.
• Partition layout, bootloader, and kernel were done by just copying the first 128MB from the official image, and then rsync’ing /lib/modules from the official image.
• Kernel is as in the official image.
• Partition resizing is left up to you, so if you want to split / and /home, feel free. (I figure anyone interested in Slackware on RISC-V knows how, but the partition layout is a little strange, so make a note of the starting block for partition 4, delete it, make a new one with that starting block.) The image is a little under 8GB.
• Instead of passing --autologin to agetty(8), it just gives you a login prompt. root and cpi both have the password cpi.
• Some miscellaneous Plan 9 tools: /usr/local/bin/drawterm and p9p in /opt/plan9. (Haven’t attempted a native Plan 9 image but I suspect it would work great aside from the lack of Plan 9 drivers for, e.g., wifi chip.) If you have a venti server set up, you can save yourself a lot of wear and tear on your SD card by setting up fossil to run out of /tmp.
• /home/cpi is set up as in the official image, with twm and orange-on-black gkrellm and everything.
• I loved the orange look from the official image (my first computer had a Hercules monochrome CGA card and monitor, which was already very old by the time I got it), so /etc/issue sets the terminal colors to amber monochrome colors. Feels really nice. (I did the same with my ~/.Xdefaults and ~/.conkyrc; ping me if you are interested.)
• Most of the package selection is coder-centric (slow but cool experimental CPU in a cyberdeck, I am guessing everyone that got an R01 got it for the love of the game), compilers and stuff.
• Most of the available editors are small to keep the image size down, elvis for the vi, joe for emacs, acme and sam are available in /opt/plan9/bin. slackpkg install your large editor of choice if those don’t work. (Ken Thompson still uses sam, though!)
• Retained CPi tradition of echo $message|figlet>/etc/motd, but it’s appropriately wide-screen.

Other than that, it is vanilla Slackware.

I booted it up to test it before dumping the image, and then shrank it, so you will want to clear out the ssh keys before starting sshd (same as the official image): sudo rm -fv /etc/ssh/*key*.

I recorded the entire process in screen, so any questions about what I did, I can answer, but may not be able to remember why I did it. This image is a one-off: I’ll be doing a CRUX image after this and probably also CRUX for the A06 after that, or since the hard work has been done for Plan 9 on RPi, maybe a Plan 9 image for the CM4, but I will probably be moving slow since I have a lot of projects (some of which rely on being able to use my DevTerm) and also have to work. (Building a new OS image is a nice background task, since there is a lot of waiting. I started a CRUX image but fried the microSD card it was on, and figured that making a Slackware image where it was mostly downloading precompiled packages would be faster than recompiling everything. Thanks to the slarm64 project for producing RISC-V packages! slarm64 - unofficial slackware port for aarch64 / riscv64 architecture )

Tor link: http://s3ldbb3l5eqd6tjsklzmxy6i47i3fim55fpxmgeaa6rvpcllkt4ci4yd.onion/r01_slackware.img.bz2
IPFS: ipfs://bafybeihoiuobwvosy4dlxjkgophbgizq5gyyi6p7jxgh4tanjbdy73aose
Regular web (IPFS gateway): https://dweb.link/ipfs/bafybeihoiuobwvosy4dlxjkgophbgizq5gyyi6p7jxgh4tanjbdy73aose
Regular web (kinda; another P2P gateway): https://media.freespeechextremist.com/rvl/full/17b30212e33512e8aa6e861a4adb9744b4a70a7b2d6febab72df4b0816f2f0e8

MD5: 45a326a7e5f6447c6804510c935f8e4d
SHA256: 0f312c779dbc376c7985d0fb9e60026cccd441b7769d6ece05bc6668d7c06402

Also, the DevTerm extras package, most of which you could get by compiling the code in /usr/src/DevTerm/Code, along with a few trivial translations of the systemd init scripts into sysvinit scripts:
Tor: http://s3ldbb3l5eqd6tjsklzmxy6i47i3fim55fpxmgeaa6rvpcllkt4ci4yd.onion/devterm-r01-extras-0.1-riscv64-2.tgz
IPFS: ipfs://bafkreicj2pf6oprjj4ryilaudeljze4aicztetk5aylduiac74afvm5csi
IPFS gateway: https://dweb.link/ipfs/bafkreicj2pf6oprjj4ryilaudeljze4aicztetk5aylduiac74afvm5csi
Web: https://media.freespeechextremist.com/rvl/full/d551acb007301de3c0fce683304b9364afcf2bd386531c5060b717775617d9a0

ALSO, Here is yatli’s port of the fbturbo graphics accelerator, including init script, source, etc. I took the liberty of statically linking the daemon.
Tor: http://s3ldbb3l5eqd6tjsklzmxy6i47i3fim55fpxmgeaa6rvpcllkt4ci4yd.onion/xf86-video-fbturbo-r01yatli-0.2-riscv64-1.tgz
IPFS: ipfs://bafybeiafuixsxadgesa7mnppg7ey3c3ou6bhqqmxj52thljofop4pc7r64
IPFS gateway: https://dweb.link/ipfs/bafybeiafuixsxadgesa7mnppg7ey3c3ou6bhqqmxj52thljofop4pc7r64
Web: https://media.freespeechextremist.com/rvl/full/348141e7f0cb2f9d94e24a104bc347e17e5cbc923b520409d466d6fd52767fe2

[Edit: It works fine once you bring up wifi (short version: sudo vi /etc/rc.d/rc.inet1.conf, enable wlan0 by uncommenting IFNAME[4]="wlan0" on line 152, then USE_DHCP[4]="yes" below that, then WLAN_WPA[4]="wpa_supplicant" on line 166, edit /etc/wpa_supplicant.conf to add your network, then either reboot or do sudo /etc/rc.d/rc.inet1 wlan0_start) and then install some missing pieces that I erroneously trimmed in an effort to get the image size down: slackpkg install libICE libSM libnghttp2 libXpm python-Jinja2 python-PyYAML fribidi pangomm pango cairomm cairo cmake extra-cmake-modules gtk+2 glib2 startup-notification gdk-pixbuf2-xlib gdk-pixbuf2 libwacom xsm libusb libusb-compat sqlite icu4c libxml2 graphite2 brotli harfbuzz. Pango/Cairo/gtk are needed for gkrellm, libnghttp2 is needed for git, startup-notification is needed for urxvt, and X refuses to start unless you have installed the Wacom driver, for some unholy reason. I don’t know how necessary some of the other ones are but If you’re having trouble waiting for that stuff to download, try installing bsd-games first so you can do fortune -a while watching the progress bars. If you’d prefer to use wpa_gui to configure your network than to edit /etc/wpa_supplicant.conf, you can write the image to the SD card and fetch the packages directly from the slarm64 repo.]

I’m glad you find it useful!

Definitely.

CUPS printing, fan daemon, keyboard firmware) are packaged for Debian-based distros.

Yeah, I know about those; the Debian-centric part is somewhat painful.

Probably the Arch and Manjaro images you mention are the ones made for A0406 DevTerms

Oh, yeah, you are right. Apologies. It was for the A06 and from yatli, he’s around the forum a lot: GitHub - yatli/arch-linux-arm-clockworkpi-a06: Arch Linux ARM for the ClockworkPi DevTerm A06 . (Most of the time someone has done something like that, either yatli or emutyworks will be somewhere in the thread, often the person that did it. emutyworks is trying to get FreeBSD running on the R01: Home · emutyworks/DevTerm-R01 Wiki · GitHub .)

which in theory shouldn’t feel so difficult but for me it is

Haha, I feel exactly the same way, that’s why I was asking: it looks like it shouldn’t be difficult and it seems like most people think it’s relatively obvious stuff, but I feel like I’m missing something (especially around booting), so I ask around a little. Fan and printer support aside, I’ll be happy if I can get it to boot and turn on the screen, at least at that point it’s easier to debug without clipping resistors off the Ext board ( DevTerm R-01 Ext Board UART is read only? - #2 by smaeul ).

Edit: I did manage to get Slackware on the R01 to work properly and have been running it since: Slackware image for DevTerm R01 - #5 by 1337p337

Yes, the cores are swappable. If you get CPi’s carrier board for the CM4, you can put a CM4 in it, too. The R01 is a RISC-V chip (Allwinner D1), not even ARM like the A04/A06 and works in the same hardware, the uConsole and the DevTerm. It’s really cool, I have swapped cores between devices.

Thanks for this, it’s great!

don’t want to/don’t know how to modify the original image to make it work

Impossible to solve “don’t want to” but “don’t know how to” is easy to fix with some links, I suspect. I didn’t know that anything needed to be done, I thought most images should work out of the box with a few tweaks for screen orientation, etc. (Though I have had no luck getting the 9pi image to run, and have been using the DevTerm too much to spend much time hacking the device itself; R01 core arrived and I have started playing with building a CRUX system inside a Slackware chroot, but it is slow going.)

I can only find the official images

I think there’s an Arch image kicking around, and a Manjaro one.

When I ordered my DevTerm last year, that’s how the shipping time was described. The chip shortages pushed it a little longer, but it wasn’t too bad. (NB., “Business days”, so closer to 90 calendar days.)

Since they are still catching up with the uConsole orders, it wouldn’t surprise me if it took longer. CPi is great, but not fast.

Giant markup, A04 (which is not offered any more), “Sold by […] New Seller”. This is a scam.