1. 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
  2. 05 Feb, 2021 1 commit
  3. 03 Feb, 2021 1 commit
  4. 02 Feb, 2021 1 commit
  5. 29 Jan, 2021 2 commits
    • Pranav Madhu's avatar
      plat/arm/board: enable AMU for RD-N2 · f7bab276
      Pranav Madhu authored
      
      
      AMU counters are used for monitoring the CPU performance. RD-N2 platform
      has architected AMU available for each core. Enable the use of AMU by
      non-secure OS for supporting the use of counters for processor
      performance control (ACPI CPPC).
      
      Change-Id: I5cc749cf63c18fc5c7563dd754c2f42990a97e23
      Signed-off-by: default avatarPranav Madhu <pranav.madhu@arm.com>
      f7bab276
    • Pranav Madhu's avatar
      plat/arm/board: enable AMU for RD-V1 · c9bf2cf5
      Pranav Madhu authored
      
      
      AMU counters are used for monitoring the CPU performance. RD-V1 platform
      has architected AMU available for each core. Enable the use of AMU by
      non-secure OS for supporting the use of counters for processor
      performance control (ACPI CPPC).
      
      Change-Id: I4003d21407953f65b3ce99eaa8f496d6052546e0
      Signed-off-by: default avatarPranav Madhu <pranav.madhu@arm.com>
      c9bf2cf5
  6. 11 Jan, 2021 2 commits
  7. 07 Jan, 2021 1 commit
    • Pali Rohár's avatar
      Makefile: Do not mark file targets as .PHONY target · a9812206
      Pali Rohár authored
      
      
      Only non-file targets should be set a .PHONY. Otherwise if file target is
      set as .PHONY then targets which depends on those file .PHONY targets would
      be always rebuilt even when their prerequisites are not changed.
      
      File target which needs to be always rebuilt can be specified in Make
      system via having a prerequisite on some .PHONY target, instead of marking
      whole target as .PHONY. In Makefile projects it is common to create empty
      .PHONY target named FORCE for this purpose.
      
      This patch changes all file targets which are set as .PHONY to depends on
      new .PHONY target FORCE, to ensure that these file targets are always
      rebuilt (as before). Basically they are those targets which calls external
      make subprocess.
      
      After FORCE target is specified in main Makefile, remove it from other
      Makefile files to prevent duplicate definitions.
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Change-Id: Iee3b4e0de93879b95eb29a1745a041538412e69e
      a9812206
  8. 16 Dec, 2020 1 commit
  9. 14 Dec, 2020 2 commits
  10. 09 Dec, 2020 3 commits
  11. 08 Dec, 2020 4 commits
  12. 30 Nov, 2020 1 commit
  13. 21 Oct, 2020 1 commit
  14. 20 Oct, 2020 5 commits
  15. 09 Oct, 2020 1 commit
    • Jimmy Brisson's avatar
      Don't return error information from console_flush · 831b0e98
      Jimmy Brisson authored
      
      
      And from crash_console_flush.
      
      We ignore the error information return by console_flush in _every_
      place where we call it, and casting the return type to void does not
      work around the MISRA violation that this causes. Instead, we collect
      the error information from the driver (to avoid changing that API), and
      don't return it to the caller.
      
      Change-Id: I1e35afe01764d5c8f0efd04f8949d333ffb688c1
      Signed-off-by: default avatarJimmy Brisson <jimmy.brisson@arm.com>
      831b0e98
  16. 06 Oct, 2020 1 commit
    • Usama Arif's avatar
      plat/arm: common: add guard for arm_get_rotpk_info_regs · 3bfcc9d7
      Usama Arif authored
      
      
      Only define arm_get_rotpk_info_regs if ROTPK is in registers,
      i.e. (ARM_ROTPK_LOCATION_ID == ARM_ROTPK_REGS_ID). This will
      allow platform build without definition of TZ_PUB_KEY_HASH_BASE
      if dedicated registers for ROTPK are not available on the platform.
      
      Change-Id: I74ee2d5007f5d876a031a1efca20ebee2dede0c7
      Signed-off-by: default avatarUsama Arif <usama.arif@arm.com>
      3bfcc9d7
  17. 05 Oct, 2020 2 commits
  18. 02 Oct, 2020 1 commit
  19. 29 Sep, 2020 5 commits
    • Andre Przywara's avatar
      arm_fpga: Add post-build linker script · 01301b11
      Andre Przywara authored
      
      
      For the Arm Ltd. FPGAs to run, we need to load several payloads into the
      FPGA's memory:
      - Some trampoline code at address 0x0, to jump to BL31's entry point.
      - The actual BL31 binary at the beginning of DRAM.
      - The (generic) DTB image to describe the hardware.
      - The actual non-secure payloads (kernel, ramdisks, ...)
      
      The latter is application specific, but the first three blobs are rather
      generic.
      Since the uploader tool supports ELF binaries, it seems helpful to
      combine these three images into one .axf file, as this also simplifies
      the command line.
      
      Add a post-build linker script, that combines those three bits into one
      ELF file, together with their specific load addresses.
      Include a call to "ld" with this linker script in the platform Makefile,
      so it will be build automatically. The result will be called "bl31.axf".
      
      Change-Id: I4a90da16fa1e0e83b51d19e5b1daf61f5a0bbfca
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      01301b11
    • Andre Przywara's avatar
      arm_fpga: Add ROM trampoline · f45c6d86
      Andre Przywara authored
      
      
      The application cores of the FPGAs used in Arm Ltd. start execution at
      address 0x0. This is the location of some (emulated) ROM area (which can
      be written to by the uploading tool).
      Since the arm_fpga port is configured to run from DRAM, we load BL31 to
      the beginning of DRAM (mapped at 2GB). This requires some small
      trampoline code in the "ROM" to jump to the BL31 entry point.
      
      To avoid some extra magic binary, add a tiny assembly file with that
      trivial jump instruction to the tree, so this binary can be created
      alongside BL31.
      
      Change-Id: I9e4439fc0f093fa24dd49a8377c9edb030fbb477
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      f45c6d86
    • Andre Przywara's avatar
      arm_fpga: Add devicetree file · b48883c7
      Andre Przywara authored
      
      
      The FPGA images used in Arm Ltd. focus on CPU cores, so they share a
      common platform, with a minimal set of peripherals (interconnect, GIC,
      UART).
      This allows to support most platforms with a single devicetree file.
      The topology and number of CPU cores differ, but those will added at
      runtime, in BL31. Other adjustments (GICR size, SPE node, command line)
      are also done at this point.
      
      Add the common devicetree file to TF-A's build system, so it can be
      build together with BL31. At runtime, the resulting .dtb file should be
      uploaded to the address given with FPGA_PRELOADED_DTB_BASE at build time.
      
      Change-Id: I3206d6131059502ec96896e95329865452c9d83e
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      b48883c7
    • Andre Przywara's avatar
      arm_fpga: Remove SPE PMU DT node if SPE is not available · 40a0de19
      Andre Przywara authored
      
      
      The Statistical Profiling Extension (SPE) is an architectural feature we
      can safely detect at runtime. However it still relies on one piece of
      platform-specific information: the interrupt line it is connected
      to. This requires SPE to be described in a devicetree node.
      
      Since SPE support varies with the CPU cores found on an FPGA image, we
      should detect the presence of SPE at runtime, and remove a potentially
      existing SPE PMU node from the DT.
      
      This allows to always have the SPE node in a generic devicetree file,
      without risking exposing it on a CPU without this feature.
      
      Change-Id: I73d83ea8509b03fe7bba20b9cce8d1335035fa31
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      40a0de19
    • Andre Przywara's avatar
      arm_fpga: Adjust GICR size in DT to match number of cores · 283e5595
      Andre Przywara authored
      
      
      The size of a GICv3 redistributor region depends on the number of
      cores in the system. For the ARM FPGA port, we detect the topology at
      runtime, and adjust the CPU DT nodes accordingly.
      Now the size of the GICR region must also be adjusted, or Linux will
      fail to initialise the GICv3.
      
      Use the newly introduced function to overwrite the GICR size entry in
      the GICv3 reg property. We count the number of existing cores by
      iterating over the GICR frames until we find the LAST bit set in TYPER.
      
      Change-Id: Ib69565600859de9b1b15ceb8495172cd26d16fce
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      283e5595
  20. 28 Sep, 2020 1 commit
  21. 25 Sep, 2020 1 commit
    • Javier Almansa Sobrino's avatar
      arm_fpga: Add support for unknown MPIDs · 1994e562
      Javier Almansa Sobrino authored
      
      
      This patch allows the system to fallback to a default CPU library
      in case the MPID does not match with any of the supported ones.
      
      This feature can be enabled by setting SUPPORT_UNKNOWN_MPID build
      option to 1 (enabled by default only on arm_fpga platform).
      
      This feature can be very dangerous on a production image and
      therefore it MUST be disabled for Release images.
      Signed-off-by: default avatarJavier Almansa Sobrino <javier.almansasobrino@arm.com>
      Change-Id: I0df7ef2b012d7d60a4fd5de44dea1fbbb46881ba
      1994e562
  22. 24 Sep, 2020 1 commit