1. 14 Apr, 2016 1 commit
    • Gerald Lejeune's avatar
      Dump platform-defined regs in crash reporting · 9ff67fa6
      Gerald Lejeune authored
      
      
      It is up to the platform to implement the new plat_crash_print_regs macro to
      report all relevant platform registers helpful for troubleshooting.
      
      plat_crash_print_regs merges or calls previously defined plat_print_gic_regs
      and plat_print_interconnect_regs macros for each existing platforms.
      
      NOTE: THIS COMMIT REQUIRES ALL PLATFORMS THAT ENABLE THE `CRASH_REPORTING`
      BUILD FLAG TO MIGRATE TO USE THE NEW `plat_crash_print_regs()` MACRO. BY
      DEFAULT, `CRASH_REPORTING` IS ENABLED IN DEBUG BUILDS FOR ALL PLATFORMS.
      
      Fixes: arm-software/tf-issues#373
      Signed-off-by: default avatarGerald Lejeune <gerald.lejeune@st.com>
      9ff67fa6
  2. 31 Mar, 2016 1 commit
  3. 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
  4. 16 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Make SCP_BL2(U) image loading configurable on CSS platforms · 7fb9a32d
      Vikram Kanigiri authored
      Current code mandates loading of SCP_BL2/SCP_BL2U images for all
      CSS platforms. On future ARM CSS platforms, the Application
      Processor (AP) might not need to load these images. So, these
      items can be removed from the FIP on those platforms.
      
      BL2 tries to load  SCP_BL2/SCP_BL2U images if their base
      addresses are defined causing boot error if the images are not
      found in FIP.
      
      This change adds a make flag `CSS_LOAD_SCP_IMAGES` which if set
      to `1` does:
      1. Adds SCP_BL2, SCP_BL2U images to FIP.
      2. Defines the base addresses of these images so that AP loads
         them.
      
      And vice-versa if it is set to `0`. The default value is set to
      `1`.
      
      Change-Id: I5abfe22d5dc1e9d80d7809acefc87b42a462204a
      7fb9a32d
  5. 15 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Support for varying BOM/SCPI protocol base addresses in ARM platforms · 8e083ecd
      Vikram Kanigiri authored
      Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address
      for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To
      cater for future ARM platforms this is made platform specific.
      Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made
      platform specific.
      
      Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
      8e083ecd
  6. 11 Feb, 2016 2 commits
    • Vikram Kanigiri's avatar
      Add support for SSC_VERSION register on CSS platforms · 421295a0
      Vikram Kanigiri authored
      Each ARM Compute Subsystem based platform implements a System Security
      Control (SSC) Registers Unit. The SSC_VERSION register inside it carries
      information to identify the platform. This enables ARM Trusted Firmware
      to compile in support for multiple ARM platforms and choose one at
      runtime. This patch adds macros to enable access to this register.
      Each platform is expected to export its PART_NUMBER separately.
      
      Additionally, it also adds juno part number.
      
      Change-Id: I2b1d5f5b65a9c7b76c6f64480cc7cf0aef019422
      421295a0
    • 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
  7. 14 Dec, 2015 2 commits
    • Juan Castillo's avatar
      Remove dashes from image names: 'BL3-x' --> 'BL3x' · d178637d
      Juan Castillo authored
      This patch removes the dash character from the image name, to
      follow the image terminology in the Trusted Firmware Wiki page:
      
          https://github.com/ARM-software/arm-trusted-firmware/wiki
      
      Changes apply to output messages, comments and documentation.
      
      non-ARM platform files have been left unmodified.
      
      Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
      d178637d
    • Juan Castillo's avatar
      Replace all SCP FW (BL0, BL3-0) references · f59821d5
      Juan Castillo authored
      This patch replaces all references to the SCP Firmware (BL0, BL30,
      BL3-0, bl30) with the image terminology detailed in the TF wiki
      (https://github.com/ARM-software/arm-trusted-firmware/wiki):
      
          BL0          -->  SCP_BL1
          BL30, BL3-0  -->  SCP_BL2
          bl30         -->  scp_bl2
      
      This change affects code, documentation, build system, tools and
      platform ports that load SCP firmware. ARM plaforms have been
      updated to the new porting API.
      
      IMPORTANT: build option to specify the SCP FW image has changed:
      
          BL30 --> SCP_BL2
      
      IMPORTANT: This patch breaks compatibility for platforms that use BL2
      to load SCP firmware. Affected platforms must be updated as follows:
      
          BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
          BL30_BASE --> SCP_BL2_BASE
          bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
          bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()
      
      Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
      f59821d5
  8. 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
  9. 30 Oct, 2015 1 commit
    • Soby Mathew's avatar
      Support PSCI SYSTEM SUSPEND on Juno · c1bb8a05
      Soby Mathew authored
      This patch adds the capability to power down at system power domain level
      on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers
      are modified to add support for power management operations at system
      power domain level. A new helper for populating `get_sys_suspend_power_state`
      handler in plat_psci_ops is defined. On entering the system suspend state,
      the SCP powers down the SYSTOP power domain on the SoC and puts the memory
      into retention mode. On wakeup from the power down, the system components
      on the CSS will be reinitialized by the platform layer and the PSCI client
      is responsible for restoring the context of these system components.
      
      According to PSCI Specification, interrupts targeted to cores in PSCI CPU
      SUSPEND should be able to resume it. On Juno, when the system power domain
      is suspended, the GIC is also powered down. The SCP resumes the final core
      to be suspend when an external wake-up event is received. But the other
      cores cannot be woken up by a targeted interrupt, because GIC doesn't
      forward these interrupts to the SCP. Due to this hardware limitation,
      we down-grade PSCI CPU SUSPEND requests targeted to the system power domain
      level to cluster power domain level in `juno_validate_power_state()`
      and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c.
      
      A system power domain resume helper `arm_system_pwr_domain_resume()` is
      defined for ARM standard platforms which resumes/re-initializes the
      system components on wakeup from system suspend. The security setup also
      needs to be done on resume from system suspend, which means
      `plat_arm_security_setup()` must now be included in the BL3-1 image in
      addition to previous BL images if system suspend need to be supported.
      
      Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
      c1bb8a05
  10. 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
  11. 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
  12. 01 Sep, 2015 1 commit
    • Vikram Kanigiri's avatar
      Configure all secure interrupts on ARM platforms · a7270d35
      Vikram Kanigiri authored
      ARM TF configures all interrupts as non-secure except those which
      are present in irq_sec_array. This patch updates the irq_sec_array
      with the missing secure interrupts for ARM platforms.
      
      It also updates the documentation to be inline with the latest
      implementation.
      
      Fixes ARM-software/tf-issues#312
      
      Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
      a7270d35
  13. 13 Aug, 2015 1 commit
    • Sandrine Bailleux's avatar
      PSCI: Use a single mailbox for warm reset for FVP and Juno · 804040d1
      Sandrine Bailleux authored
      Since there is a unique warm reset entry point, the FVP and Juno
      port can use a single mailbox instead of maintaining one per core.
      The mailbox gets programmed only once when plat_setup_psci_ops()
      is invoked during PSCI initialization. This means mailbox is not
      zeroed out during wakeup.
      
      Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
      804040d1
  14. 09 Jun, 2015 2 commits
    • Sandrine Bailleux's avatar
      CSS: Remove the constants MHU_SECURE_BASE/SIZE · fe55612b
      Sandrine Bailleux authored
      For CSS based platforms, the constants MHU_SECURE_BASE and
      MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes.
      As such, they were misnamed because the mailboxes are completely
      unrelated to the MHU hardware.
      
      This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines.
      The address of the Trusted Mailboxes is now relative to the base of
      the Trusted SRAM.
      
      This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE,
      which is the address of the first memory region used for communication
      between AP and SCP. This is used by the BOM and SCPI protocols.
      
      Change-Id: Ib200f057b19816bf05e834d111271c3ea777291f
      fe55612b
    • Sandrine Bailleux's avatar
      CSS: Clarify what the SCP boot config is · 9255da5f
      Sandrine Bailleux authored
      Add a comment explaining what the SCP boot configuration information
      is on CSS based platforms like Juno. Also express its address
      relatively to the base of the Trusted SRAM rather than hard-coding it.
      
      Change-Id: I82cf708a284c8b8212933074ea8c37bdf48b403b
      9255da5f
  15. 27 May, 2015 1 commit
  16. 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