This page is meant to collect and organize information about Devicetree support for EOMA68.


  • A single operating system running on an EOMA68 CPU card needs to support many different EOMA68 housings, and a housing needs to be supported by many different CPU cards. Thus, the devicetree description of the CPU card and the devicetree description of the housing must be decoupled. A housing's devicetree cannot refer to the specific internal hardware (e.g. GPIO controller) of a CPU card. A housing's devicetree may only refer to an abstract EOMA68 connector.
  • The OS running on a CPU card must be able to automatically extend its devicetree according to the information it finds in a housing's EEPROM.

Prior work

  • [PATCH v5 0/4] OF phandle nexus support + GPIO nexus: Stephen Boyd's work on devicetree connectors. 96boards have the same combinatorial problem as EOMA68: Many different main boards must work with many different expansion boards.
  • Capemgr: A mechanism for loading devicetree overlays, developed for the BeagleBone. A BeagleBone Cape has an I2C EEPROM containing the cape's name (or model number); the OS loads the right .dtbo file from /lib/firmware/, based on the name.
  • Devicetree overlays are also supported in mainline Linux.


  • A devicetree overlay describing a housing may exceed the size of the EEPROM. Thus it makes sense to only store the housing's model number.