Trusted Firmware binary repository

This repository hosts redistributable binary components that are needed with certain platform ports of trustedfirmware.org projects. All contributions to this repository must follow the rules and process laid out below as well as individual contribution guidelines of the respective project. License terms for individual binaries are described in the accompanying release-notes.rst.

1.   Scope

This repository is intended for cases where it's not possible to fully open-source a trustedfirmware.org project platform port. Binary components should be as minimal as possible, augmenting the more significant, open-source part of the platform port. Binary components that contain all meaningful functionality of a platform port and are merely linked into a boilerplate shell of open-source code will not be accepted.

The trustedfirmware.org Technical Steering Committee or Governing Board will decide whether to host binary components in this repository on a case by case basis. Applications for inclusion can be sent to tsc@lists.trustedfirmware.org.

Binary components must always be associated with a specific platform port. No generic code (i.e. any code outside the plat/<vendor> directory) may depend on a binary component.

2.   License

All binary components must be accompanied by a distribution license. The license should:

  1. be irrevocable
  2. be royalty-free
  3. grant usage rights for both copyright and patents covering the binary
  4. allow unlimited redistribution under the same terms
  5. not restrict the ability to publish test results from the platform port

To simplify legal review and avoid potential concerns, we recommend that the license should be as short and simple as possible. Special terms should be limited to what is absolutely necessary. The Permissive Binary License adapted from the Arm Mbed project is a good example of a license that fulfills these requirements, and contributors are welcome to reuse it for their binaries. Reusing an already accepted license may greatly speed up and simplify the acceptance process for a new binary.

When a binary is including third-party code (including open-source code) that is covered by separate license terms, all those licenses must be compatible with the distribution license.

3.   Notices

All license and copyright notices covering the binary (including for linked third-party components) must be listed or linked to in the release notes. For licenses that are included in the SPDX license list, please link to the appropriate SPDX license page rather than uploading a copy of the license to the binary repository.

4.   Release Notes

All binary components must be clearly versioned and accompanied by a release notes document that lists the following (updated for each version):

  1. version
  2. release date
  3. distribution license
  4. full list of license and copyright notices for (all parts of) the binary (can be put into a separate file and linked from release notes if desired)
  5. supported silicon
  6. changes since the last version
  7. errata, known issues
  8. commit hash of the open-source trustedfirmware.org project it was tested with

See the example release notes for suggestions on how to format these notes.

5.   Support

As interfaces in open-source trustedfirmware.org projects change and get deprecated, it may not be possible to keep a platform port functional without updating the binary components it depends on. Contributors of binary components are expected to maintain them together with their platform ports and release updates as necessary. A binary component that no longer works with current builds of the open-source project and is not being kept up to date may be removed. Likewise, new binary component updates need to be tested with the latest version of the open-source platform port (and the latter needs to be updated if necessary) before they can be accepted.

6.   Directory Structure

This repository contains binaries, license files and release notes. Release notes must always be placed in the same directory as the binary file(s) they apply to and should be called release-notes.rst. Directories should be scoped by vendor and platform if necessary (e.g. a binary pertaining to a single platform should be placed under vendorname/platformname whereas a binary that can support multiple SoCs of a vendor can be placed directly under vendorname). Vendor-specific licenses should be placed in the licenses/ subdirectory of a vendor directory and referenced from the release-notes.rst files of the binaries they apply to.

Example layout:

- readme.rst
- licenses/
  - permissive-binary-license.txt
- vendorA/
  - licenses/
    - vendor-specific-license.txt
  - commonBinaryX/
    - fileA.bin
    - fileB.hex
    - release-notes.rst
  - platformA1/
    - fileC.bin
    - release-notes.rst
  - platformA2
    - binaryY/
      - fileD.bin
      - release-notes.rst
    - binaryZ/
      - fileE.elf
      - fileF.bin
      - release-notes.rst