fitzsim's development log

I decided to try running Mezzano on real hardware. I figured my Librebooted ThinkPads would be good targets, since, thanks to Coreboot and the Linux kernel, I have reference source code for all the hardware.

On boot, these machines load Libreboot from SPI flash; included in this Libreboot image is GRUB, as a Coreboot payload.

Mezzano, on the other hand, uses the KBoot bootloader. I considered chainloading KBoot from GRUB, but I wondered if I could have GRUB load the Mezzano image directly, primarily to save a video mode switch.

I didn’t want to have to reflash the Libreboot payload on each modification (writing to SPI flash is slow and annoying to recover from if something goes wrong), so I tried building a GRUB module “out-of-tree” and loading it in the existing GRUB. Eventually I got this working, at which point I could load the module from a USB drive, allowing fast development iteration. (I realize out-of-tree modules are non-ideal so if there’s interest I may try to contribute this work to GRUB.)

The resulting GRUB module, mezzano.mod, is largely the KBoot Mezzano loader code, ported to use GRUB facilities for memory allocation, disk access, etc. It’s feature-complete, so I released it to Sourcehut. (I’ve only tested it on Libreboot GRUB, not GRUB loaded by other firmware implementations.)

Here’s a demo of loading Mezzano on two similar ThinkPads:

For ease of use, mezzano.mod supports directly loading the mezzano.image file generated by MBuild — instead of requiring that mezzano.image be dd‘d to a disk. It does so by skipping the KBoot partitions to find the Mezzano disk image. The T500 in the video is booted this way. Alternatively, mezzano.mod can load the Mezzano disk image from a device, as is done for the W500 in the video. Both methods look for the Mezzano image magic — first at byte 0 and, failing that, just after the KBoot partitions.

I added the set-i8042-bits argument because Coreboot does not set these legacy bits, yet Mezzano’s PS/2 keyboard and mouse drivers expect them; at this point Mezzano does not have a full ACPI device tree implementation.

So you want to write a utility script, and you want to write it in Common Lisp. I created a template Common Lisp script called start.lisp. It’s meant to be renamed and hacked up but it provides a starting point for a new Common Lisp script, with some utility libraries included.

Here’s a “one-liner” that you can paste into a text editor, verify visually, then copy-n-paste from the editor into a terminal. This will get you up and running on major distros:

sudo apt install sbcl || \
sudo dnf install sbcl || \
sudo yum install sbcl && \
git clone --recursive https://git.sr.ht/~fitzsim/cl-starter-script && \
./cl-starter-script/start.lisp --help

It uses some shell tricks I found on the EmacsWiki, and a UIOP¹ feature ((uiop:argv0) with __CL_ARGV0) I discovered via the impressive cl-launch project. It’s too bad cl-launch isn’t more widely packaged, since it seems like a good idea.

I may add more utility features to this template repository, but I’ll also try to keep it simple and self-contained. Self-contained meaning after the initial git clone there’s no need to go back to the Internet for more libraries.

This is only meant for utility scripts (and for me as a learning exercise for ASDF and Common Lisp packages). It is available in my Sourcehut, and mirrored to Microsoft GitHub.

For bigger projects, check out Quickproject, and for installing newer Common Lisp implementations than your operating system provides, consider Roswell.

Thanks to Didier Verna for help with ASDF and for quickly incorporating into CLON some new features I requested.

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:

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.