At this point in my Chumby kernel upgrade project (parts 1, 2, 3, and 4 here), I had made a ton of progress but there wasn’t really much to show for it because I didn’t have the LCD working. Even though I had put a ton of work into the project, the display was still black. I knew it was time to get it working.

I started out with U-Boot. As a very basic overview of the LCD controller in the PXA168, basically you just set aside some of your RAM for a framebuffer, copy image data into it, tell the controller the format and address of the framebuffer, set up the clocking and timing, and turn it on. Then it just handles everything in the background for you.

The steps I listed above are overly simplified — there is more stuff going on with the PXA168’s display controller. But it’s enough to get a splash screen working in U-Boot. I booted into the old kernel and dumped the LCD registers using devmem. Here’s an example of this process. The LCD_SPU_DMA_CTRL0 register contains a bunch of format configuration bits for the framebuffer, such as which bits are red/green/blue. It’s at offset 0x190 in the LCD controller, and the LCD controller is located at an offset of 0xD420B000, so I could dump the 32-bit register value with this command:

devmem 0xD420B190 32

This resulted in a printout of the value of the register:

0x8441111

Read the rest of this entry

Update on 2023/05/19: ASUS has publicly acknowledged the issue and provided an explanation and workaround of their own (rebooting, or a hard reset if the reboot doesn’t fix it). The original post is below:

When I woke up today around 6:45 AM PDT, I didn’t seem to have internet service available. My phone told me that I was connected to my Wi-Fi network, but it didn’t have connectivity. “Hmm, that’s weird,” I thought. Maybe a fiber cut in the area or something? I looked at my IRC client on my desktop Windows PC, which is nice because it records timestamps of when I lose my connection:

03:24:23 - Disconnected (Remote host closed socket)

My connection had been down for over 3 hours at this point. Weird! I figured I would log into my ASUS RT-AC86U router’s web interface and see what was going on. Something happened that I wasn’t expecting at all — the page wouldn’t fully load. Portions of it showed the little “sad page” icon indicating a connection error.

I tried to SSH into the router instead. The first few connection attempts failed, and then finally I got in. What I found, though, was that I couldn’t run any commands. It just spit this error back at me:

-sh: can't fork

OK, so something was really messed up. I decided to power cycle the router at this point. Maybe some weird glitch happened or something. Which would be odd — this router has been pretty rock solid since I’ve had it, aside from 2.4 GHz Wi-Fi issues over time. That’s another story I don’t want to get into today.

Anyway, when the router came back up everything seemed fine. But then, 40 minutes later, my connection dropped again with the same symptoms.

07:26:23 - Disconnected (Remote host closed socket)

Read the rest of this entry

My cousin recently got ahold of me, saying that he was having trouble with his Brother FAX-2840 fax machine/laser printer. It still worked fine as a fax machine or copy machine, but he couldn’t print to it from his Windows 10 computer. He has a business where he needs to be able to print forms and receipts for customers, so it’s a big deal when he can’t print. This particular printer only has a USB port for PC connectivity. It’s connected directly to his computer. I went through all the basic troubleshooting with him:

“Did you try unplugging and replugging it? Did you try a different USB port on the computer? Maybe the computer needs a reboot?” None of that fixed it. I stopped by after work to take a look, hoping that it was just some simple glitch that I could resolve.

When I arrived, it quickly became apparent that this was more than a glitch. Whenever I plugged the printer into his computer, a message popped up saying: The last USB device you connected to this computer malfunctioned, and Windows does not recognize it.

Read the rest of this entry

For the next post in my series about upgrading my Chumby 8’s Linux kernel (here are links to parts 1, 2, and 3), I thought I’d look at what was involved in getting the reboot and poweroff commands working properly. I noticed pretty early during the development process that they didn’t work, which was pretty annoying.

The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot
[   46.457580] reboot: Restarting system
[   47.458947] Reboot failed -- System halted

This meant that in order to restart the Chumby, I had to physically press a button to power it off and again to power it back on. As you can imagine, this got old really fast during development. For that reason it was one of the earliest things that I got working.

I actually implemented it in U-Boot first, but I thought the Linux side of it would be more fun to share. If you want to see what was involved on the U-Boot side, see this commit from my fork of U-Boot.

Read the rest of this entry

If you’ve been reading my blog for a while, you might remember back in 2012 when I changed the startup sound on my Power Mac G3 (Blue and White). That was a fun introduction to the Forth programming language. I had to reverse-engineer just enough of Apple’s firmware update script to understand what was going on.

Recently, Aidan Halpin, a reader of this site, asked me if I could do the same kind of startup sound customization on his iMac. This particular iMac is officially known as the “iMac (Slot Loading)” and has a model identifier of PowerMac2,1. As you can guess from the name, it has a slot-loading CD-ROM drive unlike the original iMac that had a laptop-style tray-loading drive. By the way, Aidan’s iMac is special because it has a PowerPC G4 processor soldered onto the logic board instead of the original G3.

Photo courtesy of Aidan Halpin

Read the rest of this entry

This is the next post in my series about upgrading my old Chumby 8’s kernel. Here are links to part 1 and part 2 if you missed them. As a quick summary, I got U-Boot working in part 1 and then got the SD card working in part 2. In this part I’ll describe the complicated process of how I got Wi-Fi working.

The Chumby 8/Insignia Infocast 8 has a built-in AzureWave AW-GH321 802.11g module. This is a pretty old module that doesn’t even support 802.11n, so it maxes out at 54 Mbps and the link is an archive.org link because it’s nowhere to be found these days. The module makes use of the Marvell 88W8686 chipset, which connects through the SDIO bus. SDIO is basically just the same as SD, except it’s for I/O devices like Wi-Fi and Bluetooth modules instead of SD cards. This wireless chipset is supported by a Linux driver called libertas.

Read the rest of this entry

This is a continuation of my previous post about upgrading the old 2.6.28 Linux kernel that came with my Chumby 8. In that post, I got a modern U-Boot working with SD card support, which is what I needed in order to boot Linux.

After I finished getting U-Boot working, I began work on the kernel. I based my work on the stable kernel version 5.15.33. I started by compiling a kernel using the bundled pxa168_defconfig file. I created a device tree file called pxa168-chumby8.dts based on pxa168-aspenite.dts. It needed a few tweaks. I specified the correct amount of RAM for the Chumby 8 (128 MB) and changed the model and compatible strings. I also disabled “twsi1” which is an I2C host. I wasn’t ready to deal with I2C yet. Here’s a small snippet of the relevant changed parts of my new device tree file.

Read the rest of this entry

As I mentioned in my last post, I spent a good chunk of my spare time over the past 6 months working on a project I’ve been thinking about for over a decade. I bought a Chumby 8 in 2011. It’s an 8″ touchscreen device powered by the Marvell PXA166 processor. It is essentially a souped-up digital picture frame with extra capabilities like speakers, a microphone, and Wi-Fi. There are a bunch of little Flash-based “apps” you can install for stuff like pictures, music, sports scores, weather, games, etc. I have no idea how many of the apps still work these days. Chumby actually went out of business a few months after I bought mine, although one of the founders stepped up to keep the service running. A variant of this device was also created for Insignia, which was called the Infocast 8″ Internet Media Display.

I was never really interested in using it for any of the stock functionality. I thought it would be a fun development platform. It would be exciting to make some custom apps in Qt or something. One thing that was a little frustrating was that it came with a Linux 2.6.28 “Erotic Pickled Herring” kernel circa Christmas 2008, which was ancient even at the time I bought it. This is a pretty common issue with Linux-based devices. I will even admit I’ve been responsible for some old kernels out in the field in Internet-connected devices. I don’t blame Chumby. It’s tough when the SoC vendor doesn’t submit their kernel modifications upstream or at least keep their fork up to date. I’ve been there.

Read the rest of this entry

I’ve been doing some Linux kernel development in my spare time over the past 6 months or so. The goal has been to get my old Chumby 8 (stock kernel 2.6.28) running on a modern kernel with custom firmware. It has been going really well and there have been lots of fun problems I’ve needed to solve along the way. I may write some posts about that process if there is any interest. It’s been a blast.

Anyway, I thought it would also be fun to jump into the current craze of OpenAI’s ChatGPT free research preview and apply it to Linux kernel development. Let’s see just how well this AI can write a basic kernel module that I describe. Can it improve the module as I ask it to make tweaks?

I started out by asking:

Write a Linux kernel module that prints “Hello world” to the console every 5 seconds. Also provide a Makefile for compiling it.

Read the rest of this entry

This post is going to be a bit different from my usual posts. It’s still about computers, but it’s about a different type of computer: the computer modules in my 2009 Dodge Ram 1500 pickup. Vehicles these days have lots of computers in them. I’ve historically been afraid to mess too much with them in fear of screwing them up. Something going wrong has much more serious consequences when it’s your vehicle, as opposed to a spare computer you’re dinking around with. I’m slowly getting more confident though.

Read the rest of this entry