Pocket Lisp Computer

I recently built three Lisp Badge computers with some help from my kids. I bought a hot air soldering station and learned TQFP soldering. The kids did some through-hole and SMT soldering and really enjoyed it!

The hardware assembly and debugging process was really fun, other than worrying several times that I had put too much heat into a component, or set the wrong programmable fuse. During that phase I received some advice from the board’s designer, which really helped.

I’ve learned from the hardware people at work to always order extra parts, and I did, including an extra PCB. I was half expecting to damage stuff while learning, so I was really happy that we ended up with all three boards fully working, after locating and fixing some cold solder joints.

It was challenging as DIY projects go, since the Lisp Badge is not available as a kit. But ever since I saw the Technoblogy post about it, I knew I had to attempt building one, and it was worth it. Other than the display, compatible parts were all available from Digi-Key, and I got the PCBs from OSH Park.

The result is a really neat little computer. Here is a picture showing “big text” support that I added:

Three Lisp Badge computers displaying (lisp-badge) in large text split across the screens.

I also added support for building standalone on Debian (Arduino-Makefile), made the audio buzzer work, and wrote an example of how to play a tune on the buzzer. I published the changes to my sourcehut.

It’s fun to try writing small programs on the badge itself, within the constraints of its minimal uLisp REPL.

An excellent machine

I finished building my Talos II system, and I decided to post my thoughts on it here.

This is an excellent machine, the best workstation I’ve ever used. It’s very fast — it compiles Emacs and the kernel in 2 minutes, and just spins up the fans a little bit while doing so (under normal operation it’s quiet). And it’s in a completely different league in terms of openness than any other computer I’ve owned (and any other high performance computer on the market today).

The system came with a nice user’s manual, and full schematics! I’ve already referred to the schematics to set up the pinmux for a rarely-used serial port so that I could use a TTL serial cable I had lying around (I submitted the device tree patch to Raptor).

It’s really two computers in one: the “baseboard management controller” (BMC), a low power ARMv6, with a full distro on it, and the main POWER9 CPUs. The BMC boots up as soon as you plug in the power supply, before you even press the power button. (It would be nice if there were an ncurses top-like viewer for fan speeds and temperatures that I could leave running on the BMC serial console, but I haven’t found such a thing yet.)

It has serial ports everywhere! One right into the main CPU, and two into the BMC. This is great for low level development, e.g., breaking into bootcode at an early stage.

I left the machine running overnight after first booting it. My neighbourhood had a power glitch, and in the morning I discovered the main CPU was off, and power cycling it via the BMC wasn’t working. Before unplugging and plugging back in, I asked on #talos-workstation, and it turns out I had hit a bug in the first-release firmware. With special commands I was able to power cycle the main CPU just via BMC software (no unplug required). Wanting to know the details, I asked if there was a data sheet for the chip I was interacting with. The amazing thing, from an openness perspective, is that one of the Raptor engineers instead referred me directly to the Verilog source code of the FPGA handling the power sequencing. No searching for datasheets, no black box testing, just straight source code (which is recompilable using an open source FPGA toolchain, BTW.)

It’s so refreshing to not have to do reverse engineering and speculation on opaque things when something fails. On this machine, everything is there, you just look up the source code.

I’ve always disliked the inflexibility and opacity of BIOS/EFI in the x86 world. IBM has done an amazing job here with OpenPOWER. All the early boot code is open, no locked management engines or anything like that. And they’ve adopted Petitboot as the bootloader. It runs on a Linux kernel, so I was able to bootstrap via deboostrap over NFS by building everything within the bootloader environment. Running a compiler in a boot environment is surreal. Even with free options on x86 like libreboot or coreboot, and GRUB, the boot environment is extremely limited. With Petitboot at times I wondered if I even needed to boot into a “desktop” kernel (at least for serial-only activities.)

Now I’m setting up my development environment and I’m learning about the PPC64 ELFv2 ABI, with a view toward figuring out how to bootstrap SBCL. I feel lucky that I got a POWER9 machine early while there are still some rough edges to figure out.

Talos II available for pre-order

The Talos II is now available for pre-order. It is the more affordable, more power-efficient successor to the Talos I machine I wrote about in a previous post.

This is a very affordable machine for how powerful it will be, and there are minimal mainboard + CPU + RAM bundles (e.g., this one), around which one can build a workstation with more readily-available parts. I’ve placed an order for one of the bundles, and will buy the chassis and GPU separately (mainly to avoid high cross-border shipping fees for the full workstation).

The Talos II is an important machine for Free Software, and will likely be RYF-certified by the FSF. Pre-orders end September 15th!

Talos Secure Workstation

This is a very important machine that really deserves to get built. Anyone who cares about Free Software should consider funding this project at some level, and spreading the word to their friends. If this project succeeds, it will bootstrap a market for new, owner-controlled performant desktop machines. If it fails, no such computers will exist. The project page and updates explain the current (rather depressing) state of general purpose computing better than I could, so take a look.

Think Penguin

I bought a ThinkPenguin.com laptop for my Mom for her birthday. She’s a long time GNU/Linux user and she was ready for an upgrade from her ThinkPad T41. I decided to try ThinkPenguin.com. I’m really impressed with their service and their product.

The laptop shipped within a few days, and when it arrived it had Fedora 17 pre-installed like I had requested. The build quality is very good. It’s a slim light laptop with attractive styling, and a solid keyboard. One of ThinkPenguin’s main selling points is hardware support, and it really was great. Graphics, Wi-Fi, suspend, hibernate, resume all worked perfectly, out-of-the-box, no configuration necessary. It’s fantastic to get this smooth out-of-the-box experience with GNU/Linux instead of a proprietary operating system.

If you care about Free Software and are in the market for a laptop, check out ThinkPenguin.com.

Pulse-Eight USB CEC Adapter

I bought the Pulse-Eight USB CEC adapter a few months back and so far it’s been a great addition to my XBMC setup. For a long time I wanted to control my TV from my Android phone, for a few reasons. First, I usually have it with me and charged up, unlike my TV remote which might be misplaced or out of batteries. Second, I find it annoying that the infrared TV remote requires line-of-sight. And finally, a smart phone remote just seems like the right way to control a TV in this day and age.

For such a tiny package the Pulse-Eight adapter enables a lot of functionality. I can turn my TV on and off from my phone over Wi-Fi, using the Official XBMC Remote Android app and a slightly-hacked version of XBMC. But there’s more. Guests who prefer using a TV remote can use its extended buttons to control XBMC playback. The adapter enables communication in both the TV-to-XBMC and XBMC-to-TV directions by passing CEC commands over the HDMI bus. And its inventors maintain a Free Software library, libcec, to control it. This is a much cleaner and cheaper solution than the various Wi-Fi-to-IR converters I’ve looked at.

If you run XBMC make sure to check out this adapter.

True Fullscreen Fit-to-Width Document Viewer

I like to read documents in fullscreen mode using keyboard navigation. I want a viewing mode with the following properties:

  1. No scrollbars
  2. No navigation toolbars
  3. No drop-shadow page borders
  4. Fit-to-width display
  5. Emacs-style scrolling, maintaining 2 lines of context for continuity

To me 1, 2 and probably 3 should be properties of anything claiming to be “fullscreen mode”. Unfortunately fullscreen mode now seems to mean “mostly fullscreen mode with some widgets reminding you you’re in fullscreen mode”. Nowadays what I want would be called “true fullscreen mode”.

The DjVuLibre document viewer can be configured to support all these requirements. It provides a perfectly clean mode, allowing you to really focus on the document itself with no distractions. Unfortunately it only supports DjVu documents.

Evince has excellent multi-format support but its fullscreen fit-to-width mode fails 1 with an ever-present vertical scrollbar, 3 and 5. Its presentation mode is fully-uncluttered but it is necessarily not fit-to-width, so it’s not great for just reading documents.

Okular seems at first glance to have format support equivalent to Evince but its fullscreen fit-to-width mode fails 2 with a non-removable navigation footer, 3 and 5.

Maybe I’ll file some Evince feature requests. In the meantime, any suggestions for other viewers?

Android Development

A patch I wrote for mobileorg-android was accepted and shipped to the Market in mobileorg-android 0.4.8. It works around lighttpd’s missing support for the Expect HTTP header. The issue was that pulling from lighttpd to the phone would work, but pushing from the phone to lighttpd wouldn’t.

To debug the problem I set up an Android development environment. In doing so I found android-mode.el and android.el (shipped with the SDK in android-sdk-linux_86/tools/lib) very useful both during development and initially for learning the Android Emacs workflow. For the most part, developing for my Nexus One was very straightforward. The only issue I ran into was not being able to start /sbin/adbd on the phone.

Since none of the Android development tutorials I Googled mentioned this problem, I’ll outline the symptoms here. If this issue affects you, the Settings -> Applications -> Development -> USB debugging check box on your phone will have no effect. After you’ve checked “USB debugging”, when you plug your phone into your development machine via USB, the USB file storage dialog will come up. “adb devices” on your development machine will not list the USB-connected phone. If you open a terminal window on your phone,

$ getprop persist.service.adb.enable

will print 0, and

$ ps

will not list /sbin/adbd.

When things are working correctly, checking USB debugging causes /sbin/adbd to be run on the phone. /sbin/adbd exports different USB endpoints to “adb fork-server server” (started by adb on the development machine) so that the phone shows up as an Android development device, instead of a USB hard drive.

In my case the workaround was to check “USB debugging” then reboot my phone. After the reboot, persist.service.adb.enable was set to 1 and /sbin/adbd started when I checked USB debugging.

Unfortunately I couldn’t find a way out of this scenario without rebooting my phone which I avoid doing if possible (my best uptime so far is 60 days ended by the 2.2.1 system update). I haven’t rooted my Nexus One so /sbin/adbd caused “Permission denied”, and I couldn’t change persist.service.adb.enable to 1 with setprop; it would stay set to 0. Without /sbin/adbd (and before I discovered the reboot workaround), I was left having to manually install a mobileorg-android .apk file via the SD card which was a pain. I was disappointed that I didn’t have control over persist.service.adb.enable (which I assume I would if I had root). The main reason I bought the Nexus One was for its unlocked hackability, so things like this leave a bad taste. Hopefully the issue I linked to gets resolved.

IcedTeaPlugin and Live USB

I’m very happy to see IcedTeaPlugin enabled by default in the Fedora 12 Live USB images. This wasn’t always the case — in the past space-savings arguments were made to exclude java-1.6.0-openjdk and java-1.6.0-openjdk-plugin from Live images. I haven’t found out who’s responsible for the editorial change-of-heart, but to the people who made it happen: thanks! It’s great to see this plugin, and others, installed and enabled in the browser by default. No messing around finding and downloading Firefox plugins post-install or worse, during a Live session; just true “Works-Out-of-the-Box” operation.