- 20 Sep, 2016 1 commit
-
-
Yatharth Kochar authored
This patch adds changes in BL1 & BL2 to use new version of image loading to load the BL images. Following are the changes in BL1: -Use new version of load_auth_image() to load BL2 -Modified `bl1_init_bl2_mem_layout()` to remove using `reserve_mem()` and to calculate `bl2_mem_layout`. `bl2_mem_layout` calculation now assumes that BL1 RW data is at the top of the bl1_mem_layout, which is more restrictive than the previous BL1 behaviour. Following are the changes in BL2: -The `bl2_main.c` is refactored and all the functions for loading BLxx images are now moved to `bl2_image_load.c` `bl2_main.c` now calls a top level `bl2_load_images()` to load all the images that are applicable in BL2. -Added new file `bl2_image_load_v2.c` that uses new version of image loading to load the BL images in BL2. All the above changes are conditionally compiled using the `LOAD_IMAGE_V2` flag. Change-Id: Ic6dcde5a484495bdc05526d9121c59fa50c1bf23
-
- 22 Aug, 2016 1 commit
-
-
Yatharth Kochar authored
This patch removes the tight loop that calls `plat_report_exception` in unhandled exceptions in AArch64 state. The new behaviour is to call the `plat_report_exception` only once followed by call to `plat_panic_handler`. This allows platforms to take platform-specific action when there is an unhandled exception, instead of always spinning in a tight loop. Note: This is a subtle break in behaviour for platforms that expect `plat_report_exception` to be continuously executed when there is an unhandled exception. Change-Id: Ie2453804b9b7caf9b010ee73e1a90eeb8384e4e8
-
- 09 Aug, 2016 1 commit
-
-
Soby Mathew authored
This patch moves the macro SIZE_FROM_LOG2_WORDS() defined in `arch.h` to `utils.h` as it is utility macro. Change-Id: Ia8171a226978f053a1ee4037f80142c0a4d21430
-
- 18 Jul, 2016 1 commit
-
-
Soby Mathew authored
This patch moves the PSCI services and BL31 frameworks like context management and per-cpu data into new library components `PSCI` and `el3_runtime` respectively. This enables PSCI to be built independently from BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant PSCI library sources and gets included by `bl31.mk`. Other changes which are done as part of this patch are: * The runtime services framework is now moved to the `common/` folder to enable reuse. * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture specific folder. * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder to `plat/common` folder. The original file location now has a stub which just includes the file from new location to maintain platform compatibility. Most of the changes wouldn't affect platform builds as they just involve changes to the generic bl1.mk and bl31.mk makefiles. NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION. Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
-
- 08 Jul, 2016 2 commits
-
-
Sandrine Bailleux authored
At the moment, all BL images share a similar memory layout: they start with their code section, followed by their read-only data section. The two sections are contiguous in memory. Therefore, the end of the code section and the beginning of the read-only data one might share a memory page. This forces both to be mapped with the same memory attributes. As the code needs to be executable, this means that the read-only data stored on the same memory page as the code are executable as well. This could potentially be exploited as part of a security attack. This patch introduces a new build flag called SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data on separate memory pages. This in turn allows independent control of the access permissions for the code and read-only data. This has an impact on memory footprint, as padding bytes need to be introduced between the code and read-only data to ensure the segragation of the two. To limit the memory cost, the memory layout of the read-only section has been changed in this case. - When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e. the read-only section still looks like this (padding omitted): | ... | +-------------------+ | Exception vectors | +-------------------+ | Read-only data | +-------------------+ | Code | +-------------------+ BLx_BASE In this case, the linker script provides the limits of the whole read-only section. - When SEPARATE_CODE_AND_RODATA=1, the exception vectors and read-only data are swapped, such that the code and exception vectors are contiguous, followed by the read-only data. This gives the following new layout (padding omitted): | ... | +-------------------+ | Read-only data | +-------------------+ | Exception vectors | +-------------------+ | Code | +-------------------+ BLx_BASE In this case, the linker script now exports 2 sets of addresses instead: the limits of the code and the limits of the read-only data. Refer to the Firmware Design guide for more details. This provides platform code with a finer-grained view of the image layout and allows it to map these 2 regions with the appropriate access permissions. Note that SEPARATE_CODE_AND_RODATA applies to all BL images. Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
-
Sandrine Bailleux authored
This patch adds a new linker symbol in BL1's linker script named '__BL1_ROM_END__', which marks the end of BL1's ROM content. This covers BL1's code, read-only data and read-write data to relocate in Trusted SRAM. The address of this new linker symbol is exported to C code through the 'BL1_ROM_END' macro. The section related to linker symbols in the Firmware Design guide has been updated and improved. Change-Id: I5c442ff497c78d865ffba1d7d044511c134e11c7
-
- 03 Jun, 2016 1 commit
-
-
Soby Mathew authored
The system registers that are saved and restored in CPU context include AArch32 systems registers like SPSR_ABT, SPSR_UND, SPSR_IRQ, SPSR_FIQ, DACR32_EL2, IFSR32_EL2 and FPEXC32_EL2. Accessing these registers on an AArch64-only (i.e. on hardware that does not implement AArch32, or at least not at EL1 and higher ELs) platform leads to an exception. This patch introduces the build option `CTX_INCLUDE_AARCH32_REGS` to specify whether to include these AArch32 systems registers in the cpu context or not. By default this build option is set to 1 to ensure compatibility. AArch64-only platforms must set it to 0. A runtime check is added in BL1 and BL31 cold boot path to verify this. Fixes ARM-software/tf-issues#386 Change-Id: I720cdbd7ed7f7d8516635a2ec80d025f478b95ee
-
- 26 May, 2016 1 commit
-
-
Sandrine Bailleux authored
This patch introduces some assembler macros to simplify the declaration of the exception vectors. It abstracts the section the exception code is put into as well as the alignments constraints mandated by the ARMv8 architecture. For all TF images, the exception code has been updated to make use of these macros. This patch also updates some invalid comments in the exception vector code. Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95
-
- 30 Mar, 2016 1 commit
-
-
Gerald Lejeune authored
Asynchronous abort exceptions generated by the platform during cold boot are not taken in EL3 unless SCR_EL3.EA is set. Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture initialisation. Further write accesses to SCR_EL3 preserve these bits during cold boot. A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions being trapped by EL3 after cold boot or not. For further reference SError Interrupts are also known as asynchronous external aborts. On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in EL3 whatever the SCR_EL3.EA value is. Fixes arm-software/tf-issues#368 Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
-
- 22 Feb, 2016 1 commit
-
-
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
-
- 15 Dec, 2015 2 commits
-
-
Dan Handley authored
The current FWU_SMC_UPDATE_DONE implementation incorrectly passes an unused framework cookie through to the 1st argument in the platform function `bl1_plat_fwu_done`. The intent is to allow the SMC caller to pass a cookie through to this function. This patch fixes FWU_SMC_UPDATE_DONE to pass x1 from the caller through to `bl1_plat_fwu_done`. The argument names are updated for clarity. Upstream platforms currently do not use this argument so no impact is expected. Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2
-
Dan Handley authored
The current implementation of FWU_SMC_IMAGE_RESUME when called from the normal world, uses the provided image_id argument to determine which secure image to resume into. This implies that the normal world has a choice of which secure image to resume into when in fact it is only possible to resume into the previously interrupted secure image. This patch removes the argument, tightens up the pre-conditions for the SMC and adds additional asserts. The pre-conditions for FWU_SMC_SEC_IMAGE_DONE are also tightened up. Change-Id: Ia5a46753bb01e8f8dad8a2999314f90db8f300e8
-
- 14 Dec, 2015 2 commits
-
-
Dan Handley authored
The implementation of FWU_SMC_IMAGE_AUTH performs a number of pre-condition checks before authenticating the image. One of these checks calls `bl1_plat_mem_check()` to ensure the image source is mapped in when authenticating an image in place. The framework incorrectly passes the security state of the caller into this function instead of the security state of the source image. This patch corrects the defect. The defect would only manifest itself for secure world callers authenticating non-secure images in place, which is not done by current upstream platforms. Change-Id: I617c7b43e02ac7149f266aeaf3874316e62f3003
-
Juan Castillo authored
This patch removes the dash character from the image name, to follow the image terminology in the Trusted Firmware Wiki page: https://github.com/ARM-software/arm-trusted-firmware/wiki Changes apply to output messages, comments and documentation. non-ARM platform files have been left unmodified. Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
-
- 09 Dec, 2015 4 commits
-
-
Yatharth Kochar authored
Firmware update(a.k.a FWU) feature is part of the TBB architecture. BL1 is responsible for carrying out the FWU process if platform specific code detects that it is needed. This patch adds support for FWU feature support in BL1 which is included by enabling `TRUSTED_BOARD_BOOT` compile time flag. This patch adds bl1_fwu.c which contains all the core operations of FWU, which are; SMC handler, image copy, authentication, execution and resumption. It also adds bl1.h introducing #defines for all BL1 SMCs. Following platform porting functions are introduced: int bl1_plat_mem_check(uintptr_t mem_base, unsigned int mem_size, unsigned int flags); This function can be used to add platform specific memory checks for the provided base/size for the given security state. The weak definition will invoke `assert()` and return -ENOMEM. __dead2 void bl1_plat_fwu_done(void *cookie, void *reserved); This function can be used to initiate platform specific procedure to mark completion of the FWU process. The weak definition waits forever calling `wfi()`. plat_bl1_common.c contains weak definitions for above functions. FWU process starts when platform detects it and return the image_id other than BL2_IMAGE_ID by using `bl1_plat_get_next_image_id()` in `bl1_main()`. NOTE: User MUST provide platform specific real definition for bl1_plat_mem_check() in order to use it for Firmware update. Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed
-
Yatharth Kochar authored
As of now BL1 loads and execute BL2 based on hard coded information provided in BL1. But due to addition of support for upcoming Firmware Update feature, BL1 now require more flexible approach to load and run different images using information provided by the platform. This patch adds new mechanism to load and execute images based on platform provided image id's. BL1 now queries the platform to fetch the image id of the next image to be loaded and executed. In order to achieve this, a new struct image_desc_t was added which holds the information about images, such as: ep_info and image_info. This patch introduces following platform porting functions: unsigned int bl1_plat_get_next_image_id(void); This is used to identify the next image to be loaded and executed by BL1. struct image_desc *bl1_plat_get_image_desc(unsigned int image_id); This is used to retrieve the image_desc for given image_id. void bl1_plat_set_ep_info(unsigned int image_id, struct entry_point_info *ep_info); This function allows platforms to update ep_info for given image_id. The plat_bl1_common.c file provides default weak implementations of all above functions, the `bl1_plat_get_image_desc()` always return BL2 image descriptor, the `bl1_plat_get_next_image_id()` always return BL2 image ID and `bl1_plat_set_ep_info()` is empty and just returns. These functions gets compiled into all BL1 platforms by default. Platform setup in BL1, using `bl1_platform_setup()`, is now done _after_ the initialization of authentication module. This change provides the opportunity to use authentication while doing the platform setup in BL1. In order to store secure/non-secure context, BL31 uses percpu_data[] to store context pointer for each core. In case of BL1 only the primary CPU will be active hence percpu_data[] is not required to store the context pointer. This patch introduce bl1_cpu_context[] and bl1_cpu_context_ptr[] to store the context and context pointers respectively. It also also re-defines cm_get_context() and cm_set_context() for BL1 in bl1/bl1_context_mgmt.c. BL1 now follows the BL31 pattern of using SP_EL0 for the C runtime environment, to support resuming execution from a previously saved context. NOTE: THE `bl1_plat_set_bl2_ep_info()` PLATFORM PORTING FUNCTION IS NO LONGER CALLED BY BL1 COMMON CODE. PLATFORMS THAT OVERRIDE THIS FUNCTION MAY NEED TO IMPLEMENT `bl1_plat_set_ep_info()` INSTEAD TO MAINTAIN EXISTING BEHAVIOUR. Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881
-
Yatharth Kochar authored
The upcoming Firmware Update feature needs transitioning across Secure/Normal worlds to complete the FWU process and hence requires context management code to perform this task. Currently context management code is part of BL31 stage only. This patch moves the code from (include)/bl31 to (include)/common. Some function declarations/definitions and macros have also moved to different files to help code sharing. Change-Id: I3858b08aecdb76d390765ab2b099f457873f7b0c
-
Yatharth Kochar authored
The primary usage of `RUN_IMAGE` SMC function id, used by BL2 is to make a request to BL1 to execute BL31. But BL2 also uses it as opcode to check if it is allowed to execute which is not the intended usage of `RUN_IMAGE` SMC. This patch removes the usage of `RUN_IMAGE` as opcode passed to next EL to check if it is allowed to execute. Change-Id: I6aebe0415ade3f43401a4c8a323457f032673657
-
- 26 Nov, 2015 3 commits
-
-
Sandrine Bailleux authored
This patch introduces a new build option named COLD_BOOT_SINGLE_CPU, which allows platforms that only release a single CPU out of reset to slightly optimise their cold boot code, both in terms of code size and performance. COLD_BOOT_SINGLE_CPU defaults to 0, which assumes that the platform may release several CPUs out of reset. In this case, the cold reset code needs to coordinate all CPUs via the usual primary/secondary CPU distinction. If a platform guarantees that only a single CPU will ever be released out of reset, there is no need to arbitrate execution ; the notion of primary and secondary CPUs itself no longer exists. Such platforms may set COLD_BOOT_SINGLE_CPU to 1 in order to compile out the primary/secondary CPU identification in the cold reset code. All ARM standard platforms can release several CPUs out of reset so they use COLD_BOOT_SINGLE_CPU=0. However, on CSS platforms like Juno, bringing up more than one CPU at reset should only be attempted when booting an EL3 payload, as it is not fully supported in the normal boot flow. For platforms using COLD_BOOT_SINGLE_CPU=1, the following 2 platform APIs become optional: - plat_secondary_cold_boot_setup(); - plat_is_my_cpu_primary(). The Porting Guide has been updated to reflect that. User Guide updated as well. Change-Id: Ic5b474e61b7aec1377d1e0b6925d17dfc376c46b
-
Sandrine Bailleux authored
This patch modifies the prototype of the bl1_plat_prepare_exit() platform API to pass the address of the entry point info structure received from BL2. The structure contains information that can be useful, depending on the kind of clean up or bookkeeping operations to perform. The weak implementation of this function ignores this argument to preserve platform backwards compatibility. NOTE: THIS PATCH MAY BREAK PLATFORM PORTS THAT ARE RELYING ON THE FORMER PROTOTYPE OF THE BL1_PLAT_PREPARE_EXIT() API. Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb
-
Sandrine Bailleux authored
This patch introduces a new build flag, SPIN_ON_BL1_EXIT, which puts an infinite loop in BL1. It is intended to help debugging the post-BL2 phase of the Trusted Firmware by stopping execution in BL1 just before handing over to BL31. At this point, the developer may take control of the target using a debugger. This feature is disabled by default and can be enabled by rebuilding BL1 with SPIN_ON_BL1_EXIT=1. User Guide updated accordingly. Change-Id: I6b6779d5949c9e5571dd371255520ef1ac39685c
-
- 02 Nov, 2015 2 commits
-
-
Sandrine Bailleux authored
- Remove out-dated information about the use of printf() in the function comment. - Make the argument const, as the function doesn't need to modify it. - Rename the function into bl1_print_bl31_ep_info() to make its purpose clearer. Change-Id: I2a9d215a37f0ec11aefce0c5c9e050473b7a6b25
-
Sandrine Bailleux authored
This patch introduces a new function called 'print_entry_point_info' that prints an entry_point_t structure for debugging purposes. As such, it can be used to display the entry point address, SPSR and arguments passed from a firmware image to the next one. This function is now called in the following images transitions: - BL1 to BL2 - BL1 to BL31 - BL31 to the next image (typically BL32 or BL33) The following changes have been introduced: - Fix the output format of the SPSR value : SPSR is a 32-bit value, not a 64-bit one. - Print all arguments values. The entry_point_info_t structure allows to pass up to 8 arguments. In most cases, only the first 2 arguments were printed. print_entry_point_info() now prints all of them as 'VERBOSE' traces. Change-Id: Ieb384bffaa7849e6cb95a01a47c0b7fc2308653a
-
- 28 Oct, 2015 1 commit
-
-
Juan Castillo authored
This patch adds an optional API to the platform port: void plat_error_handler(int err) __dead2; The platform error handler is called when there is a specific error condition after which Trusted Firmware cannot continue. While panic() simply prints the crash report (if enabled) and spins, the platform error handler can be used to hand control over to the platform port so it can perform specific bookeeping or post-error actions (for example, reset the system). This function must not return. The parameter indicates the type of error using standard codes from errno.h. Possible errors reported by the generic code are: -EAUTH : a certificate or image could not be authenticated (when Trusted Board Boot is enabled) -ENOENT : the requested image or certificate could not be found or an IO error was detected -ENOMEM : resources exhausted. Trusted Firmware does not use dynamic memory, so this error is usually an indication of an incorrect array size A default weak implementation of this function has been provided. It simply implements an infinite loop. Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3
-
- 20 Oct, 2015 1 commit
-
-
Juan Castillo authored
This patch adds an optional API to the platform port: void bl1_plat_prepare_exit(void); This function is called prior to exiting BL1 in response to the RUN_IMAGE_SMC request raised by BL2. It should be used to perform platform specific clean up or bookkeeping operations before transferring control to the next image. A weak empty definition of this function has been provided to preserve platform backwards compatibility. Change-Id: Iec09697de5c449ae84601403795cdb6aca166ba1
-
- 19 Oct, 2015 1 commit
-
-
Sandrine Bailleux authored
The AArch64 synchronous exception vector code in BL1 is almost reaching its architectural limit of 32 instructions. This means there is very little space for this code to grow. This patch reduces the size of the exception vector code by moving most of its code in a function to which we branch from SynchronousExceptionA64. Change-Id: Ib35351767a685fb2c2398029d32e54026194f7ed
-
- 02 Sep, 2015 1 commit
-
-
Vikram Kanigiri authored
BL2 loads secure runtime code(BL3-1, BL3-2) and hence it has to run in secure world otherwise BL3-1/BL3-2 have to execute from non-secure memory. Hence, This patch removes the change_security_state() call in bl1_run_bl2() and replaces it with an assert to confirm the BL2 as secure. Fixes ARM-software/tf-issues#314 Change-Id: I611b83f5c4090e58a76a2e950b0d797b46df3c29
-
- 25 Jun, 2015 3 commits
-
-
Juan Castillo authored
This patch modifies the Trusted Board Boot implementation to use the new authentication framework, making use of the authentication module, the cryto module and the image parser module to authenticate the images in the Chain of Trust. A new function 'load_auth_image()' has been implemented. When TBB is enabled, this function will call the authentication module to authenticate parent images following the CoT up to the root of trust to finally load and authenticate the requested image. The platform is responsible for picking up the right makefiles to build the corresponding cryptographic and image parser libraries. ARM platforms use the mbedTLS based libraries. The platform may also specify what key algorithm should be used to sign the certificates. This is done by declaring the 'KEY_ALG' variable in the platform makefile. FVP and Juno use ECDSA keys. On ARM platforms, BL2 and BL1-RW regions have been increased 4KB each to accommodate the ECDSA code. REMOVED BUILD OPTIONS: * 'AUTH_MOD' Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
-
Juan Castillo authored
This patch adds the authentication framework that will be used as the base to implement Trusted Board Boot in the Trusted Firmware. The framework comprises the following modules: - Image Parser Module (IPM) This module is responsible for interpreting images, check their integrity and extract authentication information from them during Trusted Board Boot. The module currently supports three types of images i.e. raw binaries, X509v3 certificates and any type specific to a platform. An image parser library must be registered for each image type (the only exception is the raw image parser, which is included in the main module by default). Each parser library (if used) must export a structure in a specific linker section which contains function pointers to: 1. Initialize the library 2. Check the integrity of the image type supported by the library 3. Extract authentication information from the image - Cryptographic Module (CM) This module is responsible for verifying digital signatures and hashes. It relies on an external cryptographic library to perform the cryptographic operations. To register a cryptographic library, the library must use the REGISTER_CRYPTO_LIB macro, passing function pointers to: 1. Initialize the library 2. Verify a digital signature 3. Verify a hash Failing to register a cryptographic library will generate a build time error. - Authentication Module (AM) This module provides methods to authenticate an image, like hash comparison or digital signatures. It uses the image parser module to extract authentication parameters, the crypto module to perform cryptographic operations and the Chain of Trust to authenticate the images. The Chain of Trust (CoT) is a data structure that defines the dependencies between images and the authentication methods that must be followed to authenticate an image. The Chain of Trust, when added, must provide a header file named cot_def.h with the following definitions: - COT_MAX_VERIFIED_PARAMS Integer value indicating the maximum number of authentication parameters an image can present. This value will be used by the authentication module to allocate the memory required to load the parameters in the image descriptor. Change-Id: Ied11bd5cd410e1df8767a1df23bb720ce7e58178
-
Juan Castillo authored
The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
-
- 19 Jun, 2015 1 commit
-
-
Andrew Thoelke authored
The validation of the caching enable state in bl1_main() was incorrect resulting in the state not being checked. Using the right operator fixes this. Change-Id: I2a99478f420281a1dcdf365d3d4fd8394cd21b51
-
- 04 Jun, 2015 2 commits
-
-
Sandrine Bailleux authored
This patch introduces a new platform build option, called PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has a programmable or fixed reset vector address. If the reset vector address is fixed then the code relies on the platform_get_entrypoint() mailbox mechanism to figure out where it is supposed to jump. On the other hand, if it is programmable then it is assumed that the platform code will program directly the right address into the RVBAR register (instead of using the mailbox redirection) so the mailbox is ignored in this case. Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308
-
Sandrine Bailleux authored
The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
-
- 27 Apr, 2015 1 commit
-
-
Dan Handley authored
The required platform constant PLATFORM_CACHE_LINE_SIZE is unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the same information. CACHE_WRITEBACK_GRANULE is preferred since this is an architecturally defined term and allows comparison with the corresponding hardware register value. Replace all usage of PLATFORM_CACHE_LINE_SIZE with CACHE_WRITEBACK_GRANULE. Also, add a runtime assert in BL1 to check that the provided CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0. Change-Id: If87286be78068424217b9f3689be358356500dcd
-
- 08 Apr, 2015 1 commit
-
-
Kévin Petit authored
In order for the symbol table in the ELF file to contain the size of functions written in assembly, it is necessary to report it to the assembler using the .size directive. To fulfil the above requirements, this patch introduces an 'endfunc' macro which contains the .endfunc and .size directives. It also adds a .func directive to the 'func' assembler macro. The .func/.endfunc have been used so the assembler can fail if endfunc is omitted. Fixes ARM-Software/tf-issues#295 Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc Signed-off-by: Kévin Petit <kevin.petit@arm.com>
-
- 28 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch adds support to authenticate the BL2 content certificate and image using the authentication module in BL1. The FIP driver has been extended to include the BL2 certificate UUID. FVP and Juno ports include the BL2 certificate FIP file definition. Change-Id: I32680e9bd123c8db4a4193c14448c9b32b0e9325
-
- 22 Jan, 2015 1 commit
-
-
Soby Mathew authored
This patch extends the build option `USE_COHERENT_MEMORY` to conditionally remove coherent memory from the memory maps of all boot loader stages. The patch also adds necessary documentation for coherent memory removal in firmware-design, porting and user guides. Fixes ARM-Software/tf-issues#106 Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
-
- 19 Sep, 2014 1 commit
-
-
Juan Castillo authored
This patch fixes the incorrect value of the LENGTH attribute in the linker scripts. This attribute must define the memory size, not the limit address. Fixes ARM-software/tf-issues#252 Change-Id: I328c38b9ec502debe12046a8912d7dfc54610c46
-
- 27 Aug, 2014 1 commit
-
-
Sandrine Bailleux authored
This patch gathers miscellaneous minor fixes to the documentation, and comments in the source code. Change-Id: I631e3dda5abafa2d90f464edaee069a1e58b751b Co-Authored-By: Soby Mathew <soby.mathew@arm.com> Co-Authored-By: Dan Handley <dan.handley@arm.com>
-
- 20 Aug, 2014 1 commit
-
-
Soby Mathew authored
This patch introduces a framework which will allow CPUs to perform implementation defined actions after a CPU reset, during a CPU or cluster power down, and when a crash occurs. CPU specific reset handlers have been implemented in this patch. Other handlers will be implemented in subsequent patches. Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/. Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956
-