April 3, 2018

Reading linux mouse input with golang

I think mouse input in linux is generally awful. It always feels terrible in any window manager and I have begun digging into the whys. It seems mostly related with X adding acceleration. In my ventures I learned how to read from a mouse device without X. Lets read the mouse input from linux!

In UNIX'y operating systems everything is a file which many people seem to enjoy shouting off at irrelevant times with no context. For our purposes, this means the mouse will be represented as a file somewhere.

If you only have one mouse (why would you have two? freak) you can check /dev/input/mouse0

$ file /dev/input/mouse0

/dev/input/mouse0: character special (13/32)

With that we can see the mouse is a so called 'special' which is short for a 'special file', aka device file

A quick and dirty example in go to get the relative x/y update and whether or not left/right/middle is down would look something like this. Note this is blocking and could be drastically better

package main

import (

// TODO https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/input.h#n28

func main() {
    f, err := os.OpenFile("/dev/input/mouse0", os.O_RDONLY, 0600)
    if err != nil {

    data := make([]byte,  3)

    for {
        nr, err := f.Read(data)
        if err != nil {

        if nr == 0 {
        left := data[0] & 0x1 != 0;
        right := data[0] & 0x2 != 0;
        middle := data[0] & 0x4 != 0;
        x := int8(data[1])
        y := int8(data[2])
        fmt.Printf("\r x=%d y=%d left=%v right=%v middle=%v ",
            x, y, left, right, middle)

Assuming you have your GOPATH setup correctly (or use the default of ~/go), save this in a package called eg, linux-mouse-events.

Then you can test it like so (CTRL-C to exit):

$ go install linux-mouse-events
$ sudo ~/go/bin/linux-mouse-events
x=1 y=0 left=false right=false middle=false ^C

Amazing! Next we will move to timing evdev events to see if anything mucks with raw mouse report rate

March 26, 2018

'Le Potato' boot serial port

The AML-S905X-CC (Le Potato) is a strange beast. It doesn't have reams of friendly documentations and is fairly barebones.

I decided to start looking into where u-boot lives, where early boot output goes and things of that nature.

So off I went and plugged in a USB serial cable to the usual spot for a raspberry pi style header. From top right, its VCC VCC Ground UART_TX UART_RX.

attempt 1

Cracked open putty, serial 115200 baud lets go. Not my first rodeo..


Never said I was able to ride the bull 8 seconds. Wrong baud rate? That would be a first for me. Maybe it has different headers. I go to check pin-out, but they do not provide a pinout!

They do however provide a schematic. I've mirrored it HERE because they served it from drive so who knows how long that will be around.

Huh, it mostly matches the raspberry pi layout..

header schematic

I decided to quickly flip around to the CPU(s) section of the schematic to make sure UART_A_TX and UART_A_RX are the right thing. In the process I discovered they have broken out the IO pins for UART in a separate spot named 'UART DEBUG' (promising!) and they are labelled differently as 'linux rx/tx':

uart debug

physical location next to hdmi

Instead of wasting time guessing UART baud rate incase its something weird I decided to crack out a saleae logic analyzer. By the way, I cannot recommend these things enough, they are amazing.

I plugin the UART pins and add async serial analyzers with 'autobaud' on, so they will scan smallest pulses as they are received and adjust baud.


serial analyzer

This works without issue and the reported baud setting is ~116279 after a capture, so 115200 is probably correct.

Plugging the usual USB serial cable into the debug UART at 115200 shows us glorious U-boot output and works.

serial analyzer

This is a custom u-boot that I am unsure is completely upstreamed. I've never seen so much stuff printed out before uboot header.


As expected, the le potato will require digging. aside from one (active) forum, you're basically on you're own. On the plus side the developers seem engaged with upstream, have their sources on github and provided schematics.

March 25, 2018

NetBSD features you may have missed

It's no secret NetBSD is the smallest of the three contemporary modern BSDs (FreeBSD, OpenBSD, NetBSD, intentionally ignoring PC-BSD/TrueOS). Many don't give NetBSD any more thought than 'oh its the one that can run on a toaster' (which is true as long as it has a MMU :)

the netbsd poster-child toaster-child (Full article here )

There are some interesting features that are useful on desktops as well as embedded that deserve being mentioned. I list some of the features that caught my eye in no particular order. Also in no way are these unique to NetBSD (well mostly), but some may surprise you.

Lua kernel / ring0 code

I'm not sure how popular it is or if its really used, but it is a possibility to write kernel modules in Lua. This is pretty darn cool and lua support in the kernel is the fruits of a previous Google Summer of Code (GSoC) project.

For Lua to work, you need to load the lua and lua sytem modules:

# modload lua
# modload luasystm

Then you can create a Lua state and load a script like so:

# luactl create state1
# luactl require state1 systm
# luactl load state1 ./luahello.lua

You can find full examples here Def checkout intro(9lua) too.

CGD disk/partition encryption

CGD (Cryptographic device driver) lets you encrypt disks at an entire disk or partition level. Of course, this is nothing new, but it has more flexibility for key sizes and available ciphers versus, eg, OpenBSD. This may no longer be true

rump kernel drivers in userspace

juicy rump

NetBSD Rump kernels offer many benefits, of particular interest is being able to compile kernel drivers and test it in seconds without using a VM. In simplified terms, it is basically the various drivers that usually live in kernel space, but running as separate entities in the rump kernel userspace.

Rump kernels are not an operating system specific concept, for background see What is a rump kernel? NetBSD 'anykernel' is (was?) the first implementation of a usable rump kernel though. It has a funny name to boot

pkgsrc can do some cool stuff

I have to admit I'm just starting to dip my toes in pkgsrc. It's a solid package manager, downloading and compiling sources for you and managing deps, as you would expect of a package manager in 2018. It has some lesser known auxiliary features:

  • Portable, you can use it on other BSDs as well as Linux!
  • Built in tools for auditing vulnerable software with pkg_admin audit
  • It can check licenses if you care about that. Eg warn/disable installing XYZ license software.

Veriexec - Ring0 binary/file/data verification

In layman terms, veriexec compares binaries and files to a pre-configured whitelist of hashes and refuses to run any that diverge. While this would require a bit of setup (and would be annoying for casual daily desktop use), you could really lock down a machine with this setup that would be resilient to even root privilege escalations.

With the state of MD5 and SHA1 hashes being worthless for integrity and having vulnerabilities and proof of collision respectively, it supports SHA256, SHA384, SHA512, and RMD160 hashing. There are a few levels of strictness which can make the machine dynamically learn or report in an IDS style of operation as well.

Sane config/directory hierarchies and other non-technical things

This is not so much a feature as my personal preferences, but on NetBSD you get things like a sane, centralized rc.d startup system. No 6 runlevels, no systemd, no having to rifle around to find defaults. /etc/rc.d after looking at /etc/defaults/rc.conf and be done with it.

Additionally, third party stuff always ends up in /usr/pkg and their configs go in /usr/pkg/etc. While GNU/Linux isnt awful, I am annoyed switching distros and having no idea where things go, install to, overwrite, etc.

Being able to install an entire system (with X) using an installer under 350mb is unheard of in this day and age too. I'm pretty sure the Nvidia drivers are bigger than that now.

March 22, 2018

NetBSD docs tarpits and kernel compiling

While my VM setup is the way to go I eventually got NetBSD-current going on the spare machines I previously mentioned. It would only be fair to mention that when NetBSD 8 comes out, it will work much better on amd64 systems.

With that said, I've been trucking along to basic usage and compiling the system. For package management, I've been just grabbing binary packages as needed with pkgin, not really interested in trying to compile big stuff with pkgsource yet.

As a beginner, I found the package management scenario presented in a burdened way. The flexibility of (having to) picking your package trees, binary versus sources, pkgsource config, pulling in CVS etc increases the cognitive load. I just needed tmux! So I only do basic pkgin usage for now.

Scan mailing lists

It's worth mentioning, even if you have no intention of running NetBSD-current or getting into the code, if you run into issues, visually scan or search the mailing list archives, someone else likely has already griped about your issue if its even remotely common.

There are actually two approaches to this, you can search GNATS, but its kinda slow to query, and you kind of have to know what you're looking for in issues. Or just check netbsd-bugs and netbsd-users mailing lists for a decent litmus-test.


NetBSD-bugs will be slightly exaggerated noise with GNATS auto replies, but if you're having an issue it will likely be beaten to death by faithful testers here.

Moving on to grabbing tarballs of sources (sets as it were) and compiling the kernel, I googled and ended up at the NetBSD wikis for various things, eg:

I plodded through and things immediately went very badly and in hindsight I should have checked sooner..


long story short: DO NOT USE THE WIKI (for stuff in the guide). It's basically redundant compared to the guide, and has largely fallen to the wayside. I think the guide is in tree next to sources and was mostly up to date.

I still ran into minor issues with the current release and reported them. But overall there was no show stoppers for the kernel compiling section of the guide.

System and kernel compiling

One minor issue I had was the build.sh instructions not working as prescribed. But looking at the error output, it was easy to figure out. For people less weathered it might not have been trivial to know to create an 'obj' folder or specify it and run as -U for non-root users. But then again NetBSD demands a bit of knowledge up front. For example (this is after you have dong config <cfgfile>, GENERIC on amd64 here), here's how I got going. Change -j9 to number of cores in your machine +/- 1 for best results. There is a useful file, BUILDING sitting in /usr/src once you have unzipped sets that has full explanations and useful examples. Alternatively the 'building the kernel manually' guide works fine still. I'm interested in using the excellent cross compiling capabilities of build.sh though.

$ cd /usr/src
$ mkdir obj
$ ./build.sh -U -u -O obj -j9 tools

(this will take a while, gcc is a bear of a compile)

$ ./build.sh -U -u -O obj -j9 kernel=GENERIC

--- netbsd ---
#      link  GENERIC/netbsd
/usr/src/obj/tooldir.NetBSD-7.1.2-amd64/bin/x86_64--netbsd-ld -Map netbsd.map --cref -T /usr/src/sys/arch/amd64/conf/kern.ldscript -Ttext 0xffffffff80100000 -e start -z max-page-size=0x100000 -X -o netbsd ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
NetBSD 7.1.2 (GENERIC) #1: Fri Mar 23 13:51:54 MDT 2018
   text    data     bss     dec     hex filename
14223597         654556  593920 15472073         ec15c9 netbsd
===> Kernels built from GENERIC:
===> build.sh ended:      Fri Mar 23 13:51:57 MDT 2018
===> Summary of results:
         build.sh command:    ./build.sh -U -O obj -j9 kernel=GENERIC
         build.sh started:    Fri Mar 23 13:49:31 MDT 2018
         NetBSD version:      7.1.2
         MACHINE:             amd64
         MACHINE_ARCH:        x86_64
         Build platform:      NetBSD 7.1.2 amd64
         HOST_SH:             /bin/sh
         MAKECONF file:       /etc/mk.conf (File not found)
         TOOLDIR path:        /usr/src/obj/tooldir.NetBSD-7.1.2-amd64
         DESTDIR path:        /usr/src/obj/destdir.amd64
         RELEASEDIR path:     /usr/src/obj/releasedir
         Updated makewrapper: /usr/src/obj/tooldir.NetBSD-7.1.2-amd64/bin/nbmake-amd64
         Building kernel without building new tools
         Building kernel:     GENERIC
         Build directory:     /usr/src/obj/sys/arch/amd64/compile/GENERIC
         Kernels built from GENERIC:
         build.sh ended:      Fri Mar 23 13:51:57 MDT 2018
===> .

Finally, I can start digging in. This compile time certainly helps! Modern computing rules! This VM is not even on a SSD. I'm hopeful if I moved it and gave it a few more cores it could build in 60 seconds. A full release build of tools, userland and X across 16 cores probably still takes 10s of minutes though.

March 20, 2018

Installing NetBSD: amd64 pain ahoy

As covered in a previous post, I decided to deep dive a more UNIX'y operating system, ultimately NetBSD. And so it begins

When I want to learn something new, I go all-in. Diving into NetBSD, I wanted to go a 'total immersion' route, mostly because I'm fortunate enough to have lots of spare machines around I could test on and thought it would be best to use on real hardware. And focus on that machine with no distractions, just man pages like times past.

I also went all-in on coke cherry zero at my battlestation as you will see. This stuff is like nectar from the sugar free gods.


I picked NetBSD because I wanted a challenge and I wasn't exactly expecting smooth sailing but so far I've got challenges in all the places I was not expecting!

Sometimes I get irrationally mad or frustrated with things when in a hurry to get started, so this is more me aligning reality with expectations and documenting my progress.

Let me say this is not an attack on NetBSD, I understand that it's a smaller project compared to FreeBSD and OpenBSD and not even to mention GNU/Linux. It's not like companies are paying people to hack out drives for NetBSD.


First, here's some of the hardware I've seriously tried (and remembered to write stuff down on) so far:

  • Dell Vostro 3500 laptop from 2011
  • i5 3570k Desktop with ancient 2008 intel sata SSD (Spoilers!)

I decided to start with the latest regular, non-development release NetBSD 7.1.2, the newest release (5 days old at time of writing)

Getting diagnostics during installation

But first an aside: know how to dig info off a machine during installation!

This may not be obvious for newer experimenters like myself, but it didn't occur to me how difficult it would be to grab outputs of dmesg off a machine during installation to share for help.

The easiest way is to have an USB stick formatted as FAT and insert it after dropping to shell from installer menu (if you can). I was booting off the installation USB stick, in that case I needed two. Do not have both plugged in when you boot, just installation media.

You can boot the install media and immediately bail to shell once you see the menu. Once there you can mount the USB stick like so

# mkdir /mnt/usbstick2

(plugin usb stick, at this point you might see in console, or:)

# dmesg

... check the latest message about mounting umass on device /dev/sd1 or such. Mine looked like this

umass1 at uhub2 port 7 configuration 1 interface 0
umass1: USB2.0 Flash Disk, rev 2.00/0.00, addr 5
umass1: using SCSI over Bulk-Only
scsibus1 at umass1: 2 targets, 1 lun per target
sd1 at scsibus1 target 0 lun 0: <USB2.0, Flash Disk, 2.60> disk removable
sd1: fabricating a geometry
sd1: 961 MB, 961 cyl, 64 head, 32 sec, 512 bytes/sect x 1968128 sectors
sd1: fabricating a geometry
sd1: mbr partition exceeds disk size

Now we know the device is 'sd1', so the first partition would be `sd1a':

# mount_msdos /dev/sd1a /mnt/usbstick2
# dmesg > /mnt/usbstick2/dmesg.txt
# sync (or you can do umount /dev/sd1a)

If you're coming from a gnu/linux background like me, take heed and do not typo it sda1 a million times, because the backspace key will NOT work correctly and you'll go mad.

Importantly, dont forget the sync or umount command. If you rip out the USB stick before hand, the file could be not there, or likely, present but empty.

Installation - laptop

Starting with the laptop, this one was very frustrating to figure out at first due to some red herring level issues.

In an effort to save anyone else chasing this, I basically saw this during boot of the installer:

# root device:

There was two steps to this

  1. Set hard drive mode from AHCI to IDE :(
  2. Boot from a cdrom instead of of USB stick

For reasons unclear to me booting from cdrom worked fine and successfully installed without issue. HOWEVER, booting the new installation ran into the same issue, even with the hard drive detected in either mode (IDE/AHCI), it fails to open. I never got past this and gave up on the laptop:

root device: wd0a
vfs_mountroot: can't open root device
cannot mount root, error = 6

Heres a lame picture to follow par for the course


At this point I decided to move to the desktop, considering laptop no go. RIP

Installation - desktop

I booted off USB stick for desktop, but ran into same issue. It wouldnt detect hard drive in AHCI mode, but it did report an error. The error in dmesg which seemed to indicate hardware failure:

ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0

I was very skeptical because this machine ran windows 10, Linux, other BSDs without issue right before this. I clicked it over to 'IDE' mode instead and it detected drive and started the installer. Smooth sailing from here right?

soda panic

I got a panic during auto configuration of a wifi card (which, by the way it detected no problem, go figure). I tried to reproduce it to report in GNATS but had no luck, so I just started over and skipped network configuration during installation.

At this point I had a working NetBSD 7.1.2 installation on the desktop. So at this point, I have NetBSD booting but unconfigured. I could technically move to configuration and usage at this point if I wanted. On fast hardware to boot!

Run current sources to test things

Bringing up some of the panics and really obnoxious issues, I looked into reporting/debugging them. I was told to try again on 'current' in NetBSD parlance, working sources. Which of course, is a good idea in case it has been fixed, and to ensure it is reproducible.

So I grabbed a recent snapshot of NetBSD 8-current and tried that installer. Mostly the same story there, no working AHCI.

One big thing I want to capture somewhere is that the installer failed to run due to some drivers. You'll get a panic something like this booting current:

boot growing soda panic2

After trying this tip from IRC:

14:02:38 <medfly_> you can drop to boot prompt
14:02:41 <medfly_> userconf disable i915*
14:02:44 <medfly_> userconf disable radeondrm*
14:02:47 <medfly_> userconf disable nouveau*
14:02:48 <medfly_> boot

Which by the way, the IRC channel (#NetBSD on freenode) had a lot of very patient and helpful people. The machine has an nvidia 780Ti so i try the last one, userconf disable nouveau* and boot. Bam Current installer off to the races!

I was able to install current at this point. One thing I need to figure out is how to make disabling nouveau permanent because I have to drop to boot prompt every reboot to do so. I could now use the machine. I'll probably just ssh into it moving forward.

Moving forward

After doing some cross-checking, the old intel SSD in the desktop is in fact actually starting to fail just now! This is no surprise considering its from 2008. With that in mind, I'll consider it non usable even tho it's running current doing not much right now.

I decided to just learn how to use the system in VM on my main desktop in the meantime. NetBSD mostly works great on the emulated hardware, and my primary desktop is an extremely fast machine which can build NetBSD in minutes. My beefy desktop has a 4k monitor, if you use it on 4k or similar make sure to set display scaling in virtualbox or else you will go blind:

display scaling

hello world

Eventually, I'll move some stuff around and put a good hard drive in the spare desktop and SSH into it. Now I can dig into usage, maybe run and build some software on it for starters.


NetBSD is very likely going to be difficult to install. Don't think amd64 will be smooth sailing just because its the comptemporary hardware of choice. While it's likely got the best coverage there are lots of open issues and lacking support for newer things like GPT/UEFI boot.

At some points I figured hacking custom u-boot code to get NetBSD to boot on a SBC would have been easier in some ways. But we'll see about that later.

Once it gets going, its pretty good. it's the consistent, rock solid UNIX experience I was hoping for. Coming from someone who primarily uses windows, but knows the basics of linux server administration, the UNIX experience equals I have no idea how to do anything in an otherwise familiar environment. I really like the simple rc.conf and rc.d init system and the sane directory hierarchies for third party software so far.

March 17, 2018

Waterboarding your brain / becoming a BSD curmudgeon

Buckle up, this is going to be a wordy, disjointed one.

“There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.”

― Ernest Hemingway

tacky, lofty quote opener: ✔️

Over the years I've been thrown into tasks at work I had zero experience or knowledge of. As those who work in the tech industry know, this isn't uncommon or even undesirable (for most).

One of the big pulls for people who are intellectually driven is the perk of getting paid to constantly tackle new and potentially interesting challenges and become better and stronger. For many, this is what makes the tech work fulfilling and satisfying. I assume this parallels in any other industry with creative or open ended efforts.

Drive and the perversions of nerdy desire

While I want to say "nobody would enjoy copy pasting mindlessly for 8 hours a day!" I worked with people doing just that for years in a few entry level jobs. For example, processing ten digit triggers in telephone switches. Another example would be 'ACDVs', Automated credit dispute verifications which consisted of copy pasting personal information from one form to blank along side it. Back when I worked in collections (over 10 years ago now..) it could not legally be automated, hence 'verification'.


Aside, let me be perfectly clear: That is completely ok. These people were not interested in becoming LLVM core contributors or porting the OCAML compiler to a MIPS processor for fun. They were working one of the only jobs in town, that they despised, to feed their family. All without complaint. And as mentioned, a few people actually enjoyed it. A certain Zen to it. I get that. I was not sitting there, stewing, thinking I was better than the work or anyone. More importantly, I was sitting right there too, grinding it out.

Barely passing high school and never going to college, I thought programming was going to probably remain just a hobby while I went through the motions at entry level jobs indefinitely unless I changed something (I didn't). And that's exactly what happened. But I practiced at home, and roughly knew what I was capable of. Getting paid to explore this further was a pipe dream. I got very lucky, That's a story for another day

The point

I want to really push myself in something I've never done before that is also technically very challenging (for me, of course). This may be a recipe for disaster, but, I'd rather face frustration and 'failure' (learning stuff on the way doesn't make this a loss) instead of becoming complacent or niche'd. Finding where your current capabilities lie and pushing them even further is about as core nerd experience as you can get.

So with that said, here's what I got in mind

UNIX and BSD operating systems

As I grow older and learn more and more about OS design, either through osmosis or casual reading, I find UNIX and modern BSD descendants growingly interesting. I couldn't tell you why, I can't run MUH GAMEZ on them. UNIX is the essence of bygone development simplicity.

unix teletype session Attracting ladies on OKCupid

The BSD family is the modern descendent of UNIX, though the family tree is quite nuanced and a story of copyright and tribulations, you can see the full thing Here (wikipedia)

I've been meaning to really get into BSD for a while, too. John Carmack having a honeymoon with OpenBSD recently really resonated with me, even just as a user of the OS.

Heck. You can run the first UNIX in docker or still read the first UNIX programmers manual. I think anyone with an interest in OS legacy owes it to themselves to get familiar or at least know about the UNIX bloodline. Yea, I'm a big hit at parties!

As I was writing this blog, I saw this tweet fly by:


I've used BSDs a little bit, but very superficially. I run FreeBSD on servers, but I couldn't tell you how to do more than install and configure PostgreSQL on one. Never mind fancy ZFS stuff.

So taking a break from complaining about there being no good video games to play, getting intimate with a BSD is probably a good deep dive choice.

Which one? Well, I was going to pick either NetBSD or OpenBSD under the impression they are still smaller than FreeBSD, whichever had a smaller USB installation media. For the current releases, by chance they are both exactly the same size.

I picked NetBSD because I find the project goals more interesting, and it seems to be in more of a need. Another one of my primary interests that I do not act on and just fetishize is embedded development. And most importantly, the deeply logical fact I like the logo.

At the end of the day, I find the folks hacking on BSDs hardcore of the hardcore (or maybe just most oldschool) of this realm, maybe unfairly so. Do I want to 'hang out with the big boys' or embarrass myself trying?

What about GNU/Linux

GNU/Linux would definitely be a more usable choice when it comes to contemporary hardware. It also has far more developers, more people using it, banging on it and writing about it too. I'm also just not as interested in it from a nerdy lore background if nothing else. I'll definitely dig into it later on. BSDs also have the advantage of the entire system being built together, userspace and kernel. I find this a huge benefit to the system expectations and stability. Not to mention no intrusive updaters or systemd (bandwagon: ✔️)

New challenge

I have some lofty goals in mind. I'd be happy to get 2 or 3 of these under my belt, especially with the way work has been going lately, I'll probably be weekend warrior'n these out. Battle plan:

  1. Install and setup NetBSD, basic usage and configuration
  2. Compile NetBSD from sources, run current/srcs
  3. Dissect boot process (mostly for extra credit real goal below)

I really haven't done any of the above, but this is all straight forward and documented. There are a lot of other minor tasks this involves. For example, The BSD projects still use CVS (for some good reason I presume), so that would be another thing to learn. These will all probably not be a challenge, just prerequisites. Hell, I should admit, I've never done any sizable development in C, so I'll need to brush up on that (along with compiler extensions, buildchain etc).

Here is a nice NetBSD milestone:

bring up NetBSD on a new or unsupported SBC/board

How cool would that be? It'd require a good understanding of the hardware AND the software from ground zero if it was a new board.

I have a lot of single board computers, a few of which are newer, like the Libre Computer and ASUS tinker board, surely I can find one that isn't currently supported. Of course I have Raspberry PIs too, but I'm sure lots of others will try to get those going (not that I'm opposed to helping out).

They are both ARM processors, so I don't think it would be a soul crushing endeavor. I'll likely just pick one and go until I get things booting (if no one else has), I'd prefer the Libre computer (Amlogic ARM Cortex A-53), I think the Rockchip ARM Cotrex-A17 the ASUS Tinker board has more coverage.

If I wanted to go an extra step, I could even try to do so for a MIPS board, the MIPS Creator CI20 from imgtec. It's basically dead in the water and they've sold back MIPS, probably not the most fruitful. In fact, one of the NetBSD devs started the process years ago.

I'm also, for the first time in my life, well equipped to tackle early boot (well, as much as you can be) debugging. I own a logic analyzer, several USB FTDI serial cables, an oscilloscope, etc. But this would be more for new board bringup. Slightly different ARM SoCs is probably not as bad.

Yep, that's it! How hard could it be right? How long before I lose interest and just stop talking about it like all those other projects? Only time will tell. If I could even finish the first 3 things, that'd be a net win for me (no pun intended). This post is already far too long so I shall document the journey in more discreet chunks! Instead of a glacier of content!

<titanic picture here>