blob: e2003f213a63bb69c5babc3522b6932b08dcda21 [file] [log] [blame]
Julius Wernera7843f02019-04-18 17:45:24 -07001Trusted Firmware binary repository
2==================================
3
4.. section-numbering::
5 :suffix: .
6
7.. contents::
8
9This repository hosts redistributable binary components that are needed with
10certain platform ports of trustedfirmware.org projects. All contributions to
11this repository must follow the rules and process laid out below as well as
12individual contribution guidelines of the respective project. License terms for
13individual binaries are described in the accompanying ``release-notes.rst``.
14
15Scope
16-----
17
18This repository is intended for cases where it's not possible to fully
19open-source a trustedfirmware.org project platform port. Binary components
20should be as minimal as possible, augmenting the more significant, open-source
21part of the platform port. Binary components that contain all meaningful
22functionality of a platform port and are merely linked into a boilerplate shell
23of open-source code will not be accepted.
24
25The trustedfirmware.org Technical Steering Committee or Governing Board will
26decide whether to host binary components in this repository on a case by case
27basis. Applications for inclusion can be sent to tsc@lists.trustedfirmware.org.
28
29Binary components must always be associated with a specific platform port. No
30generic code (i.e. any code outside the ``plat/<vendor>`` directory) may depend
31on a binary component.
32
33License
34-------
35
36All binary components must be accompanied by a distribution license. The license
37should:
38
39#. be irrevocable
40
41#. be royalty-free
42
43#. grant usage rights for both copyright and patents covering the binary
44
45#. allow unlimited redistribution under the same terms
46
47#. not restrict the ability to publish test results from the platform port
48
49To simplify legal review and avoid potential concerns, we recommend that the
50license should be as short and simple as possible. Special terms should be
51limited to what is absolutely necessary. The `Permissive Binary License`_
52adapted from the Arm Mbed project is a good example of a license that fulfills
53these requirements, and contributors are welcome to reuse it for their binaries.
54Reusing an already accepted license may greatly speed up and simplify the
55acceptance process for a new binary.
56
57When a binary is including third-party code (including open-source code) that is
58covered by separate license terms, all those licenses must be compatible with
59the distribution license.
60
61Notices
62-------
63
64All license and copyright notices covering the binary (including for linked
65third-party components) must be listed or linked to in the release notes. For
66licenses that are included in the `SPDX license list`_, please link to the
67appropriate SPDX license page rather than uploading a copy of the license to the
68binary repository.
69
70Release Notes
71-------------
72
73All binary components must be clearly versioned and accompanied by a release
74notes document that lists the following (updated for each version):
75
76#. version
77
78#. release date
79
80#. distribution license
81
82#. full list of license and copyright notices for (all parts of) the binary
83 (can be put into a separate file and linked from release notes if desired)
84
85#. supported silicon
86
87#. changes since the last version
88
89#. errata, known issues
90
91#. commit hash of the open-source trustedfirmware.org project it was tested with
92
93See the `example release notes`_ for suggestions on how to format these notes.
94
95Support
96-------
97
98As interfaces in open-source trustedfirmware.org projects change and get
99deprecated, it may not be possible to keep a platform port functional without
100updating the binary components it depends on. Contributors of binary components
101are expected to maintain them together with their platform ports and release
102updates as necessary. A binary component that no longer works with current
103builds of the open-source project and is not being kept up to date may be
104removed. Likewise, new binary component updates need to be tested with the
105latest version of the open-source platform port (and the latter needs to be
106updated if necessary) before they can be accepted.
107
108Directory Structure
109-------------------
110
111This repository contains binaries, license files and release notes. Release
112notes must always be placed in the same directory as the binary file(s) they
113apply to and should be called ``release-notes.rst``. Directories should be
114scoped by vendor and platform if necessary (e.g. a binary pertaining to a single
115platform should be placed under ``vendorname/platformname`` whereas a binary
116that can support multiple SoCs of a vendor can be placed directly under
117``vendorname``). Vendor-specific licenses should be placed in the ``licenses/``
118subdirectory of a vendor directory and referenced from the ``release-notes.rst``
119files of the binaries they apply to.
120
121Example layout::
122
123 - readme.rst
124 - licenses/
125 - permissive-binary-license.txt
126 - vendorA/
127 - licenses/
128 - vendor-specific-license.txt
129 - commonBinaryX/
130 - fileA.bin
131 - fileB.hex
132 - release-notes.rst
133 - platformA1/
134 - fileC.bin
135 - release-notes.rst
136 - platformA2
137 - binaryY/
138 - fileD.bin
139 - release-notes.rst
140 - binaryZ/
141 - fileE.elf
142 - fileF.bin
143 - release-notes.rst
144
145.. _Permissive Binary License: licenses/permissive-binary-license.txt
146.. _SPDX license list: https://spdx.org/licenses/
147.. _example release notes: example-release-notes.rst