1. 07 Sep, 2018 1 commit
    • Sathees Balya's avatar
      juno: Revert FWU update detect mechanism · 4da6f6cd
      Sathees Balya authored
      The patch 7b56928a
      
       unified the FWU mechanism on FVP and Juno
      platforms due to issues with MCC firmware not preserving the
      NVFLAGS. With MCCv150 firmware, this issue is resolved. Also
      writing to the NOR flash while executing from the same flash
      in Bypass mode had some stability issues. Hence, since the
      MCC firmware issue is resolved, this patch reverts to the
      NVFLAGS mechanism to detect FWU. Also, with the introduction
      of SDS (Shared Data Structure) by the SCP, the reset syndrome
      needs to queried from the appropriate SDS field.
      
      Change-Id: If9c08f1afaaa4fcf197f3186887068103855f554
      Signed-off-by: default avatarSathees Balya <sathees.balya@arm.com>
      Signed-off-by: default avatarSoby Mathew <Soby.Mathew@arm.com>
      4da6f6cd
  2. 30 Aug, 2018 1 commit
  3. 21 Aug, 2018 1 commit
  4. 06 Aug, 2018 1 commit
  5. 24 Jul, 2018 1 commit
  6. 20 Jul, 2018 1 commit
  7. 18 Jun, 2018 1 commit
  8. 07 Jun, 2018 2 commits
    • Soby Mathew's avatar
      Juno: Bump up the BL1-RW size · 2013d8f0
      Soby Mathew authored
      
      
      This patch bumps up the BL1-RW size for Juno and at the same time reduces
      the BL2 size when TBB is enabled, TF_MBEDTLS_KEY_ALG=rsa+ecdsa. The BL2
      size for this config is reduced as it was observed that the peak memory
      usage is only reached when SPD=opteed and the dual rsa+ecdsa support is
      not needed for this case.
      
      Change-Id: Ia9009771b5cfd805e9cc75410aabb7db99fc2fbc
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      2013d8f0
    • Soby Mathew's avatar
      ARM platforms: Move BL31 below BL2 to enable BL2 overlay · c099cd39
      Soby Mathew authored
      
      
      The patch changes the layout of BL images in memory to enable
      more efficient use of available space. Previously BL31 was loaded
      with the expectation that BL2 memory would be reclaimed by BL32
      loaded in SRAM. But with increasing memory requirements in the
      firmware, we can no longer fit BL32 in SRAM anymore which means the
      BL2 memory is not reclaimed by any runtime image. Positioning BL2
      below BL1-RW and above BL31 means that the BL31 NOBITS can be
      overlaid on BL2 and BL1-RW.
      
      This patch also propogates the same memory layout to BL32 for AArch32
      mode. The reset addresses for the following configurations are also
      changed :
         * When RESET_TO_SP_MIN=1 for BL32 in AArch32 mode
         * When BL2_AT_EL3=1 for BL2
      
      The restriction on BL31 to be only in DRAM when SPM is enabled
      is now removed with this change. The update to the firmware design
      guide for the BL memory layout is done in the following patch.
      
      Change-Id: Icca438e257abe3e4f5a8215f945b9c3f9fbf29c9
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      c099cd39
  9. 11 May, 2018 1 commit
  10. 01 May, 2018 1 commit
    • Roberto Vargas's avatar
      ARM platforms: Demonstrate mem_protect from el3_runtime · 638b034c
      Roberto Vargas authored
      
      
      Previously mem_protect used to be only supported from BL2. This is not
      helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates
      mem_protect from el3_runtime firmware on ARM Platforms specifically
      when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent
      in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap
      tables temporarily and then the protected regions are then cleared. This
      avoids the need to map the non secure DRAM permanently to BL31/sp_min.
      
      The stack size is also increased, because DYNAMIC_XLAT_TABLES require
      a bigger stack.
      
      Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      638b034c
  11. 10 Apr, 2018 2 commits
  12. 09 Apr, 2018 1 commit
    • Amit Daniel Kachhap's avatar
      Juno: Increase bl2 max size to fix build when SPD=opteed · 83a2376e
      Amit Daniel Kachhap authored
      
      
      Building TBBR(SPD=opteed) and non-TBBR TF-A images is breaking for
      Juno for different configurations listed below:
      
      * Overflow error of 4096 bytes for rsa algorithm.
      * Overflow error of 8192 bytes for ecdsa algorithm.
      * Overflow error of 4096 bytes for rsa+ecdsa algorithm.
      * Overflow error of 4096 bytes for non-TBBR case.
      
      So this patch increments macro PLAT_ARM_MAX_BL2_SIZE for all the above
      cases accordingly.
      
      Change-Id: I75ec6c0a718181d34553fe55437f0496f467683f
      Signed-off-by: default avatarAmit Daniel Kachhap <amit.kachhap@arm.com>
      83a2376e
  13. 08 Mar, 2018 1 commit
    • Soby Mathew's avatar
      Juno: Change the Firmware update detect mechanism · 7b56928a
      Soby Mathew authored
      
      
      Previously, Juno used to depend on the SSC_GPRETN register to inform
      about the reset syndrome. This method was removed when SCP migrated
      to the SDS framework. But even the SDS framework doesn't report the
      reset syndrome correctly and hence Juno failed to enter Firmware
      update mode if BL2 authentication failed.
      
      In addition to that, the error code populated in V2M_SYS_NVFLAGS register
      does not seem to be retained any more on Juno across resets. This could
      be down to the motherboard firmware not doing the necessary to preserve
      the value.
      
      Hence this patch modifies the Juno platform to use the same mechanism to
      trigger firmware update as FVP which is to corrupt the FIP TOC on
      authentication failure. The implementation in `fvp_err.c` is made common
      for ARM platforms and is moved to the new `arm_err.c` file in
      plat/arm/common folder. The BL1 and BL2 mmap table entries for Juno
      are modified to allow write to the Flash memory address.
      
      Change-Id: Ica7d49a3e8a46a90efd4cf340f19fda3b549e945
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      7b56928a
  14. 28 Feb, 2018 2 commits
  15. 26 Feb, 2018 1 commit
    • 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
  16. 19 Dec, 2017 1 commit
  17. 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
  18. 29 Nov, 2017 2 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
  19. 25 Oct, 2017 1 commit
  20. 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
  21. 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
  22. 22 Sep, 2017 2 commits
  23. 07 Sep, 2017 1 commit
  24. 06 Sep, 2017 3 commits
    • Soby Mathew's avatar
      CSS: Changes for SDS framework · 18e279eb
      Soby Mathew authored
      
      
      This patch does the required changes to enable CSS platforms
      to build and use the SDS framework. Since SDS is always coupled with
      SCMI protocol, the preexisting SCMI build flag is now renamed to
      `CSS_USE_SCMI_SDS_DRIVER` which will enable both SCMI and SDS on
      CSS platforms. Also some of the workarounds applied for SCMI are
      now removed with SDS in place.
      
      Change-Id: I94e8b93f05e3fe95e475c5501c25bec052588a9c
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      18e279eb
    • Soby Mathew's avatar
      Split CSS makefile for sp_min on Juno · 0a04c69a
      Soby Mathew authored
      
      
      This patch factors out common files required for sp_min for all CSS
      platforms from the JUNO specific makefile to a the new `css_sp_min.mk`
      makefile. This also allows the common build options that affect CSS
      platforms to be configured in a central makefile for sp_min.
      
      Change-Id: Ida952d8833b1aa5eda77ae0a6664a4632aeab24c
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      0a04c69a
    • Roberto Vargas's avatar
      juno: Fix bug in plat_get_my_entrypoint · d9b7636e
      Roberto Vargas authored
      
      
      plat_get_my_entrypoint was branching to juno_do_reset_to_aarch_32_state,
      which is not supposed to return, and in case of returning it implemented
      an infinite loop. The problem was that plat_get_my_entrypoint was using
      "b" instead of "bl", so juno_do_reset_to_aarch_32_state was returning to
      the caller of plat_get_my_entrypoint instead of stop the system with a
      panic.
      
      To avoid this problem juno_do_reset_to_aarch_32_state was modified to
      call directly to plat_panic_handler if it tries to return.
      
      Change-Id: I591cf2dd78d27d8568fb15b91366e4b3dce027b5
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      d9b7636e
  25. 31 Aug, 2017 1 commit
    • Soby Mathew's avatar
      Juno: Define PLAT_LOG_LEVEL_ASSERT to LOG_LEVEL_INFO · bea363ad
      Soby Mathew authored
      
      
      This patch fixes the PLAT_LOG_LEVEL_ASSERT to 40 which corresponds
      to LOG_LEVEL_INFO. Having this level of log for assertions means that the
      `assert()` will not generate the strings implied in the expression taken
      as parameter. This allows to save some memory when Juno is built for
      LOG_LEVEL = LOG_LEVEL_VERBOSE and DEBUG = 1.
      
      Fixes ARM-software/tf-issues#511
      
      Change-Id: Id84a40f803ab07a5a8f6e587167af96694a07d04
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      bea363ad
  26. 09 Aug, 2017 1 commit
    • Summer Qin's avatar
      Add Trusted OS extra image parsing support for ARM standard platforms · 54661cd2
      Summer Qin authored
      
      
      Trusted OS may have extra images to be loaded. Load them one by one
      and do the parsing. In this patch, ARM TF need to load up to 3 images
      for optee os: header, pager and paged images. Header image is the info
      about optee os and images. Pager image include pager code and data.
      Paged image include the paging parts using virtual memory.
      
      Change-Id: Ia3bcfa6d8a3ed7850deb5729654daca7b00be394
      Signed-off-by: default avatarSummer Qin <summer.qin@arm.com>
      54661cd2
  27. 20 Jul, 2017 1 commit
    • Soby Mathew's avatar
      Resize the BL2 size limit for Juno · 6c401f31
      Soby Mathew authored
      
      
      Recent patches to reduce the memory footprint of BL images have
      resulted in saving several pages of memory. This patch reduces
      the BL2 size limit by 20KB for Juno when ARM_BOARD_OPTIMISE_MEM=1
      so that more free space can be freed up for Trusted OS (BL32). Also
      SCP_BL2/SCP_BL2U size is now restricted to 80K.
      
      Change-Id: I1573d7a34e24d15e4abce8a14da40dbb5dc81e37
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      6c401f31
  28. 14 Jul, 2017 1 commit
  29. 28 Jun, 2017 1 commit
    • Soby Mathew's avatar
      ARM plat changes to enable CryptoCell integration · e60f2af9
      Soby Mathew authored
      
      
      This patch makes the necessary changes to enable ARM platform to
      successfully integrate CryptoCell during Trusted Board Boot. The
      changes are as follows:
      
      * A new build option `ARM_CRYPTOCELL_INTEG` is introduced to select
        the CryptoCell crypto driver for Trusted Board boot.
      
      * The TrustZone filter settings for Non Secure DRAM is modified
        to allow CryptoCell to read this memory. This is required to
        authenticate BL33 which is loaded into the Non Secure DDR.
      
      * The CSS platforms are modified to use coherent stacks in BL1 and BL2
        when CryptoCell crypto is selected. This is because CryptoCell makes
        use of DMA to transfer data and the CryptoCell SBROM library allocates
        buffers on the stack during signature/hash verification.
      
      Change-Id: I1e6f6dcd1899784f1edeabfa2a9f279bbfb90e31
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      e60f2af9
  30. 26 Jun, 2017 2 commits
    • Dimitris Papastamos's avatar
      juno: Invalidate all caches before warm reset to AArch32 state. · 35bd2dda
      Dimitris Papastamos authored
      
      
      On Juno AArch32, the L2 cache may contain garbage after the warm reset
      from AArch64 to AArch32.  This is all fine until the MMU is configured
      and the data caches enabled.  To avoid fetching stale data from the L2
      unified cache, invalidate it before the warm reset to AArch32 state.
      
      Change-Id: I7d27e810692c02c3e83c9f31de67f6bae59a960a
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      35bd2dda
    • Dimitris Papastamos's avatar
      juno/aarch32: Restore `SCP_BOOT_CFG_ADDR` to the cold boot value · cc47e1ad
      Dimitris Papastamos authored
      
      
      Before BL2 loads the SCP ram firmware, `SCP_BOOT_CFG_ADDR` specifies
      the primary core.  After the SCP ram firmware has started executing,
      `SCP_BOOT_CFG_ADDR` is modified.  This is not normally an issue but
      the Juno AArch32 boot flow is a special case.  BL1 does a warm reset
      into AArch32 and the core jumps to the `sp_min` entrypoint.  This is
      effectively a `RESET_TO_SP_MIN` configuration.  `sp_min` has to be
      able to determine the primary core and hence we need to restore
      `SCP_BOOT_CFG_ADDR` to the cold boot value before `sp_min` runs.
      
      This magically worked when booting on A53 because the core index was
      zero and it just so happened to match with the new value in
      `SCP_BOOT_CFG_ADDR`.
      
      Change-Id: I105425c680cf6238948625c1d1017b01d3517c01
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      cc47e1ad
  31. 22 Jun, 2017 1 commit
    • Douglas Raillard's avatar
      Apply workarounds for A53 Cat A Errata 835769 and 843419 · a94cc374
      Douglas Raillard authored
      These errata are only applicable to AArch64 state. See the errata notice
      for more details:
      http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.epm048406/index.html
      
      
      
      Introduce the build options ERRATA_A53_835769 and ERRATA_A53_843419.
      Enable both of them for Juno.
      
      Apply the 835769 workaround as following:
      * Compile with -mfix-cortex-a53-835769
      * Link with --fix-cortex-a53-835769
      
      Apply the 843419 workaround as following:
      * Link with --fix-cortex-a53-843419
      
      The erratum 843419 workaround can lead the linker to create new sections
      suffixed with "*.stub*" and 4KB aligned. The erratum 835769 can lead the
      linker to create new "*.stub" sections with no particular alignment.
      
      Also add support for LDFLAGS_aarch32 and LDFLAGS_aarch64 in Makefile for
      architecture-specific linker options.
      
      Change-Id: Iab3337e338b7a0a16b0d102404d9db98c154f8f8
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      a94cc374