1. 28 Sep, 2018 1 commit
  2. 22 Aug, 2018 1 commit
  3. 07 Apr, 2018 1 commit
    • Jiafei Pan's avatar
      Add support for BL2 in XIP memory · 7d173fc5
      Jiafei Pan authored
      
      
      In some use-cases BL2 will be stored in eXecute In Place (XIP) memory,
      like BL1. In these use-cases, it is necessary to initialize the RW sections
      in RAM, while leaving the RO sections in place. This patch enable this
      use-case with a new build option, BL2_IN_XIP_MEM. For now, this option
      is only supported when BL2_AT_EL3 is 1.
      Signed-off-by: default avatarJiafei Pan <Jiafei.Pan@nxp.com>
      7d173fc5
  4. 27 Mar, 2018 1 commit
    • Joel Hutton's avatar
      Clean usage of void pointers to access symbols · 9f85f9e3
      Joel Hutton authored
      
      
      Void pointers have been used to access linker symbols, by declaring an
      extern pointer, then taking the address of it. This limits symbols
      values to aligned pointer values. To remove this restriction an
      IMPORT_SYM macro has been introduced, which declares it as a char
      pointer and casts it to the required type.
      
      Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0
      Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9f85f9e3
  5. 03 May, 2017 1 commit
  6. 26 Jan, 2017 1 commit
    • David Cunado's avatar
      Resolve build errors flagged by GCC 6.2 · 9edac047
      David Cunado authored
      
      
      With GCC 6.2 compiler, more C undefined behaviour is being flagged as
      warnings, which result in build errors in ARM TF build.
      
      The specific issue that this patch resolves is the use of (1 << 31),
      which is predominantly used in case statements, where 1 is represented
      as a signed int. When shifted to msb the behaviour is undefined.
      
      The resolution is to specify 1 as an unsigned int using a convenience
      macro ULL(). A duplicate macro MAKE_ULL() is replaced.
      
      Fixes ARM-software/tf-issues#438
      
      Change-Id: I08e3053bbcf4c022ee2be33a75bd0056da4073e1
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      9edac047
  7. 18 Jan, 2017 2 commits
    • Masahiro Yamada's avatar
      Move BL_COHERENT_RAM_BASE/END defines to common_def.h · 47497053
      Masahiro Yamada authored
      
      
      We have lots of duplicated defines (and comment blocks too).
      Move them to include/plat/common/common_def.h.
      
      While we are here, suffix the end address with _END instead of
      _LIMIT.  The _END is a better fit to indicate the linker-derived
      real end address.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      47497053
    • Masahiro Yamada's avatar
      Use *_END instead of *_LIMIT for linker derived end addresses · ecdc898d
      Masahiro Yamada authored
      
      
      The usage of _LIMIT seems odd here, so rename as follows:
        BL_CODE_LIMIT     --> BL_CODE_END
        BL_RO_DATA_LIMIT  --> BL_RO_DATA_END
        BL1_CODE_LIMIT    --> BL1_CODE_END
        BL1_RO_DATA_LIMIT --> BL1_RO_DATA_END
      
      Basically, we want to use _LIMIT and _END properly as follows:
        *_SIZE + *_MAX_SIZE = *_LIMIT
        *_SIZE + *_SIZE     = *_END
      
      The _LIMIT is generally defined by platform_def.h to indicate the
      platform-dependent memory constraint.  So, its typical usage is
        ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
      in a linker script.
      
      On the other hand, _END is used to indicate the end address of the
      compiled image, i.e. we do not know it until the image is linked.
      
      Here, all of these macros belong to the latter, so should be
      suffixed with _END.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      ecdc898d
  8. 21 Sep, 2016 1 commit
    • Yatharth Kochar's avatar
      AArch32: Common changes needed for BL1/BL2 · 1a0a3f06
      Yatharth Kochar authored
      This patch adds common changes to support AArch32 state in
      BL1 and BL2. Following are the changes:
      
      * Added functions for disabling MMU from Secure state.
      * Added AArch32 specific SMC function.
      * Added semihosting support.
      * Added reporting of unhandled exceptions.
      * Added uniprocessor stack support.
      * Added `el3_entrypoint_common` macro that can be
        shared by BL1 and BL32 (SP_MIN) BL stages. The
        `el3_entrypoint_common` is similar to the AArch64
        counterpart with the main difference in the assembly
        instructions and the registers that are relevant to
        AArch32 execution state.
      * Enabled `LOAD_IMAGE_V2` flag in Makefile for
        `ARCH=aarch32` and added check to make sure that
        platform has not overridden to disable it.
      
      Change-Id: I33c6d8dfefb2e5d142fdfd06a0f4a7332962e1a3
      1a0a3f06
  9. 20 Sep, 2016 1 commit
    • Yatharth Kochar's avatar
      Changes for new version of image loading in BL1/BL2 · 42019bf4
      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
      42019bf4
  10. 08 Jul, 2016 1 commit
    • Sandrine Bailleux's avatar
      ARM platforms: Add support for SEPARATE_CODE_AND_RODATA · 0af559a8
      Sandrine Bailleux authored
      The arm_setup_page_tables() function used to expect a single set of
      addresses defining the extents of the whole read-only section, code
      and read-only data mixed up, which was mapped as executable.
      
      This patch changes this behaviour. arm_setup_page_tables() now
      expects 2 separate sets of addresses:
      
       - the extents of the code section;
       - the extents of the read-only data section.
      
      The code is mapped as executable, whereas the data is mapped as
      execute-never. New #defines have been introduced to identify the
      extents of the code and the read-only data section. Given that
      all BL images except BL1 share the same memory layout and linker
      script structure, these #defines are common across these images.
      The slight memory layout differences in BL1 have been handled by
      providing values specific to BL1.
      
      Note that this patch also affects the Xilinx platform port, which
      uses the arm_setup_page_tables() function. It has been updated
      accordingly, such that the memory mappings on this platform are
      unchanged. This is achieved by passing null values as the extents
      of the read-only data section so that it is ignored. As a result,
      the whole read-only section is still mapped as executable.
      
      Fixes ARM-software/tf-issues#85
      
      Change-Id: I1f95865c53ce6e253a01286ff56e0aa1161abac5
      0af559a8
  11. 22 Feb, 2016 1 commit
    • Yatharth Kochar's avatar
      Fix the inconsistencies in bl1_tbbr_image_descs[] · 843ddee4
      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
      843ddee4
  12. 14 Jan, 2016 1 commit
  13. 14 Dec, 2015 1 commit
  14. 09 Dec, 2015 1 commit
    • Yatharth Kochar's avatar
      Add descriptor based image management support in BL1 · 7baff11f
      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
      7baff11f
  15. 24 Nov, 2015 1 commit
    • Soby Mathew's avatar
      Replace build macro WARN_DEPRECATED with ERROR_DEPRECATED · 7a24cba5
      Soby Mathew authored
      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
      7a24cba5
  16. 13 Aug, 2015 1 commit
    • Soby Mathew's avatar
      PSCI: Add deprecated API for SPD when compatibility is disabled · 5c8babcd
      Soby Mathew authored
      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
      5c8babcd
  17. 25 Jun, 2015 2 commits
    • Juan Castillo's avatar
      TBB: add TBBR Chain of Trust · dff93c86
      Juan Castillo authored
      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
      dff93c86
    • Juan Castillo's avatar
      Use numbers to identify images instead of names · 16948ae1
      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
      16948ae1
  18. 28 Apr, 2015 1 commit
    • Dan Handley's avatar
      Add common ARM and CSS platform code · b4315306
      Dan Handley authored
      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
      b4315306