1. 03 Mar, 2021 3 commits
  2. 01 Mar, 2021 1 commit
  3. 25 Feb, 2021 2 commits
  4. 24 Feb, 2021 2 commits
  5. 17 Feb, 2021 1 commit
  6. 16 Feb, 2021 1 commit
  7. 15 Feb, 2021 1 commit
    • Andre Przywara's avatar
      plat/arm: juno: Condition Juno entropy source with CRC instructions · eb18ce32
      Andre Przywara authored
      
      
      The Juno Trusted Entropy Source has a bias, which makes the generated
      raw numbers fail a FIPS 140-2 statistic test.
      
      To improve the quality of the numbers, we can use the CPU's CRC
      instructions, which do a decent job on conditioning the bits.
      
      This adds a *very* simple version of arm_acle.h, which is typically
      provided by the compiler, and contains the CRC instrinsics definitions
      we need. We need the original version by using -nostdinc.
      
      Change-Id: I83d3e6902d6a1164aacd5060ac13a38f0057bd1a
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      eb18ce32
  8. 12 Feb, 2021 1 commit
    • Pankaj Gupta's avatar
      nxp: added the makefile helper macros · b749ae3d
      Pankaj Gupta authored
      
      
      NXP specifc macro SET_NXP_MAKE_FLAG is added.
      
      NXP has pool of multiple IPs. This macro helps:
      - In soc.mk, this macro help the selected IP source files to be included
        for that SoC.
        -- The set of IPs required for one NXP SoC is different to the set of IPs
           required by another NXP SoC.
      
      - For the same SoC,
        -- For one feature, the IP may be required in both BL2 and BL31.
        -- Without the above feature, that IP may be required in one.
           This macro help in selecting the inclusion of source and header files to:
           --- BL2 only
           --- BL31 only
           --- COMM (used by BL2 and BL31)
      Signed-off-by: default avatarPankaj Gupta <pankaj.gupta@nxp.com>
      Change-Id: I2cdb13b89aa815fc5219cf8bfb9666d0a9f78765
      b749ae3d
  9. 11 Feb, 2021 4 commits
  10. 09 Feb, 2021 2 commits
    • Manish V Badarkhe's avatar
      plat/arm: fvp: Protect GICR frames for fused/unused cores · f98630fb
      Manish V Badarkhe authored
      
      
      Currently, BLs are mapping the GIC memory region as read-write
      for all cores on boot-up.
      
      This opens up the security hole where the active core can write
      the GICR frame of fused/inactive core. To avoid this issue, disable
      the GICR frame of all inactive cores as below:
      
      1. After primary CPU boots up, map GICR region of all cores as
         read-only.
      2. After primary CPU boots up, map its GICR region as read-write
         and initialize its redistributor interface.
      3. After secondary CPU boots up, map its GICR region as read-write
         and initialize its redistributor interface.
      4. All unused/fused core's redistributor regions remain read-only and
         write attempt to such protected regions results in an exception.
      
      As mentioned above, this patch offers only the GICR memory-mapped
      region protection considering there is no facility at the GIC IP
      level to avoid writing the redistributor area.
      
      These changes are currently done in BL31 of Arm FVP and guarded under
      the flag 'FVP_GICR_REGION_PROTECTION'.
      
      As of now, this patch is tested manually as below:
      1. Disable the FVP cores (core 1, 2, 3) with core 0 as an active core.
      2. Verify data abort triggered by manually updating the ‘GICR_CTLR’
         register of core 1’s(fused) redistributor from core 0(active).
      
      Change-Id: I86c99c7b41bae137b2011cf2ac17fad0a26e776d
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      f98630fb
    • Manish V Badarkhe's avatar
      plat/arm: fvp: Do not map GIC region in BL1 and BL2 · e0cea783
      Manish V Badarkhe authored
      
      
      GIC memory region is not getting used in BL1 and BL2.
      Hence avoid its mapping in BL1 and BL2 that freed some
      page table entries to map other memory regions in the
      future.
      
      Retains mapping of CCN interconnect region in BL1 and BL2
      overlapped with the GIC memory region.
      
      Change-Id: I880dd0690f94b140e59e4ff0c0d436961b9cb0a7
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      e0cea783
  11. 08 Feb, 2021 1 commit
  12. 05 Feb, 2021 1 commit
  13. 04 Feb, 2021 1 commit
  14. 03 Feb, 2021 2 commits
    • Julius Werner's avatar
      qti: spmi_arb: Fix NUM_APID and REG_APID_MAP() argument · de67080f
      Julius Werner authored
      
      
      The NUM_APID value was derived from kernel device tree sources, but I
      made a conversion mistake: the amount of bytes in the APID map is the
      total size of the "core" register range (0x1100) minus the offset of the
      APID map in that range (0x900). This is of course 0x1100 - 0x900 = 0x800
      and not 0x200, so the amount of 4-byte integers it can fit is not 0x80
      but 0x200. Fix this and make the math more explicit so it can be more
      easily factored out and adjusted if that becomes necessary for a future
      SoC.
      
      Also fix a dangerous typo in REG_APID_MAP() where the macro would
      reference a random variable `i` rather than its argument (`apid`), and
      we just got lucky that the only caller in the current code happened to
      pass in a variable called `i` as that argument.
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Change-Id: I049dd044fa5aeb65be0e7b12150afd6eb4bac0fa
      de67080f
    • Avinash Mehta's avatar
      product/tc0: Enable Theodul DSU in TC platform · e5da15e0
      Avinash Mehta authored
      
      
      Increase the core count and add respective entries in DTS.
      Add Klein assembly file to cpu sources for core initialization.
      Add SCMI entries for cores.
      Signed-off-by: default avatarAvinash Mehta <avinash.mehta@arm.com>
      Change-Id: I14dc1d87df6dcc8d560ade833ce1f92507054747
      e5da15e0
  15. 02 Feb, 2021 1 commit
  16. 29 Jan, 2021 13 commits
  17. 28 Jan, 2021 1 commit
  18. 24 Jan, 2021 2 commits
    • Andre Przywara's avatar
      allwinner: Allow conditional compilation of SCPI and native PSCI ops · b23ab8eb
      Andre Przywara authored
      
      
      Now that we have split the native and the SCPI version of the PSCI ops,
      we can introduce build options to compile in either or both of them.
      
      If one version is not compiled in, some stub functions make sure the
      common code still compiles and makes the right decisions.
      
      By default both version are enabled (as before), but one of them can be
      disabled on the make command line, or via a platform specific Makefile.
      
      Change-Id: I0c019d8700c0208365eacf57809fb8bc608eb9c0
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarSamuel Holland <samuel@sholland.org>
      b23ab8eb
    • Samuel Holland's avatar
      allwinner: Split native and SCPI-based PSCI implementations · fe753c97
      Samuel Holland authored
      
      
      In order to keep SCP firmware as optional, the original, limited native
      PSCI implementation was kept around as a fallback. This turned out to be
      a good decision, as some newer SoCs omit the ARISC, and thus cannot run
      SCP firmware.
      
      However, keeping the two implementations in one file makes things
      unnecessarily messy. First, it is difficult to compile out the
      SCPI-based implementation where it is not applicable. Second the check
      is done in each callback, while scpi_available is only updated at boot.
      This makes the individual callbacks unnecessarily complicated.
      
      It is cleaner to provide two entirely separate implementations in two
      separate files. The native implementation does not support any kind of
      CPU suspend, so its callbacks are greatly simplified. One function,
      sunxi_validate_ns_entrypoint, is shared between the two implementations.
      
      Finally, the logic for choosing between implementations is kept in a
      third file, to provide for platforms where only one implementation is
      applicable and the other is compiled out.
      
      Change-Id: I4914f07d8e693dbce218e0e2394bef15c42945f8
      Signed-off-by: default avatarSamuel Holland <samuel@sholland.org>
      fe753c97