1. 13 Jan, 2021 21 commits
  2. 12 Jan, 2021 2 commits
  3. 11 Jan, 2021 4 commits
    • Marek Behún's avatar
      plat: marvell: armada: a3k: improve 4GB DRAM usage from 3.375 GB to 3.75 GB · b04921f7
      Marek Behún authored
      
      
      The current configuration of CPU windows on Armada 37x0 with 4 GB DRAM
      can only utilize 3.375 GB of memory. This is because there are only 5
      configuration windows, configured as such (in hexadecimal, also showing
      ranges not configurable by CPU windows):
      
               0 - 80000000 |   2 GB | DDR  | CPU window 0
        80000000 - C0000000 |   1 GB | DDR  | CPU window 1
        C0000000 - D0000000 | 256 MB | DDR  | CPU window 2
        D0000000 - D2000000 |  32 MB |      | Internal regs
            empty space     |        |      |
        D8000000 - D8010000 |  64 KB |      | CCI regs
            empty space     |        |      |
        E0000000 - E8000000 | 128 MB | DDR  | CPU window 3
        E8000000 - F0000000 | 128 MB | PCIe | CPU window 4
            empty space     |        |      |
        FFF00000 - end      |  64 KB |      | Boot ROM
      
      This can be improved by taking into account that:
      - CCI window can be moved (the base address is only hardcoded in TF-A;
        U-Boot and Linux will not break with changing of this address)
      - PCIe window can be moved (upstream U-Boot can change device-tree
        ranges of PCIe if PCIe window is moved)
      
      Change the layout after the Internal regs as such:
      
        D2000000 - F2000000 | 512 MB | DDR  | CPU window 3
        F2000000 - FA000000 | 128 MB | PCIe | CPU window 4
            empty space     |        |      |
        FE000000 - FE010000 |  64 KB |      | CCI regs
            empty space     |        |      |
        FFF00000 - end      |  64 KB |      | Boot ROM
      
      (Note that CCI regs base address is moved from D8000000 to FE000000 in
       all cases, not only for the configuration with 4 GB of DRAM. This is
       because TF-A is built with this address as a constant, so we cannot
       change this address at runtime only on some boards.)
      
      This yields 3.75 GB of usable RAM.
      
      Moreover U-Boot can theoretically reconfigure the PCIe window to DDR if
      it discovers that no PCIe card is connected. This can add another 128 MB
      of DRAM (resulting only in 128 MB of DRAM not being used).
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      Change-Id: I4ca1999f852f90055fac8b2c4f7e80275a13ad7e
      b04921f7
    • Aditya Angadi's avatar
      plat/arm: rename rddanielxlr to rdv1mc · 90aecf1e
      Aditya Angadi authored
      
      
      Reference Design platform RD-Daniel-ConfigXLR has been renamed to
      RD-V1-MC. Correspondingly, remove all uses of 'rddanielxlr' and replace
      it with 'rdv1mc' where appropriate.
      Signed-off-by: default avatarAditya Angadi <aditya.angadi@arm.com>
      Change-Id: I5d91c69738397b19ced43949b4080c74678e604c
      90aecf1e
    • Aditya Angadi's avatar
      plat/arm: rename rddaniel to rdv1 · edf771a1
      Aditya Angadi authored
      
      
      Reference Design platform RD-Daniel has been renamed to RD-V1.
      Correspondingly, remove all uses of 'rddaniel' and replace it with
      'rdv1' where appropriate.
      Signed-off-by: default avatarAditya Angadi <aditya.angadi@arm.com>
      Change-Id: I1702bab39c501f8c0a09df131cb2394d54c83bcf
      edf771a1
    • Venkatesh Yadav Abbarapu's avatar
      plat: xilinx: Fix non-MISRA compliant code · e43258fa
      Venkatesh Yadav Abbarapu authored
      
      
      This patch fixes the non compliant code like missing braces for
      conditional single statement bodies.
      Signed-off-by: default avatarVenkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
      Change-Id: I95b410ae5950f85dc913c4448fcd0a97e0fd490c
      e43258fa
  4. 05 Jan, 2021 1 commit
    • Marek Behún's avatar
      plat: marvell: armada: a3k: support doing system reset via CM3 secure coprocessor · d9243f26
      Marek Behún authored
      
      
      Introduce a new build option CM3_SYSTEM_RESET for A3700 platform, which,
      when enabled, adds code to the PSCI reset handler to try to do system
      reset by the WTMI firmware running on the Cortex-M3 secure coprocessor.
      (This function is exposed via the mailbox interface.)
      
      The reason is that the Turris MOX board has a HW bug which causes reset
      to hang unpredictably. This issue can be solved by putting the board in
      a specific state before reset.
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      Change-Id: I3f60b9f244f334adcd33d6db6a361fbc8b8d209f
      d9243f26
  5. 04 Jan, 2021 3 commits
  6. 29 Dec, 2020 1 commit
    • Alexei Fedorov's avatar
      Plat AXG: Fix PLAT_MAX_PWR_LVL value · 47f2445a
      Alexei Fedorov authored
      
      
      This patch fixes AXG platform build error:
      plat/amlogic/axg/axg_pm.c: In function 'axg_pwr_domain_off':
      plat/amlogic/axg/axg_pm.c:124:43: error: array subscript 2
       is above array bounds of 'const plat_local_state_t[2]'
       {aka 'const unsigned char[2]'}
      by changing PLAT_MAX_PWR_LVL from MPIDR_AFFLVL1 to MPIDR_AFFLVL2
      in plat\amlogic\axg\include\platform_def.h.
      
      Change-Id: I9a701e8f26231e62f844920aec5830664f3fb324
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      47f2445a
  7. 23 Dec, 2020 8 commits
    • Andrew F. Davis's avatar
      ti: k3: Introduce lite device board support · 84af8956
      Andrew F. Davis authored
      Add device support for the 'lite' K3 devices. These will use modified
      device addresses and allow for fewer cores to save memory.
      
      Note: This family of devices are characterized by a single cluster
      of ARMv8 processor upto a max of 4 processors and lack of a level 3
      cache.
      
      The first generation of this family is introduced with AM642.
      
      See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
      for further details: https://www.ti.com/lit/pdf/spruim2
      
      Signed-off-by: default avatarAndrew F. Davis <afd@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Change-Id: I8cd2c1c9a9434646d0c72fca3162dd5bc9bd692a
      84af8956
    • Nishanth Menon's avatar
      ti: k3: common: sec_proxy: Introduce sec_proxy_lite definition · 7f323eb2
      Nishanth Menon authored
      There are two communication scheme that have been enabled to communicate
      with Secure Proxy in TI.
      a) A full fledged prioritized communication scheme, which involves upto
         5 threads from the perspective of the host software
      b) A much simpler "lite" version which is just a two thread scheme
         involving just a transmit and receive thread scheme.
      
      The (a) system is specifically useful when the SoC is massive
      involving multiple processor systems and where the potential for
      priority inversion is clearly a system usecase killer. However, this
      comes with the baggage of significant die area for larger number of
      instances of secure proxy, ring accelerator and backing memories
      for queued messages. Example SoCs using this scheme would be:
      AM654[1], J721E[2], J7200[3]  etc.
      
      The (b) scheme(aka the lite scheme) is introduced on smaller SoCs
      where memory and area concerns are paramount. The tradeoff of
      priority loss is acceptable given the reduced number of processors
      communicating with the central system controller. This brings about
      a very significant area and memory usage savings while the loss of
      communication priority has no demonstrable impact. Example SoC using
      this scheme would be: AM642[4]
      
      While we can detect using JTAG ID and conceptually handle things
      dynamically, adding such a scheme involves a lot of unused data (cost
      of ATF memory footprint), pointer lookups (performance cost) and still
      due to follow on patches, does'nt negate the need for a different
      build configuration. However, (a) and (b) family of SoCs share the
      same scheme and addresses etc, this helps minimize our churn quite a
      bit
      
      Instead of introducing a complex data structure lookup scheme, lets
      keep things simple by first introducing the pieces necessary for an
      alternate communication scheme, then introduce a second platform
      representing the "lite" family of K3 processors.
      
      NOTE: This is only possible since ATF uses just two (secure) threads
      for actual communication with the central system controller. This is
      sufficient for the function that ATF uses.
      
      The (a) scheme and the (b) scheme also varies w.r.t the base addresses
      used, even though the memory window assigned for them have remained
      consistent. We introduce the delta as part of this change as well.
      This is expected to remain consistent as a standard in TI SoCs.
      
      References:
      [1] See AM65x Technical Reference Manual (SPRUID7, April 2018)
      for further details: https://www.ti.com/lit/pdf/spruid7
      
      [2] See J721E Technical Reference Manual (SPRUIL1, May 2019)
      for further details: https://www.ti.com/lit/pdf/spruil1
      
      [3] See J7200 Technical Reference Manual (SPRUIU1, June 2020)
      for further details: https://www.ti.com/lit/pdf/spruiu1
      
      [4] See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
      for further details: https://www.ti.com/lit/pdf/spruim2
      
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Change-Id: I697711ee0e6601965015ddf950fdfdec8e759bfc
      7f323eb2
    • Nishanth Menon's avatar
      ti: k3: Move USE_COHERENT_MEM only for the generic board · ff7b75e2
      Nishanth Menon authored
      commit 65f7b817
      
       ("ti: k3: common: Use coherent memory for shared data")
      introduced WARMBOOT_ENABLE_DCACHE_EARLY and USE_COHERENT_MEM to handle
      multiple clusters across L3 cache systems. This is represented by
      "generic" board in k3 platform.
      
      On "lite" platforms, however, system level coherency is lacking since
      we don't have a global monitor or an L3 cache controller. Though, at
      a cluster level, ARM CPU level coherency is very much possible since
      the max number of clusters permitted in lite platform configuration is
      "1".
      
      However, we need to be able to disable USE_COHERENT_MEM for the lite
      configuration due to the lack of system level coherency.
      
      See docs/getting_started/build-options.rst for further information.
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Change-Id: I4a0ec150b3f9ea12369254aef834a6cbe82d6be6
      ff7b75e2
    • Suman Anna's avatar
      ti: k3: drivers: ti_sci: Update ti_sci_msg_req_reboot to include domain · 22b7a229
      Suman Anna authored
      
      
      The ti_sci_msg_req_reboot message payload has been extended to include
      a domain field, and this should be zero to reset the entire SoC with
      System Firmwares newer than v2020.04. Add the domain field to the
      ti_sci_msg_req_reboot message structure for completeness. Set it up
      to zero to fix the reboot issues with newer firmwares.
      
      This takes care of the specific ABI that changed and has an impact on
      ATF function.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Change-Id: I4f8064b9d6555687822dc2b2b8ec97609286fa0b
      22b7a229
    • Nishanth Menon's avatar
      ti: k3: common: sec_proxy: Fill non-message data fields with 0x0 · f577388a
      Nishanth Menon authored
      
      
      Sec proxy data buffer is 60 bytes with the last of the registers
      indicating transmission completion. This however poses a bit
      of a challenge.
      
      The backing memory for sec_proxy is regular memory, and all sec proxy
      does is to trigger a burst of all 60 bytes of data over to the target
      thread backing ring accelerator. It doesn't do a memory scrub when
      it moves data out in the burst. When we transmit multiple messages,
      remnants of previous message is also transmitted which results in
      some random data being set in TISCI fields of messages that have been
      expanded forward.
      
      The entire concept of backward compatibility hinges on the fact that
      the unused message fields remain 0x0 allowing for 0x0 value to be
      specially considered when backward compatibility of message extension
      is done.
      
      So, instead of just writing the completion register, we continue
      to fill the message buffer up with 0x0 (note: for partial message
      involving completion, we already do this).
      
      This allows us to scale and introduce ABI changes back into TF-A only
      as needed.
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Change-Id: Ie22cb2a319f4aa80aef23ffc7e059207e5d4c640
      f577388a
    • Nishanth Menon's avatar
      ti: k3: common: Make plat_get_syscnt_freq2 check CNT_FID0 GTC reg · 6a22d9ea
      Nishanth Menon authored
      ARM's generic timer[1] picks up it's graycode from GTC. However, the
      frequency of the GTC is supposed to be programmed in CNTFID0[2]
      register.
      
      In K3, architecture, GTC provides a central time to many parts of the
      SoC including graycode to the generic timer in the ARMv8 subsystem.
      However, due to the central nature and the need to enable the counter
      early in the boot process, the R5 based bootloader enables GTC and
      programs it's frequency based on central needs of the system. This
      may not be a constant 200MHz based on the system. The bootloader is
      supposed to program the FID0 register with the correct frequency it
      has sourced for GTC from the central system controller, and TF-A is
      supposed to use that as the frequency for it's local timer.
      
      A mismatch in programmed frequency and what we program for generic
      timer will, as we can imagine, all kind of weird mayhem.
      
      So, check the CNTFID0 register, if it is 0, warn and use the default
      frequency to continue the boot process.
      
      While at it, we can also check CNTCR register to provide some basic
      diagnostics to make sure that we don't have OS folks scratch their
      heads. Even though this is used during cpu online operations, the cost
      of this additional check is minimal enough for us not to use #ifdeffery
      with DEBUG flags.
      
      [1] https://developer.arm.com/documentation/100095/0002/generic-timer/generic-timer-register-summary/aarch64-generic-timer-register-summary
      [2] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntfid0
      [3] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntcr
      
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Change-Id: Ib03e06788580f3540dcb1a11677d0d6d398b2c9f
      6a22d9ea
    • Nishanth Menon's avatar
      ti: k3: common: Enable A72 erratum 1319367 · 60fba7c8
      Nishanth Menon authored
      The CatB erratum ARM_ERRATA_A72_1319367 applies to all TI A72
      platforms as well.
      
      See the following for further information:
      https://developer.arm.com/documentation/epm012079/11/
      
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Change-Id: I80c6262b9cdadcb12f6dfd5a21272989ba257719
      60fba7c8
    • Nishanth Menon's avatar
      ti: k3: common: Enable A53 erratum 1530924 · c3e23332
      Nishanth Menon authored
      The CatB erratum ARM_ERRATA_A53_1530924 applies to all TI A53
      platforms as well.
      
      See the following for further information:
      https://developer.arm.com/documentation/epm048406/2100
      
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Change-Id: Ic095424ce510139e060b38cfb84509d2cc573cad
      c3e23332