| /rk3399_ARM-atf/fdts/ |
| H A D | juno-ethosn.dtsi | 40 compatible = "ethosn-memory"; 45 compatible = "ethosn-memory"; 56 compatible = "ethosn-memory"; 61 compatible = "ethosn-memory"; 66 compatible = "ethosn-memory"; 71 compatible = "ethosn-memory"; 81 compatible = "ethosn-memory"; 86 compatible = "ethosn-memory"; 91 compatible = "ethosn-memory"; 96 compatible = "ethosn-memory"; [all …]
|
| H A D | morello-fvp.dts | 17 reserved-memory { 110 /* The first bank of memory, memory map is actually provided by UEFI. */ 111 memory@80000000 { 112 device_type = "memory"; 117 memory@8080000000 { 118 device_type = "memory";
|
| H A D | stm32mp15-fw-config.dtsi | 17 /* OP-TEE secure memory: located at DDR top */ 67 memory-ranges = < 72 memory-ranges = <
|
| H A D | stmm_template.dts | 77 memory-regions { 78 compatible = "arm,ffa-manifest-memory-regions"; 81 * SPM Payload memory. Mapped as code region for S-EL0 109 * Heap used by SP to allocate memory for DMA.
|
| H A D | n1sdp-single-chip.dts | 23 * In the first 2GB of DRAM bank the top 16MB are reserved by firmware as secure memory. 26 memory@80000000 { 27 device_type = "memory";
|
| H A D | tc-fpga.dtsi | 29 reserved-memory { 32 * starting from 0x8_8000_0000 reserve some memory
|
| H A D | fvp-ve-Cortex-A7x1.dts | 31 memory@0,80000000 { 32 device_type = "memory"; 36 reserved-memory {
|
| /rk3399_ARM-atf/tools/memory/ |
| H A D | pyproject.toml | 2 name = "memory" 4 description = "A tool for analysis of static memory consumption by TF-A images" 7 packages = [{include = "memory", from = "src"}] 18 memory = "memory.memmap:main" qkey
|
| /rk3399_ARM-atf/plat/arm/board/fvp/fdts/ |
| H A D | fvp_spmc_optee_sp_manifest.dts | 61 memory@6000000 { 62 device_type = "memory"; 66 memory@80000000 { 67 device_type = "ns-memory"; 73 memory@0 { 74 device_type = "device-memory";
|
| H A D | fvp_spmc_manifest.dts | 86 memory@0 { 87 device_type = "memory"; 93 memory@1 { 94 device_type = "ns-memory"; 100 memory@2 { 101 device_type = "device-memory"; 108 memory@3 { 109 device_type = "ns-device-memory";
|
| /rk3399_ARM-atf/plat/arm/board/tc/fdts/ |
| H A D | tc_spmc_manifest.dtsi | 94 memory@0 { 95 device_type = "memory"; 100 memory@1 { 101 device_type = "ns-memory"; 107 memory@2 { 108 device_type = "device-memory"; 113 device_type = "device-memory"; 119 device_type = "ns-device-memory";
|
| /rk3399_ARM-atf/plat/arm/board/neoverse_rd/platform/rdv3/fdts/ |
| H A D | rdv3_spmc_sp_manifest.dts | 67 memory@0 { 68 device_type = "memory"; 75 memory@1 { 76 device_type = "ns-memory"; 80 memory@2 { 81 device_type = "device-memory";
|
| /rk3399_ARM-atf/docs/tools/ |
| H A D | memory-layout-tool.rst | 4 TF-A's memory layout tool is a Python script for analyzing the virtual 5 memory layout of TF-A builds. 32 poetry run memory --help 39 main memory regions in an ELF file (i.e. text, bss, rodata) but can be modified 44 $ poetry run memory symbols 114 poetry run memory --help 119 The tool enables users to view static memory consumption. When the ``footprint`` 121 generate a table (per memory type), showing memory allocation and usage. This is 126 $ poetry run memory footprint 153 A hierarchical view of the memory layout can be produced by passing the ``tree`` [all …]
|
| /rk3399_ARM-atf/docs/components/ |
| H A D | numa-per-cpu.rst | 13 other isolated compute and memory units. Each node typically has its own local 14 memory, and CPUs within a node can access this memory with lower latency than 17 usually located in the memory of a single node. This approach introduces two key 21 centralized allocation becomes a bottleneck. The memory capacity of a single 23 limits scalability in systems where each node has limited local memory. 27 memory. From bottom to top: \`.text\`, \`.rodata\`, \`.data\`, 31 the top. The memory extends from the local memory start address at 34 *Figure: Typical BL31/BL32 binary storage in local memory* 36 - **Non-Uniform Memory Access (NUMA) Latency:** In multi-node systems, memory 61 the local memory of each NUMA node. The figure below illustrates how per-CPU [all …]
|
| H A D | xlat-tables-lib-v2-design.rst | 6 tables based on a description of the memory layout, as well as setting up system 13 on a description of the memory layout. The memory layout is typically 14 provided by the platform port as a list of memory regions; 20 on. This can be used to temporarily map some memory regions and unmap them 26 #. Support for changing memory attributes of memory regions at run-time. 56 An ``mmap_region`` is an abstract, concise way to represent a memory region to 71 The region attributes specify the type of memory (for example device or cached 72 normal memory) as well as the memory access permissions (read-only or 81 granule size, the library might map a 2MB memory region using either of the two 89 potentially less memory. However, if part of this 2MB region is later remapped [all …]
|
| H A D | granule-protection-tables-design.rst | 7 the systems memory layout, configure the system registers to enable granule 13 address spaces have been added to control memory access for each state. The PAS 48 level 0 table controls access to a relatively large region in memory (GPT Block 68 determines how much physical memory is governed by each level 0 entry. A granule 69 is the smallest unit of memory that can be independently assigned to a PAS. 79 creates the tables in memory, and enables granule protection checks. It also 80 allocates memory for fine-grained locks adjacent to the L0 tables. In the 82 memory using the GPT register configuration and saves important data to a 106 #. The desired attributes of this memory region (mapping type, PAS type) 111 structures, then the library will check the desired memory access layout for [all …]
|
| H A D | secure-partition-manager-mm.rst | 167 describe the memory regions that the SPM needs to allocate for a Secure 172 with information about the memory map of the Secure Partition. 204 through a shared memory region. The location of data in the shared memory area 205 is passed as a parameter to the ``MM_COMMUNICATE`` SMC. The shared memory area 210 memory area. The shared memory area is implemented as per the guidelines 214 The format of data structures used to encapsulate data in the shared memory is 293 partition (e.g. management of memory attributes in the translation tables for 408 2. Code memory regions are mapped with RO data and Executable instruction access 411 3. Read Only data memory regions are mapped with RO data and Execute Never 414 4. Read Write data memory regions are mapped with RW data and Execute Never [all …]
|
| /rk3399_ARM-atf/docs/security_advisories/ |
| H A D | security-advisory-tfv-3.rst | 5 | Title | RO memory is always executable at AArch64 Secure EL1 | 27 memory mappings in the form of ``mmap_region`` structures. Each ``mmap_region`` 28 has memory attributes represented by the ``mmap_attr_t`` enumeration type. This 32 Read-Only (RO), non-executable memory region. 35 Any memory region mapped as RO will always be executable, regardless of whether 47 permissions separately to data access permissions. All RO normal memory regions 49 would only manifest itself for device memory mapped as RO; use of this mapping 62 permissions but always leaves the memory as executable at Secure EL1. 66 - The xlat\_tables library ensures that all Read-Write (RW) memory regions are 80 - ARM TF EL3 code (for example BL1 and BL31) ensures that all non-secure memory
|
| H A D | security-advisory-tfv-4.rst | 6 | | authentication of unexpected data in secure memory in | 20 | | memory | 72 memory for subsequent authentication. This is implemented by the 88 these unsanitized values and allow the following memory copy operation, that 90 secure memory if the memory is mapped in BL1's address space, or cause a fatal 94 resident in secure memory. This is implemented by the ``bl1_fwu_image_auth()`` 112 on the unexpected secure memory accesses. Moreover, the normal world FWU code
|
| /rk3399_ARM-atf/plat/nvidia/tegra/scat/ |
| H A D | bl31.scat | 174 * Bakery locks are stored in normal .bss memory 193 /* padded memory section to store per cpu bakery locks */ 204 * Time-stamps are stored in normal .bss memory 206 * The compiler will allocate enough memory for one CPU's time-stamps, 212 /* store timestamps in this carved out memory */ 225 /* padded memory section to store per cpu timestamps */ 242 * The base address of the coherent memory section must be page-aligned (4K) 245 * memory attributes for the coherent data page tables. 250 * Bakery locks are stored in coherent memory
|
| /rk3399_ARM-atf/plat/qemu/qemu_sbsa/ |
| H A D | sbsa_platform.c | 173 dynamic_platform_info.memory[memnode].nodeid = in read_meminfo_from_dt() 190 dynamic_platform_info.memory[memnode].addr_base = cur_base; in read_meminfo_from_dt() 191 dynamic_platform_info.memory[memnode].addr_size = cur_size; in read_meminfo_from_dt() 195 dynamic_platform_info.memory[memnode].nodeid, in read_meminfo_from_dt() 196 dynamic_platform_info.memory[memnode].addr_base, in read_meminfo_from_dt() 197 dynamic_platform_info.memory[memnode].addr_base + in read_meminfo_from_dt() 198 dynamic_platform_info.memory[memnode].addr_size - 1); in read_meminfo_from_dt() 458 return dynamic_platform_info.memory[index]; in sbsa_platform_memory_node()
|
| /rk3399_ARM-atf/ |
| H A D | pyproject.toml | 12 memory = {path = "tools/memory", develop = true} qkey
|
| /rk3399_ARM-atf/docs/components/measured_boot/ |
| H A D | event_log.rst | 24 - Event Log base address in secure memory. 26 Note. Currently OP-TEE does not support reading DTBs from Secure memory 31 - Event Log base address in non-secure memory.
|
| /rk3399_ARM-atf/tools/memory/src/memory/ |
| H A D | memmap.py | 15 from memory.elfparser import TfaElfParser 16 from memory.image import Image 17 from memory.mapparser import TfaMapParser 18 from memory.printer import TfaPrettyPrinter 19 from memory.summary import MapParser
|
| /rk3399_ARM-atf/docs/threat_model/firmware_threat_model/ |
| H A D | threat_model_arm_cca.rst | 36 - All TF-A images run from on-chip memory. Data used by these images also live 37 in on-chip memory. This means TF-A is not vulnerable to an attacker that can 38 probe or tamper with off-chip memory. 42 *[R0147] Monitor code executes entirely from on-chip memory.* 45 *than GPT, is either held in on-chip memory, or in external memory but with* 49 hold data in external memory, even if it is integrity-protected - except for 53 read-only memory or write-protected memory. This could be on-chip ROM, on-chip 62 *memory then other trusted subsystems or application PE cannot modify that* 114 | | memory. |
|