3.2.2.11.7. S/W Architecture of System Suspend¶
3.2.2.11.7.1. Overview¶
In AM62, Deep Sleep is the state of the SoC in which it consumes very low power overall yet it is not completely shut off. During Deep Sleep, Certain IPs (depending on the power domain to which then belong) will lose context on suspend. S/W should save and restore the context as required across state transitions. DDR is in self- refresh to allow context saving.
This document explains the overall high level Software Flow of deep sleep in AM62x.
3.2.2.11.7.2. System diagram and components¶
Above diagram has software sequence for how deep sleep (ie. Suspend to RAM) works on SK-AM62 ( Read more on the Starter Kit here ).
3.2.2.11.7.2.1. Deep Sleep Entry:¶
The user first instructs the System to Suspend. This triggers a suspend sequence from linux side (which runs on the A53 cluster of the SoC).
As part of the TI_SCI driver’s suspend hook, I/O isolation is invoked which isolates all the pads from their respective pinmuxed controllers. Refer to Wakeup sources Documentation to understand more on this.
Linux then suspends all the drivers in the order that they are probed. After ensuring that there were no faults in suspending the drivers, linux then issues core system suspend which ultimately is a PSCI system suspend call. Read more about PSCI here
At this point only ATF is running on A53 cores and it does the job of sending a TISCI Message to the TIFS Core telling it to enter deep sleep and then it puts A53 into standby.
The TIFS Core then encrypts and writes the contents of it’s own SRAM to DDR.
Further it stops tick timer, disables interrupts that are not needed, and suspends local drivers. After the above steps it sends TISCI To DM for Suspend Finish and enters WFI.
The DM (Device Manager) is the final entity in this entire deep sleep sequence. It does the following:
Saves own context to DDR
Disables Security IP LPSCs, such as LPSC_SAUL.
Disables non-critical “IP-less” LPSCs, such as LPSC_main_test.
Saves MAIN PADCONF MMRs
Saves GTC counter and Disable it.
Finally, Suspends OS.
The OS in this case is the Free RTOS based Device Manager firmware itself. After this step it starts performing final Steps toward completion of Suspend to RAM.
These steps include the following:
Place DDR into Self Refresh
Place USB into reset isolation
Disable all LPSCs in MAIN except Debug, Always ON
Disable all HSDIVs in MAIN_PLL.
Bypass all MAIN PLLs.
Configure selected wake sources, Enable MAIN IO Isolation.
Disable MCU Core LPSCs, PDs
Bypass MCU PLL
Finally, DM R5 Enters WFI with all the other power domains turned OFF except WKUP Always ON. DM in WFI will basically wait for the configured wakeup source to trigger an interrupt that will act as the wakeup signal.
3.2.2.11.7.2.2. Deep Sleep Exit:¶
External async wakeup from wake source triggers the DM to resume.
The DM brings MAIN Domain out of reset.
Secure (TIFS) ROM begins to boot.
A small piece of code called the FS Stub is required to restore the remaining context and resume the TIFS firmware.
The TIFS Stub is loaded into the ATCM (Tightly Coupled Memory A of the DM R5) during device boot. The R5 SPL loads the TIFS Stub (which is a part of tispl.bin) onto DDR at address 0x9dc00000. The DM Firmware pulls in this TIFS Stub from DDR RAM to it’s ATCM where it then resides as long as the device is not shutdown.
Then, the rest of the resume sequence is a mirror image of the deep sleep entry sequence.
As the A53 core resumes, and subsequently the linux TI_SCI driver’s resume hook is called, I/O isolation is disabled. This allows the pads to be re-connected to their respective controllers and allow the device to function normally post resume.