1. 12 Feb, 2015 1 commit
    • 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
  2. 28 Jan, 2015 5 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
    • Juan Castillo's avatar
      TBB: add a platform specific function to validate the ROTPK · 6eadf762
      Juan Castillo authored
      This patch adds the function plat_match_rotpk() to the platform
      porting layer to provide a Root Of Trust Public key (ROTPK)
      verification mechanism. This function is called during the
      Trusted Board Boot process and receives a supposed valid copy
      of the ROTPK as a parameter, usually obtained from an external
      source (for instance, a certificate). It returns 0 (success) if
      that key matches the actual ROTPK stored in the system or any
      other value otherwise.
      
      The mechanism to access the actual ROTPK stored in the system
      is platform specific and should be implemented as part of this
      function. The format of the ROTPK is also platform specific
      (to save memory, some platforms might store a hash of the key
      instead of the whole key).
      
      TRUSTED_BOARD_BOOT build option has been added to allow the user
      to enable the Trusted Board Boot features. The implementation of
      the plat_match_rotpk() funtion is mandatory when Trusted Board
      Boot is enabled.
      
      For development purposes, FVP and Juno ports provide a dummy
      function that returns always success (valid key). A safe trusted
      boot implementation should provide a proper matching function.
      
      Documentation updated accordingly.
      
      Change-Id: I74ff12bc2b041556c48533375527d9e8c035b8c3
      6eadf762
    • Juan Castillo's avatar
      TBB: add tool to generate certificates · 6f971622
      Juan Castillo authored
      This patch adds a tool that generates all the necessary elements
      to establish the chain of trust (CoT) between the images.
      
      The tool reads the binary images and signing keys and outputs the
      corresponding certificates that will be used by the target at run
      time to verify the authenticity of the images.
      
      Note: the platform port must provide the file platform_oid.h. This
      file will define the OIDs of the x509 extensions that will be added
      to the certificates in order to establish the CoT.
      
      Change-Id: I2734d6808b964a2107ab3a4805110698066a04be
      6f971622
  3. 26 Jan, 2015 1 commit
    • Yatharth Kochar's avatar
      Call reset handlers upon BL3-1 entry. · 79a97b2e
      Yatharth Kochar authored
      This patch adds support to call the reset_handler() function in BL3-1 in the
      cold and warm boot paths when another Boot ROM reset_handler() has already run.
      
      This means the BL1 and BL3-1 versions of the CPU and platform specific reset
      handlers may execute different code to each other. This enables a developer to
      perform additional actions or undo actions already performed during the first
      call of the reset handlers e.g. apply additional errata workarounds.
      
      Typically, the reset handler will be first called from the BL1 Boot ROM. Any
      additional functionality can be added to the reset handler when it is called
      from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used
      to identify whether this is the first version of the reset handler code to be
      executed or an overridden version of the code.
      
      The Cortex-A57 errata workarounds are applied only if they have not already been
      applied.
      
      Fixes ARM-software/tf-issue#275
      
      Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053
      79a97b2e
  4. 23 Jan, 2015 2 commits
    • Soby Mathew's avatar
      Validate power_state and entrypoint when executing PSCI calls · 539dcedb
      Soby Mathew authored
      This patch allows the platform to validate the power_state and
      entrypoint information from the normal world early on in PSCI
      calls so that we can return the error safely. New optional
      pm_ops hooks `validate_power_state` and `validate_ns_entrypoint`
      are introduced to do this.
      
      As a result of these changes, all the other pm_ops handlers except
      the PSCI_ON handler are expected to be successful. Also, the PSCI
      implementation will now assert if a PSCI API is invoked without the
      corresponding pm_ops handler being registered by the platform.
      
      NOTE : PLATFORM PORTS WILL BREAK ON MERGE OF THIS COMMIT. The
      pm hooks have 2 additional optional callbacks and the return type
      of the other hooks have changed.
      
      Fixes ARM-Software/tf-issues#229
      
      Change-Id: I036bc0cff2349187c7b8b687b9ee0620aa7e24dc
      539dcedb
    • Soby Mathew's avatar
      Remove `ns_entrypoint` and `mpidr` from parameters in pm_ops · e146f4cc
      Soby Mathew authored
      This patch removes the non-secure entry point information being passed
      to the platform pm_ops which is not needed. Also, it removes the `mpidr`
      parameter for  platform pm hooks which are meant to do power management
      operations only on the current cpu.
      
      NOTE: PLATFORM PORTS MUST BE UPDATED AFTER MERGING THIS COMMIT.
      
      Change-Id: If632376a990b7f3b355f910e78771884bf6b12e7
      e146f4cc
  5. 22 Jan, 2015 2 commits
    • Soby Mathew's avatar
      Remove coherent memory from the BL memory maps · ab8707e6
      Soby Mathew authored
      This patch extends the build option `USE_COHERENT_MEMORY` to
      conditionally remove coherent memory from the memory maps of
      all boot loader stages. The patch also adds necessary
      documentation for coherent memory removal in firmware-design,
      porting and user guides.
      
      Fixes ARM-Software/tf-issues#106
      
      Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
      ab8707e6
    • 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
  6. 12 Jan, 2015 1 commit
    • Juan Castillo's avatar
      Juno: Add support for image overlaying in Trusted SRAM · 1217d28d
      Juan Castillo authored
      This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W
      section since the former will always be used after the latter.
      Similarly, the BL3-2 NOBITS section can overlay the BL2 image
      when BL3-2 is loaded in Trusted SRAM.
      
      Due to the current size of the images, there is no actual overlap.
      Nevertheless, this reorganization may help to optimise the Trusted
      SRAM usage when the images size grows.
      
      Note that because BL3-1 NOBITS section is allowed to overlap the
      BL1 R/W section, BL1 global variables will remain valid only until
      execution reaches the BL3-1 entry point during a cold boot.
      
      Documentation updated accordingly.
      
      Fixes ARM-software/tf-issues#254
      
      Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
      1217d28d
  7. 10 Dec, 2014 1 commit
    • Sandrine Bailleux's avatar
      Remove IRQ_SEC_SGI_8 constant · 47ca01e7
      Sandrine Bailleux authored
      In both FVP and Juno ports, IRQ #16, which is a PPI, is incorrectly
      identified as secure SGI #8 through the constant IRQ_SEC_SGI_8.
      This patch removes it.
      
      Fixes ARM-software/tf-issues#282
      
      Change-Id: I9e52d849611ffcd2b1f28e56dd156c5b217ed63e
      47ca01e7
  8. 04 Nov, 2014 1 commit
    • Soby Mathew's avatar
      Use the BL3-1 runtime console as the crash console. · ce6ee933
      Soby Mathew authored
      This patch reassigns the crash console on Juno and FVP to use the runtime
      BL3-1 console. The crash console is changed to SoC UART0 (UART2) from the
      previous FPGA UART0 (UART0) on Juno. In FVP, it is changed from UART0 to
      UART1.
      
      Fixes ARM-software/tf-issues#256
      
      Change-Id: I7df54f86ca00ec2652c27261dd66a94c12610816
      ce6ee933
  9. 31 Oct, 2014 1 commit
    • Juan Castillo's avatar
      Juno: Use the generic ARM GIC driver · 33132e64
      Juan Castillo authored
      This patch replaces the usage of the GIC private driver in Juno with
      the generic ARM GIC driver. The private driver is no longer necessary
      and has been removed from the Juno port.
      
      Fixes ARM-software/tf-issues#253
      
      Change-Id: I6aaabc252e5e6fb5fcf44ab6d0febd9b38791056
      33132e64
  10. 29 Oct, 2014 1 commit
    • Soby Mathew's avatar
      Optimize Cortex-A57 cluster power down sequence on Juno · 5541bb3f
      Soby Mathew authored
      This patch optimizes the Cortex-A57 cluster power down sequence by not
      flushing the Level1 data cache. The L1 data cache and the L2 unified
      cache are inclusive. A flush of the L2 by set/way flushes any dirty
      lines from the L1 as well. This is a known safe deviation from the
      Cortex-A57 TRM defined power down sequence. This optimization can be
      enabled by the platform through the 'SKIP_A57_L1_FLUSH_PWR_DWN' build
      flag. Each Cortex-A57 based platform must make its own decision on
      whether to use the optimization.
      
      This patch also renames the cpu-errata-workarounds.md to
      cpu-specific-build-macros.md as this facilitates documentation
      of both CPU Specific errata and CPU Specific Optimization
      build macros.
      
      Change-Id: I299b9fe79e9a7e08e8a0dffb7d345f9a00a71480
      5541bb3f
  11. 21 Oct, 2014 1 commit
    • Vikram Kanigiri's avatar
      Juno: Support entry into a standby state · fc680456
      Vikram Kanigiri authored
      This patch adds support on the Juno platform for entering a wfi in
      response to a PSCI CPU_SUSPEND call where the state type is a
      standby state.
      
      Change-Id: I0a102dee1f8d2ad936c63ad1d1d3ad001a4a4768
      fc680456
  12. 14 Oct, 2014 1 commit
    • Juan Castillo's avatar
      Juno: Reserve some DDR-DRAM for secure use · 740134e6
      Juan Castillo authored
      This patch configures the TrustZone Controller in Juno to split
      the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure
      regions:
      
      - Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are
        used by the SCP for DDR retraining
      - Non-Secure DDR-DRAM: remaining DRAM starting at base address
      
      Build option PLAT_TSP_LOCATION selects the location of the secure
      payload (BL3-2):
      
      - 'tsram' : Trusted SRAM (default option)
      - 'dram'  : Secure region in the DDR-DRAM (set by the TrustZone
                  controller)
      
      The MMU memory map has been updated to give BL2 permission to load
      BL3-2 into the DDR-DRAM secure region.
      
      Fixes ARM-software/tf-issues#233
      
      Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
      740134e6
  13. 09 Oct, 2014 1 commit
    • Juan Castillo's avatar
      Juno: Use TZC-400 driver calls · ef538c6f
      Juan Castillo authored
      This patch replaces direct accesses to the TZC-400 registers by the
      appropiate calls to the generic driver available in the Trusted
      Firmware in order to initialize the TrustZone Controller.
      
      Functions related to the initialization of the secure memory,
      like the TZC-400 configuration, have been moved to a new file
      'plat_security.c'. This reorganization makes easier to set up
      the secure memory from any BL stage.
      
      TZC-400 initialization has been moved from BL1 to BL2 because BL1
      does not access the non-secure memory. It is BL2's responsibility
      to enable and configure the TZC-400 before loading the next BL
      images.
      
      In Juno, BL3-0 initializes some of the platform peripherals, like
      the DDR controller. Thus, BL3-0 must be loaded before configuring
      the TrustZone Controller. As a consequence, the IO layer
      initialization has been moved to early platform initialization.
      
      Fixes ARM-software/tf-issues#234
      
      Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
      ef538c6f
  14. 25 Sep, 2014 1 commit
    • Soby Mathew's avatar
      Create BL stage specific translation tables · d0ecd979
      Soby Mathew authored
      This patch uses the IMAGE_BL<x> constants to create translation tables specific
      to a boot loader stage. This allows each stage to create mappings only for areas
      in the memory map that it needs.
      
      Fixes ARM-software/tf-issues#209
      
      Change-Id: Ie4861407ddf9317f0fb890fc7575eaa88d0de51c
      d0ecd979
  15. 22 Sep, 2014 1 commit
    • Soby Mathew's avatar
      Remove BSS section access by 'plat_print_gic' during crash reporting · 6ab03912
      Soby Mathew authored
      This patch avoids the problem of crash reporting mechanism accessing
      global data in BSS by 'plat_print_gic_regs' for FVP platforms. Earlier
      it depended on the global 'plat_config' object for the GIC Base address
      in FVP platforms which would have caused exception if it were accessed
      before the BSS was initialized. It is now fixed by dynamically
      querying the V2M_SYS_ID to find the FVP model type and accordingly
      selecting the appropriate GIC Base address.
      
      This patch also fixes the 'plat_print_gic_regs' to use the correct GIC
      Distributor base address for printing GICD_IS_PENDR register values
      for both Juno and FVP platforms.
      
      Fixes ARM-Software/tf-issues#236
      
      Change-Id: I545c7b908b3111419bf27db0575ce86acf86784b
      6ab03912
  16. 21 Aug, 2014 6 commits
    • Soby Mathew's avatar
      Rationalize UART usage among different BL stages · 12d554f9
      Soby Mathew authored
      This patch changes the UART port assignment for various BL stages
      so as to make it consistent on the platform ports. The BL1, BL2 and
      BL3-1 now uses UART0 on the FVP port and SoC UART0 on the Juno port.
      The BL3-2 uses UART2 on the FVP port and FPGA UART0 on the Juno
      port.
      
      This provides an interim fix to ARM-software/tf-issues#220 until
      support is added for changing the UART port for a BL image between
      cold boot and runtime.
      
      Change-Id: Iae5faea90be3d59e41e597b34a902f93e737505a
      12d554f9
    • Juan Castillo's avatar
      Juno: Read primary CPU MPID from SCC GPR_1 · 38af430a
      Juan Castillo authored
      This patch removes the PRIMARY_CPU definition hardcoded in the
      Juno port. Instead, the primary CPU is obtained at runtime by
      reading the SCC General Purpose Register 1 (GPR_1), whose value
      is copied by the SCP into shared memory during the boot process.
      
      Change-Id: I3981daa92eb7142250712274cf7f655b219837f5
      38af430a
    • Juan Castillo's avatar
      Juno: Implement PSCI SYSTEM_OFF and SYSTEM_RESET APIs · efafbc89
      Juan Castillo authored
      This patch adds the Juno platform specific handlers for PSCI
      SYSTEM_OFF and SYSTEM_RESET operations.
      
      Change-Id: Ie389adead533ec2314af44d721b4d0f306147c7d
      efafbc89
    • Sandrine Bailleux's avatar
      Juno: Add support for Test Secure-EL1 Payload · edfda10a
      Sandrine Bailleux authored
      This patch implements the TSP on Juno. It executes from on-chip Trusted
      SRAM.
      
      Also, the other bootloader images (i.e. BL1 R/W, BL2 and BL3-1) have
      been moved around. The reason is, although there was enough space
      overall to store the TSP in SRAM, there was no contiguous free chunk
      of SRAM big enough to hold it.
      
      This patch keeps the overall memory layout (i.e. keeping BL1 R/W at
      the bottom, BL2 at the top and BL3-1 in between) but moves the base
      addresses of all the bootloader images in such a way that:
       - memory fragmentation is reduced enough to fit BL3-2 in;
       - new base addresses are suitable for release builds as well as debug
         ones;
       - each image has a few extra kilobytes for future growth.
         BL3-1 and BL3-2 are the images which received the biggest allocations
         since they will most probably grow the most.
      
      This patch also adds instruction synchronization barriers around the code which
      handles the timer interrupt in the TSP. This ensures that the interrupt is not
      acknowledged after or EOIed before it is deactivated at the peripheral.
      
      Change-Id: I1c5b51858700027ee283ac85d18e06863a27c72e
      edfda10a
    • Achin Gupta's avatar
      Juno: Implement PSCI CPU_OFF and CPU_SUSPEND APIs · fef4fdb9
      Achin Gupta authored
      This patch adds support for PSCI CPU_OFF and CPU_SUSPEND APIs to the Juno port
      of the ARM Trusted Firmware. The maximum affinity level that can be suspended is
      the cluster level (affinity level 1). Support for suspending the system level is
      not present.
      
      Change-Id: Ie2c9da0acd7d1b0d5ac64940cdf40347153e52c8
      fef4fdb9
    • Sandrine Bailleux's avatar
      Juno: Implement initial platform port · 01b916bf
      Sandrine Bailleux authored
      This patch adds the initial port of the ARM Trusted Firmware on the Juno
      development platform. This port does not support a BL3-2 image or any PSCI APIs
      apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected
      Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno
      platform errata (Defect id 831273).
      
      Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
      01b916bf