1. 28 Sep, 2018 1 commit
  2. 26 Jul, 2018 1 commit
    • Sughosh Ganu's avatar
      ARM platforms: Allow board specific definition of SP stack base · 2e4a509d
      Sughosh Ganu authored
      
      
      The SGI platforms need to allocate memory for CPER buffers. These
      platform buffers would be placed between the shared reserved memory
      and the per cpu stack memory, thus the need to redefine stack base
      pointer for these platforms. This patch allows each board in ARM
      platform to define the PLAT_SP_IMAGE_STACK_BASE.
      
      Change-Id: Ib5465448b860ab7ab0f645f7cb278a67acce7be9
      Signed-off-by: default avatarSughosh Ganu <sughosh.ganu@arm.com>
      2e4a509d
  3. 01 May, 2018 1 commit
    • Roberto Vargas's avatar
      ARM platforms: Demonstrate mem_protect from el3_runtime · 638b034c
      Roberto Vargas authored
      
      
      Previously mem_protect used to be only supported from BL2. This is not
      helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates
      mem_protect from el3_runtime firmware on ARM Platforms specifically
      when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent
      in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap
      tables temporarily and then the protected regions are then cleared. This
      avoids the need to map the non secure DRAM permanently to BL31/sp_min.
      
      The stack size is also increased, because DYNAMIC_XLAT_TABLES require
      a bigger stack.
      
      Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      638b034c
  4. 02 Mar, 2018 1 commit
    • Roberto Vargas's avatar
      Fix FVP DRAM2 size · d0c63eaa
      Roberto Vargas authored
      
      
      This was correct according to the model specifications , but it seems
      that FVP doesn't implement it. It is safer to use the size exposed by
      the DTB which is currently used by Linux.
      
      Change-Id: I9aabe3284a50ec2a36ed94966eb7e4ddf37cec3b
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      d0c63eaa
  5. 19 Dec, 2017 1 commit
  6. 06 Dec, 2017 1 commit
  7. 16 Oct, 2017 1 commit
    • Jeenu Viswambharan's avatar
      ARM platforms: Migrate to using interrupt properties · b2c363b1
      Jeenu Viswambharan authored
      
      
      An earlier patch added provision for the platform to provide secure
      interrupt properties. ARM platforms already has a list of interrupts
      that fall into different secure groups.
      
      This patch defines macros that enumerate interrupt properties in the
      same fashion, and points the driver driver data to a list of interrupt
      properties rather than list of secure interrupts on ARM platforms.  The
      deprecated interrupt list definitions are however retained to support
      legacy builds.
      
      Configuration applied to individual interrupts remain unchanged, so no
      runtime behaviour change expected.
      
      NOTE: Platforms that use the arm/common function
      plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and
      PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and
      PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided
      INTR_PROP_DESC macro.
      
      Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      b2c363b1
  8. 11 Oct, 2017 1 commit
    • Soby Mathew's avatar
      ARM platforms: enable GICv3 state save/restore · e35a3fb5
      Soby Mathew authored
      
      
      Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and
      arm_system_pwr_domain_save functions.
      
      Introduce FVP PSCI power level 3 (System level) support. This is solely
      done to provide example code on how to use the GICv3 save and restore
      helpers.
      
      Also make CSS GICv3 platforms power off the Redistributor on SYSTEM
      SUSPEND as its state is saved and restored.
      
      Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Co-Authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      e35a3fb5
  9. 21 Sep, 2017 1 commit
  10. 02 Aug, 2017 1 commit
    • Jeenu Viswambharan's avatar
      FVP: Support Base FVP RevC · 955242d8
      Jeenu Viswambharan authored
      
      
      Revision C of the Base FVP has the same memory map as earlier revisions,
      but has the following differences:
      
        - Implements CCI550 instead of CCI400,
        - Has a single instantiation of SMMUv3,
        - CPU MPIDs are shifted left by one level, and has MT bit set in them.
      
      The correct interconnect to program is chosen at run time based on the
      FVP revision. Therefore, this patch implements FVP functions for
      interconnect programming, rather than depending on ARM generic ones. The
      macros used have been renamed to reflect this change.
      
      Additionally, this patch initializes SMMUv3 as part of FVP early
      platform setup.
      
      New ARM config flags are introduced for feature queries at run time.
      
      Change-Id: Ic7b7f080953a51fceaf62ce7daa6de0573801f09
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      955242d8
  11. 01 Aug, 2017 1 commit
    • Jeenu Viswambharan's avatar
      FVP: Add support for multi-threaded CPUs · 11ad8f20
      Jeenu Viswambharan authored
      
      
      ARM CPUs with multi-threading implementation has more than one
      Processing Element in a single physical CPU. Such an implementation will
      reflect the following changes in the MPIDR register:
      
        - The MT bit set;
      
        - Affinity levels pertaining to cluster and CPUs occupy one level
          higher than in a single-threaded implementation, and the lowest
          affinity level pertains to hardware threads. MPIDR affinity level
          fields essentially appear shifted to left than otherwise.
      
      The FVP port henceforth assumes that both properties above to be
      concomitant on a given FVP platform.
      
      To accommodate for varied MPIDR formats at run time, this patch
      re-implements the FVP platform-specific functions that translates MPIDR
      values to a linear indices, along with required validation. The same
      treatment is applied for GICv3 MPIDR hashing function as well.
      
      An FVP-specific build option FVP_MAX_PE_PER_CPU is introduced which
      specifies the maximum number of threads implemented per CPU. For
      backwards compatibility, its value defaults to 1.
      
      Change-Id: I729b00d3e121d16ce9a03de4f9db36dfac580e3f
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      11ad8f20
  12. 20 Jun, 2017 1 commit
  13. 03 May, 2017 1 commit
  14. 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
  15. 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
  16. 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
  17. 25 May, 2016 1 commit
    • Soby Mathew's avatar
      Add CCN support to FVP platform port · 71237876
      Soby Mathew authored
      This patch adds support to select CCN driver for FVP during build.
      A new build option `FVP_INTERCONNECT_DRIVER` is added to allow
      selection between the CCI and CCN driver. Currently only the CCN-502
      variant is supported on FVP.
      
      The common ARM CCN platform helper file now verifies the cluster
      count declared by platform is equal to the number of root node
      masters exported by the ARM Standard platform.
      
      Change-Id: I71d7b4785f8925ed499c153b2e9b9925fcefd57a
      71237876
  18. 31 Mar, 2016 2 commits
    • Soby Mathew's avatar
      Migrate ARM standard platforms to the refactored TZC driver · 57f78201
      Soby Mathew authored
      This patch migrates ARM Standard platforms to the refactored TZC driver.
      
      Change-Id: I2a2f60b645f73e14d8f416740c4551cec87cb1fb
      57f78201
    • David Wang's avatar
      Add support to load BL31 in DRAM · 4518dd9a
      David Wang authored
      This patch adds an option to the ARM common platforms to load BL31 in the
      TZC secured DRAM instead of the default secure SRAM.
      
      To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options.
      If TSP is present, then setting this option also sets the TSP location
      to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag.
      
      To use this feature, BL2 platform code must map in the DRAM used by
      BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose.
      Currently, only the FVP BL2 platform code maps in this DRAM.
      
      Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
      4518dd9a
  19. 19 Feb, 2016 1 commit
    • Soby Mathew's avatar
      Allow multi cluster topology definitions for ARM platforms · 0108047a
      Soby Mathew authored
      The common topology description helper funtions and macros for
      ARM Standard platforms assumed a dual cluster system. This is not
      flexible enough to scale to multi cluster platforms. This patch does
      the following changes for more flexibility in defining topology:
      
      1. The `plat_get_power_domain_tree_desc()` definition is moved from
         `arm_topology.c` to platform specific files, that is `fvp_topology.c`
         and `juno_topology.c`. Similarly the common definition of the porting
         macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform
         specific `platform_def.h` header.
      
      2. The ARM common layer porting macros which were dual cluster specific
         are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced
         which must be defined by each ARM standard platform.
      
      3. A new mandatory ARM common layer porting API
         `plat_arm_get_cluster_core_count()` is introduced to enable the common
         implementation of `arm_check_mpidr()` to validate MPIDR.
      
      4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been
         introduced which allows the user to specify the cluster count to be
         used to build the topology tree within Trusted Firmare. This enables
         Trusted Firmware to be built for multi cluster FVP models.
      
      Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
      0108047a
  20. 18 Feb, 2016 1 commit
    • Juan Castillo's avatar
      ARM platforms: rationalise memory attributes of shared memory · 74eb26e4
      Juan Castillo authored
      The shared memory region on ARM platforms contains the mailboxes and,
      on Juno, the payload area for communication with the SCP. This shared
      memory may be configured as normal memory or device memory at build
      time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on
      Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED').
      When set as normal memory, the platform port performs the corresponding
      cache maintenance operations. From a functional point of view, this is
      the equivalent of setting the shared memory as device memory, so there
      is no need to maintain both options.
      
      This patch removes the option to specify the shared memory as normal
      memory on ARM platforms. Shared memory is always treated as device
      memory. Cache maintenance operations are no longer needed and have
      been replaced by data memory barriers to guarantee that payload and
      MHU are accessed in the right order.
      
      Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f
      74eb26e4
  21. 11 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Re-factor definition of some macros on ARM platforms · ecf70f7b
      Vikram Kanigiri authored
      This patch moves the definition of some macros used only on
      ARM platforms from common headers to platform specific headers.
      It also forces all ARM standard platforms to have distinct
      definitions (even if they are usually the same).
       1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been
           moved from `css_def.h` to `platform_def.h`.
       2. `MHU_BASE` used in CSS platforms is moved from common css_def.h
          to platform specific header `platform_def.h` on Juno and
          renamed as `PLAT_ARM_MHU_BASE`.
       3. To cater for different sizes of BL images, new macros like
          `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All
          ARM platforms need to define them for each image.
      
      Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
      ecf70f7b
  22. 14 Dec, 2015 1 commit
  23. 09 Dec, 2015 2 commits
    • Soby Mathew's avatar
      Specify BL31 runtime console for ARM Standard platforms · 080225da
      Soby Mathew authored
      This patch overrides the default weak definition of
      `bl31_plat_runtime_setup()` for ARM Standard platforms to
      specify a BL31 runtime console. ARM Standard platforms are
      now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and
      `PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required
      by `arm_bl31_plat_runtime_setup()` to initialize the runtime
      console.
      
      The system suspend resume helper `arm_system_pwr_domain_resume()`
      is fixed to initialize the runtime console rather than the boot
      console on resumption from system suspend.
      
      Fixes ARM-software/tf-issues#220
      
      Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
      080225da
    • Achin Gupta's avatar
      Rework use of ARM GIC drivers on ARM platforms · 27573c59
      Achin Gupta authored
      Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
      separate drivers instead of providing a single driver that can work on both
      versions of the GIC architecture. These drivers correspond to the following
      software use cases:
      
      1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
         e.g. GIC-400
      
      2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
         e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features
      
      3. A deprecated GICv3 driver that operates in legacy mode. This driver can
         operate only in the GICv2 mode in the secure world. On a GICv3 system, this
         driver allows normal world to run in either GICv3 mode (asymmetric mode)
         or in the GICv2 mode. Both modes of operation are deprecated on GICv3
         systems.
      
      ARM platforms implement both versions of the GIC architecture. This patch adds a
      layer of abstraction to help ARM platform ports chose the right GIC driver and
      corresponding platform support. This is as described below:
      
      1. A set of ARM common functions have been introduced to initialise the GIC and
         the driver during cold and warm boot. These functions are prefixed as
         "plat_arm_gic_". Weak definitions of these functions have been provided for
         each type of driver.
      
      2. Each platform includes the sources that implement the right functions
         directly into the its makefile. The FVP can be instantiated with different
         versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
         to specify which of the three drivers should be included in the build.
      
      3. A list of secure interrupts has to be provided to initialise each of the
        three GIC drivers. For GIC v3.0 the interrupt ids have to be further
        categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
        types are merged and treated as Group 0 interrupts.
      
        The two lists of interrupts are exported from the platform_def.h. The lists
        are constructed by adding a list of board specific interrupt ids to a list of
        ids common to all ARM platforms and Compute sub-systems.
      
      This patch also makes some fields of `arm_config` data structure in FVP redundant
      and these unused fields are removed.
      
      Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
      27573c59
  24. 30 Oct, 2015 1 commit
    • Soby Mathew's avatar
      CSS: Implement topology support for System power domain · 5f3a6030
      Soby Mathew authored
      This patch implements the necessary topology changes for supporting
      system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and
      PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform
      specific. In addition, the `arm_power_domain_tree_desc[]` and
      `arm_pm_idle_states[]` are modified to support the system power domain
      at level 2. With this patch, even though the power management operations
      involving the system power domain will not return any error, the platform
      layer will silently ignore any operations to the power domain. The actual
      power management support for the system power domain will be added later.
      
      Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
      5f3a6030
  25. 20 Oct, 2015 1 commit
    • Soby Mathew's avatar
      Reorganise PSCI PM handler setup on ARM Standard platforms · 785fb92b
      Soby Mathew authored
      This patch does the following reorganization to psci power management (PM)
      handler setup for ARM standard platform ports :
      
      1. The mailbox programming required during `plat_setup_psci_ops()` is identical
         for all ARM platforms. Hence the implementation of this API is now moved
         to the common `arm_pm.c` file. Each ARM platform now must define the
         PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same
         as ARM_SHARED_RAM_BASE.
      
      2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be
         exported via `plat_arm_psci_pm_ops`. This allows the common implementation
         of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`.
         In the case of CSS platforms, a default weak implementation of the same is
         provided in `css_pm.c` which can be overridden by each CSS platform.
      
      3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now
         made library functions and a new header file `css_pm.h` is added to export
         these generic PM handlers. This allows the platform to reuse the
         adequate CSS PM handlers and redefine others which need to be customized
         when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`.
      
      Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
      785fb92b
  26. 11 Sep, 2015 2 commits
    • Vikram Kanigiri's avatar
      Define the Non-Secure timer frame ID for ARM platforms · 4b1439c5
      Vikram Kanigiri authored
      On Juno and FVP platforms, the Non-Secure System timer corresponds
      to frame 1. However, this is a platform-specific decision and it
      shouldn't be hard-coded. Hence, this patch introduces
      PLAT_ARM_NSTIMER_FRAME_ID which should be used by all ARM platforms
      to specify the correct non-secure timer frame.
      
      Change-Id: I6c3a905d7d89200a2f58c20ce5d1e1d166832bba
      4b1439c5
    • Vikram Kanigiri's avatar
      Re-factor definition of TZC-400 base address · e86c1ff0
      Vikram Kanigiri authored
      This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to
      support different TrustZone Controller base addresses across ARM platforms.
      
      Change-Id: Ie4e1c7600fd7a5875323c7cc35e067de0c6ef6dd
      e86c1ff0
  27. 28 Apr, 2015 2 commits
    • Dan Handley's avatar
      Move FVP port to plat/arm/board/fvp · 3fc4124c
      Dan Handley authored
      Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename
      some of the files so they are consistently prefixed with fvp_.
      Update the platform makefiles accordingly.
      
      Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
      3fc4124c
    • Dan Handley's avatar
      Migrate FVP port to use common code · 60eea55e
      Dan Handley authored
      Major update to the FVP platform port to use the common platform code
      in (include/)plat/arm/* and (include/)plat/common/*. This mainly
      consists of removing duplicated code but also introduces some small
      behavioural changes where there was unnecessary variation between the
      FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
      platform code` for details.
      
      Also add support for Foundation FVP version 9.1 during FVP config
      setup to prevent a warning being emitted in the console.
      
      Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
      60eea55e
  28. 27 Apr, 2015 1 commit
    • Dan Handley's avatar
      Remove use of PLATFORM_CACHE_LINE_SIZE · ce4c820d
      Dan Handley authored
      The required platform constant PLATFORM_CACHE_LINE_SIZE is
      unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the
      same information. CACHE_WRITEBACK_GRANULE is preferred since this
      is an architecturally defined term and allows comparison with the
      corresponding hardware register value.
      
      Replace all usage of PLATFORM_CACHE_LINE_SIZE with
      CACHE_WRITEBACK_GRANULE.
      
      Also, add a runtime assert in BL1 to check that the provided
      CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0.
      
      Change-Id: If87286be78068424217b9f3689be358356500dcd
      ce4c820d
  29. 12 Feb, 2015 2 commits
    • Soby Mathew's avatar
      Export maximum affinity using PLATFORM_MAX_AFFLVL macro · 8c32bc26
      Soby Mathew authored
      This patch removes the plat_get_max_afflvl() platform API
      and instead replaces it with a platform macro PLATFORM_MAX_AFFLVL.
      This is done because the maximum affinity level for a platform
      is a static value and it is more efficient for it to be defined
      as a platform macro.
      
      NOTE: PLATFORM PORTS NEED TO BE UPDATED ON MERGE OF THIS COMMIT
      
      Fixes ARM-Software/tf-issues#265
      
      Change-Id: I31d89b30c2ccda30d28271154d869060d50df7bf
      8c32bc26
    • Soby Mathew's avatar
      Minimize MAX_MMAP_REGIONS for each BL stage · ce41250e
      Soby Mathew authored
      This patch defines MAX_MMAP_REGIONS separately for each BL stage
      as per its requirements. This minimizes the size of the mmap[]
      array.
      
      Fixes ARM-Software/tf-issues#201
      
      Change-Id: I19b15e1a91a8365b2ecf24e2cd71937cb73916b2
      ce41250e
  30. 28 Jan, 2015 3 commits
    • Juan Castillo's avatar
      TBB: authenticate BL3-x images and certificates · dec840af
      Juan Castillo authored
      This patch adds support to authenticate the Trusted Key certificate
      and the BL3-x certificates and images at BL2.
      
      Change-Id: I69a8c13a14c8da8b75f93097d3a4576aed71c5dd
      dec840af
    • Juan Castillo's avatar
      TBB: authenticate BL2 image and certificate · 01df3c14
      Juan Castillo authored
      This patch adds support to authenticate the BL2 content certificate
      and image using the authentication module in BL1.
      
      The FIP driver has been extended to include the BL2 certificate
      UUID.
      
      FVP and Juno ports include the BL2 certificate FIP file
      definition.
      
      Change-Id: I32680e9bd123c8db4a4193c14448c9b32b0e9325
      01df3c14
    • Juan Castillo's avatar
      TBB: add PolarSSL based authentication module · db6071c9
      Juan Castillo authored
      This patch implements an authentication module based on the
      PolarSSL library (v1.3.9) to verify the Chain of Trust when
      Trusted Boot is enabled.
      
      PolarSSL sources must be fetched separately. The POLARSSL_DIR
      build option may be used to indicate the path to the PolarSSL
      main directory (this directory must contain the 'include' and
      'library' subdirectories).
      
      To be able to build PolarSSL sources as a part of the Trusted
      Firmware build process, the DISABLE_PEDANTIC flag in polarssl.mk
      will tell the build system to remove the -pedantic option from
      the CFLAGS.
      
      Inclusion of PolarSSL increases the memory requirements of the BL1
      and BL2 images. The following are the changes made to the FVP and
      Juno platforms to cater for this when TRUSTED_BOARD_BOOT is
      defined:
      
      Changes on FVP:
      
        - BL1 and BL2 stacks have been increased to 4 KB
        - BL1(rw) section has been increased to 32 KB.
        - BL2 memory region has been increased to 112 KB
      
      Changes on Juno:
      
        - BL1 and BL2 stacks have been increased to 4 KB
        - BL1(rw) section has been increased to 32 KB.
        - Trusted ROM region in Flash has been increased to 128 KB.
        - BL2 memory region has been increased to 116 KB
      
      Change-Id: Ie87d80d43408eb6239c4acd0ec5ab2120e4e9e80
      db6071c9
  31. 26 Jan, 2015 1 commit
    • Juan Castillo's avatar
      FVP: Allow BL3-2 to sit in the secure region of DRAM · 513dd3a0
      Juan Castillo authored
      This patch allows the secure payload (BL3-2) to be loaded in the
      DRAM region secured by the TrustZone controller (top 16 MB of DRAM1).
      
      The location of BL3-2 can be selected at build time by setting the
      build flag FVP_TSP_RAM_LOCATION to one of the following options:
      
        - 'tsram' : Trusted SRAM (this is the default option)
        - 'tdram' : Trusted DRAM
        - 'dram'  : Secure region in DRAM1 (top 16MB configured by the
                    TrustZone controller)
      
      The number of MMU tables in BL3-2 depends on its location in
      memory: 3 in case it is loaded in DRAM, 2 otherwise.
      
      Documentation updated accordingly.
      
      Fixes ARM-software/tf-issues#212
      
      Change-Id: I371eef3a4159f06a0c9e3c6c1f4c905b2f93803a
      513dd3a0
  32. 22 Jan, 2015 1 commit
    • Soby Mathew's avatar
      Move bakery algorithm implementation out of coherent memory · 8c5fe0b5
      Soby Mathew authored
      This patch moves the bakery locks out of coherent memory to normal memory.
      This implies that the lock information needs to be placed on a separate cache
      line for each cpu. Hence the bakery_lock_info_t structure is allocated in the
      per-cpu data so as to minimize memory wastage. A similar platform per-cpu
      data is introduced for the platform locks.
      
      As a result of the above changes, the bakery lock api is completely changed.
      Earlier, a reference to the lock structure was passed to the lock implementation.
      Now a unique-id (essentially an index into the per-cpu data array) and an offset
      into the per-cpu data for bakery_info_t needs to be passed to the lock
      implementation.
      
      Change-Id: I1e76216277448713c6c98b4c2de4fb54198b39e0
      8c5fe0b5
  33. 21 Jan, 2015 1 commit
    • Juan Castillo's avatar
      FVP: map non-secure DRAM1 in the MMU · 6fd9eaf3
      Juan Castillo authored
      This patch maps the non-secure region of DRAM1 in the MMU. The
      non-secure region comprises the whole DRAM1 (0x80000000 -
      0xffffffff) excluding the top 16 MB (0xff000000 - 0xffffffff).
      The TrustZone controller configures this 16 MB region as secure
      memory, so it can not be accessed in non-secure mode.
      
      The number of MMU tables in BL2 has been increased to 3 because
      the new size of the non-secure region in DRAM requires an extra L2
      table.
      
      Change-Id: I5ad080c6e181f6b6060e15cebb1d18b7fa128cf5
      6fd9eaf3