From Chips to a Laptop

6 min

There's a certain thrill to board bringup, to be the first person in existence to have code running on a brand-new board. To even get your first "Hello, world!" requires a lot of components to be running correctly.

Computers are complicated beasts, but then again they have a great deal of functionality. The one I'm using has four cores that run at 1.2 GHz, high speed RAM that runs at 533 MHz, and a host of hardware peripherals that run at various other frequencies. Getting just one component to run reliably can be hard, and getting a whole machine full of them to run reliably can be a nightmare.

Initial Bringup

Initial board bringup requires a host system. In this case, we used a 64-bit Intel machine running Ubuntu. To simplify building, we used [Yocto]( to generate build system images, and to build the compiler. Yocto is a great system for building embedded platforms, as it allows you to decide exactly what goes into a build image. It also builds support components such as the bootloader, as well as the entire toolchain. It's a Gentoo-inspired wonder system that was great for early board bringup.

Before the board was even fully designed, we had a Sabre SD EVK (Evaluation Kit) to work with. The EVK uses the same CPU as Novena, and has many of the same peripherals. This would allow us to get at least part of the code working ahead of time, and allowed us to become more familiar with the CPU. It also let us work out how to build bootable SD cards, and work out how we'd lay out the disk image. In the end, we used our Ubuntu build system to build full disk images for the Sabre SD EVK, and ultimately prepped an image for when the first Novena hardware arrived.

When we finally got hardware, we burned the disk image to an SD card, inserted the card into the Novena board, connected the serial cable, and turned it on. What happened next almost never happens in the real world: It booted.

Okay, so it didn't boot straight to Linux and bring up a graphical user interface. But it booted to a U-Boot console prompt, which meant that a lot was working: The clocks were functioning right, voltages were correct, RAM was somehow working reliably despite being uncalibrated, the serial port worked, and the disk image was getting generated at the correct offset. More importantly, nothing was catching fire, glowing red-hot, or giving off smoke, all of which are concerns when plugging in hardware for the first time. That's a lot to get right on the first go.

That's not to say it was a hole-in-one. The bootloader was trying to load the kernel image from the wrong address, and was missing a bunch of drivers. It couldn't yet calibrate DDR3 memory, meaning only one or two SO-DIMM sticks worked. If we manually loaded the kernel we noticed it was missing a lot of drivers as well, and our only method of interacting with the system was via serial cable. Still, it's a start.

Tethered Builds

For the first few months, we continued to do tethered builds. We worked on the kernel, mostly improving support for our particular platform. We had to turn various knobs to get USB support working, for example. We had to write a driver for the audio chip, which isn't a common part. Because Novena wasn't stable enough to use day-to-day, and because it was missing large aspects of functionality, Novena never became the platform we used day-to-day, only the platform we built software for.

During this time, we continued to build root filesystem images using Yocto on an Ubuntu build system. We'd copy the resulting disk images onto SD cards for testing, but all software was compiled using Yocto. That meant that if we wanted to run a particular piece of software on Novena, we either had to build it from source in Yocto, or if it wasn't available we had to first write the recipe ourselves and /then/ build it from source in Yocto.

Because of this, we didn't have a whole lot of software available. We had the vim text editor, but Bunnie prefers Emacs, which is much harder to cross-compile. We had some graphical software, but it takes a very long time to build a web browser, and the versions in Yocto aren't always very recent.

It became clear to us that if we wanted to use Novena on a daily basis, we would need to get a more common distro onto Novena.

Going Native

Debian, it turns out, is remarkably easy to load onto a new platform, assuming you're already running Linux. The "debootstrap" command is a standard Bourne shell script that runs most anywhere, doesn't need any additional software beyond what's commonly found on most Unix systems. To install Debian, we didn't need to do much beyond format a new SSD, mount it on Linux, and point debootstrap at the mountpoint.

After rebooting, Novena was running Debian. We could install X11, emacs, a web browser, and a compiler. The available software packages made Novena much more useful to us, and was a turning point in what we used it for. With Debian, Novena went from a platform that we build software for, to a platform we build software /on/.

With a compiler installed, we could begin using Novena for its own projects. We started small with a simple program to manipulate the Novena personality EEPROM, and eventually got to the point where we ended up developing the entire factory test program on Novena itself. Once we began developing software on the hardware itself, it became the easiest path forward.

Completing the Transition

Since we have a complete Linux system, it makes sense to configure the board to build its own software. After installing a toolchain and copying the kernel source over, we found that with all four cores running, a kernel takes about 40 minutes to compile from scratch. That's a long time, but fortunately, the kernel rarely needs to be compiled from scratch. Testing a change takes just a few minutes, which is not bad at all. We haven't built a kernel on the Ubuntu system in six months. All kernel development today is done on Novena itself.

Now that we have video output working, we routinely run with two displays. It really makes the system feel like a real laptop. We build kernels, add features, run presentations, and debug new hardware all on Novenas we built ourselves. It's a bit of a funny tool we've built, but it's the perfect hammer. And now everything is starting to look like a nail.