Let’s talk about the cape manager in the 3.13 kernel tree.
The 3.8 kernel offers us solid cape manager support and device tree overlays. But, the USB support leaves a bit to be desired and SGX support isn’t quite there. The 3.13 kernel has rock-solid USB and offers SGX, but lacks the overlay and cape manager support. Since the lack of flexible, run-time cape support is a deal-breaker for most people, 3.8 has been the default choice of kernel for most BBB users.
I was curious as to what exactly was involved in porting the cape manager and device overlay support from 3.8 to 3.13. After all, this was a portion of the system that actually interacts with the cape hardware, making it of interest to both hardware and firmware developers. So, I began examining the code in the 3.8 and 3.13 kernel trees to determine where the major differences are and where the new features might be integrated into the 3.13 kernel.
I figured that the best place to begin was to construct function call graphs for the device tree driver (drivers/of) in the 3.8 and 3.13 kernels. The time spent looking through the code and performing a static analysis to construct the graphs was well spent, since it provided a pretty clear picture of where overlay support fits into the device tree code. While some interfaces and locks have changed between 3.8 and 3.13, I was able to reconcile these items without too much trouble. I also copied the dtc source verbatim from 3.8 to 3.13 to add support for “overlay” symbols in the .dtbo files, though a more elegant porting of that funtionality into the 3.13 code is the proper way to approach this.
The cape manager was a completely new driver in the 3.13 tree, so I began by copying it verbatim from the 3.8 tree (drivers/misc/cape). After the locks and interface differences were reconciled, I began to integrate it with the overlay support in the device tree and the changes in the i2c interfaces. One interesting item of note is the i2c EEPROM driver used by the capes (drivers/misc/eeprom/at24.c) needed to be augmented with a .command handler in the i2c_command struct of the driver so that the cape manager can properly query the cape EEPROMs.
So, what works and what doesn’t? For starters, the cape manager and device tree overlays work. Capes are detected and the proper .dtbo is loaded. Nodes are added into the device tree and drivers are started as expected. Beyond that, things are still a bit sticky. Changes in the main device tree binary blob require some changes, particularly because the 3.13 .dtb for the BBB has several features hard-coded in. These step on the dynamic loading of the same features via the cape manager.
If I plug in an LCD3 cape, the cape is detected, resolution is set properly, and I can see the Tux penguin framebuffer image at boot. But, the boot freezes immediately prior to the console login. I suspect this is a locking issue that I need to get sorted out. If I plug in an LCD4 cape, I see much the same thing (though the yellow parts of Tux’s bill and feet are blue, rather than yellow). If I plug in an LCD7 cape, I get a failure on setting the pinmuxing for it because it conflicts with an SPI pin set in the main .dtb.
The .dts files for these capes require very minor changes, such as changing the compatibility for the “panel” section from “tilcdc,panel” to “ti,tilcdc,panel”. The BBB .dtb uses 0-based indexing for the GPIO groups (groups 0-3) while all of the capes require 1-based indexing (groups 1-4). Rather than change all of the capes, I changed the indexing of the GPIO groups in the BBB .dtb instead.
For the HDMI cape, I can see the TILCDC driver and NXP TDA drivers starting in the dmesg log. But, this still needs some work because the i2c bus is reporting errors (most likely due to the HDMI audio support). An “fbset” will report that the video mode has been set, and /dev/fb0 exists, so most of the plumbing is hooked up and initializing.
While there are some driver issues to still sort out, and the .dts and .dtsi files need to be reworked with the cape manager in mind, but I think I’m on the right track. It will certainly be nice when cape management and firmware loading is working well with the other features of the 3.13 kernel.
/me bows.