1. 24 Jun, 2020 1 commit
  2. 17 Apr, 2020 1 commit
  3. 07 Apr, 2020 1 commit
    • Manish V Badarkhe's avatar
      Increase maximum size of BL2 image · 9dfe46c2
      Manish V Badarkhe authored
      
      
      Increased the maximum size of BL2 image in order to
      accommodate the BL2 image when TF-A build with no compiler
      optimization for ARM platform.
      
      Note: As of now, "no compiler optimization" build works
      only when TRUSTED_BOOT_BOARD option is set to 0.
      
      This change is verified using below CI configuration:
      1. juno-no-optimize-default:juno-linux.uboot
      2. fvp-no-optimize-default,fvp-default:fvp-tftf-fip.tftf-aemv8a-debug
      
      Change-Id: I5932621237f8acd1b510682388f3ba78eae90ea4
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      9dfe46c2
  4. 12 Mar, 2020 1 commit
    • Chris Kay's avatar
      juno/sgm: Maximize space allocated to SCP_BL2 · ddc93cba
      Chris Kay authored
      
      
      To accommodate the increasing size of the SCP_BL2 binary, the base
      address of the memory region allocated to SCP_BL2 has been moved
      downwards from its current (mostly) arbitrary address to the beginning
      of the non-shared trusted SRAM.
      
      Change-Id: I086a3765bf3ea88f45525223d765dc0dbad6b434
      Signed-off-by: default avatarChris Kay <chris.kay@arm.com>
      ddc93cba
  5. 19 Feb, 2020 2 commits
  6. 07 Feb, 2020 2 commits
  7. 18 Nov, 2019 1 commit
    • Louis Mayencourt's avatar
      ROMLIB: Optimize memory layout when ROMLIB is used · e7b39089
      Louis Mayencourt authored
      
      
      ROMLIB extract functions code from BL images to put them inside ROM.
      This has for effect to reduce the size of the BL images.
      
      This patch take this size reduction into consideration to optimize the
      memory layout of BL2.
      A new "PLAT_ARM_BL2_ROMLIB_OPTIMIZATION" macro is defined and used to
      reduce "PLAT_ARM_MAX_BL2_SIZE". This allows to remove the gap between
      BL1 and BL2 when ROMLIB is used and provides more room for BL31.
      
      The current memory gain is 0x6000 for fvp and 0x8000 for juno.
      
      Change-Id: I71c2c2c63b57bce5b22a125efaefc486ff3e87be
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      e7b39089
  8. 01 Aug, 2019 1 commit
    • Julius Werner's avatar
      Switch AARCH32/AARCH64 to __aarch64__ · 402b3cf8
      Julius Werner authored
      
      
      NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__.
      
      All common C compilers pre-define the same macros to signal which
      architecture the code is being compiled for: __arm__ for AArch32 (or
      earlier versions) and __aarch64__ for AArch64. There's no need for TF-A
      to define its own custom macros for this. In order to unify code with
      the export headers (which use __aarch64__ to avoid another dependency),
      let's deprecate the AARCH32 and AARCH64 macros and switch the code base
      over to the pre-defined standard macro. (Since it is somewhat
      unintuitive that __arm__ only means AArch32, let's standardize on only
      using __aarch64__.)
      
      Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      402b3cf8
  9. 26 Jun, 2019 1 commit
    • Manoj Kumar's avatar
      n1sdp: add code for DDR ECC enablement and BL33 copy to DDR · de8bc83e
      Manoj Kumar authored
      
      
      N1SDP platform supports RDIMMs with ECC capability. To use the ECC
      capability, the entire DDR memory space has to be zeroed out before
      enabling the ECC bits in DMC620. Zeroing out several gigabytes of
      memory from SCP is quite time consuming so functions are added that
      zeros out the DDR memory from application processor which is
      much faster compared to SCP. BL33 binary cannot be copied to DDR memory
      before enabling ECC so this is also done by TF-A from IOFPGA-DDR3
      memory to main DDR4 memory after ECC is enabled.
      
      Original PLAT_PHY_ADDR_SPACE_SIZE was limited to 36-bits with which
      the entire DDR space cannot be accessed as DRAM2 starts in base
      0x8080000000. So these macros are redefined for all ARM platforms.
      
      Change-Id: If09524fb65b421b7a368b1b9fc52c49f2ddb7846
      Signed-off-by: default avatarManoj Kumar <manoj.kumar3@arm.com>
      de8bc83e
  10. 13 Mar, 2019 1 commit
  11. 25 Jan, 2019 2 commits
  12. 23 Jan, 2019 1 commit
    • Sathees Balya's avatar
      plat/arm: Save BL2 descriptors to reserved memory. · 5b8d50e4
      Sathees Balya authored
      
      
      On ARM platforms, the BL2 memory can be overlaid by BL31/BL32. The memory
      descriptors describing the list of executable images are created in BL2
      R/W memory, which could be possibly corrupted later on by BL31/BL32 due
      to overlay. This patch creates a reserved location in SRAM for these
      descriptors and are copied over by BL2 before handing over to next BL
      image.
      
      Also this patch increases the PLAT_ARM_MAX_BL2_SIZE for juno when TBBR
      is enabled.
      
      Fixes ARM-Software/tf-issues#626
      
      Change-Id: I755735706fa702024b4032f51ed4895b3687377f
      Signed-off-by: default avatarSathees Balya <sathees.balya@arm.com>
      5b8d50e4
  13. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored
      Enforce full include path for includes. Deprecate old paths.
      
      The following folders inside include/lib have been left unchanged:
      
      - include/lib/cpus/${ARCH}
      - include/lib/el3_runtime/${ARCH}
      
      The reason for this change is that having a global namespace for
      includes isn't a good idea. It defeats one of the advantages of having
      folders and it introduces problems that are sometimes subtle (because
      you may not know the header you are actually including if there are two
      of them).
      
      For example, this patch had to be created because two headers were
      called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
      to avoid collision."). More recently, this patch has had similar
      problems: 46f9b2c3 ("drivers: add tzc380 support").
      
      This problem was introduced in commit 4ecca339
      
       ("Move include and
      source files to logical locations"). At that time, there weren't too
      many headers so it wasn't a real issue. However, time has shown that
      this creates problems.
      
      Platforms that want to preserve the way they include headers may add the
      removed paths to PLAT_INCLUDES, but this is discouraged.
      
      Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  14. 27 Nov, 2018 1 commit
    • Chandni Cherukuri's avatar
      plat/css: allow platforms to define the system power domain level · eff2f444
      Chandni Cherukuri authored
      
      
      The CSS_SYSTEM_PWR_DMN_LVL macro that defines the system power domain
      level is fixed at ARM_PWR_LVL2 for all CSS platforms. However, the
      system power domain level can be different for CSS platforms that
      use multi-threaded CPUs.
      
      So, in preparation towards adding support for platforms that use
      multi-threaded CPUs, refactor the definition of CSS_SYSTEM_PWR_DMN_LVL
      such that CSS_SYSTEM_PWR_DMN_LVL is uniquely defined for each of the
      CSS platform.
      
      Change-Id: Ia837b13f6865e71da01780993c048b45b7f36d85
      Signed-off-by: default avatarChandni Cherukuri <chandni.cherukuri@arm.com>
      eff2f444
  15. 23 Nov, 2018 1 commit
    • Sathees Balya's avatar
      juno: Add romlib support · afa5cfea
      Sathees Balya authored
      
      
      This patch adds support to build a combined BL1
      and ROMLIB binary file with the right page
      alignment in Juno. When USE_ROMLIB=1 is set for
      Juno, it generates the combined file
      bl1_romlib.bin which needs to be used instead of
      bl1.bin
      
      Change-Id: I407efbe48d3e522fa6ef855538a9587193cb1919
      Signed-off-by: default avatarSathees Balya <sathees.balya@arm.com>
      afa5cfea
  16. 06 Nov, 2018 1 commit
  17. 01 Nov, 2018 1 commit
  18. 23 Oct, 2018 1 commit
  19. 11 Oct, 2018 2 commits
  20. 02 Oct, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Remove option ARM_BOARD_OPTIMISE_MEM · c0740e4f
      Antonio Nino Diaz authored
      
      
      This option makes it hard to optimize the memory definitions of all Arm
      platforms because any change in the common defines must work in all of
      them. The best thing to do is to remove it and move the definition to
      each platform's header.
      
      FVP, SGI and SGM were using the definitions in board_arm_def.h. The
      definitions have been copied to each platform's platform_def.h. Juno
      was already using the ones in platform_def.h, so there have been no
      changes.
      
      Change-Id: I9aecd11bbc72a3d0d7aad1ef9934d8df21dcfaf2
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c0740e4f
  21. 06 Aug, 2018 1 commit
  22. 24 Jul, 2018 1 commit
  23. 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
  24. 11 May, 2018 1 commit
  25. 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
  26. 10 Apr, 2018 1 commit
  27. 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
  28. 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
  29. 19 Dec, 2017 1 commit
  30. 29 Nov, 2017 1 commit
    • 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
  31. 25 Oct, 2017 1 commit
  32. 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
  33. 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
  34. 22 Sep, 2017 1 commit