1. 20 Apr, 2017 1 commit
  2. 23 Jan, 2017 1 commit
    • Masahiro Yamada's avatar
      Use #ifdef for IMAGE_BL* instead of #if · 3d8256b2
      Masahiro Yamada authored
      
      
      One nasty part of ATF is some of boolean macros are always defined
      as 1 or 0, and the rest of them are only defined under certain
      conditions.
      
      For the former group, "#if FOO" or "#if !FOO" must be used because
      "#ifdef FOO" is always true.  (Options passed by $(call add_define,)
      are the cases.)
      
      For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because
      checking the value of an undefined macro is strange.
      
      Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like
      follows:
      
        $(eval IMAGE := IMAGE_BL$(call uppercase,$(3)))
      
        $(OBJ): $(2)
                @echo "  CC      $$<"
                $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@
      
      This means, IMAGE_BL* is defined when building the corresponding
      image, but *undefined* for the other images.
      
      So, IMAGE_BL* belongs to the latter group where we should use #ifdef
      or #ifndef.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      3d8256b2
  3. 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
  4. 10 Aug, 2016 1 commit
    • Soby Mathew's avatar
      AArch32: Add essential ARM platform and FVP support · 877cf3ff
      Soby Mathew authored
      This patch adds AArch32 support for FVP and implements common platform APIs
      like `plat_get_my_stack`, `plat_set_my_stack`, `plat_my_core_cos` for AArch32.
      Only Multi Processor(MP) implementations of these functions are considered in
      this patch. The ARM Standard platform layer helpers are implemented for
      AArch32 and the common makefiles are modified to cater for both AArch64 and
      AArch32 builds. Compatibility with the deprecated platform API is not
      supported for AArch32.
      
      Change-Id: Iad228400613eec91abf731b49e21a15bcf2833ea
      877cf3ff
  5. 09 Aug, 2016 1 commit
  6. 25 Jul, 2016 1 commit
    • Antonio Nino Diaz's avatar
      ARM platforms: Define common image sizes · 0289970d
      Antonio Nino Diaz authored
      Compile option `ARM_BOARD_OPTIMISE_MMAP` has been renamed to
      `ARM_BOARD_OPTIMISE_MEM` because it now applies not only to defines
      related to the translation tables but to the image size as well.
      
      The defines `PLAT_ARM_MAX_BL1_RW_SIZE`, `PLAT_ARM_MAX_BL2_SIZE` and
      `PLAT_ARM_MAX_BL31_SIZE` have been moved to the file board_arm_def.h.
      This way, ARM platforms no longer have to set their own values if
      `ARM_BOARD_OPTIMISE_MEM=0` and they can specify optimized values
      otherwise. The common sizes have been set to the highest values used
      for any of the current build configurations.
      
      This is needed because in some build configurations some images are
      running out of space. This way there is a common set of values known
      to work for all of them and it can be optimized for each particular
      platform if needed.
      
      The space reserved for BL2 when `TRUSTED_BOARD_BOOT=0` has been
      increased. This is needed because when memory optimisations are
      disabled the values for Juno of `PLAT_ARM_MMAP_ENTRIES` and
      `MAX_XLAT_TABLES` are higher. If in this situation the code is
      compiled in debug mode and with "-O0", the code won't fit.
      
      Change-Id: I70a3d8d3a0b0cad1d6b602c01a7ea334776e718e
      0289970d
  7. 08 Jul, 2016 1 commit
    • Sandrine Bailleux's avatar
      Introduce arm_setup_page_tables() function · b5fa6563
      Sandrine Bailleux authored
      This patch introduces the arm_setup_page_tables() function to
      set up page tables on ARM platforms. It replaces the
      arm_configure_mmu_elx() functions and does the same thing except
      that it doesn't enable the MMU at the end. The idea is to reduce
      the amount of per-EL code that is generated by the C preprocessor
      by splitting the memory regions definitions and page tables creation
      (which is generic) from the MMU enablement (which is the only per-EL
      configuration).
      
      As a consequence, the call to the enable_mmu_elx() function has been
      moved up into the plat_arch_setup() hook. Any other ARM standard
      platforms that use the functions `arm_configure_mmu_elx()` must be
      updated.
      
      Change-Id: I6f12a20ce4e5187b3849a8574aac841a136de83d
      b5fa6563
  8. 03 Jun, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Implement plat_set_nv_ctr for FVP platforms · fe7de035
      Antonio Nino Diaz authored
      Replaced placeholder implementation of plat_set_nv_ctr for FVP
      platforms by a working one.
      
      On FVP, the mapping of region DEVICE2 has been changed from RO to RW
      to prevent exceptions when writing to the NV counter, which is
      contained in this region.
      
      Change-Id: I56a49631432ce13905572378cbdf106f69c82f57
      fe7de035
  9. 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
  10. 22 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Rationalise MMU and Page table related constants on ARM platforms · c64a0448
      Vikram Kanigiri authored
      `board_arm_def.h` contains multiple definitions of
      `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
      memory usage depending upon the chosen build configuration. To ease
      maintenance of these constants, this patch replaces their multiple
      definitions with a single set of definitions that will work on all ARM
      platforms.
      
      Platforms can override the defaults with optimal values by enabling the
      `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
      the Juno ADP port.
      
      Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
      future ARM platforms.
      
      Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
      c64a0448
  11. 09 Dec, 2015 2 commits
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL2U for ARM platforms · dcda29f6
      Yatharth Kochar authored
      This patch adds support for Firmware update in BL2U for ARM
      platforms such that TZC initialization is performed on all
      ARM platforms and (optionally) transfer of SCP_BL2U image on
      ARM CSS platforms.
      
      BL2U specific functions are added to handle early_platform and
      plat_arch setup. The MMU is configured to map in the BL2U
      code/data area and other required memory.
      
      Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
      dcda29f6
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL1 for ARM platforms · 436223de
      Yatharth Kochar authored
      This patch adds Firmware Update support for ARM platforms.
      
      New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
      platform specific Firmware update code.
      
      BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
      authenticating NS_BL2U image(For both FVP and JUNO platform).
      
      Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
      436223de
  12. 02 Dec, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add Trusted Watchdog support on ARM platforms · 7b4c1405
      Juan Castillo authored
      This patch adds watchdog support on ARM platforms (FVP and Juno).
      A secure instance of SP805 is used as Trusted Watchdog. It is
      entirely managed in BL1, being enabled in the early platform setup
      hook and disabled in the exit hook. By default, the watchdog is
      enabled in every build (even when TBB is disabled).
      
      A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
      has been introduced to allow the user to disable the watchdog at
      build time. This feature may be used for testing or debugging
      purposes.
      
      Specific error handlers for Juno and FVP are also provided in this
      patch. These handlers will be called after an image load or
      authentication error. On FVP, the Table of Contents (ToC) in the FIP
      is erased. On Juno, the corresponding error code is stored in the
      V2M Non-Volatile flags register. In both cases, the CPU spins until
      a watchdog reset is generated after 256 seconds (as specified in
      the TBBR document).
      
      Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
      7b4c1405
  13. 27 Nov, 2015 1 commit
    • Juan Castillo's avatar
      Add basic NOR flash driver for ARM platforms · 9784dbda
      Juan Castillo authored
      FVP and Juno platforms include a NOR flash memory to store and
      load the FIP, the kernel or a ramdisk. This NOR flash is arranged
      as 2 x 16 bit flash devices and can be programmed using CFI
      standard commands.
      
      This patch provides a basic API to write single 32 bit words of
      data into the NOR flash. Functions to lock/unlock blocks against
      erase or write operations are also provided.
      
      Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2
      9784dbda
  14. 25 Jun, 2015 2 commits
    • Juan Castillo's avatar
      TBB: delete deprecated plat_match_rotpk() · f04585f3
      Juan Castillo authored
      The authentication framework deprecates plat_match_rotpk()
      in favour of plat_get_rotpk_info(). This patch removes
      plat_match_rotpk() from the platform port.
      
      Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b
      f04585f3
    • 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
  15. 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