1. 24 Feb, 2020 2 commits
  2. 18 Feb, 2020 4 commits
  3. 17 Feb, 2020 3 commits
    • Vishnu Banavath's avatar
      corstone700: set UART clocks to 32MHz · 6aa138de
      Vishnu Banavath authored
      
      
      Adding support for 32MHz UART clock and selecting it as the
      default UART clock
      
      Change-Id: I9541eaff70424e85a3b5ee4820ca0e7efb040d2c
      Signed-off-by: default avatarVishnu Banavath <vishnu.banavath@arm.com>
      Signed-off-by: default avatarAbdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
      6aa138de
    • Avinash Mehta's avatar
      corstone700: clean-up as per coding style guide · 93cf1f64
      Avinash Mehta authored
      
      
      Running checkpatch.pl on the codebase and making required changes
      
      Change-Id: I7d3f8764cef632ab2a6d3c355c68f590440b85b8
      Signed-off-by: default avatarAvinash Mehta <avinash.mehta@arm.com>
      Signed-off-by: default avatarAbdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
      93cf1f64
    • Khandelwal's avatar
      Corstone700: add support for mhuv2 in arm TF-A · c6fe43b7
      Khandelwal authored
      
      
      Note: This patch implements in-band messaging protocol only.
      ARM has launched a next version of MHU i.e. MHUv2 with its latest
      subsystems. The main change is that the MHUv2 is now a distributed IP
      with different peripheral views (registers) for the sender and receiver.
      
      Another main difference is that MHUv1 duplex channels are now split into
      simplex/half duplex in MHUv2. MHUv2 has a configurable number of
      communication channels. There is a capability register (MSG_NO_CAP) to
      find out how many channels are available in a system.
      
      The register offsets have also changed for STAT, SET & CLEAR registers
      from 0x0, 0x8 & 0x10 in MHUv1 to 0x0, 0xC & 0x8 in MHUv2 respectively.
      
      0x0    0x4  0x8  0xC             0x1F
      ------------------------....-----
      | STAT |    |    | SET |    |   |
      ------------------------....-----
            Transmit Channel
      
      0x0    0x4  0x8   0xC            0x1F
      ------------------------....-----
      | STAT |    | CLR |    |    |   |
      ------------------------....-----
              Receive Channel
      
      The MHU controller can request the receiver to wake-up and once the
      request is removed, the receiver may go back to sleep, but the MHU
      itself does not actively put a receiver to sleep.
      
      So, in order to wake-up the receiver when the sender wants to send data,
      the sender has to set ACCESS_REQUEST register first in order to wake-up
      receiver, state of which can be detected using ACCESS_READY register.
      ACCESS_REQUEST has an offset of 0xF88 & ACCESS_READY has an offset
      of 0xF8C and are accessible only on any sender channel.
      
      This patch adds necessary changes in a new file required to support the
      latest MHUv2 controller. This patch also needs an update in DT binding
      for ARM MHUv2 as we need a second register base (tx base) which would
      be used as the send channel base.
      
      Change-Id: I1455e08b3d88671a191c558790c503eabe07a8e6
      Signed-off-by: default avatarTushar Khandelwal <tushar.khandelwal@arm.com>
      c6fe43b7
  4. 13 Feb, 2020 1 commit
  5. 12 Feb, 2020 1 commit
  6. 11 Feb, 2020 1 commit
  7. 10 Feb, 2020 2 commits
  8. 07 Feb, 2020 15 commits
  9. 06 Feb, 2020 2 commits
    • Max Shvetsov's avatar
      Adds option to read ROTPK from registers for FVP · a6ffddec
      Max Shvetsov authored
      
      
      Enables usage of ARM_ROTPK_LOCATION=regs for FVP board.
      Removes hard-coded developer keys. Instead, setting
      ARM_ROTPK_LOCATION=devel_* takes keys from default directory.
      In case of ROT_KEY specified - generates a new hash and replaces the
      original.
      
      Note: Juno board was tested by original feature author and was not tested
      for this patch since we don't have access to the private key. Juno
      implementation was moved to board-specific file without changing
      functionality. It is not known whether byte-swapping is still needed
      for this platform.
      
      Change-Id: I0fdbaca0415cdcd78f3a388551c2e478c01ed986
      Signed-off-by: default avatarMax Shvetsov <maksims.svecovs@arm.com>
      a6ffddec
    • Louis Mayencourt's avatar
      fvp: Slightly Bump the stack size for bl1 and bl2 · 64271c74
      Louis Mayencourt authored
      
      
      Stack usage reaches 90% with some configuration. Bump slightly the stack
      size to prevent a stack-overflow.
      
      Change-Id: I44ce8b12906586a42f152b7677785fcdc5e78ae1
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      64271c74
  10. 04 Feb, 2020 1 commit
  11. 03 Feb, 2020 1 commit
  12. 27 Jan, 2020 1 commit
  13. 10 Jan, 2020 2 commits
    • 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
    • Alexei Fedorov's avatar
      FVP: Remove re-definition of topology related build options · 94f1c959
      Alexei Fedorov authored
      
      
      This patch removes re-definition of the following FVP build
      options from plat\arm\board\fvp\fvp_def.h:
       'FVP_CLUSTER_COUNT'
       'FVP_MAX_CPUS_PER_CLUSTER'
       'FVP_MAX_PE_PER_CPU'
      which are set in platform.mk.
      
      This fixes a potential problem when a build option set in
      platform.mk file can be re-defined in fvp_def.h header file
      used by other build component with a different makefile which
      does not set this option.
      Ref. GENFW-3505.
      
      Change-Id: I4288629920516acf2c239c7b733f92a0c5a812ff
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      94f1c959
  14. 07 Jan, 2020 3 commits
  15. 03 Jan, 2020 1 commit
    • Vishnu Banavath's avatar
      drivers: add a driver for snoop control unit · c20c0525
      Vishnu Banavath authored
      
      
      The SCU connects one to four Cortex-A5/Cortex-A9 processors
      to the memory system through the AXI interfaces.
      
      The SCU functions are to:
      - maintain data cache coherency between the Cortex-A5/Cortex-A9
        processors
      - initiate L2 AXI memory accesses
      - arbitrate between Cortex-A5/Cortex-A9 processors requesting
        L2 accesses
      - manage ACP accesses.
      
      Snoop Control Unit will enable to snoop on other CPUs caches.
      This is very important when it comes to synchronizing data between
      CPUs. As an example, there is a high chance that data might be
      cache'd and other CPUs can't see the change. In such cases,
      if snoop control unit is enabled, data is synchoronized immediately
      between CPUs and the changes are visible to other CPUs.
      
      This driver provides functionality to enable SCU as well as enabling
      user to know the following
      - number of CPUs present
      - is a particular CPU operating in SMP mode or AMP mode
      - data cache size of a particular CPU
      - does SCU has ACP port
      - is L2CPRESENT
      
      Change-Id: I0d977970154fa60df57caf449200d471f02312a0
      Signed-off-by: default avatarVishnu Banavath <vishnu.banavath@arm.com>
      c20c0525