1. 06 Feb, 2020 1 commit
    • Max Shvetsov's avatar
      Adds option to read ROTPK from registers for FVP · a6ffddec
      Max Shvetsov authored
      
      
      Enables usage of ARM_ROTPK_LOCATION=regs for FVP board.
      Removes hard-coded developer keys. Instead, setting
      ARM_ROTPK_LOCATION=devel_* takes keys from default directory.
      In case of ROT_KEY specified - generates a new hash and replaces the
      original.
      
      Note: Juno board was tested by original feature author and was not tested
      for this patch since we don't have access to the private key. Juno
      implementation was moved to board-specific file without changing
      functionality. It is not known whether byte-swapping is still needed
      for this platform.
      
      Change-Id: I0fdbaca0415cdcd78f3a388551c2e478c01ed986
      Signed-off-by: default avatarMax Shvetsov <maksims.svecovs@arm.com>
      a6ffddec
  2. 25 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Sanitise includes · bd9344f6
      Antonio Nino Diaz authored
      
      
      Use full include paths like it is done for common includes.
      
      This cleanup was started in commit d40e0e08283a ("Sanitise includes
      across codebase"), but it only cleaned common files and drivers. This
      patch does the same to Arm platforms.
      
      Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      bd9344f6
  3. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored
      Enforce full include path for includes. Deprecate old paths.
      
      The following folders inside include/lib have been left unchanged:
      
      - include/lib/cpus/${ARCH}
      - include/lib/el3_runtime/${ARCH}
      
      The reason for this change is that having a global namespace for
      includes isn't a good idea. It defeats one of the advantages of having
      folders and it introduces problems that are sometimes subtle (because
      you may not know the header you are actually including if there are two
      of them).
      
      For example, this patch had to be created because two headers were
      called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
      to avoid collision."). More recently, this patch has had similar
      problems: 46f9b2c3 ("drivers: add tzc380 support").
      
      This problem was introduced in commit 4ecca339
      
       ("Move include and
      source files to logical locations"). At that time, there weren't too
      many headers so it wasn't a real issue. However, time has shown that
      this creates problems.
      
      Platforms that want to preserve the way they include headers may add the
      removed paths to PLAT_INCLUDES, but this is discouraged.
      
      Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  4. 10 Oct, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Move norflash driver to drivers/ folder · aa7877c4
      Antonio Nino Diaz authored
      
      
      This way it can be reused by other platforms if needed.
      
      Note that this driver is designed to work with the Versatile Express NOR
      flash of Juno and FVP. In said platforms, the memory is organized as an
      interleaved memory of two chips with a 16 bit word.
      
      Any platform that wishes to reuse it with a different configuration will
      need to modify the driver so that it is more generic.
      
      Change-Id: Ic721758425864e0cf42b7b9b04bf0d9513b6022e
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      aa7877c4
  5. 02 Oct, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Remove option ARM_BOARD_OPTIMISE_MEM · c0740e4f
      Antonio Nino Diaz authored
      
      
      This option makes it hard to optimize the memory definitions of all Arm
      platforms because any change in the common defines must work in all of
      them. The best thing to do is to remove it and move the definition to
      each platform's header.
      
      FVP, SGI and SGM were using the definitions in board_arm_def.h. The
      definitions have been copied to each platform's platform_def.h. Juno
      was already using the ones in platform_def.h, so there have been no
      changes.
      
      Change-Id: I9aecd11bbc72a3d0d7aad1ef9934d8df21dcfaf2
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c0740e4f
  6. 21 Aug, 2018 1 commit
  7. 25 Sep, 2017 1 commit
    • Roberto Vargas's avatar
      mem_protect: Add mem_protect support in Juno and FVP for DRAM1 · f145403c
      Roberto Vargas authored
      
      
      mem_protect needs some kind of non-volatile memory because it has
      to remember its state across reset and power down events.
      The most suitable electronic part for this feature is a NVRAM
      which should be only accesible from the secure world. Juno and
      FVP lack such hardware and for this reason the MEM_PROTECT
      functionality is implemented with Flash EEPROM memory on both
      boards, even though this memory is accesible from the non-secure
      world. This is done only to show a full implementation of
      these PSCI features, but an actual system shouldn't use a
      non-secure NVRAM to implement it.
      
      The EL3 runtime software will write the mem_protect flag and BL2
      will read and clear the memory ranges if enabled. It is done in
      BL2 because it reduces the time that TF needs access to the full
      non-secure memory.
      
      The memory layout of both boards is defined using macros which
      take different values in Juno and FVP platforms. Generic platform
      helpers are added that use the platform specific macros to generate
      a mem_region_t that is valid for the platform.
      
      Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      f145403c
  8. 22 Sep, 2017 1 commit
  9. 28 Jun, 2017 1 commit
  10. 03 May, 2017 1 commit
  11. 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
  12. 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
  13. 09 Aug, 2016 1 commit
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 31 Mar, 2015 1 commit
  21. 20 Aug, 2014 1 commit
    • Soby Mathew's avatar
      Introduce framework for CPU specific operations · 9b476841
      Soby Mathew authored
      This patch introduces a framework which will allow CPUs to perform
      implementation defined actions after a CPU reset, during a CPU or cluster power
      down, and when a crash occurs. CPU specific reset handlers have been implemented
      in this patch. Other handlers will be implemented in subsequent patches.
      
      Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/.
      
      Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956
      9b476841
  22. 06 May, 2014 2 commits
    • Dan Handley's avatar
      Remove vpath usage in makefiles · bee82417
      Dan Handley authored
      Remove all usage of the vpath keyword in makefiles as it was prone
      to mistakes. Specify the relative paths to source files instead.
      
      Also reorder source files in makefiles alphabetically.
      
      Fixes ARM-software/tf-issues#121
      
      Change-Id: Id15f60655444bae60e0e2165259efac71a50928b
      bee82417
    • Dan Handley's avatar
      Move include and source files to logical locations · 4ecca339
      Dan Handley authored
      Move almost all system include files to a logical sub-directory
      under ./include. The only remaining system include directories
      not under ./include are specific to the platform. Move the
      corresponding source files to match the include directory
      structure.
      
      Also remove pm.h as it is no longer used.
      
      Change-Id: Ie5ea6368ec5fad459f3e8a802ad129135527f0b3
      4ecca339
  23. 26 Mar, 2014 1 commit
    • Sandrine Bailleux's avatar
      Separate out BL2, BL3-1 and BL3-2 early exception vectors from BL1 · 6c595b3d
      Sandrine Bailleux authored
      bl1/aarch64/early_exceptions.S used to be re-used by BL2, BL3-1 and
      BL3-2.  There was some early SMC handling code in there that was not
      required by the other bootloader stages.  Therefore this patch
      introduces an even simpler exception vector source file for BL2,
      BL3-1 and BL3-2.
      
      Fixes ARM-software/tf-issues#38
      
      Change-Id: I0244b80e9930b0f8035156a0bf91cc3e9a8f995d
      6c595b3d
  24. 20 Mar, 2014 1 commit
    • Jeenu Viswambharan's avatar
      Specify image entry in linker script · 9f98aa1a
      Jeenu Viswambharan authored
      At present, the entry point for each BL image is specified via the
      Makefiles and provided on the command line to the linker. When using a
      link script the entry point should rather be specified via the ENTRY()
      directive in the link script.
      
      This patch updates linker scripts of all BL images to specify the entry
      point using the ENTRY() directive. It also removes the --entry flag
      passed to the linker through Makefile.
      
      Fixes issue ARM-software/tf-issues#66
      
      Change-Id: I1369493ebbacea31885b51185441f6b628cf8da0
      9f98aa1a
  25. 05 Mar, 2014 1 commit
    • Jon Medhurst's avatar
      Update Makefiles to get proper dependency checking working. · 6d55d109
      Jon Medhurst authored
      
      
      This change requires all platforms to now specify a list of source files
      rather than object files.
      
      New source files should preferably be specified by using the path as
      well and we should add this in the future for all files so we can remove
      use of vpath. This is desirable because vpath hides issues like the fact
      that BL2 currently pulls in a BL1 file bl1/aarch64/early_exceptions.S
      and if in the future we added bl2/aarch64/early_exceptions.S then it's
      likely only one of the two version would be used for both bootloaders.
      
      This change also removes the 'dump' build target and simply gets
      bootloaders to always generate a dump file. At the same time the -x
      option is added so the section headers and symbols table are listed.
      
      Fixes ARM-software/tf-issues#11
      
      Change-Id: Ie38f7be76fed95756c8576cf3f3ea3b7015a18dc
      Signed-off-by: default avatarJon Medhurst <tixy@linaro.org>
      6d55d109
  26. 20 Feb, 2014 1 commit
    • Achin Gupta's avatar
      Factor out translation table setup in ARM FVP port · a0cd989d
      Achin Gupta authored
      This patch factors out the ARM FVP specific code to create MMU
      translation tables so that it is possible for a boot loader stage to
      create a different set of tables instead of using the default ones.
      The default translation tables are created with the assumption that
      the calling boot loader stage executes out of secure SRAM. This might
      not be true for the BL3_2 stage in the future.
      
      A boot loader stage can define the `fill_xlation_tables()` function as
      per its requirements. It returns a reference to the level 1
      translation table which is used by the common platform code to setup
      the TTBR_EL3.
      
      This patch is a temporary solution before a larger rework of
      translation table creation logic is introduced.
      
      Change-Id: I09a075d5da16822ee32a411a9dbe284718fb4ff6
      a0cd989d
  27. 20 Jan, 2014 2 commits
  28. 17 Jan, 2014 1 commit
  29. 20 Dec, 2013 1 commit
    • Harry Liebel's avatar
      Create local C library implementation (1/2) · c81b1d0f
      Harry Liebel authored
      - This change is split into two separate patches in order to
        simplify the history as interpreted by 'git'. The split is
        between the move/rename and addition of new files.
      - Remove dependency on toolchain C library headers and functions in
        order to ensure behavioural compatibility between toolchains.
      - Use FreeBSD as reference for C library implementation.
      - Do not let GCC use default library include paths.
      - Remove unused definitions in modified headers and implementations.
      - Move C library files to 'lib/stdlib' and 'include/stdlib'.
      - Break std.c functions out into separate files.
      
      Change-Id: I91cddfb3229775f770ad781589670c57d347a154
      c81b1d0f
  30. 05 Dec, 2013 1 commit
    • Dan Handley's avatar
      Enable third party contributions · ab2d31ed
      Dan Handley authored
      - Add instructions for contributing to ARM Trusted Firmware.
      
      - Update copyright text in all files to acknowledge contributors.
      
      Change-Id: I9311aac81b00c6c167d2f8c889aea403b84450e5
      ab2d31ed
  31. 25 Oct, 2013 1 commit