NAVI

I was looking for good docs on E-Ink displays and found articles like Essential Scrap's tutorial for repurposing old e-reader displays, Sprite_TM's webpage-viewing low-power display, and the badgy project here on hackaday.io (coincidentally, the last two are both ESP8266-driven WiFi E-ink display projects). While I considered the ED060SC4 (preferably H2) mentioned in the Essential Scrap article, I wasn't looking forward to designing (or borrowing from an open-source hardware project) a driver with all of those weird voltages and the shift registers for setting pixels.

Upon further perusal I found a mention of Good Display in the comments of the badgy project. I looked on their website (or an affiliated reseller? It's a little confusing because half of it is in Chinese and the other half requires Javascript) and found a 7.5 inch BWR E-ink display (also on Aliexpress). As soon as I knew it was possible to have multiple colors I knew this was a feature the laptop needed. If editing code, for instance, the red could be used for minimal syntax highlighting. Looking at their demo video the display seems as responsive as the other ones I was considering, it has an SPI interface, and it only costs about $20 more than one of the old ED060SC4s. Some code can probably be shared with the badgy project as well. All things considered, the GDEW075Z09 seems like a better choice than an older recycled model.

The CPU I've chosen for the project is the ESP32. Of course, this chip is normally used in an embedded context, not as a CPU in a general-purpose PC. This may seem like an odd choice - and it is, part of the fun is trying to get this to work. But when you consider the non-goals of the project, it starts to make sense:

• The ESP32 uses little power.
• The ESP32 has WiFi capabilities tightly integrated; adding an external wireless radio would consume more power and couldn't be controlled as granularly.
• The ESP32 is cheap - a single chip is $3!
• The ESP32 is hackable (in the good way). It has lots sensors integrated (touch, ADC, DAC, amplifier, Hall effect, temperature...), good I/O (SPI, I2C, Ethernet, WiFi (duh), 3x serial...) and is simple due to its position as a microcontroller and not necessarily a CPU.
• The ESP32 has an integrated low-power coprocessor and can sleep with WiFi on.
• The ESP32 has a detailed datasheet and technical reference manual.
• I can get my hands on a single ESP32; I can't get a single BCM2837.

Of course, there are some obvious downsides to trying to use a microcontroller as a general-purpose user-facing CPU:

• It will be slower than an e.g. ARM chip designed to be used with GNU/Linux. Although it might not actually be that bad with only a terminal and 240MHz. Of course, for actual work one would probably want to just run ssh/mosh to a server somewhere.
  • Of course, the lack of out-of-order execution means the Spectre vulnerabilities are not present. I am pretty sure Meltdown is not a problem for the xtensa architecture, either, but I will ensure it is safe from both once Linux is ported.
• The Flash and RAM are very limited. Some of the docs (ESP-PSRAM, esp-idf, and hardware datasheet) contradict each other, but according to Sprite_TM "[the ESP32 can] support 16MiB of flash and 8MiB of SPI RAM. However, we don't have address ranges to keep that all mapped at the same time: the psram can have maximally 4MiB mapped at the same time, the flash can has 4MiB mapped as data memory and (iirc) 4MiB as instruction memory... I think there are 2 other 4MiB regions for the flash, but they are mappings for instruction memory and I'm not 100% sure if they're usable out of the box."
  • The Linux kernel, including the Xtensa port, includes support for XIP allowing most of the kernel code to remain in flash. Especially if I can get any of the unused instruction memory regions mentioned at the end of Sprite_tm's quote above working, it should be enough space for the kernel. As the LWN articles below point out, the ongoing "constification" effort helps not only security and code correctness but has the side benefit of allowing more variables to be stored in static Flash instead of loading them into RAM.
  • The ESP32 has an SD/MMC host controller that should allow it to read from SD cards, so the rootfs could probably be stored on there.
  • Even if esp-idf doesn't have drivers for everything, one of the most appealing features of GNU/Linux are its large set of drivers. It will probably be easier to port from other SD & sensor drivers than to try to port from esp-idf.
  • LWN has an interesting guide on shrinking the Linux kernel that covers techniques such as LTO and XIP with a step-by-step tutorial.
• While the ESP32 technically has an MMU, it is not advanced enough to be compatible with GNU/Linux. If we dig into the ESP32 OpenOCD code, we find the processor is a variant of the Diamond 108Mini which is described by Cadence as being very low power (good!) but below the 232L, the first officially GNU/Linux-capable one on the list.
  • Fortunately, obscure kernel features come to the rescue yet again! MMU-less GNU/Linux is possible in mainline (ergo with linux-xtensa which has also been mainlined). That comes with some problems as detailed in the link above, most notably the lack of fork().
    • Something I'm not sure about is the security impact of MMU-less GNU/Linux - although I haven't tested it yet, the lack of virtual paging would imply that every process can see and modify any memory, even that of the kernel. I can't find much information online about this (not even an admonishment of running untrusted software on no-MMU GNU/Linux) probably because this is mostly used on embedded platforms that would only ever run code from the manufacturer (not the case with a PC).
  • MMU-less Linux has the drawback that it can't run normal ELF binaries. If everything is built as FDPIC (essentially ELF but with PIE enforced everywhere) stuff can run though, and if I use Alpine Linux (which seems like it might work given its minimalism) I will be using musl, so I can use the musl cross toolchain that supports FDPIC.
• The ESP32 doesn't come with a native USB port. The MAX3421E can handle the USB host side and send back the data over SPI (which the ESP32 does have), but it costs $10 per chip - 3 times more than the CPU it's connecting to! I will definitely try to find a cheaper, similar chip before making boards.
  • Considering how much that chip costs, I definitely will not integrate a standard USB keyboard chip into the custom keyboard. Maybe I'll use PS/2 or just scan manually using the ULP coprocessor? I don't know, but I kind of want to find a way to use PS/2 simply because "ESPS/2" is a great name for a library ;)

What I might do during prototyping is first design an "ESPi" that breaks out all the stuff I want to use (USB port, Ethernet, SPI, etc.) in a Raspberry Pi (Zero?)-esque form factor and run tests on that, perhaps selling a few to raise money for the final prototype. In fact, I'd be willing to give them away to people who'd help me with kernel & driver development.

The number one goal of this project is to have the battery last as long as humanly possible. My goal is for this computer to be the one you'd want to be stuck with in a post-apocalypse scenario. A computer with a ten-year battery would be totally ridiculous - but in a good way.

As I mentioned in a previous project log, the computer I'm writing this on only runs free software, so I'm not about to taint it by installing Fusion 360 in a VM. Even though I don't have Fusion installed, I have the next best thing: real life. Let's get the "case" (a lunchbox for those of us just tuning in) and see how many 18650s we can put in there.)

I don't even have any 18650s on hand though. (I am a student working on this project with no budget, so skull this project so I can buy some batteries!) My first thought was to 3D print some mock 18650s, but then I realized how stupid that was. I have a jar full of U.S. pennies though, and Wikipedia tells me they are about 19 mm in diameter - just a little bigger than the 18.6 mm max diameter of an 18650. By layering pennies on the bottom of the box (and assuming I have enough vertical space), I can approximate how many batteries I can fit in there:

So let's assume I can cram 80 18650s in there. That's kind of ridiculous - and probably not something I will actually do, even with my fixation on battery life. OK, let's try again, but positioning them horizontally, as if they were in battery holders. An 18650 is 65.0 mm (it's in the name!) or about 3.5 pennies tall. If we have 8 pennies of vertical height, we could fit 10 columns of 2 batteries each, and we're left with lots of room for cooling, extra boards, etc. sort of like the Novena.

I'll discuss why I chose the ESP32 in more detail in a later project log, but for now what you need to know is that it is very power-efficient, especially when positioned as a shitty CPU instead of a great microcontroller. Its low-power modes allow it to go into sleep while staying connected to a Wi-FI AP, and it has a secondary controller that uses even less power - on the order of µA. Assuming the laptop is being actively used 25% of the time (that is, 6 hours a day - a generous estimate), sleeping while connected to an AP 50% of the time, and sleeping until keys are pressed 25% of the time (with no network traffic), a little back-of-the-Wolfram math suggests the battery should last almost ONE AND A HALF YEARS. Holy crap. Of course, this figure will be lower once I account for the e-ink display, keyboard controller, etc., but I no longer think battery life will be such a hard problem...

The Free Software Foundation's Respects Your Freedom certification "encourages the creation and sale of hardware that will do as much as possible to respect your freedom and your privacy, and will ensure that you have control over your device." The RYF cerfitication has several criteria a project needs to adhere to to earn it:

• All software running on the device as sold must be free software (duh)
  • PCB designs are made in KiCad and GPL'd, so no problem there
  • Case/mechanical designs are in Fusion 360, so while I can export the .f360 and the STL's, that might count as needing non-free software to build it...
    • If someone was motivated enough, they could "port" my designs to FreeCad, OpenSCAD, etc.
  • All Linux kernel-related stuff will obviously be under the GPL.
  • Any other software I write for the project will be released as GPL or MIT/BSD (which is GPL-comatible)
  • The ESP32 WiFi baseband/wpa-supplicant is currently a binary blob...
    • Worst-case scenario: even if this firmware is never freed, the ESP32 should be otherwise functional without it - the Ethernet port would still work, although it would undermine the point of the project to need a tethered connection.
    • Espressif says open sourcing is "on the roadmap", but little progress has been made since 2016. The main argument by Espressif seems to revolve around not wanting to kickstart another wave of those ESP8266 deauth throwies with security through obscurity for the 802.11 PHY.
    • Some WPA2 & WPS code is due to be open-sourced in the 3.1 release though, so there is hope... At my pace, it might be "liberated" by the time I get a prototype working :P
    • Sprite_TM said in the ESP32 Hack Chat that once there is another system on the market with easy direct control of the PHY he would push for it inside Espressif. So any enterprising hackers who want to make a plug-and-play SDR platform for screwing up WiFi should have at it and liberate this firmware ;)
• User installation & compilation of modified software
  • While the system probably won't have anywhere near enough memory or storage to be fully self-hosting, considering my development PC only runs free software it should be impossible for me to make compiling the software require proprietary components.
  • The security afforded by the ESP32's Secure Boot (especially when combined with Flash Encryption) is something I want to be able to capitalize on. My current plan is to ship the computers "unlocked", and to provide a tool for users to generate their own private keys to sign their software with.
• No spyware or backdoors
  • I wouldn't dream of it. I hate those as much as the next guy. Besides, if all the code is open & builds are reproducible, it should be easy to prove there's nothing evil in there.
  • Generally I am immediately suspicious of hardware built in the United States, especially without a warrant canary. One of the first things I plan to do when I build a website is add one. Until then, needless to say, this 15-year-old hasn't yet received any secret subpoenas or anything.
• Confusion with other products
  • Well this is just kind of a generic guideline for any product, libre or not. The only "products" this could be confused with are the computers in Serial Experiments Lain - and that's intentional.
• Patents
  • I don't think I could even legally hold a patent on anything...
• Documentation
  • I hereby license everything on this hackaday.io project under the GNU Free Documentation License.
  • Check.
• Cooperation with FSF PR
  • Oh hang on, let me s:Linux:GNU/Linux:g real quick...

And there you go. Once I have a working prototype and I am sure all these plans are feasible, I'm pretty much going to copy-paste this into an email to the FSF and wait for my shiny sticker.

It feels good to just dump all this out onto the page. These ideas have been brewing in my head for months...

This project started by me making lists of what my "ultimate laptop" would and wouldn't have. My ultimate laptop would have:

• Very long battery life (I have an irrational hatred of plugging things in to charge)
• Hackable design (GPIOs exposed, modular motherboard, sensors, open hardware & software)
• Robust SSH, preferably something like mosh, to connect to a beefy server somewhere else
  • Even better would be a complete local (albeit underpowered) Linux/POSIX environment for small tasks without Internet
• E-ink display (they're great for ebooks, why not for other text?)
  • There are some interesting bi-color E-ink displays now. That would allow some coloring for e.g. minimalist syntax highlighting.
• USB-C with introspection (PD Buddy Sink built in)
• Cool form factor (only 90's kids will remember the lunchbox computer from Codename K.N.D.)
• Mechanical keyboard (a DIY keyboard is needed to fit the profile of the lunchbox lid, so might as well buy a bag of Cherry MX Browns and heat up the soldering iron)

And as with any project it is important to define non-goals. In this case they almost describe the project better than the goals:

• Graphics (other than a terminal)
• Gaming (other than Zork ;) )
• Thinness (ruggedness is more important, e.g. old Thinkpads)
• Local performance (an SSH session takes little bandwidth & at least 2G data coverage is widespread enough that hard tasks can almost always be offloaded to a cloud server or home PC)
• Usability as a "normal" computer (it obviously won't run Windows, and it probably won't even support X, so it is limited to terminal apps)

Of course, many of these non-goals could still be achieved by a motivated enough hacker. For instance, I don't plan on writing a driver for the Hall effect sensor in the ESP32, but if someone needed one they could. Someone probably could run X on it given enough effort, it just isn't a priority for me.