1. 09 Dec, 2015 2 commits
    • 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
    • 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
  2. 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
  3. 26 Nov, 2015 1 commit
    • Sandrine Bailleux's avatar
      CSS: Enable booting of EL3 payloads · 4c117f6c
      Sandrine Bailleux authored
      This patch adds support for booting EL3 payloads on CSS platforms,
      for example Juno. In this scenario, the Trusted Firmware follows
      its normal boot flow up to the point where it would normally pass
      control to the BL31 image. At this point, it jumps to the EL3
      payload entry point address instead.
      
      Before handing over to the EL3 payload, the data SCP writes for AP
      at the beginning of the Trusted SRAM is restored, i.e. we zero the
      first 128 bytes and restore the SCP Boot configuration. The latter
      is saved before transferring the BL30 image to SCP and is restored
      just after the transfer (in BL2). The goal is to make it appear that
      the EL3 payload is the first piece of software to run on the target.
      
      The BL31 entrypoint info structure is updated to make the primary
      CPU jump to the EL3 payload instead of the BL31 image.
      
      The mailbox is populated with the EL3 payload entrypoint address,
      which releases the secondary CPUs out of their holding pen (if the
      SCP has powered them on). The arm_program_trusted_mailbox() function
      has been exported for this purpose.
      
      The TZC-400 configuration in BL2 is simplified: it grants secure
      access only to the whole DRAM. Other security initialization is
      unchanged.
      
      This alternative boot flow is disabled by default. A new build option
      EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
      payload's entry point address. The build system has been modified
      such that BL31 and BL33 are not compiled and/or not put in the FIP in
      this case, as those images are not used in this boot flow.
      
      Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
      4c117f6c
  4. 14 Sep, 2015 1 commit
    • Achin Gupta's avatar
      Add a generic driver for ARM CCN IP · fd6007de
      Achin Gupta authored
      This patch adds a device driver which can be used to program the following
      aspects of ARM CCN IP:
      
      1. Specify the mapping between ACE/ACELite/ACELite+DVM/CHI master interfaces and
         Request nodes.
      2. Add and remove master interfaces from the snoop and dvm
         domains.
      3. Place the L3 cache in a given power state.
      4. Configuring system adress map and enabling 3 SN striping mode of memory
         controller operation.
      
      Change-Id: I0f665c6a306938e5b66f6a92f8549b529aa8f325
      fd6007de
  5. 13 Aug, 2015 2 commits
    • Soby Mathew's avatar
      PSCI: Demonstrate support for composite power states · 2204afde
      Soby Mathew authored
      This patch adds support to the Juno and FVP ports for composite power states
      with both the original and extended state-id power-state formats. Both the
      platform ports use the recommended state-id encoding as specified in
      Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
      ARM_RECOM_STATE_ID_ENC is used to include this support.
      
      By default, to maintain backwards compatibility, the original power state
      parameter format is used and the state-id field is expected to be zero.
      
      Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
      2204afde
    • Soby Mathew's avatar
      PSCI: Migrate ARM reference platforms to new platform API · 38dce70f
      Soby Mathew authored
      This patch migrates ARM reference platforms, Juno and FVP, to the new platform
      API mandated by the new PSCI power domain topology and composite power state
      frameworks. The platform specific makefiles now exports the build flag
      ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.
      
      Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
      38dce70f
  6. 25 Jun, 2015 2 commits
    • Juan Castillo's avatar
      TBB: switch to the new authentication framework · 1779ba6b
      Juan Castillo authored
      This patch modifies the Trusted Board Boot implementation to use
      the new authentication framework, making use of the authentication
      module, the cryto module and the image parser module to
      authenticate the images in the Chain of Trust.
      
      A new function 'load_auth_image()' has been implemented. When TBB
      is enabled, this function will call the authentication module to
      authenticate parent images following the CoT up to the root of
      trust to finally load and authenticate the requested image.
      
      The platform is responsible for picking up the right makefiles to
      build the corresponding cryptographic and image parser libraries.
      ARM platforms use the mbedTLS based libraries.
      
      The platform may also specify what key algorithm should be used
      to sign the certificates. This is done by declaring the 'KEY_ALG'
      variable in the platform makefile. FVP and Juno use ECDSA keys.
      
      On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
      each to accommodate the ECDSA code.
      
      REMOVED BUILD OPTIONS:
      
        * 'AUTH_MOD'
      
      Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
      1779ba6b
    • Juan Castillo's avatar
      TBB: add TBBR Chain of Trust · dff93c86
      Juan Castillo authored
      This patch adds a CoT based on the Trusted Board Boot Requirements
      document*. The CoT consists of an array of authentication image
      descriptors indexed by the image identifiers.
      
      A new header file with TBBR image identifiers has been added.
      Platforms that use the TBBR (i.e. ARM platforms) may reuse these
      definitions as part of their platform porting.
      
      PLATFORM PORT - IMPORTANT:
      
      Default image IDs have been removed from the platform common
      definitions file (common_def.h). As a consequence, platforms that
      used those common definitons must now either include the IDs
      provided by the TBBR header file or define their own IDs.
      
      *The NVCounter authentication method has not been implemented yet.
      
      Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5
      dff93c86
  7. 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
  8. 16 Mar, 2015 1 commit
  9. 28 Jan, 2015 1 commit
    • 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
  10. 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
  11. 22 Oct, 2014 1 commit
    • Juan Castillo's avatar
      FVP: keep shared data in Trusted SRAM · 20d51cad
      Juan Castillo authored
      This patch deprecates the build option to relocate the shared data
      into Trusted DRAM in FVP. After this change, shared data is always
      located at the base of Trusted SRAM. This reduces the complexity
      of the memory map and the number of combinations in the build
      options.
      
      Fixes ARM-software/tf-issues#257
      
      Change-Id: I68426472567b9d8c6d22d8884cb816f6b61bcbd3
      20d51cad
  12. 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
  13. 14 Aug, 2014 2 commits
    • Dan Handley's avatar
      Move IO storage source to drivers directory · 935db693
      Dan Handley authored
      Move the remaining IO storage source file (io_storage.c) from the
      lib to the drivers directory. This requires that platform ports
      explicitly add this file to the list of source files.
      
      Also move the IO header files to a new sub-directory, include/io.
      
      Change-Id: I862b1252a796b3bcac0d93e50b11e7fb2ded93d6
      935db693
    • Juan Castillo's avatar
      FVP: make usage of Trusted DRAM optional at build time · 186c1d4b
      Juan Castillo authored
      This patch groups the current contents of the Trusted DRAM region at
      address 0x00_0600_0000 (entrypoint mailboxes and BL3-1 parameters) in
      a single shared memory area that may be allocated to Trusted SRAM
      (default) or Trusted DRAM at build time by setting the
      FVP_SHARED_DATA_LOCATION make variable. The size of this shared
      memory is 4096 bytes.
      
      The combination 'Shared data in Trusted SRAM + TSP in Trusted DRAM'
      is not currently supported due to restrictions in the maximum number
      of mmu tables that can be created.
      
      Documentation has been updated to reflect these changes.
      
      Fixes ARM-software/tf-issues#100
      
      Change-Id: I26ff04d33ce4cacf8d770d1a1e24132b4fc53ff0
      186c1d4b
  14. 12 Aug, 2014 1 commit
    • Juan Castillo's avatar
      FVP: apply new naming conventions to memory regions · 637ebd2e
      Juan Castillo authored
      Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
      Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
      Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM
      
      BLn_BASE and BLn_LIMIT definitions have been updated and are based on
      these new memory regions.
      
      The available memory for each bootloader in the linker script is
      defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
      region.
      
      TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
      the platform porting.
      
      FVP common definitions are defined in fvp_def.h while platform_def.h
      contains exclusively (with a few exceptions) the definitions that are
      mandatory in the porting guide. Therefore, platform_def.h now includes
      fvp_def.h instead of the other way around.
      
      Porting guide has been updated to reflect these changes.
      
      Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
      637ebd2e
  15. 28 Jul, 2014 1 commit
    • Soby Mathew's avatar
      Introduce asm console functions in TF · fce5f750
      Soby Mathew authored
      This patch replaces the pl011 console family of functions
      with their equivalents defined in assembly. The baud rate is
      defined by the PL011_BAUDRATE macro and IBRD and FBRD values
      for pl011 are computed statically. This patch will enable
      us to invoke the console functions without the C Runtime Stack.
      
      Change-Id: Ic3f7b7370ded38bf9020bf746b362081b76642c7
      fce5f750
  16. 17 Jul, 2014 1 commit
    • Sandrine Bailleux's avatar
      Define ARM_GIC_ARCH default value for all platforms · 2b98e789
      Sandrine Bailleux authored
      The ARM_GIC_ARCH build option was supposed to default to 2 on all
      platforms. However, the default value was set in the FVP makefile
      so for all other platforms it wasn't even defined.
      
      This patch moves the default value to the main Makefile. The platform
      port can then override it if needed.
      
      Change-Id: I8e2da1cce7ffa3ed18814bbdcbcf2578101f18a6
      2b98e789
  17. 09 Jul, 2014 1 commit
    • Dan Handley's avatar
      Refactor fvp gic code to be a generic driver · 1e8c5c4f
      Dan Handley authored
      Refactor the FVP gic code in plat/fvp/fvp_gic.c to be a generic ARM
      GIC driver in drivers/arm/gic/arm_gic.c. Provide the platform
      specific inputs in the arm_gic_setup() function so that the driver
      has no explicit dependency on platform code.
      
      Provide weak implementations of the platform interrupt controller
      API in a new file, plat/common/plat_gic.c. These simply call through
      to the ARM GIC driver.
      
      Move the only remaining FVP GIC function, fvp_gic_init() to
      plat/fvp/aarch64/fvp_common.c and remove plat/fvp/fvp_gic.c
      
      Fixes ARM-software/tf-issues#182
      
      Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21
      1e8c5c4f
  18. 24 Jun, 2014 2 commits
    • Andrew Thoelke's avatar
      Inline the mmio accessor functions · 5e113753
      Andrew Thoelke authored
      Making the simple mmio_read_*() and mmio_write_*() functions inline
      saves 360 bytes of code in FVP release build.
      
      Fixes ARM-software/tf-issues#210
      
      Change-Id: I65134f9069f3b2d8821d882daaa5fdfe16355e2f
      5e113753
    • Vikram Kanigiri's avatar
      Simplify entry point information generation code on FVP · 03396c43
      Vikram Kanigiri authored
      This patch reworks FVP specific code responsible for determining
      the entry point information for BL3-2 and BL3-3 stages when BL3-1
      is configured as the reset handler.
      
      Change-Id: Ia661ff0a6a44c7aabb0b6c1684b2e8d3642d11ec
      03396c43
  19. 10 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Make system register functions inline assembly · 5c3272a7
      Andrew Thoelke authored
      Replace the current out-of-line assembler implementations of
      the system register and system instruction operations with
      inline assembler.
      
      This enables better compiler optimisation and code generation
      when accessing system registers.
      
      Fixes ARM-software/tf-issues#91
      
      Change-Id: I149af3a94e1e5e5140a3e44b9abfc37ba2324476
      5c3272a7
  20. 23 May, 2014 2 commits
    • Dan Handley's avatar
      Add enable mmu platform porting interfaces · dff8e47a
      Dan Handley authored
      Previously, the enable_mmu_elX() functions were implicitly part of
      the platform porting layer since they were included by generic
      code. These functions have been placed behind 2 new platform
      functions, bl31_plat_enable_mmu() and bl32_plat_enable_mmu().
      These are weakly defined so that they can be optionally overridden
      by platform ports.
      
      Also, the enable_mmu_elX() functions have been moved to
      lib/aarch64/xlat_tables.c for optional re-use by platform ports.
      These functions are tightly coupled with the translation table
      initialization code.
      
      Fixes ARM-software/tf-issues#152
      
      Change-Id: I0a2251ce76acfa3c27541f832a9efaa49135cc1c
      dff8e47a
    • Dan Handley's avatar
      Rename FVP specific files and functions · 17a387ad
      Dan Handley authored
      FVP specific files and functions containing the word "plat" have been
      renamed to use the word "fvp" to distinguish them from the common
      platform functionality and porting functions.
      
      Change-Id: I39f9673dab3ee9c74bd18b3e62b7c21027232f7d
      17a387ad
  21. 22 May, 2014 3 commits
    • Achin Gupta's avatar
      Introduce interrupt registration framework in BL3-1 · e1333f75
      Achin Gupta authored
      This patch introduces a framework for registering interrupts routed to
      EL3. The interrupt routing model is governed by the SCR_EL3.IRQ and
      FIQ bits and the security state an interrupt is generated in. The
      framework recognizes three type of interrupts depending upon which
      exception level and security state they should be handled in
      i.e. Secure EL1 interrupts, Non-secure interrupts and EL3
      interrupts. It provides an API and macros that allow a runtime service
      to register an handler for a type of interrupt and specify the routing
      model. The framework validates the routing model and uses the context
      management framework to ensure that it is applied to the SCR_EL3 prior
      to entry into the target security state. It saves the handler in
      internal data structures. An API is provided to retrieve the handler
      when an interrupt of a particular type is asserted. Registration is
      expected to be done once by the primary CPU. The same handler and
      routing model is used for all CPUs.
      
      Support for EL3 interrupts will be added to the framework in the
      future. A makefile flag has been added to allow the FVP port choose
      between ARM GIC v2 and v3 support in EL3. The latter version is
      currently unsupported.
      
      A framework for handling interrupts in BL3-1 will be introduced in
      subsequent patches. The default routing model in the absence of any
      handlers expects no interrupts to be routed to EL3.
      
      Change-Id: Idf7c023b34fcd4800a5980f2bef85e4b5c29e649
      e1333f75
    • Sandrine Bailleux's avatar
      fvp: Move TSP from Secure DRAM to Secure SRAM · 53514b29
      Sandrine Bailleux authored
      The TSP used to execute from secure DRAM on the FVPs because there was
      not enough space in Trusted SRAM to fit it in. Thanks to recent RAM
      usage enhancements being implemented, we have made enough savings for
      the TSP to execute in SRAM.
      
      However, there is no contiguous free chunk of SRAM big enough to hold
      the TSP. Therefore, the different bootloader images need to be moved
      around to reduce memory fragmentation. 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 slice
         of the cake since they will most probably grow the most.
      
      A few useful numbers for reference (valid at the time of this patch):
              |-----------------------|-------------------------------
              |  image size (debug)   |  extra space for the future
      --------|-----------------------|-------------------------------
      BL1 R/W |         20 KB         |            4 KB
      BL2     |         44 KB         |            4 KB
      BL3-1   |        108 KB         |           12 KB
      BL3-2   |         56 KB         |            8 KB
      --------|-----------------------|-------------------------------
      Total   |        228 KB         |           28 KB       = 256 KB
      --------|-----------------------|-------------------------------
      
      Although on FVPs the TSP now executes from Trusted SRAM by default,
      this patch keeps the option to execute it from Trusted DRAM. This is
      controlled by the build configuration 'TSP_RAM_LOCATION'.
      
      Fixes ARM-Software/tf-issues#81
      
      Change-Id: Ifb9ef2befa9a2d5ac0813f7f79834df7af992b94
      53514b29
    • Vikram Kanigiri's avatar
      Add support for BL3-1 as a reset vector · dbad1bac
      Vikram Kanigiri authored
      This change adds optional reset vector support to BL3-1
      which means BL3-1 entry point can detect cold/warm boot,
      initialise primary cpu, set up cci and mail box.
      
      When using BL3-1 as a reset vector it is assumed that
      the BL3-1 platform code can determine the location of
      the BL3-2 images, or load them as there are no parameters
      that can be passed to BL3-1 at reset.
      
      It also fixes the incorrect initialisation of mailbox
      registers on the FVP platform
      
      This feature can be enabled by building the code with
      make variable RESET_TO_BL31 set as 1
      
      Fixes ARM-software/TF-issues#133
      Fixes ARM-software/TF-issues#20
      
      Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570
      dbad1bac
  22. 16 May, 2014 1 commit
    • Soby Mathew's avatar
      Rework BL3-1 unhandled exception handling and reporting · a43d431b
      Soby Mathew authored
      This patch implements the register reporting when unhandled exceptions are
      taken in BL3-1. Unhandled exceptions will result in a dump of registers
      to the console, before halting execution by that CPU. The Crash Stack,
      previously called the Exception Stack, is used for this activity.
      This stack is used to preserve the CPU context and runtime stack
      contents for debugging and analysis.
      
      This also introduces the per_cpu_ptr_cache, referenced by tpidr_el3,
      to provide easy access to some of BL3-1 per-cpu data structures.
      Initially, this is used to provide a pointer to the Crash stack.
      
      panic() now prints the the error file and line number in Debug mode
      and prints the PC value in release mode.
      
      The Exception Stack is renamed to Crash Stack with this patch.
      The original intention of exception stack is no longer valid
      since we intend to support several valid exceptions like IRQ
      and FIQ in the trusted firmware context. This stack is now
      utilized for dumping and reporting the system state when a
      crash happens and hence the rename.
      
      Fixes ARM-software/tf-issues#79 Improve reporting of unhandled exception
      
      Change-Id: I260791dc05536b78547412d147193cdccae7811a
      a43d431b
  23. 06 May, 2014 3 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 FVP power driver to FVP platform · e8246c07
      Dan Handley authored
      Move the FVP power driver to a directory under the FVP platform
      port as this is not a generically usable driver.
      
      Change-Id: Ibc78bd88752eb3e3964336741488349ac345f4f0
      e8246c07
    • 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
  24. 24 Apr, 2014 1 commit
    • Harry Liebel's avatar
      Enable secure memory support for FVPs · f2199d95
      Harry Liebel authored
      - Use the TrustZone controller on Base FVP to program DRAM access
        permissions. By default no access to DRAM is allowed if
        'secure memory' is enabled on the Base FVP.
      - The Foundation FVP does not have a TrustZone controller but instead
        has fixed access permissions.
      - Update FDTs for Linux to use timers at the correct security level.
      - Starting the FVPs with 'secure memory' disabled is also supported.
      
      Limitations:
      Virtio currently uses a reserved NSAID. This will be corrected in
      future FVP releases.
      
      Change-Id: I0b6c003a7b5982267815f62bcf6eb82aa4c50a31
      f2199d95
  25. 15 Apr, 2014 1 commit
    • Andrew Thoelke's avatar
      Allocate single stacks for BL1 and BL2 · 2bf28e62
      Andrew Thoelke authored
      The BL images share common stack management code which provides
      one coherent and one cacheable stack for every CPU. BL1 and BL2
      just execute on the primary CPU during boot and do not require
      the additional CPU stacks. This patch provides separate stack
      support code for UP and MP images, substantially reducing the
      RAM usage for BL1 and BL2 for the FVP platform.
      
      This patch also provides macros for declaring stacks and
      calculating stack base addresses to improve consistency where
      this has to be done in the firmware.
      
      The stack allocation source files are now included via
      platform.mk rather than the common BLx makefiles. This allows
      each platform to select the appropriate MP/UP stack support
      for each BL image.
      
      Each platform makefile must be updated when including this
      commit.
      
      Fixes ARM-software/tf-issues#76
      
      Change-Id: Ia251f61b8148ffa73eae3f3711f57b1ffebfa632
      2bf28e62
  26. 14 Apr, 2014 1 commit
    • Dan Handley's avatar
      Move console.c to pl011 specific driver location · d72f6e31
      Dan Handley authored
      Rename drivers/console/console.c to
      drivers/arm/peripherals/pl011/pl011_console.c. This makes it clear
      that this is a pl011 specific console implementation.
      
      Fixes ARM-software/tf-issues#129
      
      Change-Id: Ie2f8109602134c5b86993e32452c70734c45a3ed
      d72f6e31
  27. 26 Mar, 2014 1 commit
    • Soby Mathew's avatar
      Move console functions out of pl011.c · c1df3be7
      Soby Mathew authored
      This commit isolates the accessor functions in pl011.c and builds
      a wrapper layer for console functions.
      
      This also modifies the console driver to use the pl011 FIFO.
      
      Fixes ARM-software/tf-issues#63
      
      Change-Id: I3b402171cd14a927831bf5e5d4bb310b6da0e9a8
      c1df3be7
  28. 05 Mar, 2014 2 commits
    • Jon Medhurst's avatar
      fvp: Make use of the generic MMU translation table setup code · 38aa76a8
      Jon Medhurst authored
      
      
      Change-Id: I559c5a4d86cad55ce3f6ad71285b538d3cfd76dc
      Signed-off-by: default avatarJon Medhurst <tixy@linaro.org>
      38aa76a8
    • 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
  29. 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