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.

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

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.

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.

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

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.

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.

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.

I cannot remember what I did to make ninja cap itself at 2 processes instead of auto-detecting 6 cores and deciding to run 6 processes. (ninja is invoked by cmake, according to the docs there is no way to control this through an environment variable for ninja but I think there was a way to get cmake to pass -j2 or something. There are too many build systems. At any rate, since the qt6-webengine build has been running for two days, I don’t want to kill it and start from scratch.)

The issue is that too many parallel invocations of the C++ compiler overfill the RAM, and start bleeding into swap, and once the swap starts filling up, everything starts running at a glacial pace. You can kind of manually do it to a running process, though, by just suspending the ninja process (kill -STOP) and then letting the C++ compilers finish, and resuming the ninja process once RAM use is low enough. Since it’s swapping, I figured it’d be easiest to use renice -n -1 to bump the priority of whatever compiler process was using the most RAM, to get it out of the way faster.

Larry Wall said the three virtues of a great programmer are laziness, impatience, and hubris.

Exercising my laziness, the first virtue, I enlisted awk to just stop ninja when load average got over 4 and bring it back when it went back under 3:

while sleep 1; do uptime; done | mawk -Winteractive '
BEGIN{system("sudo killall -CONT ninja");s=0}
(0+$10) > 4 && !s{system("sudo killall -STOP ninja");s=1}
(0+$10) < 3 && s{system("sudo killall -CONT ninja");s=0}
{print $10, s}'

The second virtue being impatience, maybe there’s a good way to speed the process up. Since the bottleneck for the C++ compiler is RAM and I/O rather than CPU, I think I’ll make another attempt at distcc, but this time, instead of running a cross-compiler, I’ll just copy enough of the rootfs to run a minimal chroot with a compiler under qemu-aarch64 and then run distccd under that. (Shouldn’t have the problem with bad binaries if it’s not just the same version of the compiler, but an emulator running an exact copy of the same compiler, right? …Right?) If that works, it should help with the C++ stuff; I don’t think distcc works for Rust (so it might not help when building Firefox), and gcc doesn’t require nearly as much RAM as g++ (so it’s not needed for regular C compiler invocations).

The third virtue is hubris, and I use this for everything I do.

apt-cache search libretro should show you a list of cores that you can install, and you can do, for example, apt-get install libretro-beetle-psx.

That’s the rgui interface. It used to be the default for retroarch. If you want to use one of the other UIs, from the main menu you select Settings, Drivers, then Menu.

Periodically updating the repos and the prebuilt ports directory; trying qutebrowser since it seems like it’ll be easier to build than Firefox, but at this point, everything except the browser is working fine.

The qt6-base package had to be updated because I apparently built it before libxkbcommon. Poor little machine is sitting at 100% CPU for a few days; I had bad luck with distcc lately (it produced binaries that segfaulted) so I’m doing all of the building on-device. So it’s building qt6-webengine now and hopefully that completes successfully.

That’s actually not so bad if most of what you are doing is reading. On the RISC-V, just informally (powertop), it seems to use about half the power of the A06: the majority of power usage is from the backlight on the screen. So if you’re reading, 1Hz isn’t bad, probably 5Hz is usable for text interfaces.

On the other hand, it’s probably easier to just plug an e-ink display into the micro-HDMI port. I expect that a display that is pin-compatible with the stock display is going to probably going to be the same tech, an e-ink display is going to be very different.

There is the R01, which is RISC-V, but that’s even less likely to run Steam any time soon. (It is a pretty cool chip, though.)

@skalimoi While producing the CRUX image ( CRUX for DevTerm A06, dev notes ), I had to write a small build script for all of those files. I did it as one large package instead of several small ones: git.debu.gs Git - cpi-ports/blob - devterm-a06/Pkgfile .

It is technically for the A06, but it should be almost the same for the CM4. You’ll have to change a few pieces (you can skip the wiringPi section, which is huge, because the CM4 has that upstream and the gearbox) and tweak the fan part. I think, though, that this is basically all the pieces you need, and CRUX and Arch are closely related enough that it might translate almost directly into an AUR PKGBUILD file.