| /rk3399_ARM-atf/docs/design/ |
| H A D | cpu-specific-build-macros.rst | 5 operations framework to enable errata workarounds and to enable optimizations
15 `CVE-2017-5715`_. This flag can be set to 0 by the platform if none
16 of the PEs in the system need the workaround. Setting this flag to 0 provides
17 no performance benefit for non-affected platforms, it just helps to comply
19 Defaults to 1.
22 `CVE-2018-3639`_. Defaults to 1. The TF-A project recommends to keep
24 CVE-2018-3639, in order to comply with the recommendation in the spec
28 `CVE-2018-3639`_. This build option should be set to 1 if the target
30 Defaults to 0.
33 This build option should be set to 1 if the target platform contains at
[all …]
|
| H A D | alt-boot-flows.rst | 7 On a pre-production system, the ability to execute arbitrary, bare-metal code at
8 the highest exception level is required. It allows full, direct access to the
9 hardware, for example to run silicon soak tests.
11 Although it is possible to implement some baremetal secure firmware from
13 configuration required to put the system in the expected state.
15 Rather than booting a baremetal application, a possible compromise is to boot
18 other BL images and passing control to BL31. It reduces the complexity of
27 configured to permit secure access only. This gives full access to the whole
28 DRAM to the EL3 payload.
52 - The EL3 payload needs to be loaded in volatile memory (e.g. DRAM) at
[all …]
|
| H A D | psci-pd-tree.rst | 8 ``plat_get_aff_state()`` APIs to enable the generic PSCI code to
10 system. This approach is inflexible because a change to the topology
13 It would be much simpler for the platform to describe its power domain tree
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.
22 Therefore, there is a need to decouple allocation of MPIDRs from the
23 mechanism used to populate the power domain topology tree.
26 over the sibling nodes at a particular level to find a specified power
28 a 'start' to an 'end' power level. The binary search is required to find the
[all …]
|
| H A D | auth-framework.rst | 4 The aim of this document is to describe the authentication framework
8 #. It should be possible for a platform port to specify the Chain of Trust in
9 terms of certificate hierarchy and the mechanisms used to verify a
14 - The mechanism used to encode and transport information, e.g. DER encoded
15 X.509v3 certificates to ferry Subject Public Keys, hashes and non-volatile
18 - The mechanism used to verify the transported information i.e. the
63 the abstraction mechanisms available to specify a Chain of Trust.
69 behind them. These aspects are key to verify a Chain of Trust.
76 illustrates how this maps to a CoT for the BL31 image described in the
126 authentication image contains information to authenticate a data image or
[all …]
|
| H A D | interrupt-framework-design.rst | 4 This framework is responsible for managing interrupts routed to EL3. It also
5 allows EL3 software to configure the interrupt routing behavior. Its main
6 objective is to implement the following two requirements.
8 #. It should be possible to route interrupts meant to be handled by secure
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
14 respect to their delivery and handling without the possibility of
17 #. It should be possible to route interrupts meant to be handled by
18 non-secure software (Non-secure interrupts) to the last executed exception
23 ensures that non-secure software is able to execute in tandem with the
[all …]
|
| /rk3399_ARM-atf/docs/plat/arm/fvp/ |
| H A D | fvp-aemv8-base.rst | 4 AArch64 with reset to BL1 entrypoint
7 The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
12 <path-to>/FVP_Base_RevC-2xAEMv8A \
19 -C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \
20 -C bp.flashloader0.fname="<path-to>/<FIP-binary>" \
21 --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
22 --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
26 a specific DTS for all the CPUs to be loaded.
28 AArch32 with reset to BL1 entrypoint
31 The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
[all …]
|
| H A D | fvp-cortex-a32.rst | 4 With reset to BL1 entrypoint
7 The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
12 <path-to>/FVP_Base_Cortex-A32x4 \
17 -C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \
18 -C bp.flashloader0.fname="<path-to>/<FIP-binary>" \
19 --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
20 --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
22 With reset to SP_MIN entrypoint
25 The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
30 <path-to>/FVP_Base_Cortex-A32x4 \
[all …]
|
| H A D | fvp-cortex-a57-a53.rst | 4 With reset to BL1 entrypoint
7 The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
12 <path-to>/FVP_Base_Cortex-A57x4-A53x4 \
17 -C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \
18 -C bp.flashloader0.fname="<path-to>/<FIP-binary>" \
19 --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
20 --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
22 With reset to BL31 entrypoint
25 The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
30 <path-to>/FVP_Base_Cortex-A57x4-A53x4 \
[all …]
|
| H A D | fvp-build-options.rst | 6 - ``FVP_CLUSTER_COUNT`` : Configures the cluster count to be used to
8 cluster topology and this option can be used to override the default value.
10 - ``FVP_INTERCONNECT_DRIVER``: Selects the interconnect driver to be built. The
20 a single cluster. This option defaults to 4.
23 in the system. This option defaults to 1. Note that the build option
26 - ``FVP_USE_GIC_DRIVER`` : Selects the GIC driver to be built. Options:
32 - ``FVP_HW_CONFIG_DTS`` : Specify the path to the DTS file to be compiled
33 to DTB and packaged in FIP as the HW_CONFIG. See :ref:`Firmware Design` for
34 details on HW_CONFIG. By default, this is initialized to a sensible DTS
37 and this option is needed to specify the appropriate DTS file.
[all …]
|
| /rk3399_ARM-atf/docs/getting_started/ |
| H A D | build-options.rst | 5 otherwise, these options are expected to be specified at the build command
6 line and are not to be modified in any component makefiles. Note that the
17 compiler should use. Valid values are T32 and A32. It defaults to T32 due to
20 - ``AARCH32_SP`` : Choose the AArch32 Secure Payload component to be built as
21 as the BL32 image when ``ARCH=aarch32``. The value should be the path to the
22 directory containing the SP source, relative to the ``bl32/``; the directory
23 is expected to contain a makefile called ``<aarch32_sp-value>.mk``.
25 - ``AMU_RESTRICT_COUNTERS``: Register reads to the group 1 counters will return
31 ``aarch64`` or ``aarch32`` as values. By default, it is defined to
36 and defaults to ``none``. It translates into compiler option
[all …]
|
| H A D | initial-build.rst | 5 to your cross compiler.
11 export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-none-elf-
17 export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-none-eabi-
19 It is possible to build TF-A using Clang or Arm Compiler 6. To do so
20 ``CC`` needs to point to the clang or armclang binary, which will
22 when the base name of the path assigned to ``CC`` matches the string
32 export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-none-elf-
33 make CC=<path-to-armclang>/bin/armclang PLAT=<platform> all
36 default instead of GNU utilities (LLVM linker (LLD) 14.0.0 is known to
40 Clang will be selected when the base name of the path assigned to ``CC``
[all …]
|
| /rk3399_ARM-atf/docs/process/ |
| H A D | security-hardening.rst | 4 This page contains guidance on what to check for additional security measures,
5 including build options that can be modified to improve security or catch issues
15 Do not leak secrets to the normal world
18 The secure world **must not** leak secrets to the normal world, for example in
19 response to an SMC.
24 The secure world **should never** crash or become unusable due to receiving too
31 The Secure world needs to implement some defenses to prevent the Non-secure
36 Refer to the :ref:`Performance Monitoring Unit` guide for detailed information
42 Since the Non-secure world has access to the ``PMCR`` register, it can
43 configure the PMU to increment counters at any exception level and in both
[all …]
|
| H A D | faq.rst | 7 Often it is necessary to update your patch set before it is merged. Refer to the
8 `Gerrit Upload Patch Set documentation`_ on how to do so.
10 If you need to modify an existing patch set with multiple commits, refer to the
13 How long will my changes take to merge into ``integration``?
20 set and the impact of any delay. Feel free to add a comment to your patch set
21 to get an estimate of when it will be merged.
23 * The quality of the patch set. Patches are likely to be merged more quickly if
28 API is likely to receive much greater scrutiny than a local change to a
32 maintainers may not wait for external review comments to merge trivial
33 bug-fixes but may wait up to a week to merge major changes, or ones requiring
[all …]
|
| H A D | platform-ports-policy.rst | 10 Platform compatibility is mainly affected by changes to Platform APIs (as
12 library interfaces (like xlat_table library). The project will try to maintain
15 Due to evolving requirements and enhancements, there might be changes affecting
16 platform compatibility, which means the previous interface needs to be deprecated
17 and a new interface introduced to replace it. In case the migration to the new
18 interface is trivial, the contributor of the change is expected to make good
19 effort to migrate the upstream platforms to the new interface.
23 to upstream their platform code or copy the latest version of the code being
28 deprecated, the page must be updated to indicate the release after which the
30 For non-trivial interface changes, an email should be sent out to the `TF-A
[all …]
|
| /rk3399_ARM-atf/docs/components/ |
| H A D | exception-handling.rst | 17 The |EHF| is selected by setting the build option ``EL3_EXCEPTION_HANDLING`` to
24 allows for asynchronous exceptions to be routed to EL3. As described in the
27 ``SCR_EL3`` register to effect this routing. For most use cases, other than for
29 FIQs and IRQs routed to EL3 are not required to be handled in EL3.
35 introduced to the Arm architecture. With RAS features implemented, various
36 components of the system may use one of the asynchronous exceptions to signal
37 error conditions to PEs. These error conditions are of critical nature, and
40 followed in response to RAS events in the system.
43 interacts with the Runtime Firmware in order to request notification of
47 first received by the EL3 firmware, and then dispatched to Normal world
[all …]
|
| H A D | platform-interrupt-controller-API.rst | 22 is read to determine the priority of the interrupt.
34 associated to system-wide peripherals, and these interrupts can target any PE in
47 associated with peripherals that are private to each PE. Interrupts from private
48 peripherals target to that PE only.
75 the GIC *Set Active Register* to read and return the active status of the
87 ``id``. PEs in the system are expected to receive only enabled interrupts.
90 inserts barrier to make memory updates visible before enabling interrupt, and
91 then writes to GIC *Set Enable Register* to enable the interrupt.
102 ``id``. PEs in the system are not expected to receive disabled interrupts.
105 writes to GIC *Clear Enable Register* to disable the interrupt, and inserts
[all …]
|
| H A D | granule-protection-tables-design.rst | 6 to initialize the GPTs based on a data structure containing information about
7 the systems memory layout, configure the system registers to enable granule
12 and non-secure. In addition to new security states, corresponding physical
13 address spaces have been added to control memory access for each state. The PAS
14 access allowed to each security state can be seen in the table below.
48 level 0 table controls access to a relatively large region in memory (GPT Block
49 descriptor), and the entire region can belong to a single PAS when a one step
50 mapping is used. Level 0 entry can also link to a level 1 table (GPT Table
54 The Level 1 tables entries with the same PAS can be combined to form a
69 is the smallest unit of memory that can be independently assigned to a PAS.
[all …]
|
| /rk3399_ARM-atf/docs/security_advisories/ |
| H A D | security-advisory-tfv-8.rst | 5 | Title | Not saving x0 to x3 registers can leak information from one |
6 | | Normal World SMC client to another |
19 | | client to another |
26 When taking an exception to EL3, BL31 saves the CPU context. The aim is to
29 ``x0`` to ``x3`` are not part of the CPU context saved on the stack.
31 As per the `SMC Calling Convention`_, up to 4 values may be returned to the
32 caller in registers ``x0`` to ``x3``. In TF-A, these return values are written
36 Before returning to the caller, the ``restore_gp_registers()`` function is
38 CPU context stored on the stack. This includes registers ``x0`` to ``x3``, as
40 (referring to the version of the code as of `commit c385955`_):
[all …]
|
| /rk3399_ARM-atf/docs/about/ |
| H A D | lts.rst | 17 | | Varun Wadekar | made by both authors, cosmetic changes to the content |
22 | 2022-08-05 | Varun Wadekar | Changed the “Future plans” section to “FAQ” and |
26 | 2025-01-07 | Govindraj Raja | Convert from pdf to rst. |
38 when a product is released, the companies have to support that in-market product
39 such that the amount of changes to the firmware are kept to a minimum to avoid
40 the risk of regression. At the same time the companies don't want to exclude
42 companies want to minimize the churn when deploying fixes during incident
43 response, e.g. due to critical security bugs.
46 cybersecurity standards for products containing digital elements, aiming to
50 sold in the EU to meet specific cybersecurity requirements.
[all …]
|
| /rk3399_ARM-atf/docs/perf/ |
| H A D | psci-performance-juno.rst | 25 Juno supports CPU, cluster and system power down states, corresponding to power
46 ``CPU_SUSPEND`` to deepest power level
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
125 ``CPU_SUSPEND`` to power level 0
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 …]
|
| /rk3399_ARM-atf/lib/compiler-rt/ |
| H A D | LICENSE.TXT | 7 to use it under either license. As a contributor, you agree to allow your code
8 to be used under both.
29 Permission is hereby granted, free of charge, to any person obtaining a copy of
30 this software and associated documentation files (the "Software"), to deal with
31 the Software without restriction, including without limitation the rights to
33 of the Software, and to permit persons to whom the Software is furnished to do
34 so, subject to the following conditions:
44 Urbana-Champaign, nor the names of its contributors may be used to
60 Permission is hereby granted, free of charge, to any person obtaining a copy
61 of this software and associated documentation files (the "Software"), to deal
[all …]
|
| /rk3399_ARM-atf/plat/nxp/soc-ls1043a/ |
| H A D | soc.def | 17 # set to GIC400 or GIC500
20 # set to CCI400 or CCN504 or CCN508
23 # indicate layerscape chassis level - set to 3=LSCH3 or 2=LSCH2
32 # Select the DDR PHY generation to be used
37 # ddr controller - set to MMDC or NXP
40 # ddr phy - set to NXP or SNPS
46 # Max Size of CSF header. Required to define BL2 TEXT LIMIT in soc.def
47 # Input to CST create_hdr_esbc tool
68 # BL2_HDR_LOC has to be (OCRAM_START_ADDR + OCRAM_SIZE - NXP_ROM_RSVD - CSF_HDR_SZ)
70 # Input to CST create_hdr_isbc tool
[all …]
|
| /rk3399_ARM-atf/docs/plat/arm/ |
| H A 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
10 sets the TSP location to DRAM and ignores the ``ARM_TSP_RAM_LOCATION`` build
13 - ``ARM_CONFIG_CNTACR``: boolean option to unlock access to the ``CNTBase<N>``
17 kernel). Default is true (access to the frame is allowed).
19 - ``ARM_FW_CONFIG_LOAD_ENABLE``: Boolean option to enable the loading of
25 - ``ARM_DISABLE_TRUSTED_WDOG``: boolean option to disable the Trusted Watchdog.
26 By default, Arm platforms use a watchdog to trigger a system reset in case
33 - ``ARM_LINUX_KERNEL_AS_BL33``: The Linux kernel expects registers x0-x3 to
35 to have a Linux kernel image as BL33 by preparing the registers to these
[all …]
|
| /rk3399_ARM-atf/docs/plat/ |
| H A D | rpi3.rst | 7 The following instructions explain how to use this port of the TF-A with the
17 shouldn't be considered more than a prototype to play with and implement
18 elements like PSCI to support the Linux kernel.
28 This explains why it is possible to change the execution state (AArch64/AArch32)
36 a `default AArch64 stub`_ at address **0x0** that jumps to the kernel.
43 `Raspbian`_ distribution by renaming it to ``kernel8.img``, while TF-A and
45 default bootstrap code. When using a AArch64 kernel, it is only needed to make
48 Ideally, we want to load the kernel and have all cores available, which means
49 that we need to make the secondary cores work in the way the kernel expects, as
53 To get the most out of a AArch32 kernel, we want to boot it in Hypervisor mode
[all …]
|
| H A D | allwinner.rst | 5 SoCs with ARMv8 cores. Only BL31 is used to provide proper EL3 setup and
37 So for instance to build for a board with the Allwinner A64 SoC::
45 some build options that allow to fine-tune the firmware, or to disable support
50 to be loaded into the ARISC SCP (A64, H5), or the power sequence control
51 registers to be programmed directly (H6, H616). This supports only basic
53 This option defaults to 1. If an active SCP supporting the SCPI protocol
58 powerup sequence by talking to the SCP processor via the SCPI protocol.
59 This allows more advanced power saving techniques, like suspend to RAM.
60 This option defaults to 1 on SoCs that feature an SCP. If no SCP firmware
66 power management controller, BL31 tries to set up all needed power rails,
[all …]
|