• Zynq UltraScale+ MPSoC Design Example - Deep Sleep with Periodic Wake-up


  1. ZCU102 development board (This design example has been tested on silicon 3.0 revD board).
  2. SDK (2017.1 release)
  3. Petalinux (2017.1 release)

ZU+ Example - Deep Sleep with Periodic Wake-up

The RPU can be configured to service regular real-time events while the APU remains suspended most of the time. A typical example would be an automotive engine management unit, where the RPU would perform typical engine management functions at regular interval of 2 seconds. The APU would only wake up for passenger entertainment functions, software upgrade and to service other non-realtime events.

Basic Flow
  1. Linux/baremetal application boots on the APU.
  2. Real-time application runs on the RPU.
  3. RPU requests the APU to suspend.
  4. APU suspends itself.
  5. RPU sets the RTC to expire in 2 second, in auto-rearm mode.
  6. RPU sets the RTC as the wake-up source.
  7. RPU suspends itself.
  8. RPU wakes up and perform real-time service. In this example, the RPU toggles the DS50 LED.
  9. RPU suspends itself, and the same repeats.

Steps to build demo example standalone applications
  • APU Application (APU can run either standalone application or Linux.):
    1. APU running standalone application.
  • RPU Application:
    1. Start with an empty RPU application (like the Hello World example here).
    2. Configure the RPU to run from TCM (see above.)
    3. (Default HDF has split mode, So RPU will run in split mode. If application doesn't fit into default memory region, user may need to divide the sections for ATCM and BTCM memory regions in lscript.ld file. For more information please see Table 4-5: TCM Address Map in TRM. When running in split mode, each R5 processor has 64KB ATCM and 64KB BTCM. So, user has to divide sections across ATCM and BTCM. As per below snapshot vectors and text sections are in ATCM and other
      sections are in BTCM)
    4. Replace the main.c with this file:
    5. Build application elf.

Configuration Object

Configuration Object file Generated by PetaLinux tool chain and Vivado is attached below.

Subsystems -
1) Linux Subsystem
Master -
  1. APU
Slaves -
  1. DDR
  2. L2 Cache,
  3. OCM Bank 0, 1, 2 and 3,
  4. I2C0,
  5. I2C1,
  6. SD1,
  7. QSPI,
  8. PL

2) R5-0 Subsystem
Master -
  1. RPU0
Slaves -
  1. TCM Bank 0 - A
  2. TCM Bank 0 - B

3) R5-1 Subsystem
Master -
  1. RPU1
Slaves -
  1. TCM Bank 1 - A
  2. TCM Bank 1 - B

Steps to run demo example (APU running Linux) using SD boot mode
  1. Create RPU application rpu.elf from SDK as described in above section.
  2. Create a new folder and copy pmufw.elf, zynqmp_fsbl.elf, bl31.elf and u-boot.elf from Petalinux 2017.1 pre-built images. Also copy rpu.elf into same folder.
  3. Create demo-example.bif file in same folder as shown below.
         [fsbl_config] a53_x64
         [pmufw_image] pmufw.elf
         [bootloader,destination_cpu=a53-0] zynqmp_fsbl.elf
         [bootloader,destination_cpu=r5-0] rpu.elf
         [destination_cpu=a53-0, exception_level=el-3,trustzone] bl31.elf
         [destination_cpu=a53-0, exception_level=el-2] u-boot.elf
  4. Create BOOT.bin file using following command.
    bootgen -arch zynqmp -image demo-example.bif -w -o BOOT.bin
  5. Create a boot and root partition in SD card and copy BOOT.bin file to boot partition.
  6. Copy image.ub and system.dtb from Petalinux 2017.1 pre-built images to boot partition of the SD card.
  7. Boot the ZCU102 board in SD boot mode.
  8. After booting linux write following lines on linux console.
    (In petalinux prebuilt image by default RTC wakeup source is enabled. So you need to disable RTC wakeup source otherwise Linux can wakeup from RTC)(In petalinux prebuilt image by default split mode config object is present, So if RPU is running in split mode, RPU1 needs to be powered down, else PMU would consider it PM disabled PU and would not released all unused nodes causing FPD on during APU suspend)
    echo disabled > /sys/devices/platform/amba/ffa60000.rtc/power/wakeup
    echo request_wakeup 8 1 0 1 > /sys/kernel/debug/zynqmp_pm/power
    echo force_powerdown 8 >  /sys/kernel/debug/zynqmp_pm/power
    echo release_node 69 > /sys/kernel/debug/zynqmp_pm/power
    echo MMIO_WRITE 0xFFD80064 1 1 > /sys/kernel/debug/zynqmp_pm/power

The DS50 LED will on for 2 seconds when RPU wakes up, after that RPU goes down to sleep for 2 seconds. RPU wakes up again and same cycle repeats every time. One can change LED on time (or do another task instead of LED on/off) and RPU sleep time according to requirement.

Debug or run applications using system debugger
  1. Open Xilinx SDK (It is assumed that APU standalone application, RPU standalone application and PMU firmware are already built using SDK).

  2. In Project Explorer, right-click the RPU-app project and select Debug As > Debug Configurations... popup window appears. Double click on Xilinx C/C++ application (system Debugger). Click on application tab and select checkbox as per below snapshot for each selected application.

  3. Click on Target Setup tab and select checkbox as per below snapshot and click on Apply.
  4. Now click on debug. A new debug popup window with debug prospective configuration appears. Cortex-A53 will be stopped at main() due to breakpoint.

  5. Select Cortex-A53 processor in debug window and click Resume to continue application.
  6. Open serial console COM2 and it will display as per below snapshot.

  7. Similarly Cortex-R5 will be stopped at main() due to breakpoint.

  8. Select Cortex-R5 processor in debug window and select Resume to continue running the program.
  9. In serial console COM2 it will display as per below snapshot.

  10. Select Skip All Breakpoints from tool bar. Now click on Resume.

  11. Application will now run without stopping at anywhere. RPU state will change from Running to Halted and vice versa at 2 seconds. Similarly DS50 LED will remain on for 2 seconds after that RPU goes to sleep for 2 seconds.


Related Links

Default Configuration
By default, there are 3 sub-systems, and each has one PM Master: APU, R5-0 and R5-1. All three sub-systems contain all the PM Slaves (meaning that the sub-systems completely overlap each other.) This is the default configuration generated by PCW when the “Enable Isolation” box is unchecked. Note that the default PetaLinux kernel is “PM-capable”, but R5-0 and R5-1 must be also running “PM-capable” applications, or be powered down. Otherwise, the PMU will not power down any PM Slaves.
Note that it *is* possible to create a configuration that would not allow the processors to boot and run. Novice users should start with the APU-only configuration shown above and customize it as they go.
RPU Lock-step vs. Split Mode
The toolchain infers the RPU run modes from the PCW Isolation Configuration as follows:
• No RPU present in any subsystem: Config Object contains no RPU.
• Only R5-0 present in subsystem(s): Config Object contains R5-0 running in lock-step mode.
• Both R5-0 and R5-1 in subsystems: Config Object contains R5-0 and R5-1 running in split mode.
• Only R5-1 present in subsystem(s): Config Object contains R5-1 running in split mode.
The default Configuration Object contains two RPU PM Masters: R5-0 and R5-1, and the PMU assumes that the R5-0 and R5-1 are running in split mode.
However, the boot image actually determines whether the RPU runs in lock-step or split mode at boot time.
The RPU run mode from the boot image must match the number of RPU PM Masters in the Configuration Object.
Otherwise, the power management framework will not work properly.