devicetree

2 Articles

At Last, Chumby Is Ready

August 5, 2024 by 14 Comments

It has been two years, but the slow and steady progress that [Doug Brown] has been making towards bringing a modern Linux kernel to the Chumby has approached the point that it could be called done. In his final blog post of the series, [Doug] walks through the highs and lows of the whole process.

Many of the changes [Doug] and others have made are already upstream in the Linux mainline. However, some will likely remain in private branches for a few reasons that [Doug] gets into. The blog post covers every commit needed to turn a Chumby or other Marvell ARMADA-powered widget into a working device. At the end of the day, what does [Doug] have to show? He can turn it on, see a boot logo, and then see an indefinite white screen. While underwhelming to most of the world, an X server is coming up, Wi-fi is online, the time syncs from an NTP server, and the touchscreen is ready to be tapped. A white screen, yes, but a white screen of potential. [Doug] has to decide what to launch after boot.

However, the future of the Chumby and other older devices is still on the chopping block of progress. Compiler writers want to drop support for platforms that nobody uses anymore, and the Chumby is ARMv5. With many changes destined to languish, [Doug] still considers it a huge success, and we do too. The whole series represents a journey with beautiful lessons about the power of the Linux device tree, making the dark and scary world of Linux kernel drivers seem a little more approachable.

We’ve covered the first post and when graphics started coming along. We salute the mighty Chumby and the idea it stood for. Of course, the idea of a handy screen displaying information is still alive and well. This handy e-paper HomeAssistant display is just one of many examples.

WiFi, PWM Backlight, And Graphics On Updated Chumby Kernel

August 29, 2023 by 5 Comments

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.