You’re missing a space. sudo cp target/release/upico /usr/local/bin.

I finally decided to try another way to wake it up, by plugging in an external mouse and keyboard, and I discovered the system immediately woke up and was responsive.

Check powertop. One of the screens in it has a list of USB devices and whether their power management status puts them to sleep or not. If the internal keyboard/trackball go to sleep (or maybe are put to sleep by the OS/DE combination you are using, so if you are using a DE, check if it does any power management in its settings), but an external keyboard doesn’t, then that might be that the reason your device has trouble waking up.

They’re compatible, yeah, even swapping between DevTerm and uConsole. The R01 is really fun and it has ridiculous battery life. A few times I was reading on my DevTerm and fell asleep and it was still running when I woke up.

relies heavily on the “mod” key, which is the “Super” key by default so Fn + AltL on the uConsole

I do not know how easy it is to remap things under Wayland, but on the uConsole, I use the volume button for the window manager’s meta key. (escape XF86AudioLowerVolume in ratpoison. I use ratpoison on the DevTerm, too, but I use the Cmd key, which is Super_R. I have the volume up/down buttons mapped to screen brightness, and Fn+< and Fn+> cycle through windows.) One thing you might try is remapping the right Ctrl/Alt keys, depending on whether you need both pairs.

I was wondering if there is a way to use one of the gamepad buttons

There are some dip switches on the back of the keyboard that can be used to send normal keypresses instead of gamepad keypresses, but they’re mapped to letter keys. (I seem to recall the dip switches are actually on the board, but it’s a bit more involved to disassemble than the DevTerm is.)

You could try getting the Arduino devkit to work (if anyone knows a way to rebuild the firmware for the keyboard without going through Arduino’s IDE, please let me know) and that’d enable you to just tweak the appropriate bits in the firmware and reflash. Remapping a single key is not difficult. Have a look at uConsole/Code/uconsole_keyboard at master · clockworkpi/uConsole · GitHub . The bit that handles the presses for the A button is here: uConsole/Code/uconsole_keyboard/keymaps.ino at master · clockworkpi/uConsole · GitHub . It looks like it’s mapped to “j” when the switch is toggled, so if you wanted it to send the same keycode as Cmd/Fn+Alt does, then, per line 670, it looks like you want to use _CMD_KEY.

For a first LFS, you’ll have an easier time doing it for a more standard machine first before doing it for a quirky SOC with a lot of custom hardware. Especially if it’s your first time, it can be tricky to determine if something breaks because you haven’t done it before and you missed something, or because it’s a different CPU, or your cross-compiling toolkit has some problem, or whatever else. It will take a while to build some things and you’ll have to deviate from standard LFS for the bootloader and image format, you’ll have to add some of the CPi-specific bits for hardware support (like the gearbox if you go with A-06, drivers for the fan, printer, etc.).

That aside, I’ve been playing with ARM stuff for years and I love ARM (and the A-06 is wonderful, I love it), but so far, riscv64 is really nice and compiling stuff goes a little smoother. The chip’s less beefy than the ARM offerings by quite a bit but RISC-V is open (so dev support is pretty enthusiastic) and there’s so much variance in ARM that the R-01 goes a lot smoother when compiling anything.

It is the explaination . I have to find why .batteries are 9900 mAh GTF

That’s why. The 9900mAh batteries are false advertising. There’s a thread about it: Large Capacity Batteries in uConsole . Regardless of the advertised capacity, most of the Chinese batteries on Amazon are about 1000-1200mAh. There’s a link in there to a video, a place to buy reasonable batteries, etc. I haven’t used the store they link to, but I have had the same experience with Amazon batteries; I have had the best luck with the MXJO brand, the A06 lasts 4-6 hours on that easily. If you try out sudo powertop, you can see a lot of information, the screen brightness takes more power than the CPU sometimes.

Only one OS working .

It takes some effort to get another distro running. On the DevTerm, I’ve been running Slackware on my R01 and CRUX on my A06, though I’m running a stock CPi OS image on my uConsole (CM4). There are wiki pages for building the OS from scratch, they’re very helpful.

If you are trying to run Kali like you mentioned in the other thread, the easiest way to do this is to start with the official image and keep the kernel/DTB stuff in place and then clear out everything but /lib/modules and extract a Kali aarch64 rootfs over it. There is some userspace stuff you’ll want to keep from the official image or build from the git repo, like the gearbox.

Raspi 5 is ruuning most of linux distribution

It’s a very popular platform so more people are interested in producing images for it that work out of the box. The Clockwork Pi gear is excellent stuff, but it often requires some hacking; this is fine with me, I got it for hacking. They’re not really comparable systems, one of them is an SBC and the other is a full system that contains an SBC and a screen/keyboard and a lot of other hardware. There are a lot of people building add-on boards ( uPico Expansion Card ), building out distros (so many threads), creating music ( uConsole Music Production ).

The Raspberry Pi is useful and started as an educational tool and it’s now really popular as a small computer that people can use, but most of Clockwork Pi’s gear is designed for creative hacking: building strange software, soldering jumper wires for hardware mods (it was really pleasant how many solder pads and circuit diagrams are available), that kind of thing.

wifi lost the communication , I have to reconnect to my access point

There are a few threads about this. Did you check out the antenna mods? I haven’t tried them but people say that they work great.

On battery , it is switch off after 10 minutes even if batteries are full , without any alarm

This sounds like a problem with the batteries. What kind are you using?

USB speed isn’t fast enough , have to reduce sample from sdr radio to minimum

This sounds cool. What are you trying to do with SDR? I’ve been playing with gqrx and rtl_fm but I am fairly new to those. SDR seems pretty popular with these devices.

Well I 'm quite unhappy

This forum has been really helpful to me, but I think you will have an easier time if you focus on one problem at a time instead of making several top-level posts complaining. Try asking one question per topic. I like the device, but I didn’t design the hardware, I didn’t make it, complaining to people here just adds negativity. A lot of people here are really happy to help with problems! A lot of them solve these problems and then post the results.

I got the R01 just for fun but I think I use it more than the A06. It’s a really delightful chip.

People have tried BananaPis without success; I don’t have a BPi or a Milky-V (though I have a DevTerm with the R01 installed and it’s delightful) to test, but I imagine you’d need, at minimum, the DTB overlays and whatever kernel patches the Milky-V wants.

There’s also some variation in models, like the embedded eMMC, wifi, things like that. So it depends on how compatible with the CM4 the Milky-V Mars CM is. The eMMC models apparently require some fiddling to boot because they have difficulty finding the boot device although it appears that the A06 will boot from a USB drive (which I found out by accident when I rebooted after my microSD card failed; I was building a CRUX system on the uSD card plugged in by a USB adapter and apparently had built out enough of the system to get a login prompt).

It’s Debian-based, so apt-cache search mgba should help, and then apt-get install the package you want.

It comes with RetroArch preinstalled, though, and I think it includes mGBA. If not, apt-get install retroarch libretro-mgba should install it.

DOSBox worked fine for me, but maybe because I’m using ratpoison rather than the full Xfce environment.

screen cuts in half unless I reboot my uConsole

This is an issue that DOSBox has even on my desktop system. Basically, in full-screen mode, instead of using its own scaling method, it adjusts the X resolution. Huge pain, especially in dual-screen setups.

I had this trouble after some wear on the trackball (have been using the DevTerm somewhat heavily) and eventually had to replace the trackball (see The Cheapest Keyboard Hardware Mod - #9 by omgmog for information). Basically, the ball spins and there are some tiny gears and sometimes it doesn’t generate enough friction. You might be able to fix it by cleaning if you’re very careful.

It’s in the wiki on the Github repo: Create DevTerm R01 OS image from scratch · clockworkpi/DevTerm Wiki · GitHub

On average, a few months, but last year was a little crazy so there’s a backlog. Aside from that, it depends on the core you order. Sometimes helps to email and ask which one ships fastest before ordering.

Ha, after so long in this thread, I kept coming back to this thread out of habit and then to follow the adventures of the other people I had waited with.

parcels progress across the globe!

That is uConsole shipping-related!

replacement “spare” cpu board just in case

Oh, yeah, I’m gonna be ordering more CPi stuff this year. Very excited by the gear so far, I have been using this DevTerm every day for a year (literally every day), and the uConsole has been extremely fun.

@MHam68HC11 @star @Funcron

I guess I don’t have a reason to keep checking this thread.

After two more 3-day builds of qt6-webengine, the last was successful! New packages are present in the .onion link and a couple of small additions to the ports repo.

I was tempted, because distcc was farming all of the compilation to my desktop and I had crammed an 8GB microSD card into the USB port for swap, to leave the JOBS=6 in. It turns out that if the wifi gets congested, distccd will sometimes blink out temporarily and distcc will do the compile locally. This is usually fine, but in this case, there wasn’t enough RAM to do six compiles locally, so it started eating into swap. I wake up and check the screen and the clock is lagging about 30 minutes in the past. After that, a couple of dependent packages needed to be rebuilt, nothing serious, and then qutebrowser was easy.

Nothing special to report for Firefox. Took about a day to compile, distcc handled it, except for the parts where rustc was involved. I think it might have worked out fine without distcc but I didn’t wanna risk it after spending a little more than a week trying to get qt6-webengine to build. I was braced for it to take three days but it was just under one day; I’m actually moderately surprised. (I might have skipped qutebrowser if I’d known Firefox was going to be this easy by comparison, but I had expected the opposite.)

This is, I think, the end of the part where I’m just checking in every few hours to see if it’s done. :‌P

So all that remains is to add ports for a couple of packages (e.g., drawterm is useful, cool-retro-term is fun, maybe try to build retroarch and love2d, though I mostly use my DevTerm for work and the uConsole for games), make some tweaks to the startup scripts, set up some defaults that are friendly for the DevTerm (e.g., minimize writes to disk and generally run lightweight), clean and polish, live with the system a few days to see if I’ve missed anything, and then use these packages to build a fresh image and upload that somewhere a little more accessible than just a Tor site and IPFS. (If you are in a hurry to run it, you can just take the packages and dump them into a rootfs.) I am excessively excited to have my machine available again instead of leaving it plugged in, occupied building packages. Very excited to pass -s 2 to the gear script again!

Except some small changes to the hardware (no rotating the screen, trade the printer for 4G modem, etc.), the same images work on both the DevTerm and the uConsole, so maybe next up I run off a uConsole image.

As a side note, barrier is extremely useful so there’s a package for that: git.debu.gs Git - cpi-ports/blob - barrier/Pkgfile . If you are not familiar, it’s a fork of the last open-source version of synergy, and basically it allows you to just move your mouse off the edge of one screen and onto another, running on another machine, so you can control multiple machines with one keyboard/mouse. (Like VNC but if you can just see the other monitor and thus don’t need the screen mirrored.) So when I’m at my desk, I have my DevTerm between my monitor and keyboard, and I turn on barrier and then I can just move my mouse down. I’ve also used it to control the uConsole from the DevTerm (uConsole is way newer, but you can imagine sitting at a table and using the DevTerm to edit code while using the uConsole to show documentation or play a video), or to control a machine that’s sitting on a desk using the DevTerm that I’m carrying around the room. Highly recommended.

Looks like it’s attempting to use a variable-width font; probably the one you were using was renamed or replaced in the upgrade. Tried setting a new font?

No cursor on the framebuffer, and I checked the number of 0’s in vt.cur_defaut=0xF00058 about a dozen times; the mistake I made the first time was I only added two zeroes. And I was also slightly suspicious, because the filesystem interface only accepts decimal. Anyway, all of that before just noticing today that I spelled “default” with no “l”.

The cursor returns to the framebuffer if you fix the last part of /boot/extlinux/extlinux.conf so that it reads vt.cur_default=0xF00058. (That is from hyperyay in RO1 : No software cursor displayed on fbcon - #20 by hyperyay .)

I should have probably guessed this, but doing this on an x86-64 host does not do what you might hope it does:

sudo qemu-aarch64 /tmp/a06root/bin/busybox chroot /tmp/a06root

It executes the chroot(2) syscall by emulating a 64-bit ARM CPU, and then tries to execute a shell in that chroot, but cannot do so because it is looking for an x86-64 executable. So I tried the binfmt script that comes with qemu:

$ sudo mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc
$ sudo /usr/local/bin/qemu-binfmt-conf.sh --qemu-path /usr/bin --persistent yes --credential
### [...lotsa output, succeeded...]
$ sudo /tmp/a06root/bin/busybox ls
### Works!
$ sudo /tmp/a06root/bin/busybox chroot /tmp/a06root /bin/busybox
### Fails because it can't find the libraries for qemu!

This would probably work better with qemu statically compiled and it is probably a bad idea to copy the x86-64 libraries into the chroot and then run ldconfig but that is what I did and I have no regrets:

$ sudo cp /lib/libz.so.1 /lib/librt.so.1 /usr/lib/libglib-2.0.so.0 /usr/lib/libgnutls.so.30 /usr/lib/libgmodule-2.0.so.0 /usr/lib/libstdc++.so.6 /lib/libm.so.6 /lib/libpthread.so.0 /usr/lib/libgcc_s.so.1 /lib/libc.so.6 /lib/libpcre.so.1 /usr/lib/../lib/libp11-kit.so.0 /usr/lib/../lib/libtasn1.so.6 /usr/lib/../lib/libnettle.so.8 /usr/lib/../lib/libhogweed.so.6 /usr/lib/../lib/libgmp.so.10 /lib/libdl.so.2 /usr/lib/../lib/libffi.so.7 /tmp/a06root/lib64
$ sudo cp /lib/ld-linux-x86-64.so.2 /tmp/a06root/lib
### I was worried this part wouldn't work:
$ sudo ldconfig -r /tmp/a06root
### ...but it did!  And then, after that, this worked:
$ sudo /tmp/a06root/bin/busybox chroot /tmp/a06root /bin/bash
# uname -m
aarch64

Before attempting that, note that I copied all of them into $chroot/lib64 rather than $chroot/lib. /lib64 is a symlink to /lib, so I just removed the symlink and then added the lbiraries there (the list of which libraries to copy having been generated by doing ldd $(which qemu-aarch64)). /lib/ld-linux is special, that’s the dynamic loader, it’s got to be in /lib.

Anyway, now that that’s working (I wish I had done it sooner; it would have made this build go smoother and likewise with the R01 Slackware build), I can start using that for distcc at least, maybe build more packages in it.

No updates yet. I ordered about a day after the email came. (Still waiting for my DevTerm, which I am very excited about, but I have been waiting for that computer my entire life, so it’s nothing to wait a few more months, haha.)

Just arrived and I love the thing, can’t put it down.

This is very cool! However, I think putting that into the firmware might be a problem; you lose software control of it. I have filed an issue: Hard-coded scroll wheel · Issue #49 · clockworkpi/DevTerm · GitHub

I’m using mine as a terminal mainly. :‌‌) drawterm to talk to the Plan 9 system, ssh to talk to everything else.

On-device I’m mostly using text files. I use awk a lot so that’s a convenient format. I have sqlite3 and Redis installed (but persistence disabled for Redis because I’m paranoid about wearing out the SD card). I am not using sqlite3 for anything yet, I just install it out of habit because

A wiki is not quite a database but I’ve been using AwkiAwki for taking notes and collecting links and as a browser start page; as a bonus, it lets me show the notes to people on the LAN. (Or using a fork of it: GitHub - pete/awki: Awki is a lightweight wiki written in awk. These are my patches, original here: http://awkiawki.bogosoft.com/ . If you are familiar with the first wiki, Ward’s Wiki, it’s a clone of that done a long time back.)

(Edit: If you type “:‌)” and it tries to draw a , you can put a U+200C between the colon and the close paren.)

That is very cool! Coincidentally, I have the same SDR. What are you using for ADS-B? (I’m very new to SDR.)

Edit: Found it: it’s called “dump1090”. It’s by Antirez, he’s really cool!

I’m just very excited still. I’m sorry to hear about the customs troubles (hope it gets solved) but mainly I’m still just extremely excited. It’s a very cool device, ClockworkPi has a very cool team, the DevTerm feels like it was made for hackers and I cannot put it down, I spent a week out of town visiting sick family and I could still work from the hospital all day (regrettably forgot to bring my SDR dongle, that might have been fun, but the hospital had good wifi), and I expect to love the uConsole when it arrives, too.

(There are a lot of negative posts. I am still excited about the device and still excited whenever I check this thread.)

I ordered on the 26th also. Very excited!

I ordered the uConsole October on October 27 (UTC, though I’m in the US, so it was still the 26th for me) and my order number is 197xx. I had placed another order October 18, a while before the uConsole announcement, and it was 189xx. I think the earliest I had seen for uConsoles was 190xx (looks like @Kumasun / @GreenAcres / @John_Kennedy ordered the first day; I hesitated a day because I was still waiting for my DevTerm), so in the first two days there were at ~700 orders. If @adcockm is 201xx on November 3, then there were ~1100 orders in the first nine days. (Very high volume for a small shop, no surprise that they are extremely busy! I hope the margins were high enough that they can afford to stay in business and expand; I got nervous when they moved to a more expensive shell.)

You can’t be certain of that, just how many orders are in the queue.

I don’t have a uConsole yet (still waiting) but I can say that I had to go out of town for a week and I took a DevTerm and only needed that the entire time. I’m a programmer, so I think with the uConsole, the smaller keyboard would make it trickier to use full-time without a keyboard/mouse, but I think I’d be fine using it as my main desktop with that (probably also a monitor).

Photographers have a saying, “What’s the best camera? The one you have with you.” The idea is that if the alternative is not taking the photo, any camera works, so it’s good to have one you can always carry. That’s the thing I expect I’ll like about the uConsole: it’s small enough that you can always have it with you.

Shipping notification! 197xx! Very excited!

Ah, yeah. My normal keyboard is the HHKB and the Fn key mappings match most of the HHKB’s. The trackball didn’t bother me too much, worked fine more or less, but I use ratpoison instead of a DE (not a very mousey UI) and most of the coding I do is either acme (somewhat mousey editor) or vi. I did stutter some when writing SQL or chatting with people, but for the most part, I’m close enough to regular typing speed on it that I can stop noticing the keyboard.

I have some WiFi troubles on mine, so I’m using a USB WiFi dongle until I get around to fixing it.

Assuming it’s not all due to the complicated setup, there was a thread somewhere around here about the CM4 defaulting to using the onboard antenna and ignoring the one that is actually plugged into the board, which makes a bigger difference on the metal-bodied uConsole. Apparently, that can be toggled with a kernel parameter: sudo sh -c 'echo "dtparam=ant2" >> /boot/config.txt'. (There was some elaboration in the thread but I don’t remember which thread.)

Yeah, I ordered a DevTerm mid-September of last year and it arrived mid-January. Of course, the uConsole was announced just a month after that; I hesitated to order for about a day because I had just ordered a DevTerm and was still waiting, but I figured that since it was a pre-order it would take a long time. So it was a long wait, but the timing was fine for me, by coincidence. My DevTerm still feels new, though I’ve been using it every day.

Though I suppose you could find a used PocketCHIP

Ah, that’s how I found the DevTerm: someone had posted photos of their PocketCHIP and I was excited about it, asked where to get one, and at least two people recommended I check out the DevTerm. I’m glad they did.

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

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.

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.

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.

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

[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.]

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.

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.

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.

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.

Is there anything in the X logs?

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.

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.

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.

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.

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

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

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.