Suspend to RAM / SC7

SC7 is an SoC power state where NVIDIA Orin® is in low-power mode and DRAM is in self-refresh mode. SC7 is also known as Suspend to RAM mode. In SC7, all domains in Tegra SOC will be powered down except for the AON domain. AON domain will be powered on but in sleep mode.

Note:

  • This section only talks about Suspend to Ram / SC7, which is one of many Tegra SOC power states. It does not talk about the power states at the global platform level or at the device level. You are responsible for defining power states at the platform level.

  • The term Suspend to RAM and SC7 are used interchangeably in this documentation and mean the same thing.

Legal SoC Power States

For information on the defined power states, refer to the SMCU integration guide.

Why Suspend to RAM / SC7

A significant part of the system boot time is taken up in the initialization of the application, including loading of libraries and data (DNN and map files). Achieving the boot time target in cold-boot for all use-cases is difficult.

A way around this is to keep the DRAM pre-loaded and initialized before the system needs to be a fully functional state. Rather than keep the system powered off when not in use, it retains the system in SC7 state (which minimizes the power consumption while keeping the DRAM loaded and most of the software initialized).

With SC7, data is loaded and applications are initialized (example: DNN unpacking) before suspend that does not require external interaction. When it resumes, the application programs the external sensor and the rest of the application init. Since most of the initialization, which is I/O and CPU intensive, happened before suspend, the visible time is only the resume time (and much less compared to cold boot) for the end user.

How It Works

The Tegra sequence:

  • When the vehicle engine is turned OFF, instead of doing a shutdown, Tegra is put in the suspend state. Optionally, before Tegra is put into suspend, KeyOFFIST can be executed.

  • Minimal power is consumed in SC7 state and requires a timeout after which you can shut down the system to save power.

  • The diagram below shows SC7 transitions and actions that need to be performed by DRIVE OS and customer applications to achieve SC7 functionality.

The App Pre-Init stage can be used for initialization and loading of libraries like CUDA and cuDNN before going into SC7 state. This can bring substantial optimizations to the Resume time, as loading of these libraries running into Gigabytes of memory can consume a lot of time. Binarized DNN can also be loaded during preInit state from memory.

The App Post-Init stage is used for initialization and allocation of resources which were not done in the Pre-Init stage. This includes powering on IO peripherals like Camera sensors, serializers-deserializers etc. The Runtime phase is meant for active processing and streaming of data captured through the various sensors. In short pipeline creation is done in this stage.

The App Post-DeInit stage is meant for freeing up resources allocated during the App Post init stage. i.e Pipeline teardown needs to be done at this stage. The loaded cuDNN and CUDA libraries shouldn’t be released at this stage and these along with other resources should be freed during the App DeInit stage.

Since the Orin SoC is going to be in SC7 mode until the next vehicle key-on optionally HW latent checks can be executed once in MPFDTI (every 8 hrs i.e., N=8 hours). More details are provided in the SMCU integration guide.

If the system continues to stay in SC7 for a period of M then the tegra SOC can be powered off from SMCU.The value of M needs to be decided by the customer.

SC7 Suspend Sequence

The diagram below shows the sequence to enter SC7, starting from the KeyOFF IST sequence at high level. For a detailed sequence diagram please refer to SMCU integration guide.

Where:

  • ENV - Represents the environment that provides the event that triggers the startup or shutdown

  • DRIVEOS - Rest of the DRIVEOS software running on the Orin chip

  • DRIVEOS_FSI - FSI functionality delivered by DRIVE OS

  • DRIVEOS_MCU - MCU functionality delivered by DRIVE OS

  • GuestOSApplication - User application running on the OS in a Guest Virtual Machine

  • USER_FSI - FSI firmware and user application integrated with DRIVEOS_FSI

  • USER_MCU - MCU Firmware and user application integrated with DRIVEOS_MCU

SC7 Resume Sequence

The diagram below shows the sequence to resume from SC7 state.

Interfaces Exposed by DRIVEOS_MCU

Refer to the MCU Software Modules Integration Guide chapter in the NVIDIA DRIVE OS 6.0 PDK Developer Guide for details on Interfaces of NvMCU_SwModules.

Interface Description
SC7Exit Interface to wake up Tegra from suspend state.

Functionality Implemented by User Software on MCU

Functionality Description
Transition2MissionMode Application on Guest OS notifies the user software on MCU that the system has transitioned to mission mode.

Functionality Implemented by User Software on FSI

Table 1.
Functionality Description
Transition2MissionMode Application on Guest OS notifies the user software on FSI that the system has transitioned to mission mode.

Limitations

  • Camera pipeline context is not saved between suspend and resume so the camera pipeline needs to be recreated after resume and purged/teardown before suspending.

  • Any jobs submitted to any engines must be completed before SC7 is started.

Steps to Enter and Exit SC7

Prerequisite

  • Flash and boot P3710 as per SDK documentation.

Start SC7 Suspend

In Tegra shell, execute:
common_if_testapp -enter_sc7
echo 1 > /sys/class/tegra_hv_pm_ctl/tegra_hv_pm_ctl/device/trigger_sys_suspend

Exit from SC7

In AURIX shell, execute:
exitsc7

Component-Specific Limitations

  • NvStreams:

    Before SC7 entry, ensure the following requirements for the applications using NvStreams framework to stream data between the producer and consumers:

    • There are no jobs that were submitted by the NvStreams applications pending in the CPU or engine pipelines.

    • The application is not performing any active NvSciSync fence waits.

    To meet the requirements, perform the following tasks before proceeding to SC7 entry, if the NvStreams pipeline is being initialized:

    • Wait for the buffer and synchronization primitives to be allocated and the NvSciBuf and NvSciSync objects are registered to the UMDs.

    • For the NvSciStream application, wait for pipeline initialization to complete and all the packets are available in the pool block.

    When the application is in the streaming phase, ensure that there are no jobs pending in the CPU or UMD engine pipelines by following the SC7 entry guidelines of the respective UMDs and that there are no packets in flight.

  • CUDA:

    Before SC7 entry, ensure the following requirements for the applications:

    • Any outstanding GPU tasks (for example, kernel, memcopies, and event waits) are completed using appropriate synchronization APIs, such as cudaEventSynchronize, cudaStreamSynchronize, and cudaDeviceSynchronize.

    • Outstanding GPU tasks can also be cross-engine dependencies (for example, between DLA and GPU) that are built using NvSciSync interop. Waiting on unsignaled NvSciSync can lead to infinite waits, so applications should ensure that the signaler of such fences has unblocked all waiters on the GPU.

    • Any ongoing CUDA APIs that are synchronous with respect to the host (for example, cudaMalloc and cudaStreamCreate) are complete.

    • Note that timestamps recorded by cudaEvent after returning from SC7 state will account for the duration in which the GPU was in a suspended state, so the elapsed time returned by cudaEventElapsedTime should be interpreted accordingly.

  • DLA:

    Before the SC7 entry, if the application fails to ensure that there are no outstanding tasks (submitted but not completed), the DLA detects the scenario and fails the SC7 entry.

  • PVA:

    Before SC7 entry,

    • The applications must ensure that there are no pending tasks/commands on the PVA engine by waiting for all the previously submitted commands to finish before entering into SC7 by calling cupva::Fence::wait().

    • The applications must not submit any new commands to PVA while the DOS is transitioning to SC7 suspend state.

  • Camera:

    The SIPL camera application should only request NVIDIA DRIVE® OS to transition into the SC7 power state outside of the SIPL hardware initialization and SIPL runtime states.

  • NvDisplay:

    For information on the recommendations, see OpenWFD Usage Guidelines in NvDisplay.

  • Graphics:

    Before SC7 entry, ensure that any tasks submitted to GPU should not be in pending state. To do so, applications must call vkQueueWaitIdle() for each VkQueue created.

  • NvSciIpc:

    Before SC7 entry, ensure that there are no outstanding tasks for applications using NvSciIpc. If a peer endpoint process goes down and up because it is not running during SC7 (that is, Trust Agent), applications must call NvSciIpcResetEndpointSafe() and then establish connection using the NvSciIpcGetEventSafe() API after SC7 exit.

  • NvGPU:

    Before SC7 entry, ensure that there are no outstanding tasks for applications using NVGPU. There should not be any new request to NVGPU after the suspend callback is issued other than resume callback. Requests can be made after the driver resumes back and sets the process state to resume done.