Home
last modified time | relevance | path

Searched refs:in (Results 1 – 25 of 246) sorted by relevance

12345678910

/rk3399_ARM-atf/drivers/gpio/
H A Dgpio_spi.c72 static void xfer(unsigned int bytes, const void *out, void *in, int cpol, int cpha) in xfer() argument
97 if (in != NULL) { in xfer()
98 *(uint8_t *)in++ = in_byte; in xfer()
104 const uint8_t *out, uint8_t *in) in gpio_spi_xfer() argument
106 if ((out == NULL) && (in == NULL)) { in gpio_spi_xfer()
112 xfer(bytes, out, in, 0, 0); in gpio_spi_xfer()
115 xfer(bytes, out, in, 0, 1); in gpio_spi_xfer()
118 xfer(bytes, out, in, 1, 0); in gpio_spi_xfer()
121 xfer(bytes, out, in, 1, 1); in gpio_spi_xfer()
/rk3399_ARM-atf/lib/zlib/
H A Dinffast.c52 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 …]
/rk3399_ARM-atf/docs/perf/
H A Dpsci-performance-juno.rst5 operations in the Trusted Firmware-A Power State Coordination Interface (PSCI)
6 implementation, using the in-built Performance Measurement Framework (PMF) and
41 configuration in CI.
49 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
68 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
87 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
106 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
128 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
147 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
166 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in serial (v2.14)
[all …]
H A Dpsci-performance-n1sdp.rst16 configuration in CI.
23 .. table:: ``CPU_SUSPEND`` latencies (ns) to deepest power level in parallel (v2.14)
37 .. table:: ``CPU_SUSPEND`` latencies (ns) to deepest power level in parallel (v2.13)
51 .. table:: ``CPU_SUSPEND`` latencies (ns) to deepest power level in serial (v2.14)
65 .. table:: ``CPU_SUSPEND`` latencies (ns) to deepest power level in serial (v2.13)
82 .. table:: ``CPU_SUSPEND`` latencies (ns) to power level 0 in parallel (v2.14)
96 .. table:: ``CPU_SUSPEND`` latencies (ns) to power level 0 in parallel (v2.13)
110 .. table:: ``CPU_SUSPEND`` latencies (ns) to power level 0 in serial (v2.14)
124 .. table:: ``CPU_SUSPEND`` latencies (ns) to power level 0 in serial (v2.13)
141 ``CPU_OFF`` on all non-lead CPUs in sequence then, ``CPU_SUSPEND`` on the lead
[all …]
H A Dpsci-performance-instr.rst22 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 …]
H A Dpsci-performance-methodology.rst5 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.
/rk3399_ARM-atf/docs/
H A Darchitecture_features.rst5 almost every year listed in `Feature_description`_. While most of these features require no control
10 in TF-A.
16 versions (8.X, 9.X) to which they apply can be found in `Feature_description`_
25 * ``WIP``: Implementation in progress;
456 FEAT_xxx in the architecure manual. Some of those features require setup code in
459 Most of the feature flags defined in the TF-A build system are allowed to take
466 ENABLE_FEAT_* = 2: Feature support is compiled in, but only enabled if the
477 If the feature flag is set to 2, support for the feature will be compiled in,
480 multiple different CPUs, or where the CPU is configured at runtime, like in
495 in this case a fictional ``FEAT_ABC``. This is not an exhaustive list on how to
[all …]
/rk3399_ARM-atf/docs/plat/arm/
H A Darm-build-options.rst7 - ``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
25 By default, Arm platforms use a watchdog to trigger a system reset in case
27 could not be loaded or authenticated). The watchdog is enabled in the early
28 platform setup hook at BL1 and disabled in the BL1 prepare exit hook. The
44 is set, the functions which deal with MPIDR assume that the ``MT`` bit in
45 MPIDR is set and access the bit-fields in MPIDR accordingly. Default value of
48 - ``ARM_PLAT_PROVIDES_BL2_MEM_PARAMS``: This flag can be overriden to 1 in the Arm
51 in ``plat/arm/common/`` is omitted, and the platform must add its own
[all …]
/rk3399_ARM-atf/docs/security_advisories/
H A Dsecurity-advisory-tfv-13.rst25 | | Also see mitigation guidance in the `Official Arm Advisory`_ |
33 An issue has been identified in some Arm-based CPUs that may allow
40 for which a mitigation is provided in TF-A.
47 | cortex-x4 | r0p0, r0p1, r0p2 | fixed in r0p3 |
49 | cortex-x925 | r0p0, r0p1 | fixed in r0p2 |
53 | neoverse-v3 | r0p0, r0p1 | fixed in r0p2 |
55 | neoverse-v3ae | r0p0, r0p1 | fixed in r0p2 |
57 | c1-premium | r0p0 | fixed in r1p0 |
59 | c1-pro | r0p0, r1p0 | fixed in r1p1 |
61 | c1-ultra | r0p0 | fixed in r1p0 |
[all …]
H A Dsecurity-advisory-tfv-1.rst5 | 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 …]
H A Dsecurity-advisory-tfv-10.rst6 | | 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 …]
H A Dsecurity-advisory-tfv-4.rst5 | 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 …]
/rk3399_ARM-atf/docs/plat/
H A Drpi3.rst12 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 …]
H A Dhikey960.rst6 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 …]
H A Dxilinx-zynqmp.rst52 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 …]
/rk3399_ARM-atf/docs/components/
H A Dromlib-design.rst4 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 …]
H A Dnuma-per-cpu.rst16 example, PSCI or SPM context) is stored in a global array or contiguous region,
17 usually located in the memory of a single node. This approach introduces two key
18 issues in multi-node systems:
23 limits scalability in systems where each node has limited local memory.
26 :alt: Diagram showing the BL31 binary section layout in TF-A within local
34 *Figure: Typical BL31/BL32 binary storage in local memory*
46 platforms place them in the nodes with the lowest access latency.
52 **allocating**, **defining**, and **accessing** per-CPU data in a NUMA-aware
54 platforms while optimizing for performance in multi-node systems.
60 to **allocate** per-CPU global variables and ensure that these objects reside in
[all …]
H A Dras.rst30 EA’s and Error interrupts corresponding to NS nodes are handled first in firmware
40 FFH works in conjunction with `Exception Handling Framework`. Exceptions resulting from
41 errors in Non-secure world are routed to and handled in EL3. Said errors are Synchronous
44 RAS Framework in TF-A allows the platform to define an external abort handler and to
59 EA's originating/attributed to NS world are handled first in NS and Kernel navigates
64 to lower EL. This happens when there is an error (EA) in the system which is not yet
72 reflected back to lower EL (KFH) or handled in EL3 itself (FFH).
76 Limitation in KFH Mode
79 When handling asynchronous External Aborts (EAs) synchronized at EL3 entry in Kernel First Handling
80 (KFH) mode, there is a limitation in the current implementation:
[all …]
/rk3399_ARM-atf/docs/design/
H A Dalt-boot-flows.rst13 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 …]
H A Dinterrupt-framework-design.rst9 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 …]
H A Dpsci-pd-tree.rst9 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 …]
H A Dconsole-framework.rst10 will need to be written for the new UART in TF-A. Current supported UARTs are:
45 runtime output, while the crash console will be used to print the crash log in the
49 These multiple scopes can be useful in many ways, for example:
60 To register a console in TF-A check if the hardware (UART) that is going to be used
62 UART driver API is defined in ``include/drivers/arm/pl011.h``.
64 A skeleton console driver (assembly) is provided in TF-A ``drivers/console/aarch64/
78 to pass an empty ``console_t`` struct which *MUST* be allocated in persistent
81 This function takes a ``console_t`` struct placed in x0 and additional
82 arguments placed in x1 - x7. It returns x0 with either a 0 on failure or 1
89 The ``xxx`` in the function name is replaced with the console driver
[all …]
H A Dcpu-specific-build-macros.rst4 This document describes the various build options present in the CPU specific
16 of the PEs in the system need the workaround. Setting this flag to 0 provides
18 with the recommendation in the spec regarding workaround discovery.
24 CVE-2018-3639, in order to comply with the recommendation in the spec
38 in EL3 FW. This build option should be set to 1 if the target platform contains
56 in the CPU specific errata documents published by Arm:
61 errata workaround is identified by its ``ID`` as specified in the processor's
71 errata workaround build flags in the platform specific makefile. In case
130 r0p4 and onwards, this errata is enabled by default in hardware. Identical to
139 CPUs. Though the erratum is present in every revision of the CPU,
[all …]
/rk3399_ARM-atf/
H A Ddco.txt17 (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
/rk3399_ARM-atf/plat/arm/board/common/swd_rotpk/
H A DREADME2 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
9 * arm_swd_rotprivk_ecdsa.pem is a P-256 ECSA private key in PEM format. It has been
14 * arm_swd_rotprivk_ecdsa_secp384r1.pem is a P-384 ECSA private key in PEM format. It has been

12345678910