An 128x64 OLED display with a weird image on it, showing a mouse cursor, date and time in the bottom right corner, and a whole lot of presumably dithered dots

Making Your Own Technically-HDMI OLED Monitor

One day, [mitxela] got bored and decided to build his own HDMI monitor – the unconventional way. HDMI has a few high-speed differential pairs, but it also has an I2C interface used for detecting the monitor’s resolution and issuing commands like brightness control. In fact, I2C is the backbone for a lot of side channels like these – it’s also one of our preferred interfaces for connecting to cool sensors, and in this case, an OLED display!

[mitxela] describes his journey from start to end, with all the pitfalls and detours. Going through the pinout with a broken hence sacrificial HDMI cable in hand, he figured out how to probe the I2C lines with Linux command-line tools and used those to verify that the display was recognized on the HDMI-exposed I2C bus. Then, he turned to Python and wrote a short library for the display using the smbus bindings – and, after stumbling upon an FPS limitation caused by SMBus standard restrictions, rewrote his code to directly talk to the I2C device node, raising FPS from 2 to 5-10.

From there, question arose – what’s the best software route to take? He tried making a custom X modeline on the HDMI port the display was technically attached to, but that didn’t work out. In the end, he successfully employed the Linux capability called “virtual monitors”, and found out about an interesting peculiarity – there was no mouse cursor to be seen. Turns out, they’re typically hardware-accelerated and overlaid by our GPUs, but in [mitxela]’s case, the GPU was not involved, so he added cursor support to the picture forwarding code, too.

With partial refresh, the display could be redrawn even faster, but that’s where [mitxela] decided he’s reached a satisfactory conclusion to this journey. The write-up is a great read, and if videos are more your forte, he also made a video about it all – embedded below.

We first covered the ability to get I2C from display ports 14 years ago, and every now and then, this fun under-explored opportunity has been popping up in hackers’ projects. We’ve even seen ready-to-go breakouts for getting I2C out of VGA ports quickly. And if you go a bit further, with your I2C hacking skills, you can even strip HDCP!

We thank [sellicott] and [leo60228] for sharing this with us!

Continue reading “Making Your Own Technically-HDMI OLED Monitor”

Hacked GDB Dashboard Puts It All On Display

Not everyone is a fan of GUI interfaces. But some tasks really lend themselves to something over a bare command line. Very few people enjoy old command line text editors like edlin or ed. Debugging is another task where showing source files and variables at all times makes sense. Of course, you don’t absolutely have to have a GUI per se. You can also use a Text User Interface (TUI). In fact, you can build gdb — the GNU Debugger — with a built-in TUI mode. Try adding –tui to your gdb command line and see what happens. There are also many GUI frontends for gdb, but [cyrus-and] has an easy way to get a very useful TUI-like interface to gdb that doesn’t require rebuilding gdb or even hacking its internals in any way.

The secret? The gdb program runs a .gdbinit file on startup. By using Python and some gdb commands, [cyrus-and] causes the debugger to have a nice dashboard interface for your debugging sessions. If you install a helper script, you can even get syntax highlighting.

The system uses modules and you can even add your own custom modules and commands, if you like. You can also control what modules appear on each dashboard display. Normally, the dashboard shows when the program stops. For example, on each breakpoint. However, gdb has a hook system that allows you to trigger a dashboard using the appropriately-named dashboard command on other commands, too. Using the layout option to the dashboard command, you can even trigger different modules at different times.

Installation is simple. Just put the .gdbinit file in your home directory. If you want syntax highlights, you need to install Pygments, too. We understand you can even use his under Windows, if you like.

We don’t always take full advantage, but gdb is actually amazing. The flexible architecture makes all sorts of interesting things possible.

Linux Fu: Simple Pipes

In the old days, you had a computer and it did one thing at a time. Literally. You would load your cards or punch tape or whatever and push a button. The computer would read your program, execute it, and spit out the results. Then it would go back to sleep until you fed it some more input.

The problem is computers — especially then — were expensive. And for a typical program, the computer is spending a lot of time waiting for things like the next punched card to show up or the magnetic tape to get to the right position. In those cases, the computer was figuratively tapping its foot waiting for the next event.

Someone smart realized that the computer could be working on something else while it was waiting, so you should feed more than one program in at a time. When program A is waiting for some I/O operation, program B could make some progress. Of course, if program A didn’t do any I/O then program B starved, so we invented preemptive multitasking. In that scheme, program A runs until it can’t run anymore or until a preset time limit occurs, whichever comes first. If time expires, the program is forced to sleep a bit so program B (and other programs) get their turn. This is how virtually all modern computers outside of tiny embedded systems work.

But there is a difference. Most computers now have multiple CPUs and special ways to quickly switch tasks. The desktop I’m writing this on has 12 CPUs and each one can act like two CPUs. So the computer can run up to 12 programs at one time and have 12 more that can replace any of the active 12 very quickly. Of course, the operating system can also flip programs on and off that stack of 24, so you can run a lot more than that, but the switch between the main 12 and the backup 12 is extremely fast.

So the case is stronger than ever for writing your solution using more than one program. There are a lot of benefits. For example, I once took over a program that did a lot of calculations and then spent hours printing out results. I spun off the printing to separate jobs on different printers and cut like 80% of the run time — which was nearly a day when I got started. But even outside of performance, process isolation is like the ultimate encapsulation. Things you do in program A shouldn’t be able to affect program B. Just like we isolate code in modules and objects, we can go further and isolate them in processes.

Doubled-Edged Sword

But that’s also a problem. Presumably, if you want to have two programs cooperate, they need to affect each other in some way. You could just use a file to talk between them but that’s notoriously inefficient. So operating systems like Linux provide IPC — interprocess communications. Just like you make some parts of an object public, you can expose certain things in your program to other programs.

Continue reading “Linux Fu: Simple Pipes”

Run Your Own Server For Fun (and Zero Profit)

It seems there’s a service for everything, but sometimes you simply learn more by doing it yourself. If you haven’t enjoyed the somewhat anachronistic pleasures of running your own server and hosting your own darn website, well, today you’re in luck!

Yes, we’re going to take an old computer of some sort and turn it into a web server for hosting all of your projects at home. You could just as easily use a Raspberry Pi –even a Zero W would work — or really anything that’ll run Linux, but be aware that not all computing platforms are created equally as we’ll discuss shortly.

Yes, we’re going to roll our own in this article series. There are a lot of moving parts, so we’re going to have to cover a lot of material. Don’t worry- it’s not incredibly complicated. And you don’t have to do things the way we say. There’s flexibility at every turn, and you’re encouraged to forge your own path. That’s part of the fun!

Note: For the sake of space we’re going to skip over some of the most basic details such as installing Linux and focus on those that have the greatest impact on the project. This article gives a high level overview of what it takes to host your project website at home. It intentionally glosses over the deeper details and makes some necessary assumptions.

Continue reading “Run Your Own Server For Fun (and Zero Profit)”

Linux Fu: Fusing Hackaday

Unix and, by extension, Linux, has a mantra to make everything possible look like a file. Files, of course, look like files. But also devices, network sockets, and even system information show up as things that appear to be files. There are plenty of advantages to doing that since you can use all the nice tools like grep and find to work with files. However, making your own programs expose a filesystem can be hard. Filesystem code traditionally works at the kernel module level, where mistakes can wipe out lots of things and debugging is difficult. However, there is FUSE — the file system in user space library — that allows you to write more or less ordinary code and expose anything you want as a file system. You’ve probably seen FUSE used to mount, say, remote drives via ssh or Dropbox. We’ve even looked at FUSE before, even for Windows.

What’s missing, naturally, is the Hackaday RSS feed, mountable as a normal file. And that’s what we’re building today.

Writing a FUSE filesystem isn’t that hard, but there are a lot of tedious jobs. You essentially have to provide callbacks that FUSE uses to do things when the operating system asks for them. Open a file, read a file, list a directory, etc. The problem is that for some simple projects, you don’t care about half of these things, but you still have to provide them.

Luckily, there are libraries that can make it a lot easier. I’m going to show you a simple C++ program that can mount your favorite RSS feed (assuming your favorite one is Hackaday, of course) as a file system. Granted, that’s not amazing, but it is kind of neat to be able to grep through the front page stories from the command line or view the last few articles using Dolphin. Continue reading “Linux Fu: Fusing Hackaday”

Getting Root On Linux Amplifier Adds New Inputs

We remember when getting Linux on your average desktop computer was a tricky enough endeavor that only those with the most luxurious of graybeards would even attempt it. A “Linux box” in those heady days was more than likely an outdated machine salvaged from the dumpster, side panel forever removed, cranking away in a basement or garage. Fast forward today, and Linux is literally everywhere: from smartphones and luxury cars, to TVs and refrigerators. Ironically it’s still not on most desktop computers, but that’s a discussion for another time.

So when [Michael Nothhard] sent in the fascinating account of how he hacked his Linux-powered Bluesound Powernode N150 amplifier to unlock more inputs, the least surprising element was that there was a “smart amplifier” out there running the free and open source operating system. What piqued our interest was that he was able to bust his way in with relative ease and enable some impressive new capabilities that the manufacturer would probably have rather been kept under wraps.

Configuring the CM6206’s audio settings.

[Michael] explains that the N150 has a USB port on the back side of it, and that officially, it only works with mass storage devices and a handful of approved peripherals such as a Bluetooth dongle. But as he was hoping to connect some more devices to the input-limited amplifier, he wondered if he could get a USB audio adapter recognized by the OS. After using a known exploit to get root access, he started poking around at the underlying Linux system to see what kind of trickery the developers had done.

Based on a fairly common C-Media CM6206 chipset, the StarTech 7.1 USB audio adapter was picked up by the kernel without an issue. But to actually get it working with the amplifier’s stock software, he then needed to add a new <capture> entry to the system’s sovi_info.xml configuration file and make some changes to its default ALSA settings. With the appropriate files modified, the new USB audio input device popped up under the official Bluesound smartphone application.

At the end of the write-up [Michael] notes that you’ll need to jump through a few additional hoops to make sure that an upstream firmware update doesn’t wipe all your hard work. Luckily it sounds like backing up the configuration and returning it to the newly flashed Powernode is easy enough. We’ve certainly seen more elaborate methods of gaining control of one’s sound system over the years.

Linux Arcade Cab Gives Up Its Secrets Too Easily

Sometimes reverse engineering embedded systems can be a right old faff, with you needing to resort to all kinds of tricks such as power glitching in order to poke a tiny hole in the armour, giving you an way in. And, sometimes the door is just plain wide open. This detailed exploration of an off-the-shelf retro arcade machine, is definitely in that second camp, for an unknown reason. [Matthew Alt] of VoidStar Security, took a detailed look into how this unit works, which reads as a great introduction to how embedded Linux is constructed on these minimal systems.

Could this debug serial port be more obvious?

The hardware is the usual bartop cabinet, with dual controls and an LCD display, with just enough inside a metal enclosure to drive the show. Inside this, the main PCB has the expected minimal ARM-based application processor with its supporting circuit. The processor is the Rockchip RK3128, sporting a quad-core ARM Neon and a Mali400 GPU, but the main selling point is the excellent Linux support. You’ll likely see this chip or its relatives powering cheap Android TV boxes, and it’s the core of this nice looking ‘mini PC’ platform from firefly. Maybe something to consider seeing as though Raspberry Pis are currently so hard to come by?

Anyway, we digress a little, [Matthew] breaks it down for us in a very methodical way, first by identifying the main ICs and downloading the appropriate datasheets. Next he moves on to connectors, locating an internal non-user-facing USB micro port, which is definitely going to be of interest. Finally, the rather obvious un-populated 3-pin header is clearly identified as a serial port. This was captured using a Saleae clone, to verify it indeed was a UART interface and measure the baud rate. After doing that, he hooked it into a Raspberry Pi UART and by attaching the standard screen utility to the serial device, lo-and-behold, a boot log and a root prompt! This thing really is barn-door wide-open.

Is that a root prompt you have for me? Oh why yes it is!

Simply by plugging in a USB stick, the entire flash memory was copied over, partitions and all, giving a full backup in case subsequent hacking messed things up. Being based on U-Boot, it was a trivial matter of just keying in ‘Ctrl-C’ at boot time, and he was dropped straight into the U-Boot command line, and all configuration could be easily read out. By using U-Boot to low-level dump the SPI flash to an external USB device, via a RAM copy, he proved he could do the reverse and write the same image back to flash without breaking something, so it was now possible to reverse engineer the software, make changes and write it back. Automation of the process was done using Depthcharge on the Raspberry Pi, which was also good to read about. We will keep an eye on the blog for what he does with it next!

As we’ve covered earlier, embedded Linux really is everywhere, and once you’ve got hardware access and some software support, hacking in new tricks is not so hard either.