1. 28 Feb, 2018 5 commits
    • Roberto Vargas's avatar
      Fix MISRA rule 8.4 Part 2 · fd116b9f
      Roberto Vargas authored
      
      
      Rule 8.4: A compatible declaration shall be visible when
                an object or function with external linkage is defined
      
      Fixed for:
      	make DEBUG=1 PLAT=juno LOG_LEVEL=50 all
      
      Change-Id: Ic8f611da734f356566e8208053296e6c62b54709
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      fd116b9f
    • Roberto Vargas's avatar
      Fix MISRA rule 8.4 Part 1 · 1af540ef
      Roberto Vargas authored
      
      
      Rule 8.4: A compatible declaration shall be visible when
                an object or function with external linkage is defined
      
      Fixed for:
      	make DEBUG=1 PLAT=fvp LOG_LEVEL=50 all
      
      Change-Id: I7c2ad3f5c015411c202605851240d5347e4cc8c7
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      1af540ef
    • Roberto Vargas's avatar
      Fix MISRA rule 8.3 Part 1 · dc6aad2e
      Roberto Vargas authored
      
      
      Rule 8.3: All declarations of an object or function shall
                use the same names and type qualifiers.
      
      Fixed for:
      
      	make DEBUG=1 PLAT=fvp LOG_LEVEL=50 all
      
      Change-Id: I48201c9ef022f6bd42ea8644529afce70f9b3f22
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      dc6aad2e
    • Jeenu Viswambharan's avatar
      FVP: Allow building for DynamIQ systems · fe7210cd
      Jeenu Viswambharan authored
      
      
      FVPs that model DynamIQ configuration implements all CPUs in a single
      cluster. I.e., such models have a single cluster with more than 4 CPUs.
      This differs from existing default build configuration for FVP where up
      to 4 CPUs are assumed per cluster.
      
      To allow building for DynamIQ configuration, promote the macro
      FVP_MAX_CPUS_PER_CLUSTER as a build option to have it set from the build
      command line. The value of the build option defaults to 4.
      
      Change-Id: Idc3853bc95f680869b434b011c2dbd733e40c6ce
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      fe7210cd
    • Sandrine Bailleux's avatar
      Select SCMI/SDS drivers by default on Juno · 01e808c6
      Sandrine Bailleux authored
      
      
      The SCP binaries provided in the 17.10 Linaro release (and onwards)
      have migrated to the SCMI/SDS protocols. Therefore, the ARM TF should
      now use the corresponding drivers by default.
      
      This patch changes the default value of the CSS_USE_SCMI_SDS_DRIVER
      build option to 1 for Juno.
      
      Change-Id: Idb7e3c6af582f49e332167a2158703c2d781b437
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      01e808c6
  2. 27 Feb, 2018 4 commits
  3. 26 Feb, 2018 5 commits
    • Soby Mathew's avatar
      Dynamic cfg: MISRA fixes · da5f2745
      Soby Mathew authored
      
      
      Change-Id: I1d85b76af002b8b672fcaeca94939b7420bc8243
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      da5f2745
    • Soby Mathew's avatar
      FVP: Add TB_FW_CONFIG and HW_CONFIG · ce6d9643
      Soby Mathew authored
      
      
      This patch adds TB_FW_CONFIG for FVP and allows FVP
      to select the appropriate HW_CONFIG to include in the
      fip. The HW_CONFIG for FVP is selected via `FVP_HW_CONFIG_DTS`
      build option. The TB_FW_CONFIG specifies the load address of
      HW_CONFIG to BL2. Since currently the load address is different
      between AARCH32 and AARCH64, 2 separate TB_FW_CONFIGs are
      maintained for the 2 modes.
      
      Change-Id: Ide8581e752dfa900087f5895c775073c841c0daf
      Signed-Off-By: default avatarSoby Mathew <soby.mathew@arm.com>
      ce6d9643
    • Soby Mathew's avatar
      ARM Platforms: Load HW_CONFIG in BL2 · cab0b5b0
      Soby Mathew authored
      
      
      The patch adds the necessary changes to load HW_CONFIG in BL2 for
      ARM Platforms :
      
      1. The load address of HW_CONFIG is specified via the `hw_config_addr`
      property in TB_FW_CONFIG is loaded by BL1. The `hw_config_max_size`
      property defines the maximum size to be expected for the HW_CONFIG.
      The `arm_dyn_cfg_helpers.c` and corresponding header implements
      utility functions to parse these DT properties defined.
      The `arm_dyn_cfg.c` implements wrappers to these helpers to enable
      them to be invoked from ARM platform layer.
      
      2. `HW_CONFIG` is added to the `bl2_mem_params_descs[]` array which is
      the list of images to be loaded by BL2.
      
      3. The `libfdt` sources are now included when BL2 is built
      
      4. A new helper `populate_next_bl_params_config()` is introduced in
      desc_image_load.c to populate the subsequent executable BL images
      with the `hw_config` and the corresponding `fw_config` if available.
      The `plat_get_next_bl_params()` API for ARM platforms is modified to
      invoke this new helper.
      
      5. The implementation of `bl2_early_platform_setup2()` is modified to
      consider `arg0` as well in addition to `arg1` passed from BL1.
      
      6. Bump up the BL2 size for Juno to accommodate the inclusion of libfdt.
      
      Change-Id: I80f1554adec41753e0d179a5237364f04fe13a3f
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      cab0b5b0
    • Soby Mathew's avatar
      ARM Platorms: Load TB_FW_CONFIG in BL1 · c228956a
      Soby Mathew authored
      
      
      This patch modifies the bl1_platform_setup() API to load and authenticate
      TB_FW_CONFIG in BL1. The load address of the same is passed on to BL2 in
      `arg0` of entrypoint info. The fvp_io_storage.c and arm_io_storage.c also
      adds entries corresponding to TB_FW_CONFIG. A helper function
      `arm_load_tb_fw_config()` is added to load and authenticate TB_FW_CONFIG
      if present.
      
      Change-Id: Ie7bce667b3fad2b1a083bbcbc0a773f9f04254b1
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      c228956a
    • Soby Mathew's avatar
      ARM Platforms: Migrate to new BL handover interface · 0c306cc0
      Soby Mathew authored
      
      
      This patch migrates the ARM Standard platforms to the new BL
      handover interface. The arm_blx_early_platform_setup() functions
      are also modified to take in 4 arguments. The `ARM_BL31_PLAT_PARAM_VAL`
      value passed to BL31 from BL2 is now in arg3 in preparation of dynamic
      configuration arguments.
      
      Change-Id: I33e8e61325a19e7a7127b1ff203c3b86921bf153
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      0c306cc0
  4. 29 Jan, 2018 1 commit
    • Sandrine Bailleux's avatar
      SPM: Map devices in the 1st GB · c4fa1739
      Sandrine Bailleux authored
      
      
      This patch maps the devices in the first GB of the system address map
      on the FVP into the S-EL1&0 translation regime when SPM support is
      enabled. This grants the Secure Partition access to the devices in
      this region, for example the memory-mapped Generic Timer device.
      
      Change-Id: I3aeea65f859ecbe83efde2acee20c55500c451bc
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      c4fa1739
  5. 18 Jan, 2018 2 commits
    • Roberto Vargas's avatar
      bl2-el3: Don't compile BL1 when BL2_AT_EL3 is defined in FVP · 76d26733
      Roberto Vargas authored
      
      
      This patch modifies the makefiles to avoid the definition
      of BL1_SOURCES and BL2_SOURCES in the tbbr makefiles, and
      it lets to the platform makefiles to define them if they
      actually need these images. In the case of BL2_AT_EL3
      BL1 will not be needed usually because the Boot ROM will
      jump directly to BL2.
      
      Change-Id: Ib6845a260633a22a646088629bcd7387fe35dcf9
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      76d26733
    • Roberto Vargas's avatar
      bl2-el3: Add BL2 at EL3 support in FVP · 81528dbc
      Roberto Vargas authored
      
      
      This patch add supports for the new API added for BL2 at EL3 for
      FVP. We don't have a non-TF Boot ROM for FVP, but this option can be
      tested setting specific parameters in the model.
      
      The bl2 image is loaded directly in memory instead of being loaded
      by a non-TF Boot ROM and the reset address is changed:
      
      	--data cluster0.cpu0=bl2.bin@0x4001000
      	-C cluster0.cpu0.RVBAR=0x4001000
      
      These parameters mean that in the cold boot path the processor will
      jump to BL2 again. For this reason, BL2 is loaded in dram in this
      case, to avoid other images reclaiming BL2 memory.
      
      Change-Id: Ieb2ff8535a9e67ccebcd8c2212cad366e7776422
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      81528dbc
  6. 11 Jan, 2018 1 commit
  7. 19 Dec, 2017 1 commit
  8. 06 Dec, 2017 2 commits
  9. 30 Nov, 2017 1 commit
    • David Cunado's avatar
      Do not enable SVE on pre-v8.2 platforms · 3872fc2d
      David Cunado authored
      
      
      Pre-v8.2 platforms such as the Juno platform does not have
      the Scalable Vector Extensions implemented and so the build
      option ENABLE_SVE is set to zero.
      
      This has a minor performance improvement with no functional
      impact.
      
      Change-Id: Ib072735db7a0247406f8b60e325b7e28b1e04ad1
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      3872fc2d
  10. 29 Nov, 2017 3 commits
    • Soby Mathew's avatar
      Juno AArch32: Remove duplicate definition of bl2 platform API · a9f9b608
      Soby Mathew authored
      
      
      The bl2_early_platform_setup() and bl2_platform_setup() were
      redefined for Juno AArch32 eventhough CSS platform layer had
      same definition for them. The CSS definitions definitions were
      previously restricted to EL3_PAYLOAD_BASE builds and this is now
      modified to include the Juno AArch32 builds as well thus
      allowing us to remove the duplicate definitions in Juno platform
      layer.
      
      Change-Id: Ibd1d8c1428cc1d51ac0ba90f19f5208ff3278ab5
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      a9f9b608
    • Soby Mathew's avatar
      ARM platforms: Fixup AArch32 builds · 5744e874
      Soby Mathew authored
      
      
      This patch fixes a couple of issues for AArch32 builds on ARM reference
      platforms :
      
      1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and
         AArch32 build. Since BL31 is not present in AArch32 mode, this meant that
         the BL31 memory is empty when built for AArch32. Hence this patch allocates
         BL32 to the memory region occupied by BL31 for AArch32 builds.
      
         As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot
         be used to control the load address of BL32 in AArch32 mode which was
         never the intention of the macro anyway.
      
      2. A static assert is added to sp_min linker script to check that the progbits
         are within the bounds expected when overlaid with other images.
      
      3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks
         involved when building Juno for AArch32 mode, the build option SPD needed to
         specifed. This patch corrects this and also updates the documentation in the
         user-guide.
      
      4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As
         a result the previous assumption that BL31 must be always present is removed
         and the certificates for BL31 is only generated if `NEED_BL31` is defined.
      
      Change-Id: I1c39bbc0abd2be8fbe9f2dea2e9cb4e3e3e436a8
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      5744e874
    • Dimitris Papastamos's avatar
      fvp: Enable the Activity Monitor Unit extensions by default · 3a6a9adc
      Dimitris Papastamos authored
      
      
      Change-Id: I96de88f44c36681ad8a70430af8e01016394bd14
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      3a6a9adc
  11. 20 Nov, 2017 1 commit
    • Dimitris Papastamos's avatar
      Refactor Statistical Profiling Extensions implementation · 281a08cc
      Dimitris Papastamos authored
      
      
      Factor out SPE operations in a separate file.  Use the publish
      subscribe framework to drain the SPE buffers before entering secure
      world.  Additionally, enable SPE before entering normal world.
      
      A side effect of this change is that the profiling buffers are now
      only drained when a transition from normal world to secure world
      happens.  Previously they were drained also on return from secure
      world, which is unnecessary as SPE is not supported in S-EL1.
      
      Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      281a08cc
  12. 13 Nov, 2017 1 commit
    • Jeenu Viswambharan's avatar
      ARM platforms: Make arm_validate_ns_entrypoint() common · 71e7a4e5
      Jeenu Viswambharan authored
      
      
      The function arm_validate_ns_entrypoint() validates a given non-secure
      physical address. This function however specifically returns PSCI error
      codes.
      
      Non-secure physical address validation is potentially useful across ARM
      platforms, even for non-PSCI use cases. Therefore make this function
      common by returning 0 for success or -1 otherwise.
      
      Having made the function common, make arm_validate_psci_entrypoint() a
      wrapper around arm_validate_ns_entrypoint() which only translates return
      value into PSCI error codes. This wrapper is now used where
      arm_validate_ns_entrypoint() was currently used for PSCI entry point
      validation.
      
      Change-Id: Ic781fc3105d6d199fd8f53f01aba5baea0ebc310
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      71e7a4e5
  13. 09 Nov, 2017 1 commit
  14. 25 Oct, 2017 1 commit
  15. 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
  16. 11 Oct, 2017 2 commits
    • 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
    • Soby Mathew's avatar
      ARM platforms: Add support for EL3 TZC memory region · a22dffc6
      Soby Mathew authored
      
      
      Some recent enhancements to EL3 runtime firmware like support for
      save and restoring GICv3 register context during system_suspend
      necessitates additional data memory for the firmware. This patch
      introduces support for creating a TZC secured DDR carveout for use
      by ARM reference platforms. A new linker section `el3_tzc_dram` is
      created using platform supplied linker script and data marked with
      the attribute `arm_el3_tzc_dram` will be placed in this section.
      The FVP makefile now defines the `PLAT_EXTRA_LD_SCRIPT` variable to
      allow inclusion of the platform linker script by the top level BL31
      linker script.
      
      Change-Id: I0e7f4a75a6ac51419c667875ff2677043df1585d
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      a22dffc6
  17. 05 Oct, 2017 1 commit
    • Soby Mathew's avatar
      GICv3: add functions for save and restore · ebf1ca10
      Soby Mathew authored
      
      
      During system suspend, the GICv3 Distributor and Redistributor context
      can be lost due to power gating of the system power domain. This means
      that the GICv3 context needs to be saved prior to system suspend and
      restored on wakeup. Currently the consensus is that the Firmware should
      be in charge of this. See tf-issues#464 for more details.
      
      This patch introduces helper APIs in the GICv3 driver to save and
      restore the Distributor and Redistributor contexts. The GICv3 ITS
      context is not considered in this patch because the specification says
      that the details of ITS power management is implementation-defined.
      These APIs are expected to be appropriately invoked by the platform
      layer during system suspend.
      
      Fixes ARM-software/tf-issues#464
      
      Change-Id: Iebb9c6770ab8c4d522546f161fa402d2fe02ec00
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      ebf1ca10
  18. 04 Oct, 2017 1 commit
    • Jeenu Viswambharan's avatar
      TSP: Support multi-threading CPUs on FVP · 5e4ca661
      Jeenu Viswambharan authored
      Commit 11ad8f20
      
       added supporting
      multi-threaded CPUs on FVP platform, including modifications for
      calculating CPU IDs. This patch imports the strong definition of the
      same CPU ID calculation on FVP platform for TSP.
      
      Without this patch, TSP on FVP was using the default CPU ID calculation,
      which would end up being wrong on CPUs with multi-threading.
      
      Change-Id: If67fd492dfce1f57224c9e693988c4b0f89a9a9a
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      5e4ca661
  19. 25 Sep, 2017 2 commits
    • Roberto Vargas's avatar
      mem_protect: Add DRAM2 to the list of mem protected ranges · b09ba056
      Roberto Vargas authored
      
      
      On ARM platforms, the maximum size of the address space is limited
      to 32-bits as defined in arm_def.h. In order to access DRAM2, which
      is defined beyond the 32-bit address space, the maximum address space
      is increased to 36-bits in AArch64. It is possible to increase the
      virtual space for AArch32, but it is more difficult and not supported
      for now.
      
      NOTE - the actual maximum memory address space is platform dependent
      and is checked at run-time by querying the PARange field in the
      ID_AA64MMFR0_EL1 register.
      
      Change-Id: I6cb05c78a63b1fed96db9a9773faca04a5b93d67
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      b09ba056
    • Roberto Vargas's avatar
      mem_protect: Add mem_protect support in Juno and FVP for DRAM1 · f145403c
      Roberto Vargas authored
      
      
      mem_protect needs some kind of non-volatile memory because it has
      to remember its state across reset and power down events.
      The most suitable electronic part for this feature is a NVRAM
      which should be only accesible from the secure world. Juno and
      FVP lack such hardware and for this reason the MEM_PROTECT
      functionality is implemented with Flash EEPROM memory on both
      boards, even though this memory is accesible from the non-secure
      world. This is done only to show a full implementation of
      these PSCI features, but an actual system shouldn't use a
      non-secure NVRAM to implement it.
      
      The EL3 runtime software will write the mem_protect flag and BL2
      will read and clear the memory ranges if enabled. It is done in
      BL2 because it reduces the time that TF needs access to the full
      non-secure memory.
      
      The memory layout of both boards is defined using macros which
      take different values in Juno and FVP platforms. Generic platform
      helpers are added that use the platform specific macros to generate
      a mem_region_t that is valid for the platform.
      
      Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      f145403c
  20. 22 Sep, 2017 2 commits
  21. 21 Sep, 2017 1 commit
  22. 07 Sep, 2017 1 commit