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”

WoWMIPS: A MIPS Emulator For Windows Applications

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).

Blinky Project Is 6502s All The Way Down

Virtually any platform you might find yourself programming on has some simple method of running a delay. [Joey Shepard] got rather creative on a recent project, though, relying on a rather silly nesting method that we’re calling 6502s All The Way Down.

The project in question was a simple PCB that was shaped like a robot, with blinking LED eyes. Typically, you’d simply reach for the usual sleep() or delay() function to control the blink rate, but [Joey] went off-piste for this one. Instead, the PIC32 on the board runs a 6502 emulator written in MIPS assembly. This emulated 6502 is then charged with running a further 6502 emulator coded in 6502 assembly, and so on, until there’s 6502 emulators running six-deep on the humble microcontroller. The innermost emulator runs a simple program that blinks the LED eyes in a simple loop. With the overhead of running six emulators, though, the eyes only blink at a rate of roughly once every two seconds.

It’s an amusing and complicated way to write a blink program, and we applaud [Joey] for going to all that trouble. We imagine it was a great way to learn about programming the PIC32 as well as emulation in general. Meanwhile, if you’re working on your own emulator feats, be sure to let us know!

IBM Made A MIPS Laptop. Will It Make You WinCE?

We’re used to our laptop computers here in 2022 being ultra-portable, super-powerful, and with impressively long battery lives. It’s easy to forget then that there was a time when from those three features the laptop user could usually expect only one of them in their device. Powerful laptops were the size of paving slabs and had battery lives measured in minutes, while anything small usually had disappointing performance or yet again a minuscule power budget.

In the late 1990s manufacturers saw a way out of this in Microsoft’s Windows CE, which would run on modest hardware without drinking power. Several devices made it to market, among them one from IBM which [OldVCR] has taken a look at. It makes for an interesting trip down one of those dead-end side roads in computing history.

In the box bought through an online auction is a tiny laptop that screams IBM, we’d identify it as a ThinkPad immediately if it wasn’t for that brand being absent. This is an IBM WorkPad, a baby sibling of the ThinkPad line intended as a companion device. This one has a reduced spec screen and an NEC MIPS processor, with Windows CE on a ROM SODIMM accessible through a cover on the underside. For us in 2022 MIPS processors based on the open-sourced MIPS ISA are found in low-end webcams and routers, but back then it was a real contender. The article goes into some detail on the various families of chips from that time, which is worth a read in itself.

We remember these laptops, and while the IBM one was unaffordable there was a COMPAQ competitor which did seem tempting for on-the-road work. They failed to make an impact due to being marketed as a high-end executive’s toy rather than a mass-market computer, and they were seen off as “real” laptops became more affordable. A second-hand HP Omnibook 800 did the ultra-portable job on this bench instead.

The industry had various attempts at cracking this market, most notably with the netbooks which appeared a few years after the WorkPad was produced. It was left to Google to reinvent the ultra-portable non-Intel laptop as an internet appliance with their Chromebooks before they would become a mass-market device, but the WorkPad remains a tantalizing glimpse of what might have been.

Windows CE occasionally makes an appearance here, and yes, it runs DOOM.

RISC-V: Why The ISA Battles Aren’t Over Yet

A computer processor uses a so-called Instruction Set Architecture to talk with the world outside of its own circuitry. This ISA consists of a number of instructions, which essentially define the functionality of that processor, which explains why so many ISAs still exist today. It’s hard to find that one ISA that works for as many distinct use cases as possible, after all.

A fairly new ISA is RISC-V, the first version of which was created back in 2010 at the University of California, Berkeley. Intended to be a fully open ISA, targeting both students (as a learning tool) and industrial users, it is claimed to incorporate a number of design choices that should make it more attractive for a number of applications.

In this article I’ll take a look behind the marketing to take stock of how exactly RISC-V differs from other open ISAs, including Power, SPARC and MIPS.

Continue reading “RISC-V: Why The ISA Battles Aren’t Over Yet”

Virtualizing Around The FCC’s Firmware Modification Rules

Last year, the FCC introduced new regulations requiring router manufacturers to implement software security to limit the power output in specific 5GHz bands. Government regulations follow the laws of unintended consequences, and the immediate fear surrounding this new directive from the FCC was that WiFi router manufacturers would make the easiest engineering decision. These fears came true early this year when it was revealed a large router manufacturer was not following the FCC regulations to the letter by limiting the output of the radio module itself, but instead locking down the entire router.

The FCC’s rules regarding the power output of 5GHz routers was never a serious concern; the FCC is, after all, directed to keep the spectrum clean, and can force manufacturers to limit the power output of the wireless devices. The problem comes from how manufacturers implement this regulation – the easiest solution to prevent users from modifying the output of the radio module will always be preventing users from modifying the entire router. Developers don’t like it, the smart users are horrified, and even the FCC is a little flustered with the unintended consequences of its regulation.

While the easiest solution to preventing the modification of a radio module is to prevent modification to the entire router, there is another way. The folks at Imagination Technologies have come up with a virtualization scheme that allows router manufacturers to lock down the radio module per the FCC directive while still allowing the use of Open Source router firmware like OpenWrt.

A demonstration of the capabilities of this next-generation router comes from the prpl Security Working Group and uses MIPS Warrior CPUs to create multiple trusted environments. The control of the router can be handled by one secure environment, while the rest of the router firmware – OpenWrt included – can be run in an environment more conducive to Open Source firmware.

The demo of a compartmentalized, virtualized router uses a dev kit consisting of a dual-core MIPS P5600 CPU running at 1GHz, and a Realtek RTL8192 WiFi adapter plugged into the USB port. The driver for the WiFi adapter runs under a secure hypervisor, making it secure enough to pass the FCC’s muster.

This build wouldn’t be possible without hardware virtualization in microprocessors and microcontrollers. Imagination Technologies has been working on this for a while, and only a few years ago demonstrated a PIC32 with baked in virtualization.

In the video below, Imagination Technologies demonstrates a MIPS board running three virtual machines. The first machine is running OpenWrt, the second is running a WiFi driver, and the third is running third-party applications. Crashing one machine doesn’t bring down the others, and the WiFi driver is locked away in a secure environment in accordance with the FCC regulations.

While it’s hard to imagine a router based on a MIPS board that would be cheaper than the already inexpensive router SoCs found in today’s routers, this method of secure virtualization is the best way to give consumers what they deserve: an open source option for all their devices.

Continue reading “Virtualizing Around The FCC’s Firmware Modification Rules”

Hardware Virtualization In Microcontrollers

Look at any sufficiently advanced CNC machine or robot, and you’ll notice something peculiar. On one hand, you have a computer running a true operating system for higher-level processing, be it vision or speech recognition, or just connecting to the Internet. On the other hand, you have another computer responsible only for semi-real-time tasks, like moving motors, servos, and reading sensors and switches. You won’t be doing the heavy-lifting tasks with a microcontroller, and the Raspberry Pi is proof enough that real-time functions aren’t meant for a chip running Linux. There are many builds that would be best served with two processors, but that may be changing soon.

Microchip recently announced an addition to the PIC32 family of microcontrollers that will support hardware virtualization. This addition comes thanks to the MIPS M5150 Warrior-M processor, the first microcontroller to support hardware visualization.

Continue reading “Hardware Virtualization In Microcontrollers”