Contributed by Peter N. M. Hansteen on from the all up in arms about ARM dept.
The Toronto hackathon was a complete success and went off without a hitch! I did not get as much done as I had hoped, but definitely made up for it in other ways. It was my first hackathon and I was pretty nervous, but that subsided quickly and in the end turned out to be one of the best weeks I've ever had.
I spent most of my time working on ARM-related things, both on the armv7 (32-bit) platform and the newer arm64 platform. The arm64 cross-compilation toolchain build was broken, bombing out when trying to build vestigial makedep targets which were recently obviated. drahn@ and I both individually discovered this, and ended up writing similar patches coincidentally at the same time. I was beaten by just a few minutes, however :)
Next on the list was fixing the sximmc driver (a "disk" driver supporting the external SD card slot onboard the pine64, its only nonvolatile storage medium) which I spent altogether too much time on, building debug kernels and dumping registers, trying to trace the source of the problem. It ended up being a device tree issue; an incorrect DTB file on the bootloader partition contained bogus pinctl values causing the FDT framework to wire up a completely functional driver such that it could read but not write.
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.
Thanks for the report and the great work, Ian!
(Comments are closed)