We have been working for almost two years now on the C.H.I.P platform from Nextthing Co.. One of the characteristics of this platform is that it provides an expansion headers, which allows to connect expansion boards also called DIPs in the CHIP community.
In a manner similar to what is done for the BeagleBone capes, it quickly became clear that we should be using Device Tree overlays to describe the hardware available on those expansion boards. Thanks to the feedback from the Beagleboard community (especially David Anders, Pantelis Antoniou and Matt Porter), we designed a very nice mechanism for run-time detection of the DIPs connected to the platform, based on an EEPROM available in each DIP and connected through the 1-wire bus. This EEPROM allows the system running on the CHIP to detect which DIPs are connected to the system at boot time. Our engineer Antoine Ténart worked on a prototype Linux driver to detect the connected DIPs and load the associated Device Tree overlay. Antoine’s work was even presented at the Embedded Linux Conference, in April 2016: one can see the slides and video of Antoine’s talk.
However, it turned out that this Linux driver had a few limitations. Because the driver relies on Device Tree overlays stored as files in the root filesystem, such overlays can only be loaded fairly late in the boot process. This wasn’t working very well with storage devices or for DRM that doesn’t allow hotplug of some components. Therefore, this solution wasn’t working well for the display-related DIPs provided for the CHIP: the VGA and HDMI DIP.
The answer to that was to apply those Device Tree overlays earlier, in the bootloader, so that Linux wouldn’t have to deal with them. Since we’re using U-Boot on the CHIP, we made a first implementation that we submitted back in April. The review process took its place, it was eventually merged and appeared in U-Boot 2016.09.
List of relevant commits in U-Boot:
- tests: Introduce DT overlay tests
- cmd: fdt: add fdt overlay application subcommand
- libfdt: Add overlay application function
- libfdt: Add fdt_setprop_inplace_namelen_partial
- libfdt: Add fdt_getprop_namelen_w
- libfdt: Add fdt_path_offset_namelen
- libfdt: Fix separator spelling
- libfdt: Add max phandle retrieval function
- libfdt: Add iterator over properties
- libfdt: Add new headers and defines
However, the U-Boot community also requested that the changes should also be merged in the upstream libfdt, which is hosted as part of dtc, the device tree compiler.
Following this suggestion, Bootlin engineer Maxime Ripard has been working on merging those changes in the upstream libfdt. He sent a number of iterations, which received very good feedback from dtc maintainer David Gibson. And it finally came to a conclusion early October, when David merged the seventh iteration of those patches in the dtc repository. It should therefore hopefully be part of the next dtc/libfdt release.
List of relevant commits in the Device Tree compiler:
- tests: overlay: Rename the device tree blobs to be more explicit
- tests: overlay: Add test suffix to the compiled blobs
- libfdt: Add fdt_overlay_apply to the exported symbols
- fdt: strerr: Remove spurious BADOVERLAY
- tests: overlay: Move back the bad fixup tests
- libfdt: overlay: Fix symbols and fixups nodes condition
- libfdt: overlay: Report a bad overlay for mismatching local fixups
- libfdt: Add BADPHANDLE error string
- tests: Add tests cases for the overlay code
- libfdt: Add overlay application function
- libfdt: Extend the reach of FDT_ERR_BADPHANDLE
- libfdt: Add new errors for the overlay code
- libfdt: Add fdt_setprop_inplace_namelen_partial
- libfdt: Add fdt_getprop_namelen_w
- libfdt: Add max phandle retrieval function
- libfdt: Add iterator over properties
Since the libfdt is used by a number of other projects (like Barebox, or even Linux itself), all of them will gain the ability to apply device tree overlays when they will upgrade their version. People from the BeagleBone and the Raspberry Pi communities have already expressed interest in using this work, so hopefully, this will turn into something that will be available on all the major ARM platforms.