1. 10 Jun, 2019 4 commits
  2. 08 Jun, 2019 1 commit
  3. 07 Jun, 2019 1 commit
  4. 06 Jun, 2019 9 commits
  5. 05 Jun, 2019 4 commits
    • 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
    • John Tsichritzis's avatar
    • John Tsichritzis's avatar
    • James kung's avatar
      Prevent pending G1S interrupt become G0 interrupt · acc29852
      James kung authored
      
      
      According to Arm GIC spec(IHI0069E, section 4.6.1),
      when GICD_CTLR.DS == 0, Secure Group 1 interrupts
      are treated as Group 0 by a CPU interface if:
      - The PE does not implement EL3.
      - ICC_SRE_EL1(S).SRE == 0
      
      When a cpu enter suspend or deep idle, it might be
      powered off. When the cpu resume, according to
      the GIC spec(IHI0069E, section 9.2.15, 9.2.16 and
      9.2.22) the ICC_SRE_EL1.SRE reset value is 0 (if
      write is allowed) and G0/G1S/G1NS interrupt of the
      GIC cpu interface are all disabled.
      
      If a G1S SPI interrupt occurred and the target cpu
      of the SPI is assigned to a specific cpu which is
      in suspend and is powered off, when the cpu resume
      and start to initial the GIC cpu interface, the
      initial sequence might affect the interrupt group
      type of the pending interrupt on the cpu interface.
      
      Current initial sequence on the cpu interface is:
      1. Enable G0 interrupt
      2. Enable G1S interrupt
      3. Enable ICC_SRE_EL1(S).SRE
      
      It is possible to treat the pending G1S interrupt
      as G0 interrupt on the cpu interface if the G1S
      SPI interrupt occurred between step2 and step3.
      
      To prevent the above situation happend, the initial
      sequence should be changed as follows:
      1. Enable ICC_SRE_EL1(S).SRE
      2. Enable G0 interrupt
      3. Enable G1S interrupt
      
      Change-Id: Ie34f6e0b32eb9a1677ff72571fd4bfdb5cae25b0
      Signed-off-by: default avatarJames Kung <kong1191@gmail.com>
      acc29852
  6. 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
  7. 03 Jun, 2019 3 commits
  8. 31 May, 2019 2 commits
  9. 30 May, 2019 3 commits
  10. 29 May, 2019 4 commits
  11. 28 May, 2019 5 commits
  12. 24 May, 2019 3 commits
    • Paul Beesley's avatar
    • Paul Beesley's avatar
      Merge changes from topic "jts/docs" into integration · c0e9d433
      Paul Beesley authored
      * changes:
        Docs fixes
        Update security documentation
      c0e9d433
    • Alexei Fedorov's avatar
      Add support for Branch Target Identification · 9fc59639
      Alexei Fedorov authored
      
      
      This patch adds the functionality needed for platforms to provide
      Branch Target Identification (BTI) extension, introduced to AArch64
      in Armv8.5-A by adding BTI instruction used to mark valid targets
      for indirect branches. The patch sets new GP bit [50] to the stage 1
      Translation Table Block and Page entries to denote guarded EL3 code
      pages which will cause processor to trap instructions in protected
      pages trying to perform an indirect branch to any instruction other
      than BTI.
      BTI feature is selected by BRANCH_PROTECTION option which supersedes
      the previous ENABLE_PAUTH used for Armv8.3-A Pointer Authentication
      and is disabled by default. Enabling BTI requires compiler support
      and was tested with GCC versions 9.0.0, 9.0.1 and 10.0.0.
      The assembly macros and helpers are modified to accommodate the BTI
      instruction.
      This is an experimental feature.
      Note. The previous ENABLE_PAUTH build option to enable PAuth in EL3
      is now made as an internal flag and BRANCH_PROTECTION flag should be
      used instead to enable Pointer Authentication.
      Note. USE_LIBROM=1 option is currently not supported.
      
      Change-Id: Ifaf4438609b16647dc79468b70cd1f47a623362e
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      9fc59639