1. 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
  2. 14 Jan, 2016 1 commit
  3. 14 Dec, 2015 1 commit
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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