For some, the Chumby was a peek at what could have been. That vision never died for [Doug Brown], and he has been working tirelessly on bringing mainline Linux kernel support to the customizable smart display. He has posted several updates but recently got graphics and the PWM backlight working.
Of course, we covered when [Doug] first started working on the new kernel, so it’s high time we revisited the progress. The WiFi hardware uses a Marvell 88W8686 chipset, which talks over the SDIO bus, so it’s a matter of convincing the libertas driver to talk to it. With a USB to Ethernet adapter, [Doug] could boot new kernels over NFS, so he didn’t have to walk over to swap the SD card. After dealing with an unhandled fault when trying to read the SDHCI_HOST_VERSION register, [Doug] had access points showing up in NetworkManager but could not connect. As a nasty hack, he temporarily removed the interrupts and switched to polling in the driver. While that worked, it would never get upstreamed. A critical interrupt was being dropped, and commands went out of sequence. A second, perhaps ugly hack, read a register after acknowledging an SDIO interrupt, which seemed to work. But it was still a hack, and [Doug] wanted something cleaner. In a blind stroke of luck, he found the errata online and noticed that it mentioned that an interrupt could be missed when a signal was asserted. After following the workaround with a lot of head-scratching and deep diving, he had a fully working WiFi driver.
Graphics were a more straightforward endeavor compared to WiFi. He enabled the simpledrm driver (similar to simplefb) but using Direct Rendering Manager. He had a working panel that could run Qt apps by adding the frame buffer to the device tree with the correct compatible string, registers, and data. However, there was a Vivante GC300 graphics accelerator onboard that he wanted to use. A driver for Vivante GPUs already exists in the kernel, but after enabling it, the driver detects the GC300 and then starts complaining. He discovered that older revisions of the GC300 (like the ones found in Chumbys) mapped registered at different addresses and didn’t set some bits in their idle registers. Of course, just loading a GPU driver isn’t quite enough. He modified an x11 server that supported Vivante accelerators to support the GC300.
For hacking purposes, [Doug] set the backlight GPIO high. While easy to see, perhaps not the best for a device meant to blend in. The PAX166 comes with PWM hardware, though confusingly, it has two PWM modes for pin 84. PWM1 and PWM2 share some common clock and reset bits in a decidedly undocumented way. PWM2 doesn’t work until you configure and then turn off PWM1. However, the backlight turned off once out of UBoot and into Linux. Linux re-initialized the hardware too quickly, causing the device to freak out. This was solved using the abrupt shutdown register.
It’s a journey through debugging, Linux internals, and device tree hackery. Perhaps the most incredible thing is that these changes are submitted for upstreaming to the Linux kernel, with many landing in Linux 6.2. While it’s a shame new Chumbys aren’t being made, making your own smart display has never been easier.
Many many moons ago I was building a car PC using a chumby 8″ as the base. A car wreck and continued problems with the software ecosystem shelved the project, and I eventually reused the LCD before it started to delaminate.
I.mx233 IIRC. weird bootloader stuff… Ahh the early days of hacking on ARM hardware.
That was the older chumby of the first and second generation. The third generation chumby was based on the PXA168, an 800MHz chip that Marvell made, after buying Intel’s ARM license and technology. I don’t remember much of the gpu specifics but it was a decent chip. The chumby software of course used an embedded build of Flash player which had some extensions to call out to hardware libraries. I believe the first generation NeTV used the same PXA168 to generate the video to be overlayed.
The only reason xorg “still works” at all on amd/nvidia is they spend a lot of time putting hacks into their DDX drivers. That’s also why on intel xorg tends to be buggy as all hell (their DDX driver for xorg isn’t looked after and pretty bitrotted at this point) and it’s why on arm devices xorg tends to be an absolute mess.
See for details: https://mastodon.social/@marcan@treehouse.systems/110371566651716141
With working openGL graphics drivers and DRM infrastructure, you might actually get better support from one of the more mature wayland compositors. KDE, perhaps.
A modern chumby device would be great, obviously not flash based :)