1. 30 Sep, 2019 1 commit
  2. 26 Sep, 2019 1 commit
  3. 25 Sep, 2019 1 commit
    • Sandrine Bailleux's avatar
      FVP: Fix plat_set_nv_ctr() function · bd363d35
      Sandrine Bailleux authored
      The Fast Models provide a non-volatile counter component, which is used
      in the Trusted Board Boot implementation to protect against rollback
      attacks.
      
      This component comes in 2 versions (see [1]).
      
      - Version 0 is the default and models a locked non-volatile counter,
        whose value is fixed.
      
      - Version 1 of the counter may be incremented in a monotonic fashion.
      
      plat_set_nv_ctr() must cope with both versions. This is achieved by:
      1) Attempting to write the new value in the counter.
      2) Reading the value back.
      3) If there is a mismatch, we know the counter upgrade failed.
      
      When using version 0 of the counter, no upgrade is possible so the
      function is expected to fail all the time. However, the code is
      missing a compiler barrier between the write operation and the next
      read. Thus, the compiler may optimize and remove the read operation on
      the basis that the counter value has not changed. With the default
      optimization level used in TF-A (-Os), this is what's happening.
      
      The fix introduced in this patch marks the write and subsequent read
      accesses to the counter as volatile, such that the compiler makes no
      assumption about the value of the counter.
      
      Note that the comment above plat_set_nv_ctr() was clearly stating
      that when using the read-only version of the non-volatile counter,
      "we expect the values in the certificates to always match the RO
      values so that this function is never called". However, the fact that
      the counter value was read back seems to contradict this comment, as
      it is implementing a counter-measure against misuse of the
      function. The comment has been reworded to avoid any confusion.
      
      Without this patch, this bug may be demonstrated on the Base AEM FVP:
      - Using version 0 of the non-volatile counter (default version).
      - With certificates embedding a revision number value of 32
        (compiling TF-A with TFW_NVCTR_VAL=32).
      
      In this configuration, the non-volatile counter is tied to value 31 by
      default. When BL1 loads the Trusted Boot Firmware certificate, it
      notices that the two values do not match and tries to upgrade the
      non-volatile counter. This write operation is expected to fail
      (because the counter is locked) and the function is expected to return
      an error but it succeeds instead.
      
      As a result, the trusted boot does not abort as soon as it should and
      incorrectly boots BL2. The boot is finally aborted when BL2 verifies
      the BL31 image and figures out that the version of the SoC Firmware
      Key Certificate does not match. On Arm platforms, only certificates
      signed with the Root-of-Trust Key may trigger an upgrade of the
      non-volatile Trusted counter.
      
      [1] https://developer.arm.com/docs/100964/1160/fast-models-components/peripheral-components/nonvolatilecounter
      
      
      
      Change-Id: I9979f29c23b47b338b9b484013d1fb86c59db92f
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      bd363d35
  4. 23 Sep, 2019 2 commits
    • Usama Arif's avatar
      a5ds: add multicore support · ec885bac
      Usama Arif authored
      
      
      Enable cores 1-3 using psci. On receiving the smc call from kernel,
      core 0 will bring the secondary cores out pen and signal an event for
      the cores. Currently on switching the cores is enabled i.e. it is not
      possible to suspend, switch cores off, etc.
      
      Change-Id: I6087e1d2ec650e1d587fd543efc1b08cbb50ae5f
      Signed-off-by: default avatarUsama Arif <usama.arif@arm.com>
      ec885bac
    • Usama Arif's avatar
      a5ds: Hold the secondary cpus in pen rather than panic · e231f3a5
      Usama Arif authored
      
      
      For the secondary CPUs, hold the cpu in wfe rather then panic.
      This will be needed when multicore support is added to a5ds as
      the smc call will write to the hold base and signal an event to
      power on the secondary CPUs.
      
      Change-Id: I0ffc2059e9ef894c21375ca5c94def859bfa6599
      Signed-off-by: default avatarUsama Arif <usama.arif@arm.com>
      e231f3a5
  5. 11 Sep, 2019 1 commit
    • John Tsichritzis's avatar
      Modify FVP makefile for cores that support both AArch64/32 · cd3c5b4c
      John Tsichritzis authored
      
      
      Some cores support only AArch64 from EL1 and above, e.g. A76, N1 etc. If
      TF-A is compiled with CTX_INCLUDE_AARCH32_REGS=0 so as to properly
      handle those cores, only the AArch64 cores' assembly is included in the
      TF-A binary. In other words, for FVP, TF-A assumes that AArch64 only
      cores will never exist in the same cluster with cores that also support
      AArch32.
      
      However, A55 and A75 can be used as AArch64 only cores, despite
      supporting AArch32, too. This patch enables A55 and A75 to exist in
      clusters together with AArch64 cores.
      
      Change-Id: I58750ad6c3d76ce77eb354784c2a42f2c179031d
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      cd3c5b4c
  6. 20 Aug, 2019 1 commit
    • Manish Pandey's avatar
      plat/arm: Introduce corstone700 platform. · 7bdc4698
      Manish Pandey authored
      
      
      This patch adds support for Corstone-700 foundation IP, which integrates
      both Cortex-M0+ and Cortex-A(Host) processors in one handy, flexible
      subsystem.
      This is an example implementation of Corstone-700 IP host firmware.
      
      Cortex-M0+ will take care of boot stages 1 and 2(BL1/BL2) as well as
      bringing Host out RESET. Host will start execution directly from BL32 and
      then will jump to Linux.
      
      It is an initial port and additional features are expected to be added
      later.
      
      Change-Id: I7b5c0278243d574284b777b2408375d007a7736e
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      7bdc4698
  7. 16 Aug, 2019 1 commit
    • Alexei Fedorov's avatar
      FVP: Add Delay Timer driver to BL1 and BL31 · 1b597c22
      Alexei Fedorov authored
      
      
      SMMUv3 driver functions which are called from BL1 and BL31
      currently use counter-based poll method for testing status
      bits. Adding Delay Timer driver to BL1 and BL31 is required
      for timeout-based implementation using timer delay functions
      for SMMU and other drivers.
      This patch adds new function `fvp_timer_init()` which
      initialises either System level generic or SP804 timer based on
      FVP_USE_SP804_TIMER build flag.
      In BL2U `bl2u_early_platform_setup()` function the call to
      `arm_bl2u_early_platform_setup()` (which calls
      `generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag),
      is replaced with `arm_console_boot_init()` and `fvp_timer_init()`.
      
      Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      1b597c22
  8. 13 Aug, 2019 2 commits
  9. 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
  10. 25 Jul, 2019 2 commits
  11. 23 Jul, 2019 2 commits
    • Manoj Kumar's avatar
      n1sdp: fix DMC ECC enablement sequence in N1SDP platform · 7428bbf4
      Manoj Kumar authored
      
      
      The DMC-620 memory controllers in N1SDP platform has to be put
      into CONFIG state before writing to ERR0CTLR0 register to enable
      ECC.
      
      This patch fixes the sequence so that DMCs are set to CONFIG
      state before writing to ERR0CTLR0 register and moved back to
      READY state after writing.
      
      Change-Id: I1252f3ae0991603bb29234029cddb5fbf869c1b2
      Signed-off-by: default avatarManoj Kumar <manoj.kumar3@arm.com>
      7428bbf4
    • Ambroise Vincent's avatar
      arm: Shorten the Firmware Update (FWU) process · 37b70031
      Ambroise Vincent authored
      
      
      The watchdog is configured with a default value of 256 seconds in order
      to implement the Trusted Board Boot Requirements.
      
      For the FVP and Juno platforms, the FWU process relies on a watchdog
      reset. In order to automate the test of FWU, the length of this process
      needs to be as short as possible. Instead of waiting for those 4 minutes
      to have a reset by the watchdog, tell it to reset immediately.
      
      There are no side effects as the value of the watchdog's load register
      resets to 0xFFFFFFFF.
      
      Tested on Juno.
      
      Change-Id: Ib1aea80ceddc18ff1e0813a5b98dd141ba8a3ff2
      Signed-off-by: default avatarAmbroise Vincent <ambroise.vincent@arm.com>
      37b70031
  12. 16 Jul, 2019 2 commits
  13. 10 Jul, 2019 1 commit
  14. 28 Jun, 2019 1 commit
  15. 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
  16. 05 Jun, 2019 1 commit
    • John Tsichritzis's avatar
      FVP: Remove GIC initialisation from secondary core cold boot · 9c29e5f7
      John Tsichritzis authored
      
      
      During the secondary cores' cold boot path, the cores initialise the GIC
      CPU interface. However this is a redundant action since 1) the cores are
      powered down immediately after that, 2) the GIC CPU interface is
      initialised from scratch when the secondary cores are powered up again
      later.
      
      Moreover, this part of code was introducing a bug. In a GICv3 system,
      the GIC's CPU interface system registers must not be written without the
      core being marked as "awake" in the redistributor. However, this
      sequence was performing such accesses and this would cause those cores
      to hang. The hang was caused by the DSB instruction that would never
      complete because of the GIC not recognising those writes.
      
      For the two aforementioned reasons, the entire part of the GIC CPU
      interface initialisation is removed.
      
      Change-Id: I6c33a1edda69dd5b6add16a27390a70731b5532a
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      9c29e5f7
  17. 04 Jun, 2019 1 commit
    • John Tsichritzis's avatar
      Apply compile-time check for AArch64-only cores · 629d04f5
      John Tsichritzis authored
      
      
      Some cores support only AArch64 mode. In those cores, only a limited
      subset of the AArch32 system registers are implemented. Hence, if TF-A
      is supposed to run on AArch64-only cores, it must be compiled with
      CTX_INCLUDE_AARCH32_REGS=0.
      
      Currently, the default settings for compiling TF-A are with the AArch32
      system registers included. So, if we compile TF-A the default way and
      attempt to run it on an AArch64-only core, we only get a runtime panic.
      
      Now a compile-time check has been added to ensure that this flag has the
      appropriate value when AArch64-only cores are included in the build.
      
      Change-Id: I298ec550037fafc9347baafb056926d149197d4c
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      629d04f5
  18. 15 May, 2019 2 commits
    • Sami Mujawar's avatar
      N1SDP: Fix DRAM2 start address · 49d64e5d
      Sami Mujawar authored
      
      
      The default DRAM2 start address for Arm platforms
      is 0x880000000. However, for N1SDP platform this is
      0x8080000000.
      
      Fix the DRAM2 start address by initialising
      PLAT_ARM_DRAM2_BASE.
      
      Without this fix there is a mismatch of the System
      memory region view as seen by the BL31 runtime
      firmware (PSCI) versus the view of the OS (which
      is based on the description provided by UEFI. In
      this case UEFI is correctly describing the DRAM2
      start address).
      
      This implicates in secondary cores failing to start
      on some Operating Systems if the OS decides to place
      the secondary start address in the mismatched region.
      
      Change-Id: I57220e753219353dda429868b4c5e1a69944cc64
      Signed-off-by: default avatarSami Mujawar <sami.mujawar@arm.com>
      49d64e5d
    • Sami Mujawar's avatar
      Add option for defining platform DRAM2 base · 6bb6015f
      Sami Mujawar authored
      
      
      The default DRAM2 base address for Arm platforms
      is 0x880000000. However, on some platforms the
      firmware may want to move the start address to
      a different value.
      
      To support this introduce PLAT_ARM_DRAM2_BASE that
      defaults to 0x880000000; but can be overridden by
      a platform (e.g. in platform_def.h).
      
      Change-Id: I0d81195e06070bc98f376444b48ada2db1666e28
      Signed-off-by: default avatarSami Mujawar <sami.mujawar@arm.com>
      6bb6015f
  19. 10 May, 2019 1 commit
    • Alexei Fedorov's avatar
      SMMUv3: Abort DMA transactions · 1461ad9f
      Alexei Fedorov authored
      
      
      For security DMA should be blocked at the SMMU by default
      unless explicitly enabled for a device. SMMU is disabled
      after reset with all streams bypassing the SMMU, and
      abortion of all incoming transactions implements a default
      deny policy on reset.
      This patch also moves "bl1_platform_setup()" function from
      arm_bl1_setup.c to FVP platforms' fvp_bl1_setup.c and
      fvp_ve_bl1_setup.c files.
      
      Change-Id: Ie0ffedc10219b1b884eb8af625bd4b6753749b1a
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      1461ad9f
  20. 03 May, 2019 2 commits
    • John Tsichritzis's avatar
      Add compile-time errors for HW_ASSISTED_COHERENCY flag · 076b5f02
      John Tsichritzis authored
      This patch fixes this issue:
      https://github.com/ARM-software/tf-issues/issues/660
      
      
      
      The introduced changes are the following:
      
      1) Some cores implement cache coherency maintenance operation on the
      hardware level. For those cores, such as - but not only - the DynamIQ
      cores, it is mandatory that TF-A is compiled with the
      HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is
      unpredictable. To prevent this, compile time checks have been added and
      compilation errors are generated, if needed.
      
      2) To enable this change for FVP, a logical separation has been done for
      the core libraries. A system cannot contain cores of both groups, i.e.
      cores that manage coherency on hardware and cores that don't do it. As
      such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the
      libraries only of the relevant cores.
      
      3) The neoverse_e1.S file has been added to the FVP sources.
      
      Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      076b5f02
    • Alexei Fedorov's avatar
      SMMUv3: refactor the driver code · ccd4d475
      Alexei Fedorov authored
      
      
      This patch is a preparation for the subsequent changes in
      SMMUv3 driver. It introduces a new "smmuv3_poll" function
      and replaces inline functions for accessing SMMU registers
      with mmio read/write operations. Also the infinite loop
      for the poll has been replaced with a counter based timeout.
      
      Change-Id: I7a0547beb1509601f253e126b1a7a6ab3b0307e7
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      ccd4d475
  21. 30 Apr, 2019 1 commit
  22. 17 Apr, 2019 1 commit
    • Aditya Angadi's avatar
      plat/arm: introduce wrapper functions to setup secure watchdog · b0c97daf
      Aditya Angadi authored
      
      
      The BL1 stage setup code for ARM platforms sets up the SP805 watchdog
      controller as the secure watchdog. But not all ARM platforms use SP805
      as the secure watchdog controller.
      
      So introduce two new ARM platform code specific wrapper functions to
      start and stop the secure watchdog. These functions then replace the
      calls to SP805 driver in common BL1 setup code. All the ARM platforms
      implement these wrapper functions by either calling into SP805 driver
      or the SBSA watchdog driver.
      
      Change-Id: I1a9a11b124cf3fac2a84f22ca40acd440a441257
      Signed-off-by: default avatarAditya Angadi <aditya.angadi@arm.com>
      b0c97daf
  23. 12 Apr, 2019 1 commit
    • Ambroise Vincent's avatar
      Mbed TLS: Remove weak heap implementation · 2374ab17
      Ambroise Vincent authored
      
      
      The implementation of the heap function plat_get_mbedtls_heap() becomes
      mandatory for platforms supporting TRUSTED_BOARD_BOOT.
      
      The shared Mbed TLS heap default weak function implementation is
      converted to a helper function get_mbedtls_heap_helper() which can be
      used by the platforms for their own function implementation.
      
      Change-Id: Ic8f2994e25e3d9fcd371a21ac459fdcafe07433e
      Signed-off-by: default avatarAmbroise Vincent <ambroise.vincent@arm.com>
      2374ab17
  24. 08 Apr, 2019 1 commit
  25. 01 Apr, 2019 2 commits
  26. 21 Mar, 2019 1 commit
    • John Tsichritzis's avatar
      ROMLIB bug fixes · ae2e01b8
      John Tsichritzis authored
      
      
      Fixed the below bugs:
      1) Bug related to build flag V=1: if the flag was V=0, building with
      ROMLIB would fail.
      2) Due to a syntax bug in genwrappers.sh, index file entries marked as
      "patch" or "reserved" were ignored.
      3) Added a prepending hash to constants that genwrappers is generating.
      4) Due to broken dependencies, currently the inclusion functionality is
      intentionally not utilised. This is why the contents of romlib/jmptbl.i
      have been copied to platform specific jmptbl.i files. As a result of the
      broken dependencies, when changing the index files, e.g. patching
      functions, a clean build is always required. This is a known issue that
      will be fixed in the future.
      
      Change-Id: I9d92aa9724e86d8f90fcd3e9f66a27aa3cab7aaa
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      ae2e01b8
  27. 14 Mar, 2019 2 commits
  28. 13 Mar, 2019 1 commit
  29. 28 Feb, 2019 1 commit
  30. 27 Feb, 2019 2 commits