Boot Flow¶
REVISION HISTORY¶
| Revision No. | Description |
Date |
|---|---|---|
| 1.0 | 01/31/2024 | |
| 1.1 | 06/07/2024 |
Keyword Description¶
CM4: ARM Cortex-M4 low-power core additionally equipped in the chip
VMM: Virtual Machine Monitor
WFE: Wait For Event
cx: Core x
TTFF：Time to first frame
TTCL：Time to console line
1. General Description¶
In order to adapt to market demand and meet a wide range of new application scenarios, the SigmaStar iford series chips employ cutting-edge hardware design and software technology to meet user requirements for security, real-time, low power consumption, and high performance from the chip design level.
-
This series of chips is equipped with a dual-core ARM Cortex-A32 core and supports TrustZone to ensure that the key resources (memory, interrupts, IPs, etc.) are protected from potential security risks.
-
This series of chips has an additional ARM Cortex-M4 low-power core. Based on actual application scenarios, events are processed and filtered by CM4 to reduce the power-on time of the entire system and meet the requirements of products that require power saving and long battery life.
-
The software design provides secure boot support, which can verify and load certified software during the system startup process, thereby effectively preventing tampering with flash software and plagiarism of flash software.
-
The software design incorporates VMM (virtual machine monitor) to manage CPU and hardware resources, hiding the underlying physical hardware so that multiple operating systems (Linux + FreeRTOS) can use and share hardware resources transparently.
-
Supports sensor earlyinit. After the device is powered on, this function can initialize the sensor and collect the images at a fast pace. It can quickly record images without waiting for the operating system to start, thereby meeting the requirements of products that require quick image capture.
The SDK development package provided by SigmaStar 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. In this document, we will address several common boot flows in detail.
The boot flow scenario described in this document enables security boot by default and includes OP-TEE, PM_RTOS, and earlyinit firmware (if supported). If the the scenario you are using currently does not enable TrustZone, CM4, earlyinit, signature & image verification functions, you can ignore the corresponding icons directly. The correctness of the flow chart and structural block diagram will not be affected.
If you need to know the principle and process of xz and ssz decompression during the boot flow, please refer to "XZDEC User Guide".
The descriptions given below assume that the memory division applied by SigmaStar to the boot flow is reasonable and non-conflicting. For the sake of brevity, no additional instructions on the loading address and running address of the boot flow is provided in this document.
2. Image Defconfig¶
The image defconfig of the SDK is located in the project/configs/defconfigs/ directory. Take ipc-rtos_iford.spinand.glibc-11.1.0-ramdisk.ssc029a.512.bga12_ddr4_hyp_ptree_defconfig as an example:
| defconfig Field | Description |
|---|---|
| product | ipc, ipc-rtos, usbcam |
| boot medium | nor, spinand, emmc |
| rootfs type | ramfs, ramdisk, squashfs, ext4fs. |
| DDR size | |
| package | bag12, bag11, qfn128 |
| software feature | hyp, optee, cm4_demo, str |
3. Typical Scenario Boot Flow¶
According to the ARMv8 architecture definition, the execution state of the system is divided into two worlds: the secure world for running trusted software and the non-secure world for running untrusted software. Moreover, the 32-bit processor mode is divided into three privilege levels, namely: PL0, PL1, PL2.
3.1. Pure Linux Scenario¶
3.1.1. Pure Linux Normal Boot Flow¶
For example: ipc_iford.emmc.glibc-11.1.0-ext4fs.ssc029d.256.bga8_lpddr4x_ai_glasses_defconfig is to change the startup process.
This scenario is the boot flow of IPC/USBCAM product: non-secure world only runs Linux OS, and NS.PL2 (hypervisor layer) does not need to run VMM.
SMF (secure monitor firmware): Responsible for completing the initialization setting of the CPU monitor mode and the initialization setting of the GIC during the system startup process. SMF does not have an independent partition, but is embedded in the IPL binary image.
3.1.2. Pure Linux Fast Boot Flow¶
For example: ipc_iford.norglibc-11.1.0-ramdisk.ssc029d.256.bga8_1pddr4x_fast_defconfig is to change the startup process.
This scenario is the boot flow of IPC/USBCAM product and in order to enter the Linux command line quickly, the rootfs type is set to ramfs: non-secure world only runs Linux OS, NS.PL2 (hypervisor layer) does not need to run VMM, and the boot flow skips uboot and starts Linux directly from IPL_CUST, to reduce the time it takes to enter the Linux command line after powering on.
3.2. DualOS Scenario¶
AI Glasses and D2's config do not support DualOS, there is no need to pay attention to changing the chapter
3.2.1. Sensor Earlyinit DualOS Fast Boot Flow Based on VMM in IPL¶
This scenario is the boot flow of IPC-RTOS product: non-secure world PL2 (hypervisor layer) runs VMM for interrupt and CPU scheduling. When running RTOS + Linux dual system on the same core, RTOS is scheduled first and Linux will be allowed to use the CPU when it is idle. The dual-system scenario has both the lightweight and fast boot of the RTOS system and the general scalability of the Linux system.
The role of the earlyinit firmware is to set the sensor and VIF modules to start working at the earliest possible stage. During the boot flow, the VIF output is synchronized to the cached sensor raw image data. When the non-secure world RTOS is started, the RTOS task will create a video pipeline to output the video stream data. The VIF module will first pass the cached raw image to the video pipeline, and then the real-time sensor collected raw image data.
When IPL_CUST loads VMM and jumps from IPL_CUST to execute the VMM process, it will take bootargs_hyp from ENV and pass it to VMM as cmdline_tag.
bootargs_hyp = vmm_size=0x00200000 vmm_limit_size=0x20000000 vm0_en=1 vm1_en=1 vm0_online_map=0x02 vm1_online_map=0x0F vm0_master=1 vm1_master=0 vm0_entry=0x3E308000.
The meaning of each field is as follows:
-
vm0_en=1: Enable VM0. Currently, VM0 is programmed in VMM to start RTOS.
-
vm1_en=1: Enable VM1. Currently, VM1 is programmed in VMM to start Linux.
-
vm0_online_map=0x02: Specify VM0 to run on core1.
-
vm1_online_map=0x0F: Specify VM1 to run on core0~1.
-
vm0_master=1: VM0 mainly runs on core1.
-
vm1_master=0: VM1 mainly runs on core0.
-
vm0_entry=0x3E308000: If the entry address of vmm is not specified by the vmm image header, it will be specified according to vm0_entry.
When VMM loads RTOS and jumps from VMM to execute the RTOS process, it will take bootargs_rtos from ENV and pass it to RTOS as cmdline_tag.
bootargs_rtos = rtos_size=0x0100000 limit_dram_size=0x20000000 mma_base=0x28000000 mma_size=0x16300000 rtosrd_addr=0x3ED00000 rtosrd_size=0x120000 rtosts_addr=0x3EC00000 rtosts_size=0x800 rtos_master=1 loglevel=3.
The meaning of each field is as follows:
-
rtos_size=0x0100000: Specify RTOS system memory size
-
limit_dram_size=0x40000000: Specify RTOS DRAM total size configuration
-
mma_base=0x28000000 mma_size=0x16300000: Specify the MMA start address and MMA size used by RTOS
-
rtosrd_addr=0x3ED00000 rtosrd_size=0x120000: Specify the start address and size of DDR occupied by fs
-
rtosts_addr=0x3EC00000 rtosts_size=0x800: Specify the starting address and size of DDR occupied by the structure tags holding the startup parameters for RTOS
-
loglevel=3: Specify RTOS OS log level. The log level value range is [0,7]. The larger the value, the higher the log level.
-
rtos_master=1: Specify that rtos runs on a certain physical core, which affects the booting speed and flow. It cannot be modified by default.
3.2.2. DualOS Normal Boot Flow Based on VMM¶
This scenario is the boot flow of IPC-RTOS product. It differs from scenario 3.2.1 in that, IPL will not run earlyinit firmware when it finds that the GPIO level is low according to the GPIO status; besides, IPL_CUST will load the uboot image to DDR, and finally jump to uboot job. The settings of bootcmd determine whether PL2 should load VMM, and which OS the non-secure world should load.
For example, to allow uboot to complete loading rtos, linux and vmm, and vmm to start dualos according to bootargs_hyp, the flow will be:
setenv bootcmd 'loados nand by_header MISC by_header; loados nand by_header RTOS by_header;bootm start${loados_addr};bootm loados;bootm prep; loados nand by_header RAMDISK by_header; loados nand by_header KERNEL by_header;bootm start${loados_addr};bootm loados;bootm prep; mtdparts add nand0 0x20000@0X00260000 VMM; loados nand by_header VMM by_header;dcache off;bootm${loados_addr} bypass_vm_load;'
3.2.3. DualOS Boot Flow Based on LH Mode¶
This scenario is the boot flow (LH bootflow mode) of the ipc-rtos product, which differs from scenario 3.2.1 (hyp bootflow mode) in that LH bootflow mode does not have a hypervisor layer implemented by VMM, and ns-world can only run one os. Therefore, Linux runs on ns-world PL1, rtos runs on s-world PL1. And LH bootflow does not have optee.
The bootargs_rtos used in LH bootflow mode is the same as that described in chapter 3.2.1, please refer to the description above.
In addition, due to the different Sensor Earlyinit stages in the boot flow, two flows will be forked:
Flow 1:
Sensor Earlyinit will start bringup at the IPL stage, and the RTOS does not need to access the flash. After Core0 loads RTOS in IPL_CUST, it will directly load the MISC partition (partition name is MISC_RTOS) storing the configuration file onto ddr (this practice is also called RAMFS), then core1 will start rtos, and core0 will immediately load linux and rootfs.
Advantage: It can make TTFF/TTCL speed as fast as possible.
Disadvantage: IPL CUST has no OS-related interface, and EarlyInit development and maintenance are more difficult.
Flow 2:
Sensor Earlyinit will bring up in the RTOS stage, and RTOS will access the flash. After Core0 loads RTOS in IPL_CUST, it will wake up core1 to boot rtos, and then immediately enter the wfe state. During the Rtos running process, Core1 determines that the flash has been used up, releases the right to use the flash and wakes up core0. At this time, core0 will continue to process the flow of loading linux and rootfs.
Advantage: Using RTOS interfaces for development and maintenance, the difficulty of EarlyInit development will be greatly reduced.
Disadvantage: TTFF and TTCL are slightly slower.
Note: The IPL corresponding to this flow has the configurations WAIT_RTOS_FLASH_ACCESS=y and LOAD_RTOS_RAMFS=n, and the RTOS also needs to enable the corresponding FLASH configuration and CONFIG_RTOS_FLASH_ACCESS_DONE_WAKEUP options.
For scenarios where the IPU model is relatively large, there is another process for loading the IPU model during the IPL_CUST stage:
Flow 3:
This flow is similar to flow 2, with the addition of loading the IPU model into DDR before loading the IPL_CUST kernel. After Core1 wakes up Core0, Core0 first loads the IPU model and then flow the loading of Linux and rootfs.
Advantage: The IPU model supports hardware xz decompression, resulting in a short flash load time.
Disadvantage: Additional memory is required for the IPU
Note: The IPL corresponding to this flow has the configurations iford_nand_dualos_aov_ipu. The defconfig needs to enable the CONFIG_IPU_INDEPENDENT_PARTITION option and configure the size of CONFIG_IPU_MEM_SIZE.