96Boards Compliance

96Boards Compliance is designed to ensure a level of hardware and software functionality and quality for the 96Boards Community Board program.

The following Compliance topics are covered in this document:

  1. Availability of Documentation
  2. Binary Licensing
  3. Hardware Compliance
  4. Software Compliance
  5. Functional and Stress Testing
  6. Compliance Report
  7. Compliance Services

Compliance is tested against the following:

1. Availability of Documentation

It is recommended that all documentation required under the 96Boards program for the board and SoC be freely available from the 96Boards website. Any documentation that cannot be provided from the 96Boards website shall be available from a vendor or other public website that can be linked to from the 96Boards website.

  • Board schematics shall be available under CC BY 4.0 licence on the 96Boards.org site
  • It is not required that board layout or manufacturing data documents be made available.  This is a board vendor decision.
  • A Board reference manual shall be available on the 96Boards.org site
    • This shall include information on hardware and software interfaces to enable the maker community and developers of bootloaders, kernels and OS distributions.
  • An SoC technical reference manual shall be available
    • This shall include sufficient information for developers to be able to create board drivers and software interfaces for the supported SoC features.

2. Binary Licensing

96Boards recognizes the present industry reality that it is generally not possible to provide all software on a community board as open source code. A goal of the 96Boards program is to encourage vendors and the community to move towards making more software fully open source.

For any software provided in binary form:

  • The vendor or SoC provider shall provide a binary distribution license to Linaro/96Boards to allow those binaries to be redistributed from the 96Boards websites.
  • The vendor or SoC provider shall provide a binary distribution license allowing the board manufacturer to ship all necessary binaries.
  • It is acceptable to require the end user to accept an EULA prior to first use of the board.

3. Hardware Compliance

96Boards Goals

The 96Boards program requires board vendors to publish full schematics. However, due to the cost of high performance board development, vendors are not required to provide full manufacturing information. Nevertheless, we encourage vendors to consider providing full open source hardware solutions, including full board manufacturing information.

Hardware compliance testing shall include (but is not limited to):

  • Review of schematics
  • Verification of conformance to physical footprint and component dimensions
  • Conformance to 96Boards specification minimum required hardware feature set
  • Conformance to 96Boards expansion bus functionality
    • Low speed connector
    • High speed connector

4. Software Compliance

96Boards Goals

The 96Boards program has requirements summarized below for a 96Boards branded product supported on the 96Boards.org website. We encourage and want vendors to go further and benefit from more complete open source support. Specifically we would like to see:

  • Full upstream support for 96Boards products BSP software
  • Product quality reference open source software for 96Boards products
  • Full open source stack from bootloader to distribution
  • Minimal or, even better, no binary blobs

Software compliance testing shall include (but is not limited to):

  • Review of supplied software build and functionality
  • Build of supplied software from documentation and source code


Software Compliance Requirements

  • All open source software used shall comply with its respective open source license(s)
  • A software method shall be supplied to allow the board to be recovered from a “bricked” condition.

While open source implementations are preferred, the following software will be accepted as binary blobs if necessary:

  • Power management or other modules that execute on the SoC or board (PSCI, MCU or system control block firmware for example)
  • Firmware and/or user space libraries for:
    • GPU
    • Multimedia accelerator
    • DSP/coprocessor
    • Camera ISP
    • Baseband processor
    • Bluetooth and WiFi firmware

Note that Linux kernel modules must not be provided as binary firmware blobs.
The GPLv2 licence prohibits this.

  • It is strongly recommended one open source bootloader to be provided for the board that executes immediately after the internal SoC startup code. The source for this bootloader should be available from a publicly accessible site or integrated into the bootloader trees onhttps://github.com/96boards
  • Fastboot protocol support shall be provided for all Consumer Edition boards
  • It is strongly recommended that vendors of an ARMv8 board provide a port of the ARM Trusted Firmware (ATF) and PSCI reference implementations, and a port of the Tianocore EDK2 UEFI reference implementation.
  • It shall be possible to replace or update the bootloader.
  • It shall be possible to recover from a “bricked” board (for example as a result of use of a user built bootloader) without specialized additional hardware. Typically this will be via USB/fastboot, an SD card or a UART interface.

It is strongly recommended that a 96Boards product achieves upstream kernel software support as defined below:

  • Level 1 – boot from upstream mainline kernel to a UART or USB console, or
  • Level 2 – boot from upstream kernel with full board functionality
    Hardware accelerators such as GPUs may be disabled, but the relevant function should operate – for example a frame buffer for graphics output, or
  • Level 3 – boot from upstream kernel with full board functionality
    Hardware accelerators such as GPUs are enabled with binary user space libraries, or
  • Level 4 – boot from upstream kernel with full board functionality with all hardware specific code (including any required user space libraries) available as open source


A 96Boards product shall support at least one of the following kernels:

  • An unmodified kernel.org mainline, stable or longterm (latest two releases) kernel.
    Note: Upstream mainline support is a 96Boards program goal
  • A Linaro-supported kernel with additional published patches against a kernel.org mainline, stable or longterm (latest two releases) kernel
  • A Linaro-supported kernel with additional published patches against an AOSP release kernel (latest two letter releases) or the latest AOSP current kernel
  • A vendor-supported kernel using any of the above kernel versions
  • User space libraries for GPU hardware acceleration for the supported distribution(s) shall be provided
  • It is recommended that a fully open source graphics stack that the community can freely rebuild be made available

A 96Boards product shall provide at least one of the following distributions

  • Debian
  • Ubuntu
  • Fedora
  • AOSP
  • A Linaro or vendor-supported Linux build using the Yocto Project tools or OpenEmbedded

Any distribution requirements should be met, and typically we would expect all relevant board functionality to be supported – for example on the 96Boards Consumer Edition:

  • Boot to Graphical UI
  • Networking using all onboard interfaces and USB ethernet interfaces
  • Graphics acceleration using SoC GPU
  • Software power shutdown and reboot options
  • Audio playback support for AV media files via A2DP Bluetooth and display audio
  • Video playback support for video media files
  • Appropriate activity LEDs (e.g. Bluetooth, WiFi)
  • Storage on eMMC (if fitted) and microSD
  • Standard set of Distribution end user applications

5. Functional and Stress Testing

Linaro will provide open source self-certification test suite software for prospective 96Boards vendors. Currently this software is in development. Linaro will itself carry out functional and stress testing for 96Boards products until the self-certification software test suites are available.

This certification process will include:

  1. Questionnaire covering the functionality and requirements outlined in this document
  2. Functional test software for the mandatory 96Boards hardware functionality
  3. Instructions and test files for running 24 hour AOSP monkey stress test
  4. Instructions and test files for running 24 hour Linaro 96Boards Linux stress test
  5. Instructions on submitting a compliance report

6. Compliance Report

Linaro will review the self-certification results for a submitted 96Boards product. At its sole discretion Linaro may request board samples for further testing. Once a compliance report has been approved the vendor may use the 96Boards branding and logo according to published terms and conditions, and the vendor product will be added to the 96Boards website(s).

7. Compliance Services

It is strongly recommended that vendors seeking 96Boards compliance discuss their designs and requirements with Linaro during the design phase. It is much more cost effective to fix potential issues during design than to have to redesign or rework a product if it does not meet the compliance testing requirements.
Please contact 96boards@linaro.org for further information.

Issue 1.0 / Date May 27, 2015