The t2k17 hackathon reports keep trickling in. Here's the one from Ian Sutton , who writes:

I was able to convince kettenis@ to allow me to commit my amdisplay(4)/nxptda(4) drivers which support unaccelerated video output on the BeagleBone Black, one of our armv7 platforms. This is the first instance of such video support on our ARM platforms and I hope to write similar drivers for other boards and eventually work my way up to writing acceleration support.

Finally, I dedicated just a little time to furthering a cool idea I've been hacking at for a while, something I hope will be a powerful debugging/development tool for us hardware people. Most of the ARM boards I work with have a tiny, obscure set of five or six pads curiously unlabeled on the silkscreen: JTAG interfaces! These are used for testing the behaviour/performance/conformance of individual devices on the board. Soldering a header to these pads and connecting them to a multipurpose JTAG debugger (e.g. busblaster, bus pirate, etc) allows for a much more robust debugging interface than software debuggers can provide. You can start/stop CPUs and other processors arbitrarily, gate/ungate clocks, print memory maps & register sets, set breakpoints, and do all of the above through a scripted interface. Wow! The debugger boards connect to a host machine over USB and expose a generic serial port (FTDI) which userspace software, specifically OpenOCD, opens & controls, using libusb to provide a machine-independent USB interface.

Here, things break on OpenBSD with libusb reporting tricky, misleading errors. An "unsupported" debug message lead me to believe the breakage was due to the lack of asynchronous support in the USB stack to which my solution was to finalize and import async support written during a GSoC project -- a solution that necessitates a high degree of skill and familiarity with our USB stack, and let me tell you, USB is one of those protocols you could easily fill a bookshelf with with texts comprehensively describing it. At the hackathon, I sat down with mpi@ and worked through what I wanted to accomplish & what was breaking, and through careful, slow, and sober analysis, discovered the real issue which has nothing to do with async support and is a simple race condition in libusb. D'oh!

This situation really embodies the value of hackathons, at least in my neophyte eyes. When you sit down next to someone and really /work/ with them, watch their fingers hit keys, see their workflow and see which reactions are prompted by certain situations & etc, you really pick up on their good habits and come to understand how to solve problems in a way that goes beyond the nitty-gritty-bitty sides of things. I learned an enormous amount in Toronto and very little of it had to do with technical things, and I think that is something you can only accomplish working in close physical proximity of one another.

The OpenBSD developer community plays excellently into this model; I tried to meet as many devs as I could manage (me being one of the new folks and all) and every single one, without exaggeration, was gregariously friendly, preposterously intelligent motivated, completely unconceited and more than happy to help me with whatever. Toronto really reminded me why I love this project and why OpenBSD will continue to succeed in the years to come.