💾 Archived View for gemini.stjo.hn › cobalt-qube-3-part-2 captured on 2021-12-06 at 14:29:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
_____________________________ST JOHN KARP_____________________________
__________________Ramblings of an Ornamental Hermit___________________
2018-06-07
The saga continues! I previously wrote about my laborious experiences compiling a 2.6 kernel for the Cobalt Qube 3 and getting a semi-modern Linux distro running on it. Those steps took me as far as Debian Wheezy, but official support has now ended for that release and the latest Debian won't run on an i586 processor. So where are we supposed to go from there? Read on, dot dot dot.
Slackware is the only mainstream Linux distro (outside of Gentoo) that still supports the i586 architecture. I exclude Gentoo from that calculation because it's a source-based distro and compiling all your software on a Qube will be ridiculously time-consuming, though you're welcome to have at it if you're that way inclined.
So a-slacking we must go, but will modern Slackware run a 2.6 kernel? Even if it does it would probably stop supporting it in the near future, and besides, there's all those juicy kernel updates and security improvements that have been made since then. Are we going to miss out on all those? Are we buggery.
It took me a good weekend because I'm no C developer and know precious little about the kernel, but I eventually managed to port the old Cobalt kernel patches to a 4.17.2 kernel. I daresay there are even some improvements because the maintainers of the 2.6.36 patches had disabled the code that handled writing to the LCD panel and had misplaced some of the code for the Cobalt reboot routine. It wasn't hard to uncomment that code and update it to work with the newer function calls. Again I want to state that I am not a C developer or a kernel expert, so these patches are unofficial, unsupported, and entirely at your own risk. That said they seem to be working pretty well for me and I've confirmed the Cobalt drivers do actually do their thing.
Here we go then, here's how to get your Slackware up and running:
Update: When I wrote this originally it was for the 3.16.56 kernel source. I've since updated it for the newer 4.17.2 kernel, but I'm keeping the 3.16.56 patches online in case anyone needs them.
Plug your hard drive into a separate desktop and install Slackware 14.2. You can do this by booting from the installation media, or just handling the whole process via VirtualBox as described in my previous post.
Grab kernel 4.17.2 (the latest stable release at the time of writing):
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.2.tar.xz
tar xvf linux-4.17.2.tar.xz
mv linux-4.17.2 /usr/src/linux-4.17.2-cobalt
cd /usr/src
ln -s linux-4.17.2-cobalt linux
cd linux
Apply my 4.17.2 kernel patches:
patch -p1 < ~/linux-4.17.2-cobalt.patch
I figured out a working kernel config through trial and error. Originally the kernel compiled to something like 2.3 MB, which was evidently too big because it just refused to boot. After stripping out some stuff that wasn't relevant on a Cobalt and compiling a bunch of other things as modules I got it down to 2 MB and that seems to boot just fine on my machine. If it doesn't boot for you, you may need to slim it down further.
cp arch/x86/configs/qube3_defconfig .config
I only created a working config for the Qube 3. The previous patch also contained some configs for various Raq machines, but I didn't port those because I can't test them. You should be able to use them and run "make oldconfig" to bring them up to speed with this kernel, but you might have to do some work to remove stuff you don't need.
Don't forget to make any edits you need for your own hardware. In my case I compiled CONFIG_SATA_SIL as a module because I use a particular SATA PCI card.
Update: After porting the Cobalt patches to 4.17.2, the size of the compiled kernel ballooned back up to 2.3 MB. I reduced it again by getting rid of as much as I could, which unfortunately included the RAID drivers. Please review your requirements to figure out what you need and re-enable them in your config, but you may need to take something else out or compile them as modules to keep the size down.
Compile and install:
make
make modules_install
make install
strip vmlinux
bzip2 -c vmlinux > /boot/vmlinuz-4.17.2-cobalt.bz2
cd /boot
ln -s vmlinuz-4.17.2-cobalt.bz2 vmlinux.bz2
When I did this the installation build step automatically put its System.map into the /boot folder, so no need to do it manually as we did in my last post. I also noticed it didn't create an initrd.img, but then my machine booted fine without it so I won't go dicking with it now.
Prepare the OS to be booted on your Qube.
I had my drive plugged in as a USB device so Slackware detected it as /dev/sda. If this was the case for you too, you'll need to edit the /etc/fstab entries from /dev/sda1 etc. to /dev/hda1 etc.
Edit /etc/inittab to comment out the normal tty1, tty2, etc. and uncomment the first serial line ttyS0. Edit the baud rate of that serial tty from 9600 to 115200. It should look something like this:
s1:12345:respawn:/sbin/agetty -L ttyS0 115200 vt100
This will enable you to connect to your Qube using the serial terminal.
You might also want to uncomment ttyS0 in /etc/securetty. Otherwise this will prevent you logging in as root via the serial console.
Remove the network hardware automatically detected on your current machine:
rm /etc/udev/rules.d/70-persistent-net.rules
This will get automatically regenerated when we boot off the Qube.
Now everything's jake --- you can take your drive, plug it into your Qube, and boot ’er up. Plug in via the serial console to continue setting it up the way you like it. How do I know what you want a Qube for. Get your own ideas. Go on. Shoo.
What was the point of all that fiddling around with kernel drivers if we're not actually going to use them? First I wanted to confirm they actually worked, so I did a couple of these:
cat /proc/cobalt/raminfo
cat /proc/cobalt/sensors/thermal
This spits out a bunch of data about the current RAM and CPU temperature, so we're looking good on that front.
You can also run this:
cat /proc/cobalt/lcd
Now you can read what's currently printed to the LCD panel at the back. But how the hell do you write to it? Turns out some angel-eyed developer called Jeff Walter created some utilities for interacting with the LCD panel, so let's fire those up and see what's what. His original site is now offline, but he did submit the source to the Debian repos at some point. You can download the source and compile it, then write to the LCD panel by running:
lcd-write "Skaboopy"
Go check your LCD panel --- go on, I'll wait. Isn't that nifty?
I haven't got the original program that shipped with the Qube to manage all the buttons, but it looks like these utilities will help you if you want to write a new program to do what you like with it. Personally I can't imagine using the panel often enough to bother with that, but I did set up a little cron job to run this every day to display the Discordian date:
lcd-write "$(ddate +"%A")" "$(ddate +"%e %B")"
I had to go through some bum hardware before I figured out the smart way to do things, so let me save you some time. Don't bother with an IDE hard drive. They're all getting old now, and even if you find one that works it's not going to last forever. Then what are you going to do? Make one? No, what you want is a 120 GB SATA drive to act as your main drive and an IDE-to-SATA adapter to plug it into the Qube's IDE controller. You'll need an adapter that specifically supports ATA 33, like this one from StarTech.com. If your adapter doesn't mention ATA 33, don't buy it --- it probably won't work.
120 GB is about the largest drive you can plug into that IDE controller due to the Qube's hardware limitations. That isn't a stellar amount of storage these days, so you may want some extra. You can plug an external hard drive into the USB port at the back, but it is USB 1.1 so be prepared for some glacial speeds. I preferred to grab a SATA PCI card, whack it into the Qube's free PCI slot, and plug a 1 TB drive into that. Bob's your auntie. Don't forget to pick up a Molex to SATA power adapter too. You won't be able to boot off this drive, but it will give you some bonzer extra storage at a decent transfer rate.
If you're anything like me you'll have got this far and, feeling very satisfied with yourself, prepare to put the lid back on your machine --- only to find that the damn thing won't close because your drives stick up too high. It appears that the old IDE ribbons had a pretty low clearance and the lid of the Qube was built without much wiggle room. Both my IDE-to-SATA adapter and the SATA cables for my secondary drive stuck up too high to let me shut the lid. Even replacing the SATA cables with right-angle connectors didn't make them low enough, so you're going to have to get a bit ingenious here. First thing is, make sure you get 2.5" drives, not 3.5". It turns out 2.5" drives are short enough that you can just mount them one screw lower on the Qube's mounting brackets. Sure, they'll only be secured by one screw on either side, but they'll fit into the slot like a dream and let you close that lid.
Now aside from the CPU, which can't be upgraded beyond 550 MHz, there's one remaining bottleneck with these machines — the USB port which is USB 1.1 and crawls like a dead whale. So far I haven't been able to upgrade it because I already used up the PCI slot with a SATA controller. Too bad. If you're not using a secondary drive you might consider a USB 2.0 PCI card (remembering to recompile the kernel with support for any new drivers you need). A USB card could theoretically let you plug in a fast external drive, but I'm wary about modding the hardware too much. At some point you may as well just install a Raspberry Pi in the case and be done with it. Nonsense I say! I'm here to use this beautiful machine's native hardware and I'll be damned if I let some jumped-up PCI card ruin the flawless integrity of this noble undertaking.