Skip to content
  1. Sep 12, 2024
  2. Sep 10, 2024
  3. Sep 09, 2024
  4. Sep 06, 2024
  5. Sep 05, 2024
  6. Sep 03, 2024
  7. Aug 30, 2024
  8. Aug 29, 2024
  9. Aug 27, 2024
  10. Aug 20, 2024
  11. Aug 19, 2024
  12. Aug 16, 2024
  13. Aug 15, 2024
  14. Aug 14, 2024
    • Nishant Sharma's avatar
      mod/noc_s3: add the support to program psam · ed7e163e
      Nishant Sharma authored
      
      
      Programmable System Address Map feature in NoC S3 allows configurable
      address map for address‑based routing from each upstream interface to
      the corresponding downstream interfaces.
      
      Add the support to configure PSAM during runtime in following mode
      1) Static mapping with the information passed through module config.
         It is expected that the statically mapped regions will not change
         during the runtime. Their context is handled by the module.
      2) Mapping/Unmapping requested through the APIs exposed by the module.
         These APIs are expected to be used by the modules that will change
         the mapping during the runtime and modules will do additional steps
         such as mapping peripheral base in the address translation unit
         before calling the API. For this reason, the module will maintain the
         context for the blocks that it is managing.
      
      Signed-off-by: Nishant Sharma's avatarNishant Sharma <nishant.sharma@arm.com>
      Change-Id: Ia2c08a76e5d48ecdb6b38d19180e015aca22dc41
      ed7e163e
    • Nishant Sharma's avatar
      mod/noc_s3: add the support to discovery node offset · 468ef446
      Nishant Sharma authored
      
      
      The configuration register layout for NoC S3 is laid out in a
      multibranch tree format. On the top of the tree is global configuration
      node which points to the domain and domains points to components nodes.
      The components nodes contains subfeatures that can be used to enable
      PSAM, APU, FCU and IDM.
      
      Add the support to validate the part number of NoC S3 and find the
      offset address of the configuration registers of all the nodes on the
      tree and put that into a table.
      
      For example: The discovery process will convert the following tree
                             Global CFGNI
                             /         \
                            /           \
                          VD0           VD1
                         /              /
                       PD0             PD1
                      /               /
                    CD0              CD1
                   /  \             /
                  C0  C1           C2
      
      to the following table containing node offset.
      _______________________________________________
      Node Type      | Index  |      Node Id         |
      ---------------|--------|----------------------|
                     |        |   0   |   1   |  2   |
      ---------------|--------|-------|-------|------|
      Global CFGNI   |   0    |CFGNI0 |       |      |
      Voltage Domain |   1    |VD0    |VD1    |      |
      Power Domain   |   2    |PD0    |PD1    |      |
      CLock Domain   |   3    |CD0    |CD1    |      |
      ASNI           |   4    |C0     |C1     |C2    |
      AMNI           |   5    |       |       |      |
      PMU            |   6    |       |       |      |
      HSNI           |   7    |       |       |      |
      HMNI           |   8    |       |       |      |
      PMNI           |   9    |       |       |      |
      
      As the node id and type are predefined, the offset of the target node is
      fetched in O(1) by using id and type. To get offset of the C2, the user
      will access the table using node type 4 and Id 2. Table[4][2] will give
      offset of C2
      
      Signed-off-by: Nishant Sharma's avatarNishant Sharma <nishant.sharma@arm.com>
      Change-Id: I221694d12a853e46df0f6c434058eaf6dfb4aa2b
      468ef446
    • Nishant Sharma's avatar
      mod/noc_s3: add initial framework handlers · ffd00f49
      Nishant Sharma authored
      
      
      NoC S3 Network-on-Chip Interconnect is a highly configurable
      system-level interconnect. This design allows the creation of a highly
      optimized, non-coherent interconnect which supports Programmable System
      Address Map, Programmable Access Protection Unit, Programmable Fault
      Protection Unit and many more.
      
      Add initial framework handlers as preparation to add support for the
      NoC S3 features. The handlers added in this change will be consumed by
      the subsequent changes.
      
      Signed-off-by: Nishant Sharma's avatarNishant Sharma <nishant.sharma@arm.com>
      Change-Id: I81d9d7175a4c1f43dd84e5118772bc8b9d6826d5
      ffd00f49
  15. Aug 12, 2024
    • Wei-Chia Su's avatar
      arch: Enhance compatibility for `arch_nvic_init` · e1fb6b01
      Wei-Chia Su authored and Leandro Belli's avatar Leandro Belli committed
      
      
      In Cortex-M3/M4/M23/M33, a core register block was named the System Control and
      ID Register, separate from the System Control Block (SCnSCB). In Cortex-M55/M85,
      the same block was renamed to Implementation Control Registers (ICB), creating a
      naming discrepancy within the same Cortex v8m family. Therefore, using #ifdef
      ARMV7M alone is inadequate. To ensure compatibility, the register's definition
      is utilized over the family.
      
      This adjustment should facilitate the build for Cortex-M23 and M33 cores.
      
      Signed-off-by: default avatarWei-Chia Su <Wei-Chia.Su@arm.com>
      e1fb6b01
  16. Aug 09, 2024
Loading