NXP and the NXP logo are trademarks of NXP B.V. All other product or service names are the property

of their respective owners. © 2017 NXP B.V.

PUBLIC

AUTOMOTIVE FIELD APPLICATIONS ENGINEER

MANUEL RODRIGUEZ

INTRODUCTION TO THE

i.MX8 SYSTEM CONTROLLER

UNIT

AMF-AUT-T2773 | AUGUST 2017

PUBLIC 11

AGENDA• System Controller Unit and i.MX8 architecture

overview

• i.MX8 Boot Sequence

• System Controller services

• How-to

PUBLIC 2

System Controller Unit and i.MX8

architecture overview

PUBLIC 3

Introduction

• i.MX8 features a subsystem dedicated to

− Boot management

− Power management

External power management by communicating with

external PMIC

Internal power management of all the subsystems

− Clock and reset management

− IO configuration and muxing

− Resource partitioning / access control

PUBLIC 4

Introduction

• All those subsystems are abstracted thanks to the System Controller Firmware

(SCFW) running in the SCU

− Other software components communicate with System Controller (SC) via an Application

Programming Interface (API) library

− This library makes Remote Procedure Calls (RPC) via an underlying Inter-Processor

Communication (IPC) mechanism

Core SCUIPC RPC

PUBLIC 5

SCU – architecture overview

• System control sub-system is made of

− 1x Cortex-M4 processor running at 266MHz with 256KB of TCM

− A set of peripherals

1x TPM, 1x UART, 1x I2C, 8x GPIOs, 4x MUs

− This is the first processor to boot in the design

• Security sub-system is made of

− 1x Cortex-M0 processor running at 133MHz

In charge of loading security HDCP keys in HDMI-TX and HDMI-RX as well as DTCP

Handles security services for other processors

• Key derivation for secure storage

• Generation of private / public keys

• Encryption / decryption tasks

− A set of cryptographic related hardware accelerators

RSA, ECC, AES, DES/3DES, SHA-1, SHA-2, MD5, HMAC, RNG

PUBLIC 6

High-level block diagram i.MX8QM

• Application domain

• Real time domain

• Memory

• Connectivity peripherals

• System Control Unit

PUBLIC 7

Why do we need a System Control Unit?

• Each one of these peripherals requires access to a subset of resources on the chip (clocks, connectivity, memory).

• The System Control Unit simplifies software development by providing a high-level abstraction to key system functionality.

• The SCU takes care of managing these resources.

− Resource allocation/deallocation

Imagine two peripherals using the same clock, peripheral one is shut down and it asks for the clock to be disabled while peripheral 2 is still using it, the SCU takes care of handling this situation and keeps the clock alive.

− Resource partition

A system can be configured in such a way that the application subsystem (e.g. Linux) is oblivious of the existence of the real time domain (e.g. FreeRTOS). Just like having two different chips in the same package.

PUBLIC 8

i.MX8 Boot Sequence

PUBLIC 9

Introduction

• The System Controller takes care of executing the initial stages of the Boot ROM, it

reads the boot mode pins, configures DDR (through Device Configuration Data)

and loads its own image as well as the other processors images.

• The System Controller Firmware is a binary image that must be loaded from the

boot media (eMMC, SD card, NAND, etc…) to the System Controller Unit memory

(Tightly Coupled Memory of the Cortex M4).

PUBLIC 10

Boot sources

• The device can boot from a number of sources (for i.MX8QM the list is)

− Serial download (USB)

− eMMC0

− eMMC1

− SD1

− SD2

− NAND (various types)

− Flex SPI (various types)

− SATA

• This is selected via the Boot mode pins OR by fuses programmed inside the device.

PUBLIC 11

Initial loading region layout

• The SCU Boot ROM loads

an initial region from the

selected boot media.

• This region contains all the

information the device

needs to continue the boot

process.

PUBLIC 12

Image header structure

• The image header contains information on the remaining data structures required

to continue the boot sequence.

• Boot data structure – Information on the images for the different cores on the

device (FreeRTOS, SCFW, Linux, QNX…)

• Device Configuration Data (DCD) – Data used to configure the device on early

stages of the boot sequence (e.g. DDR configuration)

• System Configuration Data (SCD) – Data used by the SCU to perform an early

allocation of resources and partition the device.

PUBLIC 13

Image header structure

PUBLIC 14

Boot data structure

• The boot data structure contains all the required information to load the core

images from the boot media.

• Each image has its own data structure with information on:

− The location of the image

− Size of the image

− Destination address

− Entry point

− Who is this image for (e.g. M4_0, M4_1, SCU)

PUBLIC 15

Boot data structure

PUBLIC 16

i.MX8 High-level Boot sequence

PUBLIC 17

System Controller services

PUBLIC 18

System Controller Services

• The SCFW provides access to the following subsystems via ‘services’ or API calls:

− Power Management Service

− Resource Management Service

− Pad Configuration Service

− Timer Service

− Interrupt Service

− Miscellaneous Service

PUBLIC 19

System Controller Firmware architecture

PM

SVC

(inc. power, reset,

clock, wake)

RM

SVC

PAD

SVC

TIMER

SVC

(inc. wdog, rtc,

syscntr)

IRQ

SVC

MISC

SVC

(inc. control and

sensor)

PUBLIC 20

System Controller Firmware and application

• Operating Systems can

configure the device through

an Application Programming

Interface (API).

• Development is simplified

thanks to the API that

provides control of key

system functionality.

• Each OS features a library

that allows it to interact with

the SCFW.

SCFW

Linux

SCFW

Library

FreeRTOS

SCFW

Library

PUBLIC 21

Power management service

PUBLIC 22

Introduction

• The SCFW is responsible for centralized management of power controls both

within the device and with external power management devices.

• The power management service is in charge of:

− Power control

− Clock control

− Reset control

− Wake-up event monitoring

PUBLIC 23

Power control introduction

• The device is subdivided in subsystems.

• Power control in the i.MX8 is managed in a distributed manner.

• Each subsystem features a module called Distributed System Controller (DSC)

which is in charge of power management and clock control of its subsystem.

• SCU interfaces with the DSC

on each of the subsystems to

control the power state of the

domain.

• SCU has a dedicated interface

to the Power Management

Integrated Circuit (PMIC).

A53

Subsystem

DSC

A72

Subsystem

DSC

Audio

Subsystem

DSC

GPU

Subsystem

DSC

System Control

UnitPMIC

PUBLIC 24

Interface to PMIC

Signal name Comments

PMIC_I2C_SDA / PMIC_I2C_SCL I2C interface to access PMIC control registers

POR_B This signal is an input only pin and is active low. When asserted low, it will reset the processor. The

processor will remain in reset until the POR_B is de-asserted high.

ON_OFF_BUTTON This signal is the button input signal to request main SoC power state changes (i.e. ON or OFF). When

device is ON it has different meaning depending on key press duration:

- If > BTN_PRESS_TIME: PMIC turns OFF power supply unconditionally

- If < BTN_PRESS_TIME: SW power sequence, likely DEEP SLEEP, is triggered on i.MX8QM.

SCU_PMIC_STANDBY This output signal is active high. When asserted high, the processor is requesting the PMIC to configure

Core power rails into pre-defined STANDBY mode. When de-asserted low, the PMIC should exit

STANDBY mode.

PMIC_ON_REQ This output signal is active high. When de-asserted low, the processor is requesting the PMIC to turn the

system off or go into deep sleep mode. When asserted high, the PMIC should bring the system out of off /

deep sleep mode.

PMIC_INT_B This signal is an input only pin and is active low. When asserted low the PMIC is signaling i.MX8QM SoC

of an event. This must be serviced by a I2C access. The SOC is then responsible for clearing the interrupt.

PUBLIC 25

Power partitioning overview

• i.MX8QM has

− 6x core voltage domains connected to specific power supplies of the PMIC

VDD_A53, VDD_A72, VDD_GPU0 & 1, VDD_MEMC and VDD_MAIN

Each voltage domain may have several power domains

− A large number of IO voltage domains that can be grouped at PMIC level

• SCU interacts

− With PMIC to manage voltage domains (power supplies)

Through an I2C + few dedicated pins

− With internal logic to manage voltage power domains

Through MSI link

PUBLIC 26

Typical power structure of a subsystem

• It belongs to a voltage domain

• It has one or more power domains

• It has a DSC island that always belongs to

− VDD_MAIN voltage domain

− AON (Always-ON) power domain

• In this example

− Cortex-A53 subsystem

Belongs to VDD_A53 voltage domain

Has 5 power domains

• 1x per core + 1x for L2 + infrastructure 5x power domains total

A power domain has internal power switches that can be used to turn it on or off

Has a DSC island

VDD_A53 voltage domain

Cortex-A53 subsystem

DSC

(MAIN-AON)

A53

Core-0

A53

Core-1

A53Core-2

A53Core-3

L2 + infrastructure

SCU

PMIC

PUBLIC 27

Clock control Introduction

• The clock control features supported are:

− Initialization of the clock controller

− Frequency scaling requests handling

− PLL power up/down management

− PLL rate configuration

− Clock switching e.g. switch between PLL and OSC

− Status queries for clock controllers.

• Clocks are also managed in a distributed fashion, with each subsystem featuring

their own clock infrastructure (PLLs and dividers).

• All the subsystems are fed by a 24MHz clock.

PUBLIC 28

Typical clock distribution in a subsystem

• Clocks are managed

− Within the DSC for frequency setting

− Outside the DSC for clock gating

• A subsystem has

− Up to 3x PLL

− Several clock slices which are in charge of

Selecting clock among available source clocks

Dividing this clock to match source clock requirement from IP block

• Further clock divider may be available within IP block

A set of clock gating mechanisms that can be controlled by another CPU than SCU

Out of DSC – can be managed by any processor in the platform

DSC – managed by the SCU only

PLL

Clock slice

Clock slice

Clock slice

Clock gating

Clock gating

Clock gating

Clock gating

.

.

.

.

.

.

Clock gating

Clock gating

.

.

.PLL

.

.

.

.

.

.

.

.

.24MHz

PUBLIC 29

Reset control

• The SCFW is responsible for reset control. The SCU interacts with the DSC in

each subsystem to configure the required behavior.

• The available features are:

− Power up/down of subsystems

− Manage resets triggered by watchdog timeout events.

− Request subsystem resets from software

− Obtaining previous reset source

− Starting/stopping CPUs

PUBLIC 30

Wake-up event monitoring

• The SC is located in an always-on power domain and is responsible for wakeup event monitoring.

• The SC NVIC handles wakeup events for power modes where the SC core platform remains clocked.

• The SC WIC handles wakeup events for power modes where the SC core platform is clock gated.

• Wakeup events arrive at the SC in one of the following ways:

− Dedicated wakeup inputs (e.g. pad with edge detection)

− IRQs from subsystems connected to the respective DSC module

• The SC firmware has handlers for wake events.

• For wake events that require service from other subsystems, the SC will apply clocks and power to the applicable subsystems.

• The wake event monitoring supports the following:

− Registration of clock/power/reset sequence to be followed for wake events

− Deregistration of clock/power/reset sequence for wake events

− Collaborates with SC power management firmware to ensure registered wake events can be received

PUBLIC 31

Resource management service

PUBLIC 32

Introduction

• SCFW is responsible for managing ownership and access permissions to system

resources.

• The resource management functions of the SC are used to divide up the System

on a Chip (SoC) resources and control master transaction attributes and peripheral

access permissions.

• The features supported by the SCFW are:

− Management of system resources such as SoC peripherals, memory regions and pads.

− Allows resources to be partitioned into different ownership groupings that are associated

with different execution environments.

− Allows owners to configure access permissions to resources.

− Provide hardware enforce isolation.

PUBLIC 33

Introduction

• The SCFW relies on the eXtended Resource Domain Controller (xRDC) to enforce hardware resource partitioning. The xRDC provides:

− Ability to build partitions of the system at boot time or at run time

− Support of secure / non-secure qualifier within a partition

− Share resources between partitions

• Principles

− Each transactions issued by a master carry on extra information

Domain ID

• Identify to which domain the transaction belongs to (up to 16 domains)

Core ID

• Identify which Core issued the access. It’s used in the context of exclusive accesses. Information is hardcoded and cannot bechanged.

Stream ID

• It’s used by sMMU to select table bases for MMU lookup. SID 0 means sMMU bypass.

Secure / non-secure

• Indicates whether transaction is a secure transaction or not

− Information is checked at the slave end to make sure transaction is allowed

PUBLIC 34

xRDC architecture

• xRDC infrastructure is made of following blocks

− MGR (Manager)

Provides the programming interface for the entire xRDC.

It dispatches incoming accesses to the different xRDC blocks implemented in a subsystem

− MDAC (Master Domain Assignment Controller)

It adds DID, SID, NS information to out-going transactions of a subsystem

Information depends on which IP issued the transaction within the subsystem

− PAC (Peripheral Access Controller)

Control access to peripherals of a subsystem with a 64KB granularity

Each peripheral can have different permissions

− MSC (Memory Slot Controller)

Used in subsystem when it’s protected as a whole (GPU for instance)

− MRC (Memory Region Controller)

It controls accesses to memory regions defined by a start address and an end address

It can handle up to 32 regions

PUBLIC 35

xRDC architecture

PUBLIC 36

xRDC interaction on bus transactions

PUBLIC 37

Example of partitioning

PUBLIC 38

Pad configuration service

PUBLIC 39

Introduction

• All the functionality needed to configure a pad is supported by the SCFW:

− Common features:

Mux selection

Mode of operation

Low-power isolation mode

− Technology specific features:

Drive strength

Pull select

Compensation configuration for pad groups with dual voltage capability

PUBLIC 40

Introduction

• There are 3 main types of CMOS I/Os

− 1.8V only I/Os

− 3.3V only I/Os

− 1.8V / 3.3V I/Os (Dual Voltage) biggest part of QM IOs

• USB High Speed Inter-Chip (HSIC) and Ethernet (ENET) interfaces have specific

integration scheme with dedicated features

− HSIC I/Os are specific to sustain 480Mbps data rate

− ENET I/Os have the capability to support 2.5V operations

PUBLIC 41

Common features within I/Os

• Muxing capability of up to 4 signals

• Mode of operation

− It defines how the I/O will behave, e.g. open drain

• Low power configuration

− It configures how isolation latch is controlled

• Wake-up capability

− Defines whether or not the I/O can be used to wake-up the system

− Defines on which event system should be woken-up (falling edge, rising edge, …)

PUBLIC 42

Common features - Mode of operation

• There are 4 modes of operation

− Normal mode

While output is enabled, input is disabled and vice-versa

− Open drain

IO switches between high-Z state and drive low

− Open drain and input

Same as open drain with input enabled unconditionally

− Output and input

Same as normal mode with input enabled unconditionally

PUBLIC 43

Common features - Low power configuration

• This is a mechanism that is used to ensure that no pads are modified during low-power state and to isolate the input/output signals.

• It is a latch that retains the value of the pad while entering low-power mode.

• There are 4 different configurations

− ISO_OFF latch is transparent

Latch is off

− ISO_EARLY latch is driven by EARLY_ISO signal

The value in the pad is latched when EARLY_ISO signal is asserted

− ISO_LATE latch is driven by LATE_ISO

The value in the pad is latched when LATE_ISO signal is asserted

− ISO_ON latch latches the data

The value in the pad is latched when this configuration is selected

PUBLIC 44

Common features - Wake-up capabilities

• Each IO has following wake-up capabilities

− OFF

IO cannot wake-up the system

− Low detect

Generate wake-up event when the pad remains in low level for a specific time amount

− High detect

Generate wake-up event when the pad remains in high level for a specific time amount

− Rising edge detect

Generate wake-up event on rising edge detection

− Falling edge detect

Generate wake-up event on falling edge detection

• Wake-up event detection is completely asynchronous

− It is based on delay elements

− The structure allows filtering out glitches

PUBLIC 45

Technology specific features

• Some of the available features for each pad depend on two factors:

− Chip manufacturing process (FDSOI or LPP)

− I/O type (1.8V, 3.3V or Dual Voltage)

• The i.MX8QM is manufactured using FDSOI technology and it features all of the

three available I/O types.

PUBLIC 46

Technology specific features – Drive strength (DSE)

• Drive strength options vary within I/O types and chip manufacturing options.

• The available options for a FDSOI chip are:

1.8V Drive strength options 3.3V Drive strength options Dual Voltage drive strength

options

Drive strength of 1mA Drive strength of 2mA Low drive strength

Drive strength of 2mA Drive strength of 4mA High drive strength

Drive strength of 4mA Drive strength of 8mA

Drive strength of 6mA Drive strength of 12mA

Drive strength of 8mA

Drive strength of 10mA

Drive strength of 12mA

High-speed drive strength

PUBLIC 47

Technology specific features – Pull Select (PS)

• The pull select available options are the same for all I/O types, but they depend on

the chip manufacturing process.

• The available options for a FDSOI process are:

Pull select options for FDSOI

Bus-keeper (only available for 1.8V)

Pull-up

Pull-down

No Pull (Disabled)

PUBLIC 48

Technology specific features – Compensation (Comp)

• The compensation feature is only available on Dual Voltage I/Os.

• Dual Voltage I/Os have a different implementation, they require:

− Voltage reference generator – provides voltage references to supply detector and

compensation cell

− Supply detector – detects whether the I/O is being supplied with 1.8V or 3.3V

− Compensation cell – adjusts drive strength of dual voltage I/Os depending on Process

Voltage and Temperature (PVT) conditions.

• The SCFW features functions to configure the compensation functionality on dual

voltage I/Os

PUBLIC 49

Timer service

PUBLIC 50

Introduction

• The System Controller Firmware supports the following timer functions via the timer

service.

− Watchdog

− RTC

PUBLIC 51

Watchdog

• As it is not practical to have physical watchdog timers for all execution environments, the SC subsystem uses a physical timer (Low Power Timer) to expose a "virtual" watchdog timer for all resource partitions.

• The SC manages a set of software watchdog timeout events and refresh requests.

• The watchdog features supported by SC firmware include:

− Update watchdog timeout

− Start/stop watchdog

− Refresh watchdog

− Return watchdog status such as maximum watchdog timeout that can be set, watchdog timeout interval, and watchdog timeout interval remaining

Note: the SC subsystem includes a physical watchdog timer that is used to insure the correct operation of the SC firmware. It isn't used to implement the timer service's watchdog function.

PUBLIC 52

RTC

• The RTC API supports

• Setting the time

• Getting the time

• Setting alarms.

Note: Only the SW partition that owns the SC_R_SYSTEM resource is allowed to

set the time. Time is maintained by the Secure Non-Volatile Storage (SNVS)

hardware. All partitions have access to the same time.

PUBLIC 53

Interrupt service

PUBLIC 54

Interrupt service

• The interrupt service provides a method for the SCFW to push events back to its

users (e.g. Linux, FreeRTOS).

• Some of the events are:

− Temperature alarms

− RTC alarms

− Wakeup events

• The API provides the following functionality:

− Enable/disable interrupts

− Read/clear status of pending interrupts

PUBLIC 55

Miscellaneous service

PUBLIC 56

Miscellaneous service

• The SCFW supports various miscellaneous functions via the miscellaneous service.

• Control

− As part of the power up/down for a subsystem, configuration of the General Purpose Register (GPR) miscellaneous controls in the respective DSC module

− Software request to set (write) miscellaneous controls

− Software request to get (read) miscellaneous controls

• Security

− The miscellaneous security functions are associated with the Security Controller (SECO). Only the SCU can communicate with the SECO ROM functions and so it has to act as a mediator. Most SECO functions are implicit in other SCU API functions, but some require explicit APIs. One function is to load images (e.g. SECO FW, IVT/CSF data for HDMI FW authentication, etc.) into SECO memory. Another is requesting authentication of SECO and HDMI FW images.

• DMA

− The various DMA engines have management pages with settings that affect all DMA uses. These have to be abstracted by the SCFW to isolate uses. This includes access to DMA channel grouping and priority functions.

PUBLIC 57

How To

PUBLIC 58

How to open/close an Inter Processor Communication Channel

• The very first thing that needs to be done to interact with the SCFW is to open an

Inter Processor Communication Channel, this channel will allow your application to

make Remote Procedure Calls to the SCFW.

• The following code showcases how to open/close an IPC channel

PUBLIC 59

How to configure a clock

• The first step before configuring a clock to a resource is to turn on the resource.

• Then we configure the Clock rate for the resource

• And the last step is to enable the clock.

PUBLIC 60

How to configure a pad

• Configure the mux alternative, the mode of operation and the low-power isolation.

• Then we configure the technology specific features, Drive Strength and Pull Select

NXP and the NXP logo are trademarks of NXP B.V. All other product or service names are the property of their respective owners. © 2017 NXP B.V.