1. 11 Jun, 2019 1 commit
  2. 10 Jun, 2019 5 commits
  3. 08 Jun, 2019 1 commit
  4. 07 Jun, 2019 1 commit
  5. 06 Jun, 2019 9 commits
  6. 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
  7. 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
  8. 03 Jun, 2019 3 commits
  9. 31 May, 2019 2 commits
  10. 30 May, 2019 3 commits
  11. 29 May, 2019 4 commits
  12. 28 May, 2019 5 commits
  13. 24 May, 2019 1 commit