Skip to content

Boot Flow

REVISION HISTORY

Revision No.
Description
Date
1.0
  • Initial release
  • 01/30/2026

    Keyword Description

    VMM: Virtual Machine Monitor, virtual machine monitor

    WFE: Wait For Event, waiting for external events

    cx: Core x

    TTCL: Time To Console Line, the time to reach the Linux command line


    1. Overview

    In order to adapt to market demand and meet a wide range of new application scenarios, the SGS mHera series chips follow cutting-edge hardware design and software technology, meeting user requirements for security, real-time performance, low power consumption, and high performance from the chip design level.

    • The mHera series chips feature a six-core ARM Cortex A55 Hex Core 64-bit ARMv8-A architecture, supporting TrustZone to ensure that critical resources (memory, interrupts, IPs, etc.) are protected from potential security risks.

    • On the software design level, Secure Boot support is provided, which can verify and load authenticated software during the system startup process, effectively preventing tampering with and plagiarism of flash software.

    The SDK development package provided by SGS contains multiple image defconfigs. Users can select an appropriate image configuration based on product form and solution requirements. Different image defconfigs will package different functional images, and the corresponding software boot flows are also different. This document explains several common boot flows.

    The boot flow scenarios described in this document assume that Secure Boot is enabled along with TF-A. If the current scenario does not enable TrustZone or signature & image verification, you can ignore the corresponding diagrams. The correctness of the flow charts and structural diagrams will not be affected.

    The boot flow scenarios described in this document assume that the memory division applied by SGS to the boot flow is reasonable and non-conflicting. For brevity, no additional instructions on the loading address and running address in the boot flow process are provided in this document.

    2. Image Defconfig Description

    The image defconfig of the SDK is located in the project/configs/verify/defconfigs/ directory. Taking nvr_mhera.emmc.glibc-12.4.0-arm64-ext4.ssm004a.s02a.2048.fccsp16_lpddr4x_defconfig as an example:


    Figure 1: defconfig Field Meaning Description
    defconfig Field Description
    product (Product) nvr, dispcam, usbcam, etc., distinguished by the defconfig name prefix to identify different product types
    boot medium (Boot Medium) nor, spinand, emmc
    rootfs type (Root Filesystem Type) ramfs, ramdisk, squashfs, ext4fs
  • ramfs: generally used for pure Linux boot
  • ramfs rootfs is generally used for fast boot
  • DDR size
  • 2048: 2G Byte
  • 1024x1024: 2G Byte
  • package (Chip Package Type) fccsp16
    software feature (Software Feature) optee, str
  • optee: TrustZone scenario, secure world runs optee os
  • str: suspend to DDR, CPU powered down, only DDR self-refresh retained, current system state saved in DDR
  • 3. Typical Scenario Boot Flow

    According to the ARMv8-A architecture definition, the system execution state is divided into two worlds: the secure world for running trusted software and the non-secure world for running untrusted software. At the same time, the processor modes are divided into four exception levels: EL0 (user mode), EL1 (OS kernel mode), EL2 (hypervisor mode), and EL3 (secure monitor mode).

    3.1. Pure Linux Scenario

    3.1.1. Pure Linux Boot Flow

    This scenario takes the NVR mHera spinand+squashfs configuration as an example (such as nvr_mhera.spinand.glibc-12.4.0-arm64-squashfs.ssm004a.s01a.1024x1024.fccsp16_ddr4_optee_defconfig): the non-secure world only runs Linux OS, with NS.EL2 (hypervisor layer) and secure world OS not enabled.

    TF-A (Trusted Firmware-A): Responsible for completing the initialization settings of the CPU monitor mode and GIC initialization during the system startup process. It has an independent partition. The overall boot chain is: BootROM → IPL → TF-A → IPL_CUST → U-Boot → Linux (kernel uImage.xz + squashfs root filesystem).


    Figure 2: Pure Linux Boot Flow

    3.2. DualOS Scenario

    • Not currently supported