- 01 Apr, 2016 1 commit
-
-
Jimmy Huang authored
BL31 usually handles confidential stuff, its memory must not be read/write accessible from non-secure world. This patch protects the BL31 memory range from non-secure read/write access. Change-Id: I442fb92b667bb2f9a62d471a90508b1ba4489911 Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
-
- 29 Mar, 2016 3 commits
- 22 Mar, 2016 2 commits
-
-
Sandrine Bailleux authored
The Firmware Design document is meant to provide a general overview of the Trusted Firmware code. Although it is useful to provide some guidance around the responsibilities of the platform layer, it should not provide too much platform specific implementation details. Right now, some sections are too tied to the implementation on ARM platforms. This makes the Firmware Design document harder to digest. This patch simplifies this aspect of the Firmware Design document. The sections relating the platform initialisations performed by the different BL stages have been simplified and the extra details about the ARM platforms implementation have been moved to the Porting Guide when appropriate. This patch also provides various documentation fixes and additions in the Firmware Design and Platform Porting Guide. In particular: - Update list of SMCs supported by BL1. - Remove MMU setup from architectural inits, as it is actually performed by platform code. - Similarly, move runtime services initialisation, BL2 image initialization and BL33 execution out of the platform initialisation paragraph. - List SError interrupt unmasking as part of BL1 architectural initialization. - Mention Trusted Watchdog enabling in BL1 on ARM platforms. - Fix order of steps in "BL2 image load and execution" section. - Refresh section about GICv3/GICv2 drivers initialisation on ARM platforms. Change-Id: I32113c4ffdc26687042629cd8bbdbb34d91e3c14
-
Soby Mathew authored
The assembler helper function `print_revision_warning` is used when a CPU specific operation is enabled in the debug build (e.g. an errata workaround) but doesn't apply to the executing CPU's revision/part number. However, in some cases the system integrator may want a single binary to support multiple platforms with different IP versions, only some of which contain a specific erratum. In this case, the warning can be emitted very frequently when CPUs are being powered on/off. This patch modifies this warning print behaviour so that it is emitted only when LOG_LEVEL >= LOG_LEVEL_VERBOSE. The `debug.h` header file now contains guard macros so that it can be included in assembly code. Change-Id: Ic6e7a07f128dcdb8498a5bfdae920a8feeea1345
-
- 16 Mar, 2016 2 commits
- 14 Mar, 2016 2 commits
-
-
Antonio Nino Diaz authored
Added a new platform porting function plat_panic_handler, to allow platforms to handle unexpected error situations. It must be implemented in assembly as it may be called before the C environment is initialized. A default implementation is provided, which simply spins. Corrected all dead loops in generic code to call this function instead. This includes the dead loop that occurs at the end of the call to panic(). All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have been removed. Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
-
danh-arm authored
Add "size" function to IO memmap device driver
-
- 11 Mar, 2016 4 commits
-
-
Gerald Lejeune authored
Hence memmap device can be used to load an image without being wrapped in a FIP. Fixes arm-software/tf-issues#371 Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
-
danh-arm authored
Mtk bl31 update
-
danh-arm authored
Initialize all translation table entries
-
danh-arm authored
Extend memory attributes to map non-cacheable memory
-
- 09 Mar, 2016 6 commits
-
-
danh-arm authored
Initialize secondary CPUs during cold boot
-
danh-arm authored
Porting guide: Clarify API that don't follow AAPCS
-
danh-arm authored
Compile stdlib C files individually
-
Jimmy Huang authored
This patch adds big core ARMPLL control in system suspend flow. Change-Id: I27a45dbbb360f17ff0b524a125630358ee2277e2 Signed-off-by: Louis Yu <louis.yu@mediatek.com> Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
-
Jimmy Huang authored
We no longer need to control power signal via gpio during system off, thus remove gpio driver support from platform code. Change-Id: I6dfec129fa163330951f37b45b71ba5b90355c3b Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
-
Jimmy Huang authored
MT8173 platform code is incompatible with RESET_TO_BL31, add #error directive to prevent the case. We also move mt8173_def.h and plat_private.h to include directory, and remove some unnecessary code. Change-Id: I47b8d0a506820a4ea1fbe8c8fb0ec6c68d88feb5 Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
-
- 07 Mar, 2016 3 commits
-
-
Antonio Nino Diaz authored
The previous reset code in BL1 performed the following steps in order: 1. Warm/Cold boot detection. If it's a warm boot, jump to warm boot entrypoint. 2. Primary/Secondary CPU detection. If it's a secondary CPU, jump to plat_secondary_cold_boot_setup(), which doesn't return. 3. CPU initialisations (cache, TLB...). 4. Memory and C runtime initialization. For a secondary CPU, steps 3 and 4 are never reached. This shouldn't be a problem in most cases, since current implementations of plat_secondary_cold_boot_setup() either panic or power down the secondary CPUs. The main concern is the lack of secondary CPU initialization when bare metal EL3 payloads are used in case they don't take care of this initialisation themselves. This patch moves the detection of primary/secondary CPU after step 3 so that the CPU initialisations are performed per-CPU, while the memory and the C runtime initialisation are only performed on the primary CPU. The diagrams used in the ARM Trusted Firmware Reset Design documentation file have been updated to reflect the new boot flow. Platforms ports might be affected by this patch depending on the behaviour of plat_secondary_cold_boot_setup(), as the state of the platform when entering this function will be different. Fixes ARM-software/tf-issues#342 Change-Id: Icbf4a0ee2a3e5b856030064472f9fa6696f2eb9e
-
Antonio Nino Diaz authored
This patch clarifies a porting API in the Porting Guide that do not follow the ARM Architecture Program Calling Standards (AAPCS). The list of registers that are allowed to be clobbered by this API has been updated in the Porting Guide. Fixes ARM-software/tf-issues#259 Change-Id: Ibf2adda2e1fb3e9b8f53d8a918d5998356eb8fce
-
Kristina Martsenko authored
The current translation table code maps in a series of regions, zeroing the unmapped table entries before and in between the mapped regions. It doesn't, however, zero the unmapped entries after the last mapped region, leaving those entries at whatever value that memory has initially. This is bad because those values can look like valid translation table entries, pointing to valid physical addresses. The CPU is allowed to do speculative reads from any such addresses. If the addresses point to device memory, the results can be unpredictable. This patch zeroes the translation table entries following the last mapped region, ensuring all table entries are either valid or zero (invalid). In addition, it limits the value of ADDR_SPACE_SIZE to those allowed by the architecture and supported by the current code (see D4.2.5 in the Architecture Reference Manual). This simplifies this patch a lot and ensures existing code doesn't do unexpected things. Change-Id: Ic28b6c3f89d73ef58fa80319a9466bb2c7131c21
-
- 03 Mar, 2016 2 commits
-
-
Sandrine Bailleux authored
At the moment, the memory translation library allows to create memory mappings of 2 types: - Device nGnRE memory (named MT_DEVICE in the library); - Normal, Inner Write-back non-transient, Outer Write-back non-transient memory (named MT_MEMORY in the library). As a consequence, the library code treats the memory type field as a boolean: everything that is not device memory is normal memory and vice-versa. In reality, the ARMv8 architecture allows up to 8 types of memory to be used at a single time for a given exception level. This patch reworks the memory attributes such that the memory type is now defined as an integer ranging from 0 to 7 instead of a boolean. This makes it possible to extend the list of memory types supported by the memory translation library. The priority system dictating memory attributes for overlapping memory regions has been extended to cope with these changes but the algorithm at its core has been preserved. When a memory region is re-mapped with different memory attributes, the memory translation library examines the former attributes and updates them only if the new attributes create a more restrictive mapping. This behaviour is unchanged, only the manipulation of the value has been modified to cope with the new format. This patch also introduces a new type of memory mapping in the memory translation library: MT_NON_CACHEABLE, meaning Normal, Inner Non-cacheable, Outer Non-cacheable memory. This can be useful to map a non-cacheable memory region, such as a DMA buffer for example. The rules around the Execute-Never (XN) bit in a translation table for an MT_NON_CACHEABLE memory mapping have been aligned on the rules used for MT_MEMORY mappings: - If the memory is read-only then it is also executable (XN = 0); - If the memory is read-write then it is not executable (XN = 1). The shareability field for MT_NON_CACHEABLE mappings is always set as 'Outer-Shareable'. Note that this is not strictly needed since shareability is only relevant if the memory is a Normal Cacheable memory type, but this is to align with the existing device memory mappings setup. All Device and Normal Non-cacheable memory regions are always treated as Outer Shareable, regardless of the translation table shareability attributes. This patch also removes the 'ATTR_SO' and 'ATTR_SO_INDEX' #defines. They were introduced to map memory as Device nGnRnE (formerly called "Strongly-Ordered" memory in the ARMv7 architecture) but were not used anywhere in the code base. Removing them avoids any confusion about the memory types supported by the library. Upstream platforms do not currently use the MT_NON_CACHEABLE memory type. NOTE: THIS CHANGE IS SOURCE COMPATIBLE BUT PLATFORMS THAT RELY ON THE BINARY VALUES OF `mmap_attr_t` or the `attr` argument of `mmap_add_region()` MAY BE BROKEN. Change-Id: I717d6ed79b4c845a04e34132432f98b93d661d79
-
Antonio Nino Diaz authored
From version 4.0 onwards, the ARM64 Linux kernel expects the device tree to indicate the cache hierarchy. Failing to provide this information results in the following warning message to be printed by the kernel: `Unable to detect cache hierarchy from DT for CPU x` All the FVP device trees provided in the TF source tree have been modified to add this information. Fixes ARM-software/tf-issues#325 Change-Id: I0ff888992e602b81a0fe1744a86151d625727511
-
- 02 Mar, 2016 1 commit
-
-
Antonio Nino Diaz authored
Enable alternative boot flow where BL2 does not load BL33 from non-volatile storage, and BL31 hands execution over to a preloaded BL33. The flag used to enable this bootflow is BL33_BASE, which must hold the entrypoint address of the BL33 image. The User Guide has been updated with an example of how to use this option with a bootwrapped kernel. Change-Id: I48087421a7b0636ac40dca7d457d745129da474f
-
- 26 Feb, 2016 3 commits
-
-
Antonio Nino Diaz authored
All C files of stdlib were included into std.c, which was the file that the Makefile actually compiled. This is a poor way of compiling all the files and, while it may work fine most times, it's discouraged. In this particular case, each C file included its own headers, which were later included into std.c. For example, this caused problems because a duplicated typedef of u_short in both subr_prf.c and types.h. While that may require an issue on its own, this kind of problems are avoided if all C files are as independent as possible. Change-Id: I9a7833fd2933003f19a5d7db921ed8542ea2d04a
-
danh-arm authored
Fix the inconsistencies in bl1_tbbr_image_descs[]
-
danh-arm authored
Fix potential deadlock in PL011 init function
-
- 24 Feb, 2016 1 commit
-
-
Juan Castillo authored
The PL011 initialization function disables the UART, flushes the FIFO and waits for the current character to be transmitted before applying the configuration and enabling the UART. This waiting might result in a deadlock if the FIFO is disabled while another CPU is printing a message since the flush of FIFO will never finish. This patch fixes the problem by removing the flush operation and the loop for last character completion from the initialization function. The UART is disabled, configured and enabled again. Change-Id: I1ca0b6bd9f352c12856f10f174a9f6eaca3ab4ea
-
- 22 Feb, 2016 4 commits
-
-
Yatharth Kochar authored
This patch fixes inconsistencies in bl1_tbbr_image_descs[] and miscellaneous fixes in Firmware Update code. Following are the changes: * As part of the original FWU changes, a `copied_size` field was added to `image_info_t`. This was a subtle binary compatibility break because it changed the size of the `bl31_params_t` struct, which could cause problems if somebody used different versions of BL2 or BL31, one with the old `image_info_t` and one with the new version. This patch put the `copied_size` within the `image_desc_t`. * EXECUTABLE flag is now stored in `ep_info.h.attr` in place of `image_info.h.attr`, associating it to an entrypoint. * The `image_info.image_base` is only relevant for secure images that are copied from non-secure memory into secure memory. This patch removes initializing `image_base` for non secure images in the bl1_tbbr_image_descs[]. * A new macro `SET_STATIC_PARAM_HEAD` is added for populating bl1_tbbr_image_descs[].ep_info/image_info.h members statically. The version, image_type and image attributes are now populated using this new macro. * Added PLAT_ARM_NVM_BASE and PLAT_ARM_NVM_SIZE to avoid direct usage of V2M_FLASH0_XXX in plat/arm/common/arm_bl1_fwu.c. * Refactoring of code/macros related to SECURE and EXECUTABLE flags. NOTE: PLATFORM PORTS THAT RELY ON THE SIZE OF `image_info_t` OR USE the "EXECUTABLE" BIT WITHIN `image_info_t.h.attr` OR USE THEIR OWN `image_desc_t` ARRAY IN BL1, MAY BE BROKEN BY THIS CHANGE. THIS IS CONSIDERED UNLIKELY. Change-Id: Id4e5989af7bf0ed263d19d3751939da1169b561d
-
danh-arm authored
Rationalise MMU and Page table related constants on ARM platforms
-
Vikram Kanigiri authored
`board_arm_def.h` contains multiple definitions of `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for memory usage depending upon the chosen build configuration. To ease maintenance of these constants, this patch replaces their multiple definitions with a single set of definitions that will work on all ARM platforms. Platforms can override the defaults with optimal values by enabling the `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in the Juno ADP port. Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate future ARM platforms. Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
-
danh-arm authored
Pl061 gpio v5
-
- 19 Feb, 2016 3 commits
-
-
danh-arm authored
Fix gpio includes of mt8173 platform to avoid collision.
-
danh-arm authored
Allow multi cluster topology definitions for ARM platforms
-
Soby Mathew authored
The common topology description helper funtions and macros for ARM Standard platforms assumed a dual cluster system. This is not flexible enough to scale to multi cluster platforms. This patch does the following changes for more flexibility in defining topology: 1. The `plat_get_power_domain_tree_desc()` definition is moved from `arm_topology.c` to platform specific files, that is `fvp_topology.c` and `juno_topology.c`. Similarly the common definition of the porting macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform specific `platform_def.h` header. 2. The ARM common layer porting macros which were dual cluster specific are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced which must be defined by each ARM standard platform. 3. A new mandatory ARM common layer porting API `plat_arm_get_cluster_core_count()` is introduced to enable the common implementation of `arm_check_mpidr()` to validate MPIDR. 4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been introduced which allows the user to specify the cluster count to be used to build the topology tree within Trusted Firmare. This enables Trusted Firmware to be built for multi cluster FVP models. Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
-
- 18 Feb, 2016 3 commits