Linux, Now In Real Time

Although Linux runs almost every supercomputer, most of the web, the majority of smart phones, and a few writers’ ancient Macbooks, there’s one major weak point in the Linux world that will almost always have developers reaching for a different operating system. Linux is not a real-time operating system (RTOS), meaning that it can’t respond to requests in the real world within a set timeframe. This means that applications needing computer control in industry, medicine, robotics, and other real-world situations generally need a purpose-built RTOS. At least, that was true until recently when an update to the Linux kernel added real-time capabilities.

The feature, called PREEMPT_RT, forces the Linux kernel to respond to certain request within a set limit of time. This means that a system with this support built into the kernel can “preempt” any current task, stopping everything else a computer is doing in order to execute that task right away. There are some existing solutions to getting a functional equivalent system working with Linux now, but they can be clunky or inelegant, requiring the user to install patches or other software to get it to work. With the support built directly into the kernel this will become much less of a pain point for anyone who needs this functionality going forward.

This feature has been in the works for around two decades now, so with this entering general use now we would expect to start seeing it show up in various projects as well as in commercial offerings soon, especially since other RTOS solutions can be pricey. Don’t recompile the kernel in your desktop for this feature just yet, though; real-time function can cause some unintended consequences with normal use you’ll need to account for. There’s some more discussion on this in the /r/Linux subreddit and there are some other real-time operating systems available for computers not typically capable of running Linux to take a look at as well.

There’s No Lower Spec Linux Machine Than This One

It’s not uncommon for a new distro version to come out, and a grudging admission that maybe a faster laptop is on the cards. Perhaps after seeing this project though, you’ll never again complain about that two-generations-ago 64-bit multi-core behemoth, because [Dimitri Grinberg] — who else! — has succeeded in booting an up-to-date Linux on the real most basic of processors. We’re not talking about 386s, ATmegas, or 6502s, instead he’s gone right back to the beginning. The Intel 4004 was the first commercially available microprocessor back in 1971, and now it can run Linux.

So, given the 4004’s very limited architecture and 4-bit bus, how can it perform this impossible feat? As you might expect, the kernel isn’t being compiled to run natively on such ancient hardware. Instead he’s achieved the equally impossible-sounding task of writing a MIPS emulator for the venerable silicon, and paring back the emulated hardware to the extent that it remains capable given the limitations of the 1970s support chips in interfacing to the more recent parts such as RAM for the MIPS, an SD card, and a VFD display. The result is shown in the video below the break, and even though it’s sped up it’s clear that this is not a quick machine by any means.

We’d recommend the article as a good read even if you’ll never put Linux on a 4004, because of its detailed description of the architecture. Meanwhile we’ve had a few 4004 stories over the years, and this one’s not even the first time we’ve seen it emulate something else.

Continue reading “There’s No Lower Spec Linux Machine Than This One”

From High Level Language To Assembly

If you cut your teeth on Z-80 assembly and have dabbled in other assembly languages, you might not find much mystery in creating programs using the next best thing to machine code. However, if you have only used high level languages, assembly can be somewhat daunting. [Shikaan] has an introductory article aimed to get you started at the “hello world” level of x86-64 assembly language. The second part is already up, too, and covers control structures.

You can argue that you may not need to know assembly language these days, and we’ll admit it’s certainly not as important as it used to be. However, there are unusual cases where you really need either the performance or the small footprint, which is only possible in assembly language. What’s more, it is super useful to be able to read assembly from your high-level tools when something goes wrong.

Of course, one of the problems is that each assembly language is different. For example, knowing that the x86 assembly doesn’t completely transfer to ARM instructions. However, in most cases, the general concepts apply, and it is usually fairly easy to learn your second, third, or fourth instruction set.

We’ve had our own tutorials on this topic. You can also debate if you should learn assembly first or wait, although in this case, the audience is people who waited.

A Clean Linux Installation For An Android TV Box

Although Android technically runs on top of Linux, generally most Android devices abstract away the underlying Linux-ness of these machines. In theory this is a good thing; we wouldn’t necessarily want to live in a world where we have to log in to a command-line interface just to make a phone call. But too much abstraction often needlessly restricts the capabilities of the underlying hardware. [Murray] a.k.a [Green Bug-Eyed Monster] has an Android TV box with just such a problem, as the Android OS included with it allows for watching TV just fine, but with a few tweaks it can run a full Linux installation instead, turning it into a much more versatile machine.

This specific Android TV box is based on the Rockchip 3566, a popular single-board computer used in a wide array of products. As such it is one of the easier targets for transforming a limited TV machine into a fully capable desktop computer. The first step is to compile an Armbian image for the machine, in this case using an x86 installation of Ubuntu to cross-compile for the ARM-based machine. With a viable image in hand, there’s an option to either solder on a microSD slot to the included pins on the computer’s PCB or to flash the image directly to the on-board eMMC storage by tricking the machine into thinking that the eMMC is missing. Either option will bring you into a full-fledged Linux environment, with just a few configuration steps to take to get it running like any other computer.

[Murray] began this process as an alternative to paying the inflated prices of Raspberry Pis over the past few years, and for anyone in a similar predicament any computer with the Rockchip 3566 processor in it could be a potential target for a project like this. You might need to make a few tweaks to the compile options and hardware, but overall the process should be similar. And if you don’t have an RK3566, don’t fret too much. We’ve seen plenty of other Android TV boxes turned into similar devices like this one which runs RetroPie instead.

At Last, Chumby Is Ready

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.

Linux Handheld Packs Dual Batteries So It’s Never Out Of Juice

There was a time — not so long ago — when a handheld terminal would have been an expensive and exotic piece of kit. Now, all it takes is a Raspberry Pi and an off-the-shelf TFT display, as [ZitaoTech] shows us.

The resemblance to a Blackberry isn’t a coincidence

Admittedly, we are now seeing these all over the place, but this build looks well thought out. It looks suspiciously like a Blackberry, which isn’t a bad thing. It also has an interesting dual-battery system that lets you swap between two identical Nokia BL-5C batteries without missing a beat.

The device looks like a Blackberry because it uses the Q10 or Q20 Blackberry keyboard. There is a pass-through switch that lets you use the keyboard and pointer as a USB device on a different host computer.

Rounding out the design are three USB ports, an I2C port, and a TF card slot. Size-wise, the device is about 140 mm tall and 82 mm wide. The thickness is less than 16 mm. Even with the batteries, it weighs a lot less than 200 grams.

In the “Something-you-can-try” directory, there are images for Windows 3.1, mini VMAC, and — of course — DOOM. As you might expect, most of the project is 3D printing the intricate case.

We’ve seen similar projects, including one that has a case inspired by the ZX Spectrum. Then there is Beepy.

LightBurn Turns Back The Clock, Bails On Linux Users

Angry Birds, flash mobs, Russell Brand, fidget spinners. All of these were virtually unavoidable in the previous decade, and yet, like so many popular trends, have now largely faded into obscurity. But in a recent announcement, the developers of LightBurn have brought back a relic of the past that we thought was all but buried along with Harambe — popular software not supporting Linux.

But this isn’t a case of the developers not wanting to bring their software to Linux. LightBurn, the defacto tool for controlling hobbyist laser cutters and engravers, was already multi-platform. Looking forward, however, the developers claim that too much of their time is spent supporting and packaging the software for Linux relative to the size of the user base. In an announcement email sent out to users, they reached even deeper into the mid-2000s bag of excuses, and cited the number of Linux distributions as a further challenge:

The segmentation of Linux distributions complicates these burdens further — we’ve had to provide three separate packages for the versions of Linux we officially support, and still encounter frequent compatibility issues on those distributions (or closely related distributions), to say nothing of the many distributions we have been asked to support.

We’re not sure how much of their time could possibly be taken up by responding to requests for supporting additional distributions (especially when the answer is no), but apparently, it was enough that they finally had to put their foot down — the upcoming 1.7.00 release of LightBurn will be the last to run on Linux.

Continue reading “LightBurn Turns Back The Clock, Bails On Linux Users”