| /trusted-firmware-a-latest/lib/zlib/ |
| D | inffast.c | 52 z_const unsigned char FAR *in; /* local strm->next_in */ in inflate_fast() local
79 in = strm->next_in; in inflate_fast()
80 last = in + (strm->avail_in - 5); in inflate_fast()
102 hold += (unsigned long)(*in++) << bits; in inflate_fast()
104 hold += (unsigned long)(*in++) << bits; in inflate_fast()
124 hold += (unsigned long)(*in++) << bits; in inflate_fast()
133 hold += (unsigned long)(*in++) << bits; in inflate_fast()
135 hold += (unsigned long)(*in++) << bits; in inflate_fast()
148 hold += (unsigned long)(*in++) << bits; in inflate_fast()
151 hold += (unsigned long)(*in++) << bits; in inflate_fast()
[all …]
|
| /trusted-firmware-a-latest/docs/perf/ |
| D | psci-performance-juno.rst | 5 operations in the Trusted Firmware-A Power State Coordination Interface (PSCI)
6 implementation, using the in-built Performance Measurement Framework (PMF) and
75 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
94 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
113 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
132 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
154 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
173 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
192 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in serial (v2.9)
210 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in serial (v2.10)
[all …]
|
| D | psci-performance-instr.rst | 22 place instrumentation points at logical locations in code for tracing purposes.
30 This is reserved a unique ID, name, and space in memory by the PMF. The
44 entry count. Residency time is the total time spent in a particular power
53 :param target_cpu: Contains copy of affinity fields in the MPIDR register
58 parameter described for CPU_SUSPEND in section 5.4.2.
60 :returns: Time spent in ``power_state``, in microseconds, by ``target_cpu``
61 and the highest level expressed in ``power_state``.
69 :returns: Number of times the state expressed in ``power_state`` has been
70 used by ``target_cpu`` and the highest level expressed in
86 restricted to PSCI, it is used primarily in TF-A to quantify the total time
[all …]
|
| D | psci-performance-methodology.rst | 5 operations in the Trusted Firmware-A Power State Coordination Interface (PSCI)
6 implementation, using the in-built Performance Measurement Framework (PMF) and
14 was used because the results in the debug build became skewed; the console
15 output prevented some of the tests from executing in parallel.
22 then initiates the test on all CPUs in parallel.
24 - **Sequential Tests** This type of test powers on each non-lead CPU in
29 Note there is very little variance observed in the values given (~1us), although
30 the values for each CPU are sometimes interchanged, depending on the order in
32 executing the tests sequentially in a single boot or rebooting between tests.
|
| D | psci-performance-n1sdp.rst | 72 #. Then, add TFTF as the Non-Secure workload in the FIP image:
95 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
110 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
125 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
140 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
158 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
175 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
190 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in serial (v2.9)
206 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in serial (v2.10)
223 ``CPU_OFF`` on all non-lead CPUs in sequence then, ``CPU_SUSPEND`` on the lead
[all …]
|
| /trusted-firmware-a-latest/docs/plat/arm/ |
| D | arm-build-options.rst | 7 - ``ARM_BL31_IN_DRAM``: Boolean option to select loading of BL31 in TZC secured
8 DRAM. By default, BL31 is in the secure SRAM. Set this flag to 1 to load
9 BL31 in TZC secured DRAM. If TSP is present, then setting this option also
20 By default, Arm platforms use a watchdog to trigger a system reset in case
22 could not be loaded or authenticated). The watchdog is enabled in the early
23 platform setup hook at BL1 and disabled in the BL1 prepare exit hook. The
33 to the location of a device tree blob (DTB) already loaded in memory. The
39 is set, the functions which deal with MPIDR assume that the ``MT`` bit in
40 MPIDR is set and access the bit-fields in MPIDR accordingly. Default value of
44 for the construction of composite state-ID in the power-state parameter.
[all …]
|
| /trusted-firmware-a-latest/docs/plat/ |
| D | rpi3.rst | 12 the Foundation can be compiled for AArch64 by following the steps in
29 depending on a few files on the SD card. We only care about the cases in which
30 the cores boot in AArch64 mode.
35 SD card, it will load it and execute in EL2 in AArch64. Basically, it executes
39 **0x0** (instead of the default stub) and execute it in EL3 in AArch64. All
42 This means that we can use the default AArch32 kernel provided in the official
44 anything else we need is in ``armstub8.bin``. This way we can forget about the
49 that we need to make the secondary cores work in the way the kernel expects, as
50 explained in `Secondary cores`_. In practice, a small bootstrap is needed
53 To get the most out of a AArch32 kernel, we want to boot it in Hypervisor mode
[all …]
|
| D | xilinx-zynqmp.rst | 52 above memory range will NOT be reserved in device tree.
54 To reserve the above memory range in device tree, the device tree base address
61 is not set in the code and to use this default address, user still needs to
68 The DDR address must be reserved in the DTB by the user, either by manually
69 adding the reserved memory node, in the device tree, with the required address
82 When FSBL runs on RPU and TF-A is to be placed in DDR address range,
86 For this use case, with the minimum base address in DDR for TF-A,
95 The stack size in TF-A for ZynqMP platform is configurable.
96 The custom package can define the desired stack size as per the requirement in
107 structure is passed in the ``PMU_GLOBAL.GLOBAL_GEN_STORAGE6`` register. The
[all …]
|
| D | hikey960.rst | 6 More information are listed in `link`_.
33 Make all the repositories in the same ${BUILD\_PATH}.
43 - Create the symbol link to OpenPlatformPkg in edk2.
68 *Make sure that you're using the sgdisk in the l-loader directory.*
83 that fails to display in minicom.
95 Append one line for serial-over-USB in *#ser2net.conf*
116 Boot UEFI in recovery mode
119 - Fetch that are used in recovery mode. The code location is in below.
153 - UEFI running in recovery mode.
154 …When prompt '.' is displayed on console, press hotkey 'f' in keyboard. Then Android fastboot app i…
[all …]
|
| D | rpi4.rst | 5 Arm Cortex-A72 cores. Also in contrast to previous Raspberry Pi versions this
29 ``config.txt``. You should have AArch64 code in the file loaded as the
33 Other options that should be set in ``config.txt`` to properly boot 64-bit
42 The BL31 code will patch the provided device tree blob in memory to advertise
55 port, also it deviates quite a lot from the RPi3 port in many other ways.
57 two could be (more) unified in the future.
69 pointed to such code by finding a ``armstub=`` key in ``config.txt``, it will
70 load this file to the beginning of DRAM (address 0) and execute it in
74 setting them in ``config.txt``. If the GPU firmware finds a magic value in the
75 armstub image file, it will put those two load addresses in memory locations
[all …]
|
| /trusted-firmware-a-latest/docs/security_advisories/ |
| D | security-advisory-tfv-1.rst | 5 | Title | Malformed Firmware Update SMC can result in copy of |
28 known as recovery mode). This allows most FWU functionality to be implemented in
30 functionality in BL1. When cold boot reaches the EL3 Runtime Software (for
42 2. Platform code arranges for untrusted normal world FWU code to be executed in
43 the cold boot path, before BL31 starts. Untrusted in this sense means code
44 that is not in ROM or has not been authenticated or has otherwise been
50 The vulnerabilities consist of potential integer overflows in the input
58 Two of the vulnerabilities are in the function ``bl1_fwu_image_copy()`` in
84 INFO("BL1-FWU: Continuing image copy in blocks\n");
92 This code fragment is executed when the image copy operation is performed in
[all …]
|
| D | security-advisory-tfv-10.rst | 6 | | result in an out-of-bounds read. |
17 | | interfaces. Not exploitable in upstream TF-A code. |
31 | | in auth_nvctr()" |
40 This security advisory describes a vulnerability in the X.509 parser used to
41 parse boot certificates in TF-A trusted boot: it is possible for a crafted
45 platforms may be, if (and only if) the interfaces described below are used in a
46 different context than seen in upstream code. Details of such context is
47 described in the rest of this document.
62 The vulnerability lies in the following source file:
73 undefined on failure. In practice, this results in ``get_ext()`` continuing to
[all …]
|
| D | security-advisory-tfv-4.rst | 5 | Title | Malformed Firmware Update SMC can result in copy or |
6 | | authentication of unexpected data in secure memory in |
19 | Impact | Copy or authentication of unexpected data in the secure |
31 result in a value large enough to wrap around, which may lead to unpredictable
51 The buggy code has been present in ARM Trusted Firmware (TF) since `Pull Request
55 then, the ``check_uptr_overflow()`` macro was not used in AArch32 code.
57 The vulnerability resides in the BL1 FWU SMC handling code and it may be
62 - Platform code uses the Firmware Update (FWU) code provided in
68 overflows in the input validation checks while handling the
84 attacker. A very large 32-bit value, for example ``2^32 -1``, may result in the
[all …]
|
| /trusted-firmware-a-latest/docs/design/ |
| D | alt-boot-flows.rst | 13 configuration required to put the system in the expected state.
30 The system is left in the same state as when entering BL31 in the default boot
33 - Running in EL3;
48 - The EL3 payload may reside in non-volatile memory (NVM) and execute in
50 address in NVM through ``EL3_PAYLOAD_BASE`` when building TF-A.
52 - The EL3 payload needs to be loaded in volatile memory (e.g. DRAM) at
55 To help in the latter scenario, the ``SPIN_ON_BL1_EXIT=1`` build option can be
56 used. The infinite loop that it introduces in BL1 stops execution at the right
60 It is expected that this loading method will work in most cases, as a debugger
61 connection is usually available in a pre-production system. The user is free to
[all …]
|
| D | interrupt-framework-design.rst | 9 software (Secure interrupts) to EL3, when execution is in non-secure state
11 the interrupt to either software in EL3 or Secure-EL1 depending upon the
19 level in the normal world when the execution is in secure world at
21 knowledge of software executing in Secure-EL1/Secure-EL0. The choice of
23 ensures that non-secure software is able to execute in tandem with the
33 the exception level(s) it is handled in.
37 context. It is always handled in Secure-EL1.
41 current execution context. It is always handled in either Non-secure EL1
46 always handled in EL3.
48 The following constants define the various interrupt types in the framework
[all …]
|
| D | psci-pd-tree.rst | 9 populate a tree that describes the hierarchy of power domains in the
11 requires a change in the code.
14 in a data structure.
16 #. The generic PSCI code generates MPIDRs in order to populate the power domain
17 tree. It also uses an MPIDR to find a node in the tree. The assumption that
20 levels in the power domain tree to four.
33 Therefore, there is a need to define data structures that implement the tree in
41 Therefore, there is a need to implement the tree in a way which facilitates this
57 #. The first entry in the array specifies the number of power domains at the
58 highest power level implemented in the platform. This caters for platforms
[all …]
|
| D | trusted-board-boot.rst | 11 Arm DEN0006D. It should be used in conjunction with the
21 - A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
26 - The BL1 image, on the assumption that it resides in ROM so cannot be
29 The remaining components in the CoT are either certificates or boot loader
47 extension fields in the `X.509 v3`_ certificates.
59 secure world images (SCP_BL2, BL31 and BL32). The public part is stored in
60 one of the extension fields in the trusted world certificate.
65 non secure world image (BL33). The public part is stored in one of the
66 extension fields in the trusted world certificate.
72 in one of the extension fields in the corresponding key certificate.
[all …]
|
| D | reset-design.rst | 5 resets in Trusted Firmware-A (TF-A). It also describes how the platform
7 resulting in a simplified and more optimised boot flow.
9 This document should be used in conjunction with the :ref:`Firmware Design`
16 The TF-A reset code is implemented in BL1 by default. The following high-level
28 above is still relevant, as all these operations will occur in BL31 in
40 If the reset vector address (reflected in the reset vector base address register
43 detection can be skipped, resulting in the following boot flow:
65 applies. This results in the following boot flow:
82 This results in the following boot flow:
101 logic in the BL31 entry point to support this use case.
[all …]
|
| D | auth-framework.rst | 5 implemented in Trusted Firmware-A (TF-A). This framework fulfills the
8 #. It should be possible for a platform port to specify the Chain of Trust in
21 The framework has been designed following a modular approach illustrated in the
75 a root of trust and culminates in a single data image. The following diagram
76 illustrates how this maps to a CoT for the BL31 image described in the
119 The root of trust is usually a public key (ROTPK) that has been burnt in the
125 Images in a CoT are categorised as authentication and data images. An
133 For every image in a Chain of Trust, the following high level operations are
138 #. Identify the image and load it in the allocated memory.
145 be used to authenticate the next image in the CoT.
[all …]
|
| /trusted-firmware-a-latest/docs/components/ |
| D | romlib-design.rst | 4 This document provides an overview of the "library at ROM" implementation in
11 be placed in ROM. This reduces SRAM usage by utilising the available space in
13 are placed in ROM. The capabilities of the "library at ROM" are:
19 3. Platform-specific libraries can be placed in ROM.
30 placed in ROM. The index file is platform specific and its format is:
37 function -- Name of the function to be placed in library at ROM
40 It is also possible to insert reserved spaces in the list by using the keyword
47 The reserved spaces can be used to add more functions in the future without
48 affecting the order and location of functions already existing in the jump
65 The index file is used to create a jump table which is placed in ROM. Then, the
[all …]
|
| D | secure-partition-manager-mm.rst | 23 in the system, i.e. EL3 in Trusted Firmware-A (TF-A). The service requirements are
35 Placement of management and security functions with diverse requirements in a
43 A **Secure Partition** is a software execution environment instantiated in
47 resources. Essentially, it is a software sandbox in the Secure world that runs
51 - Memory and device regions in the system address map.
60 services in EL3 and instantiate the rest in a partition in S-EL0.
64 The following diagram illustrates the place of a Secure Partition in a typical
66 services to software components in the Non-secure world and other Secure
72 in the FIP. During boot, BL2 includes support to authenticate and load the
105 made in the current implementation of this software architecture. Subsequent
[all …]
|
| /trusted-firmware-a-latest/ |
| D | dco.txt | 17 (a) The contribution was created in whole or in part by me and I
19 indicated in the file; or
24 work with modifications, whether created in whole or in part
27 in the file; or
|
| /trusted-firmware-a-latest/lib/compiler-rt/ |
| D | LICENSE.TXT | 17 Copyright (c) 2009-2016 by the contributors listed in CREDITS.TXT
39 * Redistributions in binary form must reproduce the above copyright notice,
40 this list of conditions and the following disclaimers in the
58 Copyright (c) 2009-2015 by the contributors listed in CREDITS.TXT
62 in the Software without restriction, including without limitation the rights
67 The above copyright notice and this permission notice shall be included in
82 have its own individual LICENSE.TXT file in the directory in which it appears.
86 The disclaimer of warranty in the University of Illinois Open Source License
87 applies to all code in the LLVM Distribution, and nothing in any of the
|
| /trusted-firmware-a-latest/plat/arm/board/common/swd_rotpk/ |
| D | README | 2 root-of-trust key used in the CCA chain of trust.
4 * swd_rotprivk_rsa.pem is a 2K RSA private key in PEM format. It has been
13 openssl rsa -in arm_swd_rotprivk_rsa.pem -pubout -outform DER | \
|
| /trusted-firmware-a-latest/docs/plat/arm/juno/ |
| D | index.rst | 21 binaries in the ``SOFTWARE/`` directory with custom built TF-A binaries.
27 Firmware, obtain the additional required firmware, and pack it all together in
38 different one. Mixing instructions for different platforms may result in
43 match the uboot image packaged as BL33 in the corresponding fip file. It is
44 recommended to use the version that is packaged in the fip file using the
48 For the FVP, the kernel FDT is packaged in FIP during build and loaded
67 package included in the Linaro release:
77 The unpack operation will result in a set of binary images extracted to the
82 exist in the current directory. If that is the case, either delete those
123 - Build BL32 in AArch32.
[all …]
|
