1. 29 Apr, 2017 1 commit
    • Scott Branden's avatar
      Move defines in utils.h to utils_def.h to fix shared header compile issues · 53d9c9c8
      Scott Branden authored
      
      
      utils.h is included in various header files for the defines in it.
      Some of the other header files only contain defines.  This allows the
      header files to be shared between host and target builds for shared defines.
      
      Recently types.h has been included in utils.h as well as some function
      prototypes.
      
      Because of the inclusion of types.h conflicts exist building host tools
      abd these header files now.  To solve this problem,
      move the defines to utils_def.h and have this included by utils.h and
      change header files to only include utils_def.h and not pick up the new
      types.h being introduced.
      
      Fixes ARM-software/tf-issues#461
      Signed-off-by: default avatarScott Branden <scott.branden@broadcom.com>
      
      Remove utils_def.h from utils.h
      
      This patch removes utils_def.h from utils.h as it is not required.
      And also makes a minor change to ensure Juno platform compiles.
      
      Change-Id: I10cf1fb51e44a8fa6dcec02980354eb9ecc9fa29
      53d9c9c8
  2. 20 Apr, 2017 1 commit
    • Yatharth Kochar's avatar
      Changes to support execution in AArch32 state for JUNO · 07570d59
      Yatharth Kochar authored
      
      
      Following steps are required to boot JUNO in AArch32 state:
      1> BL1, in AArch64 state, loads BL2.
      2> BL2, in AArch64 state, initializes DDR.
        Loads SP_MIN & BL33 (AArch32 executable)images.
        Calls RUN_IMAGE SMC to go back to BL1.
      3> BL1 writes AArch32 executable opcodes, to load and branch
        at the entrypoint address of SP_MIN, at HI-VECTOR address and
        then request for warm reset in AArch32 state using RMR_EL3.
      
      This patch makes following changes to facilitate above steps:
      * Added assembly function to carry out step 3 above.
      * Added region in TZC that enables Secure access to the
        HI-VECTOR(0xFFFF0000) address space.
      * AArch32 image descriptor is used, in BL2, to load
        SP_MIN and BL33 AArch32 executable images.
      
      A new flag `JUNO_AARCH32_EL3_RUNTIME` is introduced that
      controls above changes. By default this flag is disabled.
      
      NOTE: BL1 and BL2 are not supported in AArch32 state for JUNO.
      
      Change-Id: I091d56a0e6d36663e6d9d2bb53c92c672195d1ec
      Signed-off-by: default avatarYatharth Kochar <yatharth.kochar@arm.com>
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      07570d59
  3. 03 Apr, 2017 1 commit
    • Douglas Raillard's avatar
      Fix ARM_BL31_IN_DRAM build · f9608bc8
      Douglas Raillard authored
      
      
      Some header files using the ULL() macro were not directly including
      utils.h where the macro definition resides. As a consequence, a linker
      script with values using this macro did not see the macro definition
      and kept the "ULL(<value>)" call in the preprocessed file, which lead to
      link error.
      
      Files using ULL() macro now include utils.h directly.
      
      Change-Id: I433a7f36bd21a156c20e69bc2a2bb406140ebdf9
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      f9608bc8
  4. 08 Mar, 2017 1 commit
    • Antonio Nino Diaz's avatar
      ARM platforms: Enable xlat tables lib v2 · bf75a371
      Antonio Nino Diaz authored
      
      
      Modify ARM common makefile to use version 2 of the translation tables
      library and include the new header in C files.
      
      Simplify header dependencies related to this library to simplify the
      change.
      
      The following table contains information about the size increase in
      bytes for BL1 after applying this patch. The code has been compiled for
      different configurations of FVP in AArch64 mode with compiler GCC 4.9.3
      20150413. The sizes have been calculated with the output of `nm` by
      adding the size of all regions and comparing the total size before and
      after the change. They are sumarized in the table below:
      
                                     text   bss   data  total
              Release                +660   -20    +88   +728
              Debug                  +740   -20   +242   +962
              Debug (LOG_LEVEL=50)  +1120   -20   +317  +1417
      
      Change-Id: I539e307f158ab71e3a8b771640001fc1bf431b29
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      bf75a371
  5. 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
  6. 31 Mar, 2016 1 commit
    • Juan Castillo's avatar
      TBB: add non-volatile counter support · 48279d52
      Juan Castillo authored
      This patch adds support for non-volatile counter authentication to
      the Authentication Module. This method consists of matching the
      counter values provided in the certificates with the ones stored
      in the platform. If the value from the certificate is lower than
      the platform, the boot process is aborted. This mechanism protects
      the system against rollback.
      
      The TBBR CoT has been updated to include this method as part of the
      authentication process. Two counters are used: one for the trusted
      world images and another for the non trusted world images.
      
      ** NEW PLATFORM APIs (mandatory when TBB is enabled) **
      
      int plat_get_nv_ctr(void *cookie, unsigned int *nv_ctr);
      
          This API returns the non-volatile counter value stored
          in the platform. The cookie in the first argument may be
          used to select the counter in case the platform provides
          more than one (i.e. TBSA compliant platforms must provide
          trusted and non-trusted counters). This cookie is specified
          in the CoT.
      
      int plat_set_nv_ctr(void *cookie, unsigned int nv_ctr);
      
          This API sets a new counter value. The cookie may be
          used to select the counter to be updated.
      
      An implementation of these new APIs for ARM platforms is also
      provided. The values are obtained from the Trusted Non-Volatile
      Counters peripheral. The cookie is used to pass the extension OID.
      This OID may be interpreted by the platform to know which counter
      must return. On Juno, The trusted and non-trusted counter values
      have been tied to 31 and 223, respectively, and cannot be modified.
      
      ** IMPORTANT **
      
      THIS PATCH BREAKS THE BUILD WHEN TRUSTED_BOARD_BOOT IS ENABLED. THE
      NEW PLATFORM APIs INTRODUCED IN THIS PATCH MUST BE IMPLEMENTED IN
      ORDER TO SUCCESSFULLY BUILD TF.
      
      Change-Id: Ic943b76b25f2a37f490eaaab6d87b4a8b3cbc89a
      48279d52
  7. 05 Aug, 2015 1 commit
    • Juan Castillo's avatar
      Fix build error with optimizations disabled (-O0) · 80bb6afd
      Juan Castillo authored
      If Trusted Firmware is built with optimizations disabled (-O0), the
      linker throws the following error:
      
          undefined reference to 'xxx'
      
      Where 'xxx' is a raw inline function defined in a header file. The
      reason is that, with optimizations disabled, GCC may decide to skip
      the inlining. If that is the case, an external definition to the
      compilation unit must be provided. Because no external definition
      is present, the linker throws the error.
      
      This patch fixes the problem by declaring the following inline
      functions static, so the internal definition is used:
      
          inline void soc_css_security_setup(void)
          inline const arm_config_t *get_arm_config(void)
      
      Change-Id: Id650d6be1b1396bdb48af1ac8a4c7900d212e95f
      80bb6afd
  8. 25 Jun, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add platform API to read the ROTPK information · 95cfd4ad
      Juan Castillo authored
      This patch extends the platform port by adding an API that returns
      either the Root of Trust public key (ROTPK) or its hash. This is
      usually stored in ROM or eFUSE memory. The ROTPK returned must be
      encoded in DER format according to the following ASN.1 structure:
      
          SubjectPublicKeyInfo  ::=  SEQUENCE  {
              algorithm           AlgorithmIdentifier,
              subjectPublicKey    BIT STRING
          }
      
      In case the platform returns a hash of the key:
      
          DigestInfo  ::= SEQUENCE {
              digestAlgorithm     AlgorithmIdentifier,
              keyDigest           OCTET STRING
          }
      
      An implementation for ARM development platforms is provided in this
      patch. When TBB is enabled, the ROTPK hash location must be specified
      using the build option 'ARM_ROTPK_LOCATION'. Available options are:
      
          - 'regs' : return the ROTPK hash stored in the Trusted
            root-key storage registers.
      
          - 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
            BL2 binaries. This hash has been obtained from the development
            RSA public key located in 'plat/arm/board/common/rotpk'.
      
      On FVP, the number of MMU tables has been increased to map and
      access the ROTPK registers.
      
      A new file 'board_common.mk' has been added to improve code sharing
      in the ARM develelopment platforms.
      
      Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
      95cfd4ad
  9. 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