| /trusted-firmware-a-3.6.0-3.5.0/plat/brcm/board/stingray/src/ |
| D | scp_cmd.c | 25 uint32_t code; in scp_read_response() local
27 code = mmio_read_32(CRMU_MAIL_BOX0); in scp_read_response()
28 resp->completed = code & MCU_IPC_CMD_DONE_MASK; in scp_read_response()
29 resp->cmd = code & SCP_CMD_MASK; in scp_read_response()
30 resp->ret = (code & MCU_IPC_CMD_REPLY_MASK) >> MCU_IPC_CMD_REPLY_SHIFT; in scp_read_response()
|
| /trusted-firmware-a-3.6.0-3.5.0/lib/zlib/ |
| D | inflate.h | 110 code const FAR *lencode; /* starting table for length/literal codes */
111 code const FAR *distcode; /* starting table for distance codes */
119 code FAR *next; /* next available space in codes[] */
122 code codes[ENOUGH]; /* space for code tables */
|
| D | inffixed.h | 10 static const code lenfix[512] = {
87 static const code distfix[32] = {
|
| D | inftrees.h | 28 } code; typedef
61 unsigned codes, code FAR * FAR *table,
|
| /trusted-firmware-a-3.6.0-3.5.0/plat/brcm/board/common/ |
| D | brcm_mbedtls.c | 9 void tls_exit(int code) in tls_exit() argument
11 INFO("%s: 0x%x\n", __func__, code); in tls_exit()
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/process/ |
| D | code-review-guidelines.rst | 4 This document provides TF-A specific details about the project's code review
9 Why do we do code reviews?
12 The main goal of code reviews is to improve the code quality. By reviewing each
13 other's code, we can help catch issues that were missed by the author
19 community. People with more expertise in one area of the code base can
29 To ensure the code review gives the greatest possible benefit, participants in
39 code review helps everyone in the long run, as it creates a culture of
56 In the event that a code review takes longer than you would hope for, you
62 - If one code owner has become unresponsive, ask the other code owners for
65 - If there is only one code owner and they have become unresponsive, ask one
[all …]
|
| D | coding-style.rst | 4 The following sections outline the |TF-A| coding style for *C* code. The style
11 You will almost certainly find code in the |TF-A| repository that does not
12 follow the style. The intent is for all code to do so eventually.
17 The source code must use the **UTF-8** character encoding. Comments and
19 used for units) but code itself is still limited to ASCII characters.
91 .. code:: c
114 **slightly** where the readability of the code would otherwise be significantly
138 .. code:: c
150 .. code:: c
174 .. code:: c
[all …]
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/plat/ |
| D | hikey960.rst | 35 .. code:: shell
45 .. code:: shell
54 .. code:: shell
62 .. code:: shell
70 .. code:: shell
85 .. code:: shell
91 .. code:: shell
103 .. code:: shell
110 .. code:: shell
119 - Fetch that are used in recovery mode. The code location is in below.
[all …]
|
| D | ti-k3.rst | 28 .. code:: shell
34 .. code:: shell
40 .. code:: shell
47 .. code:: shell
55 .. code:: shell
|
| D | hikey.rst | 38 .. code:: shell
49 .. code:: shell
59 .. code:: shell
67 .. code:: shell
74 .. code:: shell
87 .. code:: shell
93 .. code:: shell
100 .. code:: shell
106 .. code:: shell
113 .. code:: shell
[all …]
|
| D | synquacer.rst | 40 .. code:: shell
48 .. code:: shell
53 - Run the following commands to clone the source code:
55 .. code:: shell
65 .. code:: shell
77 .. code:: shell
107 .. code:: shell
|
| D | stm32mp1.rst | 6 It is an Armv7-A platform, using dedicated code from TF-A.
49 The STM32MP1 resets in the ROM code of the Cortex-A7.
52 The ROM code boot sequence loads the TF-A binary image from boot device
56 for ROM code is able to load this image.
62 Only BL2 (with STM32 header) is loaded by ROM code. The other binaries are
110 ROM code -> BL2(compiled with RESET_TO_BL2) -> BL32(SP_min)-> BL33(U-Boot)
114 ROM code -> BL2 (compiled with RESET_TO_BL2) -> OP-TEE -> BL33 (U-Boot)
161 .. code:: bash
170 .. code:: bash
182 .. code:: bash
[all …]
|
| D | nvidia-tegra.rst | 9 executing both 64-bit AArch64 code, and 32-bit AArch32 code. The Carmel
24 support ARMv8, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
49 (ILP) inherent in the code, Denver extracts the ILP once via software
62 support Armv8-A, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
71 - plat/nvidia/tegra/common - Common code for all Tegra SoCs
72 - plat/nvidia/tegra/soc/txxx - Chip specific code
84 This allows other Trusted OS vendors to use the upstream code and include
106 .. code:: shell
115 The Tegra platform code expects a pointer to the following platform specific
|
| /trusted-firmware-a-3.6.0-3.5.0/plat/rpi/rpi3/ |
| D | rpi_mbox_board.c | 31 req->code = RPI3_MBOX_PROCESS_REQUEST; in rpi3_vc_hardware_get_board_revision()
42 if (req->code != RPI3_MBOX_REQUEST_SUCCESSFUL) { in rpi3_vc_hardware_get_board_revision()
43 ERROR("rpi3: mbox: Code = 0x%08x\n", req->code); in rpi3_vc_hardware_get_board_revision()
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/security_advisories/ |
| D | security-advisory-tfv-4.rst | 17 | Affected | firmware update code executing before BL31 |
34 The macro code is at line 52, referring to the version of the code as of `commit
37 .. code:: c
48 range. Therefore, any AArch32 code relying on this macro to detect such integer
51 The buggy code has been present in ARM Trusted Firmware (TF) since `Pull Request
52 #678`_ was merged (on 18 August 2016). However, the upstream code was not
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
60 - Platform code uses TF BL1 with the ``TRUSTED_BOARD_BOOT`` build option.
62 - Platform code uses the Firmware Update (FWU) code provided in
[all …]
|
| D | security-advisory-tfv-1.rst | 16 | Affected | firmware update code executing before BL31 |
19 | | reported by BL1 platform code |
26 Generic Trusted Firmware (TF) BL1 code contains an SMC interface that is briefly
35 The BL1 FWU SMC handling code, currently only supported on AArch64, contains
39 1. Platform code uses TF BL1 with the ``TRUSTED_BOARD_BOOT`` build option
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
47 3. Platform code copies the insecure pattern described below from the ARM
60 of the code:
64 .. code:: c
[all …]
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/ |
| D | license.rst | 15 - Redistributions of source code must retain the above copyright notice, this
53 This project contains code from other projects as listed below. The original
56 - The libc source code is derived from `FreeBSD`_ and `SCC`_. FreeBSD uses
57 various BSD licenses, including BSD-3-Clause and BSD-2-Clause. The SCC code
60 - The libfdt source code is disjunctively dual licensed
62 the BSD-2-Clause license. Any contributions to this code must be made under
65 - The LLVM compiler-rt source code is disjunctively dual licensed
69 contributions to this code must be made under the terms of both licenses.
71 - The zlib source code is licensed under the Zlib license, which is a
74 - Some STMicroelectronics platform source code is disjunctively dual licensed
[all …]
|
| /trusted-firmware-a-3.6.0-3.5.0/plat/allwinner/sun50i_a64/ |
| D | sunxi_power.c | 226 uint32_t *code = arisc_core_off; in sunxi_cpu_power_off_self() local
238 code[0] = (code[0] & ~0xffff) | BIT_32(core); in sunxi_cpu_power_off_self()
239 clean_dcache_range((uintptr_t)code, sizeof(arisc_core_off)); in sunxi_cpu_power_off_self()
246 mmio_write_32(arisc_reset_vec, ((uintptr_t)code - arisc_reset_vec) / 4); in sunxi_cpu_power_off_self()
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/plat/nxp/ |
| D | nxp-ls-fuse-prov.rst | 39 .. code:: shell
53 .. code:: shell
66 .. code:: shell
79 .. code:: shell
95 .. code:: shell
106 .. code:: shell
129 .. code:: shell
152 .. code:: shell
159 .. code:: shell
172 .. code:: shell
[all …]
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/getting_started/ |
| D | tools-build.rst | 30 .. code:: shell
36 .. code:: shell
52 .. code:: shell
58 .. code:: shell
73 .. code:: shell
82 .. code:: shell
88 .. code:: shell
97 .. code:: shell
104 .. code:: shell
127 .. code:: shell
[all …]
|
| D | initial-build.rst | 9 .. code:: shell
15 .. code:: shell
30 .. code:: shell
46 .. code:: shell
54 .. code:: shell
60 .. code:: shell
104 .. code:: shell
112 .. code:: shell
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/plat/arm/fvp-ve/ |
| D | index.rst | 34 .. code:: shell
40 .. code:: shell
46 .. code:: shell
55 .. code:: shell
63 .. code:: shell
75 .. code:: shell
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/design/ |
| D | reset-design.rst | 6 integrator can tailor this code to the system configuration to some extent,
10 document which provides greater implementation details around the reset code,
13 General reset code flow
16 The TF-A reset code is implemented in BL1 by default. The following high-level
19 |Default reset code flow|
45 |Reset code flow with programmable reset address|
58 Therefore, the cold boot code has to arbitrate access to hardware resources
67 |Reset code flow with single CPU released out of reset|
85 |Reset code flow with programmable reset address and single CPU released out of reset|
108 images might be done by the Trusted Boot Firmware or by platform code in BL31.
[all …]
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/resources/diagrams/plantuml/ |
| D | fconf_bl2_populate.puml | 3 box "BL2 common code"
8 box "platform common code"
14 box "arm platform code" #LightBlue
|
| /trusted-firmware-a-3.6.0-3.5.0/docs/plat/arm/arm_fpga/ |
| D | index.rst | 8 Some interconnect setup is done internally by the platform, so the TF-A code
33 churn. With this option, the code will fall back to some basic CPU support
34 code (only architectural system registers, and no errata).
46 The DT gets amended by the code, to potentially add a command line and
66 .. code:: shell
74 .. code:: shell
81 After building TF-A, the actual TF-A code will be located in ``bl31.bin`` in
84 as some simple ROM trampoline code (required by the Arm FPGA boot flow) and
91 .. code:: shell
|
