In a recent post, I mentioned that I wanted to build some tools for a stripped-down Linux running on a 3D printer with a MIPS CPU. I had two options: build a toolchain to cross-compile, or use Zig, which, in theory, has built-in toolchains for MIPS. I had to jump through hoops to get Zig to work, and I did mention Crosstool-Ng, so you might wonder why I didn’t start there. Turns out, it had its own set of hoops to work through.
Continue reading “Compile Here, Run Everywhere: Crosstool-Ng”
Having Linux on so many devices is both a blessing and a curse. Sure, it is great that you can hack on things and modify them or even totally repurpose them. But it also means you have a fleet of Linux devices you have to manage and keep track of.
My current “main” 3D printer is a Flashforge AD5X: a nice, cheap machine that does four colors with the purge/exchange method. It sort of runs Klipper. I say sort of because Flashforge has Klipper running on a Linux host in the box, but it is massively crippled and modified. I’m sure it works for most folks. I’m also sure that if you know nothing about Linux, Klipper, or 3D printing, the experience is probably better thanks to all the cloud point-and-click interfaces. But, of course, I check none of those boxes.
I’ve had the printer for probably a year or more. Almost immediately, I put a “mod” on the printer to give it a more true Klipper interface and gave me things like shell access. There are several that I think will do this, but I used Zmod, which doesn’t totally replace the printer’s firmware; it just sort of patches it and extends it. You can easily bypass or even remove it and go back to the stock printer, although I would not want to.
In my case, the issue was a printer, but the same idea might apply to any embedded Linux system, from a router to a thermostat. Sure, it runs Linux, but is it Linux you can change?
The Flashforge firmware and Zmod both will run on the AD5X’s little sister, the AD5M. However, the AD5M has a significantly less capable processor board than the AD5X. That means that Linux on the boxes is very stripped down. From Flashforge’s point of view, no one should be in the Linux OS anyway, and the author of Zmod probably figures every byte used is a byte taken away from the user or other advanced Zmod features.
It may seem like a first-world problem, but there were two things that irked me about the printer’s Linux. There was no less or more command for poking around files. There was also only vi as an editor. I did a few hacks to make myself happy. I wrote a pager in shell script, for example. I would try to remember to use my desktop emacs and tramp to edit files on the box. But it was a shame that there were some very basic tools lacking. Besides that, even the tools that were there like ls lacked help commands in case you want some strange option you can’t remember.
To save space, the printer doesn’t really have programs like ls, cat, and grep. Instead, it has a single busybox executable. This is common on small systems. You get one copy of the libraries and a single executable that will do all the work you need. You can invoke, for example, grep by running “busybox grep” or, if you make a symlink to busybox named grep, the user may never realize that you don’t really have grep installed.
However, busybox has to be built. You can’t easily install packages to it. So I couldn’t just run some package manager and install less or anything else. My plan was to produce a new busybox package myself to supply at least the missing commands and maybe some of the more basic ones, too. How hard could it be?
Continue reading “Putting Some Zig In A Linux-Based 3D Printer”
Although Windows CE doesn’t use the NT kernel, it’s similarly designed to run on a wide variety of system architectures. Since the Nintendo 64 uses a MIPS CPU it should basically just run either kernel. You might assume that the N64’s rather limited specs are a bit of a problem, but fortunately Windows CE is designed to run on a digital potato, and requires only a MB of RAM. Since that just so happens to be what the N64 has under the hood, [Throaty Mumbo] was optimistic about getting Windows CE running on the 1990s game console.
The idea for this project came when [Throaty] was tinkering with an IBM Workpad Z50 laptop that uses almost the same CPU as the N64 and also runs Windows CE. Although said laptop is probably a lot more practical of a platform to run Windows on, this didn’t mean that it wouldn’t be a fun challenge.
Since CE was intended to be customized by companies for their own embedded hardware this means that you can use an official SDK, such as Microsoft Windows CE 2.11 Platform Builder. Making Windows CE 2.11 run on an N64 thus involves creating a board-specific configuration and compile that against said SDK.
If you want to give it a shot yourself, the entire project is available on GitHub which is where you find most of the technical details as well. When using a flash cart such as the EverDrive, you can also put applications on the SD card and run them from within the Windows GUI. You’ll still be limited by the N64 hardware, but otherwise the experience is very smooth as the video below demonstrates.
The SGI O2 was SGI’s last-ditch attempt at a low-end MIPS-based workstation back in 1996, and correspondingly didn’t use the hottest parts of the time, nor did it offer much of an upgrade path. None of which is a concern to hobbyists who are more than happy to work around any hardware- and software limitations to e.g. install much faster CPUs. While quite a few CPU upgrades were possible with just some BGA chip reworking skills, installing the 900 MHz RM7900 would require some PROM hacking, which [mattst88] recently took a shake at.
The initial work on upgrading SGI O2 systems was done in the early 2000s, with [Joe Page] and [Ian Mapleson] running into the issue that these higher frequency MIPS CPUs required a custom IP32 PROM image, for which they figured that they’d need either SGI’s help or do some tricky reverse-engineering. Since SGI is no longer around, [mattst88] decided to take up the torch.
After downloading a 512 kB binary dump of the last version of the O2’s PROM, he set to work reverse-engineering it, starting by dissembling the file. A big part of understanding MIPS PROM code is understanding how the MIPS architecture works, including its boot process, so much of what followed was a crash-course on the subject.
With that knowledge it was much easier to properly direct the Capstone disassembler and begin the arduous process of making sense of the blob of data and code. The resulting source files now reassemble into bit-identical ROM files, which makes it likely that modifying it to support different CPUs is now possible with just a bit more work.
For those who want to play along, [mattst88] has made his ip32prom-decompiler project available on GitHub.
Thanks to [adistuder] for the tip.
Top image: Silicon Graphics 1600SW LCD display and O2 workstation. (Source: Wikimedia)
An Instruction Set Architecture (ISA) defines the software interface through which for example a central processor unit (CPU) is controlled. Unlike early computer systems which didn’t define a standard ISA as such, over time the compatibility and portability benefits of having a standard ISA became obvious. But of course the best part about standards is that there are so many of them, and thus every CPU manufacturer came up with their own.
Throughout the 1980s and 1990s, the number of mainstream ISAs dropped sharply as the computer industry coalesced around a few major ones in each type of application. Intel’s x86 won out on desktop and smaller servers while ARM proclaimed victory in low-power and portable devices, and for Big Iron you always had IBM’s Power ISA. Since we last covered the ISA Wars in 2019, quite a lot of things have changed, including Apple shifting its desktop systems to ARM from x86 with Apple Silicon and finally MIPS experiencing an afterlife in the form of LoongArch.
Meanwhile, six years after the aforementioned ISA Wars article in which newcomer RISC-V was covered, this ISA seems to have not made the splash some had expected. This raises questions about what we can expect from RISC-V and other ISAs in the future, as well as how relevant having different ISAs is when it comes to aspects like CPU performance and their microarchitecture.
Continue reading “Checking In On The ISA Wars And Its Impact On CPU Architectures”
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”
When Windows NT originally launched it had ports to a wide variety of platforms, ranging from Intel’s x86 and i860 to DEC’s Alpha as well as the MIPS architecture. Running Windows applications written for many of these platforms is a bit tricky these days, which [x86matthew] saw as a good reason to write a MIPS emulator. This isn’t just any old emulator, though. It maps 32-bit Windows applications targeted at the MIPS R4000 CPU to an x86 CPU instead. Since both platforms run in a little-endian, 32-bit mode, this theoretically should be a walk in the park.
The use of the Windows PE executable format is also the same, so the first task was to figure out how to load the MIPS PE binary in a way that made sense for an x86 platform. This involved some reverse-engineering of the MIPS ntdll.dll file to figure out how relocations on that platform were handled. Following this, the mapping of the instructions of the R4000 CPU to the (CISC) x86 ISA was pretty easy. Only Floating Point Unit (FPU) support was left as a future challenge. Memory access was left as direct access, meaning no sandboxing or isolation, for simplicity’s sake.
The final task was mapping the native API calls, which call almost directly into the underlying host Windows OS’s API, with a bit of glue logic. With all of this done, Windows NT applications originally written for 1990s MIPS ran just fine on a modern-day x86_64 PC running Windows — as long as you don’t need an FPU (for now).
