1. 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
  2. 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
  3. 13 Mar, 2019 1 commit
  4. 25 Jan, 2019 2 commits
  5. 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
  6. 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
  7. 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
  8. 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
  9. 06 Nov, 2018 1 commit
  10. 01 Nov, 2018 1 commit
  11. 23 Oct, 2018 1 commit
  12. 11 Oct, 2018 2 commits
  13. 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
  14. 06 Aug, 2018 1 commit
  15. 24 Jul, 2018 1 commit
  16. 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
  17. 11 May, 2018 1 commit
  18. 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
  19. 10 Apr, 2018 1 commit
  20. 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
  21. 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
  22. 19 Dec, 2017 1 commit
  23. 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
  24. 25 Oct, 2017 1 commit
  25. 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
  26. 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
  27. 22 Sep, 2017 1 commit
  28. 06 Sep, 2017 1 commit
    • 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 05 Jun, 2017 1 commit
  34. 03 May, 2017 1 commit
  35. 20 Apr, 2017 1 commit
  36. 23 Jan, 2017 1 commit
    • Masahiro Yamada's avatar
      Use #ifdef for IMAGE_BL* instead of #if · 3d8256b2
      Masahiro Yamada authored
      
      
      One nasty part of ATF is some of boolean macros are always defined
      as 1 or 0, and the rest of them are only defined under certain
      conditions.
      
      For the former group, "#if FOO" or "#if !FOO" must be used because
      "#ifdef FOO" is always true.  (Options passed by $(call add_define,)
      are the cases.)
      
      For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because
      checking the value of an undefined macro is strange.
      
      Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like
      follows:
      
        $(eval IMAGE := IMAGE_BL$(call uppercase,$(3)))
      
        $(OBJ): $(2)
                @echo "  CC      $$<"
                $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@
      
      This means, IMAGE_BL* is defined when building the corresponding
      image, but *undefined* for the other images.
      
      So, IMAGE_BL* belongs to the latter group where we should use #ifdef
      or #ifndef.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      3d8256b2