Zynq UltraScale+ Isolation Configuration

Owned by Confluence Wiki Admin (Unlicensed)
Last updated: Jan 13, 2020 by Terry O'Neal (Unlicensed)Version comment

Table of Contents

Defining Subsystems

When using multiple subsystems, each subsystem will own its own devices. Vivado isolation configuration menu is used to assign devices and memories to each subsystem.
By default, Vivado isolation is off, so no subsystems are defined. Both APU and RPU own every slave.


Subsystem Configurations Menus

Vivado isolation configuration is to configure subsystems only, but not isolation. The Vivado menu used to define a subsystem can be reached by selecting Switch To Advanced Mode -> isolation configuration and is shown below. When isolation configuration is selected, PMU subsystem is defined by default.
In the isolation configuration menu,
Check EnableIsolation to start subsystem definition. Right click and select Add New Subsystem
Check Enable Secure Debug to debug from jtag



Right click in the empty area of the isolation configuration menu to bring up the submenu to Add New Subsystem or to add master and slaves to an existing subsystem.


The subsystems defined with isolation configuration are exported as part of the hdf file and

Example Subsytems

APU Subsystem Only


For an APU subsystem running Linux, in addition to the default pmu subsystem, two APU subsystem are required, a secure APU system for running FSBL and ATF and another non-secure APU subsystem for running Linux. The required subsystems and their components are summarized in the table below.

SubsystemDescription
PMU subsystemAlways required and configured by default
All peripherals belonging to APU and RPU need to be in PMU subsystem configuration too for idling them during warm restart
  • Peripherals:
    • peripherals accessed by APU
APU secureRequired for FSBL and ATF
  • secure master:
    • Boot device (SD or QSPI, both controllers includes a DMA, used to load FSBL into OCM)
  • master:
    • APU
  • secure slaves:
    • memory:
      • OCM (ATF runs in OCM by default, but can be moved to ddr)
    • Control and Status Registers:
      • CRF_APB
      • CRL_APB
      • IOU_SLCR
      • EFUSE
APU non-secureRequired as Linux is non-secure.
  • secure master:
    • Boot device (SD or QSPI): if Linux wants to access the boot device, it must be included in the subsystem definition. However, it must be defined as a secure master so as to be in sync with the security setting of the APU secure subsystem definition. Because this is a shared device in the secure and non-secure subsystem, it has to have the same static security setting. FSBL changes the security setting of the boot device to non-secure upon exit so it can be accessed by non-secure Linux. But in the static subsystem definition, define it as secure.
  • master:
    • APU, DAP for debugging as needed.
  • non-secure master:
    • Any other master in the APU subsystem for accessing non-secure slaves only. In general, master are peripherals which include its own DMA.
  • non-secure slaves
      • Memories: DDR
      • Peripherals:
        • UART
        • Others


Example


Below is an example for APU only subsystem definition in the isolation configuration menu. The subsystem boots from SD1 with ATF residing in OCM, running non-secure Linux which has access to all the peripherals in the subsystem.








APU and RPU split non-secure


The two RPUs are running in split mode, each requiring its own subsystem configuration. The subsystem required for this configuration are PMU, APU secure, APU non-secure, RPU0 and RPU1. The RPU are non-secure in order for APU to start/stop RPU from Linux. Linux's (APU non-secure) memory map includes that of the shared DDR memory and TCM in order to allow Linux APU to load the RPU firmware. In addition, RPU control registers are include to allow APU to configure RPU operations mode from Linux.

PMU subsystem (default)Always required and configured by default
All peripherals belonging to APU and RPU need to be in PMU subsystem configuration too for idling them during warm restart
  • Peripherals:
    • peripherals accessed by APU
    • peripherals accessed by RPU0
    • peripherals accessed by RPU1
  • non-secure slaves
    • Change RPU register from secure to non-secure
APU secure (Same as APU only)Required for FSBL and ATF
  • secure master:
    • Boot device (SD or QSPI, both controllers includes a DMA)
  • master:
    • APU
  • secure slaves:
    • memory:
      • OCM
    • Control and Status Registers:
      • CRF_APB
      • CRL_APB
      • IOU_SLCR
      • EFUSE
APU non-secureRequired as Linux is non-secure.
  • secure master:
    • Boot device (SD or QSPI): if Linux wants to access the boot device, it must be included in the subsystem definition. However, it must be defined as a secure master so as to be in sync with the security setting of the APU secure subsystem definition. Because this is a shared device in the secure and non-secure subsystem, it has to have the same static security setting. FSBL changes the security setting of the boot device to non-secure upon exit so it can be accessed by non-secure Linux. But in the static subsystem definition, define it as secure.
  • master:
    • APU, DAP for debugging as needed.
  • non-secure master:
    • Any other master in the APU subsystem for accessing non-secure slaves only. In general, master are peripherals which include its own DMA.
  • non-secure slaves
    • Memories:
      • DDR
      • TCM to allow APU to load RPU firmware
    • Control and Status Registers:
      • RPU control registers to allow APU to configure RPU opertion mode from Linux
      • Others
    • Peripherals:
      • UART
      • Others
RPU0 non-secure:Non-secure only
  • non-secure masters:
    • RPU0
  • non-secure slaves
    • Memory
      • DDR_LOW
      • R50_TCM
    • Peripherals
      • devices accessed by RPU0
      • Please note that device sharing devices between subsystems are not supported. There is to be no overlap except for UART.
RPU1 non-secure:Non-secure only
  • non-secure masters:
    • RPU1
  • non-secure slaves
    • Memory
      • DDR_LOW
      • R51_TCM
    • Peripherals
      • devices accessed by RPU1
      • Please note that device sharing devices between subsystems are not supported. There is to be no overlap except for UART.


Example

This is an example of APU and RPU subsystems with RPU in split mode booting from SD1 with ATF residing in OCM. Linux non-secure has access to all the peripherals with TTC2, TTC3 and UART0 is shared with RPUs






APU and RPU Locksetp non-secure




The two RPUs are running in locksetp mode, so only one RPU subsystem configuration is needed. The subsystem required for this configuration are PMU, APU secure, APU non-secure, RPU0. The RPU are non-secure in order for APU to start/stop RPU from Linux. Linux's (APU non-secure) memory map includes that of the shared DDR memory and all TCMs in order to allow Linux APU to load the RPU firmware. In addition, RPU control registers are include to allow APU to configure RPU operations mode from Linux.

PMU subsystem, APU Secure and APU non-secure subsystem are the same as those of the APU and RPU split non-secure. The only difference is the RPU subsystem as shown in the table below


RPU non-
  • non-secure masters:
    • RPU0
  • non-secure slaves:
    • Memory
      • DDR_LOW
      • all the 4 TCM
    • Peripherals
      • devices accessed by RPUs
      • Please note that device sharing devices between subsystems are not supported. There is to be no overlap except for UART.


Example

This is an example of APU and RPU subsystems with RPU in lockstep mode booting from SD1 with ATF residing in OCM. Linux non-secure has access to all the peripherals with TTC2, TTC3 and UART0 is shared with RPUs


© Copyright 2019 - 2022 Xilinx Inc. Privacy Policy