Project Logs

Collapse

• What's black, white, and red all over: Color E-Ink

  Milkey Mouse • 03/15/2018 at 02:29 • 3 comments

  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.

• CPU

  Milkey Mouse • 03/14/2018 at 06:32 • 0 comments

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

  Read more »

• Batteries

  Milkey Mouse • 03/13/2018 at 20:01 • 0 comments

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

• Respecting Your Freedom™

  Milkey Mouse • 03/13/2018 at 19:30 • 0 comments

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

• Project Goals

  Milkey Mouse • 03/13/2018 at 18:05 • 0 comments

  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.

View all 5 project logs