summaryrefslogtreecommitdiff
path: root/include/plat/common/common_def.h
AgeCommit message (Collapse)Author
2016-02-22Fix the inconsistencies in bl1_tbbr_image_descs[]Yatharth Kochar
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
2016-01-14Migrate __warn_deprecated -> __deprecatedSoren Brinkmann
Use the new __deprecated macro from the generic cdefs header and remove the deprecated __warn_deprecated. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
2015-12-14Remove dashes from image names: 'BL3-x' --> 'BL3x'Juan Castillo
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
2015-12-09Add descriptor based image management support in BL1Yatharth Kochar
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
2015-11-24Replace build macro WARN_DEPRECATED with ERROR_DEPRECATEDSoby Mathew
This patch changes the build time behaviour when using deprecated API within Trusted Firmware. Previously the use of deprecated APIs would only trigger a build warning (which was always treated as a build error), when WARN_DEPRECATED = 1. Now, the use of deprecated C declarations will always trigger a build time warning. Whether this warning is treated as error or not is determined by the build flag ERROR_DEPRECATED which is disabled by default. When the build flag ERROR_DEPRECATED=1, the invocation of deprecated API or inclusion of deprecated headers will result in a build error. Also the deprecated context management helpers in context_mgmt.c are now conditionally compiled depending on the value of ERROR_DEPRECATED flag so that the APIs themselves do not result in a build error when the ERROR_DEPRECATED flag is set. NOTE: Build systems that use the macro WARN_DEPRECATED must migrate to using ERROR_DEPRECATED, otherwise deprecated API usage will no longer trigger a build error. Change-Id: I843bceef6bde979af7e9b51dddf861035ec7965a
2015-08-13PSCI: Add deprecated API for SPD when compatibility is disabledSoby Mathew
This patch defines deprecated platform APIs to enable Trusted Firmware components like Secure Payload and their dispatchers(SPD) to continue to build and run when platform compatibility is disabled. This decouples the migration of platform ports to the new platform API from SPD and enables them to be migrated independently. The deprecated platform APIs defined in this patch are : platform_get_core_pos(), platform_get_stack() and platform_set_stack(). The patch also deprecates MPIDR based context management helpers like cm_get_context_by_mpidr(), cm_set_context_by_mpidr() and cm_init_context(). A mechanism to deprecate APIs and identify callers of these APIs during build is introduced, which is controlled by the build flag WARN_DEPRECATED. If WARN_DEPRECATED is defined to 1, the users of the deprecated APIs will be flagged either as a link error for assembly files or compile time warning for C files during build. Change-Id: Ib72c7d5dc956e1a74d2294a939205b200f055613
2015-06-25TBB: add TBBR Chain of TrustJuan Castillo
This patch adds a CoT based on the Trusted Board Boot Requirements document*. The CoT consists of an array of authentication image descriptors indexed by the image identifiers. A new header file with TBBR image identifiers has been added. Platforms that use the TBBR (i.e. ARM platforms) may reuse these definitions as part of their platform porting. PLATFORM PORT - IMPORTANT: Default image IDs have been removed from the platform common definitions file (common_def.h). As a consequence, platforms that used those common definitons must now either include the IDs provided by the TBBR header file or define their own IDs. *The NVCounter authentication method has not been implemented yet. Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5
2015-06-25Use numbers to identify images instead of namesJuan Castillo
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
2015-04-28Add common ARM and CSS platform codeDan Handley
This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8