Novena: A Laptop With No Secrets

How we built a laptop with nothing but open-sourced hardware and software

Advertisement

Has the computer become a black box, even to experienced electrical engineers?

Will we be forever reliant upon large, opaque organizations to build them for us? Absolutely not, we say. And to prove our point, we built our very own laptop, from the circuit boards on up.

Admittedly, we did not delude ourselves that we could build a laptop that would be faster, smaller, or cheaper than those of Apple, Dell, or HP. However, we did set out to build a machine powerful and convenient enough to use every day. Fortunately, our dream inspired enough people to crowdfund the effort. Our laptop, which we call Novena, started shipping to backers in January 2015.

Events favored our quest. Because Moore’s Law is slowing down, garage innovators can take a couple of years to develop a high-tech gadget without discovering that the completed version is obsolete. It has been three years since we started the Novena project and yet the 40-nanometer process on which our central microprocessor is based continues to occupy a sweet spot between cost and performance.

Also, the economic malaise of 2008 left a lasting mark on global supply chains. Even today, manufacturers are no longer too busy printing money to make the time for producing small, boutique projects like ours; instead, they see us as an opportunity to gain an edge over their competition. Owners of small factories in China turned out to be eager to learn our agile approach to engineering, so they, too, could take on the challenge of low-volume production and address the growing market of hardware startups.

We started by considering the constraints of the most complex and brittle pieces of any such system: the software. We wanted to build a complete computer, one with a long-term-support road map, and we had neither the resources nor the manpower to negotiate with vendors of proprietary hardware and software. We wanted to be able to inspect and understand as much of the system and its components as we could, so if we came across bugs or other anomalous behavior, we could rely on our wits to figure it out, rather than on the profit-motivated (and often empty) promises of a vendor‘s sales team. As a result, we decided to produce a laptop that was as free as possible of closed-source embedded firmware.

Firmware is basically software (such as drivers, kernels, and bootloaders), installed at the factory, that runs on “bare iron”—the computer itself, not its operating system. It’s found not only on the main CPU in your laptop but also on about a dozen embedded controllers—small, special-purpose processors that take care of such things as managing the battery, keeping your hard disk free of errors, and maintaining your Wi-Fi connection. Each of these processors runs a bit of firmware; sometimes the firmware can be updated or modified, typically for the purpose of fixing bugs or adding features. But such updates can also introduce bugs or security flaws, and if you haven’t got the ability to inspect the firmware, then you, the user, must depend utterly on the vendor to take care of security.

This open-source requirement of ours ended up influencing the selection of almost every piece of hardware, including the main CPU, the battery controller, and the Wi-Fi module. For example, we couldn’t use Intel’s x86 microprocessors because they can accept firmware updates that we cannot debug or inspect. Instead we chose an ARM-based Freescale i.MX6 system-on-a-chip, which has no such updatable code embedded. (A system-on-a-chip, or SoC, is similar to a microprocessor except it has more of the supporting hardware, such as memory and peripheral interfaces, needed to make a complete computer.) The i.MX6 does have some code burned into it to coordinate the computer’s boot-up process, but this firmware can’t be changed, and its unencrypted binary code can be read out and analyzed for possible security problems.

Another advantage was Freescale’s policy of distributing a very detailed reference manual covering most of the chip’s real estate without requiring a nondisclosure agreement. That’s important because such an agreement would have gotten in the way of the community involvement that our strategy for long-term support required.

Our next choice had social repercussions. When you adopt a CPU/operating-system combination, you also adopt its developers. We decided against Google Android because it’s optimized for phones and tablets, its graphical display typically shows only one application at a time, and its touch-screen paradigm is too imprecise for computer-aided design work. Therefore, in order to create a system that our target market of developers and creators could use, we decided to run on our ARM chip a version of Linux called GNU/Linux. GNU, which authored both the OS libraries and the license that the Linux kernel uses, is a coder’s organization, right down to the self-referential acronym itself (it stands for “Gnu’s Not Unix”).

Unfortunately, most Linux versions for ARM were not designed for personal computing but rather for routers and the set-top boxes that convert signals for viewing on televisions. Manufacturers that use Linux generally build their own, highly customized system around what’s called the Linux kernel—the core framework of the OS. That way, they ensure that their customers, who integrate the software into a larger system, never see so much as a Linux command prompt. Examples include TiVo and airline in-flight–entertainment systems. On top of that, vendors use an old “snapshot” of Linux—that is, they copy whichever kernel is around at the time of chip release. Then they add a lot of patches to it to create a board support package (BSP) for their product, which is a kind of “quick start” kit for hardware developers who don’t want to muck around too much with Linux kernel minutiae.

Frequently these BSPs contain proprietary bits that developers can’t copy, that don’t take advantage of features that came with the original kernel, and don’t even follow the standard formatting procedures for Linux code. These undisciplined shortcuts may speed a product to market, but they make the kernel impossible to maintain, update, or improve. As a result, most systems that are based on Linux run kernels that are years out of date. This is not a plan for long-term customer support.

Therefore, we adopted the latest kernel available. We patched and extended Freescale’s open-source BSP code to comply with Linux community standards, then submitted our changes to the managers of the Linux community at large. They reviewed our code and provided feedback over several months of iterations.

At that point, our code was finally ready to be “upstreamed” into mainline Linux. It’s a time-consuming and laborious process, but when it’s over the Linux community can adopt our version and maintain it. The main advantage of this upstreaming process is that features that come with future Linux kernels can be unlocked by simply downloading the latest version of the operating system and compiling it, without having to repeat the code-review process.

Hardware-accelerated graphics proved to be another challenge. Most modern desktop computers assign each application or graphical widget an off-screen memory buffer to render their output on the screen. Only then does the graphics processing unit (GPU) “composite” the various outputs to make the seamless image seen on the screen.

This two-step process decouples the application’s drawing rate from the screen’s refresh rate, preventing a “race condition,” in which two input signals compete to be the first to affect the output. Such racing can produce artifacts such as “tearing,” in which the attempt to drag a window ends up moving only the top part by the time the screen refreshes. The newly redrawn half of the window closest to the cursor thus looks torn off from the lower half. Also, the two-step decoupling process can be used to create subtle cues, such as transparency and blur, where foreground windows and title bars can take on the character of frosted glass, providing a hint of what content might lie underneath them.

Unfortunately, the integrated GPU on the Freescale i.MX6 chip is closed source. Remember how we said that the vendor-supplied BSPs are typically snapshots of older kernels? The code that Freescale provided for drivers—that’s the software that controls various peripheral devices, like printers and GPUs—is compatible only with an out-of-date version of Linux. And this driver has an unfortunate quirk: It requires any application that talks to it to do all floating-point calculations in software! That’s far slower than doing the calculations in hardware.

This example nicely illustrates why closed-source products can be so frustrating. If we’d used this closed-source driver, we would have locked ourselves into an outdated version of Linux and forced other applications to do floating-point calculations in software. But if we’d gone open source to exploit all the features and benefits of the latest Linux version and to allow floating-point calculations done in hardware, users would have had to reverse-engineer the GPU to create compatible open-source drivers.

We decided to stick to our guns and reject the closed-source GPU altogether, which meant we would have to render graphics in software.

Unlike Windows and Mac OS, Linux gives you a choice of how your computer appears to the user. This appearance is governed by a software utility called a desktop window manager. You can select this appearance by picking a particular “distribution” of Linux and coupling it with a particular window manager. We couldn’t use the popular Ubuntu and RedHat distributions because they basically require GPU hardware acceleration, which we had rejected. Instead, we used a slightly older-looking but more open-source-friendly distribution called Debian. We coupled it with a desktop window manager option called Xfce4, which is explicitly designed to run well on systems without GPUs and thus is particularly good at software rendering.

But that arrangement, we hope, is merely a stopgap. The user community behind Novena is trying to create, through reverse engineering, open-source drivers that would allow the built-in GPU on the i.MX6 chip to render graphics directly. At the moment, we have drivers that can accelerate the drawing of 2-D figures on the screen, which makes scrolling and window dragging much smoother. We hope eventually to figure out enough of the GPU to let us do 3-D graphics with acceleration sufficient to produce a user experience much like that of any mainstream laptop.

As the software evolved, the hardware evolved with it. The most extraordinary step we took was to include a field-programmable gate array (FPGA), a type of processor chip that can be reconfigured by its user to change the chip’s specs and capabilities. Basically, this reconfigurability allows the chip to do things in hardware that would otherwise have to be done in software.

For instance, if you wanted to accurately control a dozen motors, you’d have a lot of trouble doing that in software. Motion control requires exquisite real-time control over waveforms, and if you try to get your operating system to do that it would constantly be shifting from one task to another and back again, adding too much timing jitter. Imagine that stutter you see in your Web browser but in a self-driving car or a drone: instant wreck. However, it’s a relatively simple matter to create hardware that runs the fussy timing and key control loops, and it’s also trivial to replicate variations of that hardware again and again in an FPGA.

And at one point, we did in fact want to control a lot of motors. We had the wacky notion of mounting Novena in a quadcopter chassis so that our laptop could hover and follow us around the office; we figured we’d use the FPGA to interface with the requisite motors and sensors. Consequently, the FPGA’s input-output connectors were originally targeted toward servos and motors.

Cooler heads eventually prevailed. We instead optimized the FPGA for data acquisition by adding a bank of local high-speed DDR3 RAM chips, a form of high-speed dynamic access memory. This upgrade allowed developers to implement a variety of expansion cards, including one for software-defined radio and another that worked as a digital sampler, which could allow engineers to use our laptop as a portable oscilloscope.

Because we developed the project on a shoestring budget and with no solid requirement other than to build the laptop we ourselves would want to use, the laptop evolved organically. Instead of designing circuits into the motherboard specific to a particular battery or LCD—typical for most consumer laptops—we modularized the system. We linked subsystems using generic connectors with pin-outs that were merely educated guesses as to what users would end up hooking onto those pins.

As a result, the final incarnation of the laptop includes specialized adapter boards for the battery pack, LCD, and front-bezel arrangement (the frame for the display). The good thing about this modularity is that users can adapt the system to meet their own needs. We’re delighted to have received reports of users changing out LCDs and building custom battery packs. And users can add the keyboard of their choice. We don’t include one.

Aside from the inclusion of an FPGA, our hardware decisions were fairly lackluster, even when compared with what comes in a low-end Intel laptop. Our i.MX6 SoC contains a quad-core ARM CortexA9 running at 1.2 gigahertz—a 32-bit processor, which means the system is limited to 4 gigabytes of RAM. We did, however, choose a fairly decent 1920-by-1080 display, which is the spec limit for the i.MX6 chip. Our battery life is acceptable, at a bit over 6 hours.

We included a few extra features just for the fun of it. We built in an accelerometer, although we really don’t know what we’re going to do with it. Accelerometers are cheap, and there are a lot of fun things you can do with your computer when it’s aware of being tilted, hit, or dropped. For instance, you could make your laptop play a sound clip of “Goodbye, Cruel World!” when it detects that it is in free fall.

Most laptops have one Ethernet port at the most, which means that they can act only as endpoints in a network. But we gave Novena two ports to let it sit between nodes, filtering and monitoring traffic for security purposes. The ports also allow our laptop to function as a Wi-Fi router and as an Internet firewall for other wired devices—a handy feature when on the road. And although 20 hertz is considered the low end of human hearing, one of us (Huang) has a broader hearing range, so we took the unusual measure of extending the analog frequency response of the headphone jack to below 20 Hz.

These little features are never included on a consumer laptop. But it’s these customizations that make the project fun and unique. They add cost—but it’s our cost overrun! The fully loaded laptop sold for US $2,000 during the crowd campaign. So far, we’ve sold about 500.

Initially, we didn’t plan on going as far as building a mass-producible case. In fact, we made our first case by hand out of leather, bound like a book. The warm reception it got on social media led us to attempt a crowdfunding campaign via Crowd Supply, a site that takes the idea of Kickstarter and turbocharges it with a Web store and logistics services.

One thing we learned in that brush with the mainstream consumer was that most people were not prepared for the experience we were delivering. Our laptop won’t run Windows or Mac OS, nor is it particularly fast or thin. So in order to differentiate our laptop and make it more attractive to true techies, we decided to add some of the things that developers prize. These included mounting bosses—an internal array of metal nuts—which we call the Peek Array (after Nadya Peek, of FabLab fame).

Typical laptops are unhackable because there’s no place to put other...stuff. If you can find the empty space in a laptop, you’d have to glue your expansion board in place or drill a hole through the case to mount your custom hardware. Not so with the Peek Array! Its dozens of threaded nuts allow users to screw all manner of small project boards into the laptop case. Want to add a pulse oximeter to Novena so you can measure the level of oxygen in the blood running through the capillaries of your finger? Or maybe a barometer so you can monitor your airliner’s cabin pressure? With just a few screws you can mount your customization inside Novena’s laptop case.

We also designed the case to open easily under the impetus of an air spring, like the ones used to raise the seat on ergonomic office chairs. With the flick of a switch, the lid (with the screen) opens automatically. We preferred this to a conventional clamshell design on the theory that any laptop that exposes its guts to the user will particularly appeal to users prepared to hack the guts. (People who fear naked circuit boards shouldn’t buy our laptop anyway!)

The case is designed to serve through generations of electronics hardware. For instance, to hold the liquid-crystal display in place we used computer numerically controlled (CNC) machining to make an aluminum bezel. Anyone with access to an entry-level machine shop can fabricate a custom bezel to accommodate a different LCD, as well as mount additional sensors (such as a camera or a microphone) or additional buttons and knobs.

By putting most of the ports on a single edge, which we call the Port Farm, we made it easy to replace the panel covering it. That way the user can keep the case itself even as the motherboard and the Port Farm evolve.

We took into account the total costs of manufacturing tooling as well. For instance, though injection-molded plastic is very cheap on a per-unit basis, the steel tools that produce it are not. You need an oil-cooled block weighing about a ton, capable of handling pressures found at the bottom of the Mariana Trench, machined internally to a tolerance less than the width of a human hair, with a moving clockwork of dozens of ejector pins, sliders, lifters, and parting surfaces separating and coming back together again smoothly over thousands of cycles. It can easily cost $250,000, which is why the injection molding process can pay for itself only in very large manufacturing runs. We instead used a combination of CNC aluminum, optimized plastic design, and family molds (whose various parts each form a different aspect of a given product). We needed just 10 machine tools to produce the case, for an up-front investment of about $50,000.

As we write this, we’ve shipped all of our standard laptop and desktop units to our crowdfunding campaign backers. We’ve marshaled nearly a thousand components from dozens of vendors, from Shenzhen, China, to Fremont, Calif.

Thanks to the magic of crowdfunding and a slowdown of Moore’s Law, a two-person team was able to have the funds and the time to implement an everyday-use laptop. Furthermore, this laptop’s schematics, circuit board layouts, mechanical design files, kernel, drivers, and application programs are all open source and available for anyone to download.

Such transparency is unprecedented. We hope it will encourage other engineers to follow in our footsteps and help users reclaim their technological independence.

This article originally appeared in print as “A Laptop With No Secrets.”

About the Author

Andrew Huang and Sean Cross are self-employed American computer scientists living in Singapore. Huang wrote on the death of Moore's Law for our April issue. 

Advertisement