1. 26 Mar, 2020 1 commit
    • Yann Gautier's avatar
      stm32mp1: dynamically map DDR later and non-cacheable during its test · 84686ba3
      Yann Gautier authored
      
      
      A speculative accesses to DDR could be done whereas it was not reachable
      and could lead to bus stall.
      To correct this the dynamic mapping in MMU is used.
      A first mapping is done for DDR tests with MT_NON_CACHEABLE attribute,
      once DDR access is setup. It is then unmapped and a new mapping DDR is done
      with cacheable attribute (through MT_MEMORY) to speed-up BL33 (or OP-TEE)
      load.
      
      The disabling of cache during DDR tests is also removed, as now useless.
      A call to new functions stm32mp_{,un}map_ddr_non_cacheable() is done
      instead.
      
      PLAT_XLAT_TABLES_DYNAMIC is activated globally as used in BL2 and BL32.
      
      BL33 max size is also updated to take into account the secure and shared
      memory areas. Those are used in OP-TEE case.
      
      Change-Id: I22c48b4a48255ee264991c34ecbb15bfe87e67c3
      Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      84686ba3
  2. 23 Mar, 2020 3 commits
  3. 17 Mar, 2020 1 commit
    • Andre Przywara's avatar
      rpi3: gpio: Simplify GPIO setup · 0d92745e
      Andre Przywara authored
      
      
      There is really no reason to use and pass around a struct when its only
      member is the (fixed) base address.
      
      Remove the struct and just use the base address on its own inside the
      GPIO driver. Then set the base address automatically.
      
      This simplifies GPIO setup for users, which now don't need to deal with
      zeroing a struct and setting the base address anymore.
      
      Change-Id: I3060f7859e3f8ef9a24cc8fb38307b5da943f127
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      0d92745e
  4. 10 Mar, 2020 1 commit
  5. 08 Mar, 2020 1 commit
  6. 06 Mar, 2020 2 commits
    • Sumit Garg's avatar
      TBB: Add an IO abstraction layer to load encrypted firmwares · 2be57b86
      Sumit Garg authored
      
      
      TBBR spec advocates for optional encryption of firmwares (see optional
      requirement: R060_TBBR_FUNCTION). So add an IO abstaction layer to
      support firmware decryption that can be stacked above any underlying IO/
      packaging layer like FIP etc. It aims to provide a framework to load any
      encrypted IO payload.
      
      Also, add plat_get_enc_key_info() to be implemented in a platform
      specific manner as handling of encryption key may vary from one platform
      to another.
      Signed-off-by: default avatarSumit Garg <sumit.garg@linaro.org>
      Change-Id: I9892e0ddf00ebecb8981301dbfa41ea23e078b03
      2be57b86
    • Sumit Garg's avatar
      drivers: crypto: Add authenticated decryption framework · 7cda17bb
      Sumit Garg authored
      
      
      Add framework for autheticated decryption of data. Currently this
      patch optionally imports mbedtls library as a backend if build option
      "DECRYPTION_SUPPORT = aes_gcm" is set to perform authenticated decryption
      using AES-GCM algorithm.
      Signed-off-by: default avatarSumit Garg <sumit.garg@linaro.org>
      Change-Id: I2966f0e79033151012bf4ffc66f484cd949e7271
      7cda17bb
  7. 05 Mar, 2020 1 commit
    • Manish Pandey's avatar
      driver/arm/css: minor bug fix · cc7f89de
      Manish Pandey authored
      
      
      The cpu index was wrongly checked causing it to assert always.
      Since this code path is exercised only during TF test "NODE_HW_STAT",
      which queries Power state from SCP, this bug was not detected earlier.
      
      Change-Id: Ia25cef4c0aa23ed08092df39134937a2601c21ac
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      cc7f89de
  8. 25 Feb, 2020 10 commits
  9. 24 Feb, 2020 1 commit
    • Sandrine Bailleux's avatar
      Introduce a new "dualroot" chain of trust · 5ab8b717
      Sandrine Bailleux authored
      
      
      This new chain of trust defines 2 independent signing domains:
      
      1) One for the silicon firmware (BL1, BL2, BL31) and optionally the
         Trusted OS. It is rooted in the Silicon ROTPK, just as in the TBBR
         CoT.
      
      2) One for the Normal World Bootloader (BL33). It is rooted in a new key
         called Platform ROTPK, or PROTPK for short.
      
      In terms of certificates chain,
      
      - Signing domain 1) is similar to what TBBR advocates (see page 21 of
        the TBBR specification), except that the Non-Trusted World Public Key
        has been removed from the Trusted Key Certificate.
      
      - Signing domain 2) only contains the Non-Trusted World Content
        certificate, which provides the hash of the Non-Trusted World
        Bootloader. Compared to the TBBR CoT, there's no Non-Trusted World
        Key certificate for simplicity.
      
      Change-Id: I62f1e952522d84470acc360cf5ee63e4c4b0b4d9
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      5ab8b717
  10. 20 Feb, 2020 1 commit
  11. 18 Feb, 2020 3 commits
    • Zelalem's avatar
      coverity: fix MISRA violations · 2fe75a2d
      Zelalem authored
      
      
      Fixes for the following MISRA violations:
      - Missing explicit parentheses on sub-expression
      - An identifier or macro name beginning with an
        underscore, shall not be declared
      - Type mismatch in BL1 SMC handlers and tspd_main.c
      
      Change-Id: I7a92abf260da95acb0846b27c2997b59b059efc4
      Signed-off-by: default avatarZelalem <zelalem.aweke@arm.com>
      2fe75a2d
    • Sandrine Bailleux's avatar
      TBBR: Reduce size of hash buffers when possible · 0b4e5921
      Sandrine Bailleux authored
      The TBBR implementation extracts hashes from certificates and stores
      them in static buffers. TF-A supports 3 variants of SHA right now:
      SHA-256, SHA-384 and SHA-512. When support for SHA-512 was added in
      commit 9a3088a5
      
       ("tbbr: Add build flag
      HASH_ALG to let the user to select the SHA"), the hash buffers got
      unconditionally increased from 51 to 83 bytes each. We can reduce that
      space if we're using SHA-256 or SHA-384.
      
      This saves some BSS space in both BL1 and BL2:
      - BL1 with SHA-256: saving 168 bytes.
      - BL1 with SHA-384: saving 80 bytes.
      - BL2 with SHA-256: saving 384 bytes.
      - BL2 with SHA-384: saving 192 bytes.
      
      Change-Id: I0d02e5dc5f0162e82339c768609c9766cfe7e2bd
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      0b4e5921
    • Sandrine Bailleux's avatar
      TBBR: Reduce size of ECDSA key buffers · 495599cd
      Sandrine Bailleux authored
      
      
      The TBBR implementation extracts public keys from certificates and
      stores them in static buffers. DER-encoded ECDSA keys are only 91 bytes
      each but were each allocated 294 bytes instead. Reducing the size of
      these buffers saves 609 bytes of BSS in BL2 (294 - 91 = 203 bytes for
      each of the 3 key buffers in use).
      
      Also add a comment claryfing that key buffers are tailored on RSA key
      sizes when both ECDSA and RSA keys are used.
      
      Change-Id: Iad332856e7af1f9814418d012fba3e1e9399f72a
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      495599cd
  12. 15 Feb, 2020 4 commits
  13. 13 Feb, 2020 2 commits
  14. 07 Feb, 2020 3 commits
    • Aditya Angadi's avatar
      drivers/arm/scmi: allow use of multiple SCMI channels · 31e703f9
      Aditya Angadi authored
      
      
      On systems that have multiple platform components that can interpret the
      SCMI messages, there is a need to support multiple SCMI channels (one
      each to those platform components). Extend the existing SCMI interface
      that currently supports only a single SCMI channel to support multiple
      SCMI channels.
      
      Change-Id: Ice4062475b903aef3b5e5bc37df364c9778a62c5
      Signed-off-by: default avatarAditya Angadi <aditya.angadi@arm.com>
      31e703f9
    • 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
    • Louis Mayencourt's avatar
      fconf: initial commit · ab1981db
      Louis Mayencourt authored
      
      
      Introduce the Firmware CONfiguration Framework (fconf).
      
      The fconf is an abstraction layer for platform specific data, allowing
      a "property" to be queried and a value retrieved without the requesting
      entity knowing what backing store is being used to hold the data.
      
      The default backing store used is C structure. If another backing store
      has to be used, the platform integrator needs to provide a "populate()"
      function to fill the corresponding C structure.
      The "populate()" function must be registered to the fconf framework with
      the "FCONF_REGISTER_POPULATOR()". This ensures that the function would
      be called inside the "fconf_populate()" function.
      
      A two level macro is used as getter:
      - the first macro takes 3 parameters and converts it to a function
        call: FCONF_GET_PROPERTY(a,b,c) -> a__b_getter(c).
      - the second level defines a__b_getter(c) to the matching C structure,
        variable, array, function, etc..
      
      Ex: Get a Chain of trust property:
          1) FCONF_GET_PROPERY(tbbr, cot, BL2_id) -> tbbr__cot_getter(BL2_id)
          2) tbbr__cot_getter(BL2_id) -> cot_desc_ptr[BL2_id]
      
      Change-Id: Id394001353ed295bc680c3f543af0cf8da549469
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      ab1981db
  15. 05 Feb, 2020 1 commit
  16. 04 Feb, 2020 1 commit
  17. 30 Jan, 2020 1 commit
    • Grzegorz Jaszczyk's avatar
      plat: marvell: armada: add support for loading MG CM3 images · 81646055
      Grzegorz Jaszczyk authored
      
      
      In order to access MG SRAM, the amb bridge needs to be configured which is
      done in bl2 platform init.
      
      For MG CM3, the image is only loaded to its SRAM and the CM3 itself is
      left in reset. It is because the next stage bootloader (e.g. u-boot)
      will trigger action which will take it out of reset when needed. This
      can happen e.g. when appropriate device-tree setup (which has enabled
      802.3 auto-neg) will be chosen. In other cases the MG CM3 should not be
      running.
      
      Change-Id: I816ea14e3a7174eace068ec44e3cc09998d0337e
      Signed-off-by: default avatarGrzegorz Jaszczyk <jaz@semihalf.com>
      81646055
  18. 28 Jan, 2020 2 commits
  19. 20 Jan, 2020 1 commit