Thank you to our supporters! Here's what we'll work on:
Thank you to each and every one of our supporters. I'm honoured by all of the positive talk about the project. Now that the campaign is over and funded, it's time to get started. Or rather, continue our work.
If you've seen either bunnie or myself at conferences, you'll have seen us with our own Novenas. Late last year these were in suede clamshells, but lately we've been sporting the SLA-printed aluminium-bezeled prototypes that we'll eventually ship. Given that we've already been using them, what could possibly be left to do? From the software side, a lot. Not including the graphics work being taken on by Jon Nettleton.
The board itself is stable, which is good. We're already on the third revision, which should be identical to production. We're getting more and more familiar with the i.MX6 family, which means we're sussing out all the little weirdnesses and pitfalls you'd normally expect with a complex project such as a System-on-a-Chip. It also works with a wide variety of hardware, and boots up reasonably quick.
There are lots of little problems we need to fix. For example, when you first boot the board, it thinks it's 1970. There is a supercap-backed realtime clock, but the RTC drains the capacitor in just a few seconds. Fortunately, if a machine is online, it can grab the time. Also, we included a provision to switch to a battery-backed RTC. We'll have to either find the source of the current drain, or switch to the battery-backed RTC.
Along those lines, the battery charger needs a lot of love. Right now, it's capable of charging a battery and then cutting power when it drains too much. What more could you need, right? Well, it turns out there's a lot more. The gas gauge is SBS-complient, and sits on an I2C bus visible to the CPU, and we have battery percentages reported directly by Linux. But it doesn't know if the charger is plugged in. Also, the battery board has provisions for acting as a second RTC, and neither the ChibiOS nor the Linux driver has been written for that. Finally, the current and voltage rating for the power supply is, right now, hardcoded. That'll have to change.
There is a unique audio codec present on Novena. The ES8328 is a nice little audio codec that is powerful, cheap, and totally unsupported by Linux. Right now we have a driver that we use that supports headphone detect, but it hardcodes the audio paths and doesn't do dynamic audio power management (DAPM). In order to get the driver submitted upstream, we'll have to completely rework the driver, and add UCM support to identify which codec ports map to either speakers or headphones.
There's also the boot process, which currently uses an outdated version of U-Boot. It would be really nice to get a two-stage bootloader going, where we use a small Secondary Program Loader to configure the RAM, before either jumping directly to Linux or loading a secondary bootloader. The boot process we use now is very inflexible, and it would be nice to, at the very least, be able to put a logo on the screen.
Power management, suspend-to-disk, and better PCI Express support are all also on the list of things to do.
Finally, there's the board itself. Linux supports something called Device Tree, which is a small (30 kB) description of all the hardware in a particular platform. We have a device tree source file we use for Novena, but it contians special hardware that we have yet to upstream. Before we ship, it would be really really nice if users could go directly to Linus and compile his kernel tree for use on their Novena. We're fortunate in that our kernel is reasonably close to mainline, so this shouldn't be too painful.
All this is in addition to manufacturing, parts sourcing, a factory test program, and shipping, all of which we aim to do in the next nine months. Thank you again to all our supporters, and we look forward to sharing the journey with all of you.