1. 07 Feb, 2020 2 commits
    • Vijayenthiran Subramaniam's avatar
      board/rdn1edge: add support for dual-chip configuration · 2d4b719c
      Vijayenthiran Subramaniam authored
      
      
      RD-N1-Edge based platforms can operate in dual-chip configuration
      wherein two rdn1edge SoCs are connected through a high speed coherent
      CCIX link.
      
      This patch adds a function to check if the RD-N1-Edge platform is
      operating in multi-chip mode by reading the SID register's NODE_ID
      value. If operating in multi-chip mode, initialize GIC-600 multi-chip
      operation by overriding the default GICR frames with array of GICR
      frames and setting the chip 0 as routing table owner.
      
      The address space of the second RD-N1-Edge chip (chip 1) starts from the
      address 4TB. So increase the physical and virtual address space size to
      43 bits to accommodate the multi-chip configuration. If the multi-chip
      mode configuration is detected, dynamically add mmap entry for the
      peripherals memory region of the second RD-N1-Edge SoC. This is required
      to let the BL31 platform setup stage to configure the devices in the
      second chip.
      
      PLATFORM_CORE_COUNT macro is set to be multiple of CSS_SGI_CHIP_COUNT
      and topology changes are added to represent the dual-chip configuration.
      
      In order the build the dual-chip platform, CSS_SGI_CHIP_COUNT macro
      should be set to 2:
      export CROSS_COMPILE=<path-to-cross-compiler>
      make PLAT=rdn1edge CSS_SGI_CHIP_COUNT=2 ARCH=aarch64 all
      
      Change-Id: I576cdaf71f0b0e41b9a9181fa4feb7091f8c7bb4
      Signed-off-by: default avatarAditya Angadi <aditya.angadi@arm.com>
      Signed-off-by: default avatarVijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
      2d4b719c
    • Aditya Angadi's avatar
      drivers/mhu: derive doorbell base address · f8931606
      Aditya Angadi authored
      
      
      In order to allow the MHUv2 driver to be usable with multiple MHUv2
      controllers, use the base address of the controller from the platform
      information instead of the MHUV2_BASE_ADDR macro.
      
      Change-Id: I4dbab87b929fb0568935e6c8b339ce67937f8cd1
      Signed-off-by: default avatarAditya Angadi <aditya.angadi@arm.com>
      f8931606
  2. 10 Jan, 2020 1 commit
    • Deepika Bhavnani's avatar
      Unify type of "cpu_idx" across PSCI module. · 5b33ad17
      Deepika Bhavnani authored
      
      
      NOTE for platform integrators:
         API `plat_psci_stat_get_residency()` third argument
         `last_cpu_idx` is changed from "signed int" to the
         "unsigned int" type.
      
      Issue / Trouble points
      1. cpu_idx is used as mix of `unsigned int` and `signed int` in code
      with typecasting at some places leading to coverity issues.
      
      2. Underlying platform API's return cpu_idx as `unsigned int`
      and comparison is performed with platform specific defines
      `PLAFORM_xxx` which is not consistent
      
      Misra Rule 10.4:
      The value of a complex expression of integer type may only be cast to
      a type that is narrower and of the same signedness as the underlying
      type of the expression.
      
      Based on above points, cpu_idx is kept as `unsigned int` to match
      the API's and low-level functions and platform defines are updated
      where ever required
      Signed-off-by: default avatarDeepika Bhavnani <deepika.bhavnani@arm.com>
      Change-Id: Ib26fd16e420c35527204b126b9b91e8babcc3a5c
      5b33ad17
  3. 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
  4. 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
  5. 13 Mar, 2019 1 commit
  6. 27 Feb, 2019 1 commit