SSD_FASTBOOT Reference


1. Basic introduction

1.1. Overview

This document will describe the configuration and use of fast boot.

The main principle of FASTBOOT is to put the necessary modules and user apps related to the panel lighting on the ramdisk to start in advance, so as to realize the function of fast panel lighting.

  • Advantages

    Can achieve fast panel lighting.

  • Disadvantages

    Making a ramdisk requires extra memory. The larger the app size is, the larger the ramdisk will be, and the more memory it will consume. Therefore, before deciding to use fastboot, it is necessary to evaluate whether the memory is sufficient.

    Note: If the user app is very large, it is not recommended to use fastboot.


1.2. Boot Flow

  • By default, fastboot will skip uboot and start the kernel directly

  • If you need to enter uboot, you can long press enter, reboot until you enter uboot

  • The post-boot flow refers to the profile execution stage after the system is up


1.3. Keyword Description

  • RAMFS

    RAMFS is a ram-based file system under Linux, so ramfs will have higher efficiency.

    One flaw of ramfs is that it takes up a lot of memory, because the rootfs is put into the memory area, even if you specify the size when you mount it.

  • dlopen

    Linux, provides a set of APIs to dynamically load libraries. These APIs are listed below:

    dlopen, opens a library and prepare it for use.

    dlsym, finds the value of a symbol in an open library.

    dlclose, closes the library.

    dlerror, returns a string describing the error message of the last call to dlopen, dlsym, or dlclose.


2.1. Compile configuration

SSD210/212/222/222D can do fastboot function, and the public version has also added the following defconfig. The memory required for the Fastboot function is relatively large, because the public version has many behaviors and UIs, and the actual development test on 222D (128M memory) is shown in blue in the following table. If the client's UI and behavior are relatively simple, it can also be developed on the 64M chip.

The subsequent practical examples are all performed in dispcam_p3_spinand.glibc-9.1.0-ramfs-s01a.128.qfn128.demo_camera_wifi_defconfig.

| Chip | Packaging | Memory | Flash | Toolchain | Other | | ------- | --------- | ------ | ----- | --------- | -------- - | ------------------------------------------------ ------------ | | SSD210 | QFN68 | 64M | NOR | glibc | NA | dispcam_p3_nor.glibc-9.1.0-ramfs.s01a.64.qfn68.demo_defconfig | | SSD212 | QFN128 | 64M | NOR | glibc | NA | dispcam_p3_nor.glibc-9.1.0-ramfs.s01a.64.qfn128.demo_defconfig | | SSD222D | QFN128 | 128M | NOR | glibc | NA | dispcam_p3_nor.glibc-9.1.0-ramfs.s01a.128.qfn128.demo_camera_defconfig | | SSD222D | QFN128 | 128M | NOR | glibc | sdio wifi | dispcam_p3_nor.glibc-9.1.0-ramfs.s01a.128.qfn128.demo_camera_wifi_defconfig | | SSD210 | QFN68 | 64M | NAND | glibc | NA | dispcam_p3_spinand.glibc-9.1.0-ramfs-s01a.64.qfn68.demo_defconfig | | SSD212 | QFN128 | 64M | NAND | glibc | NA | dispcam_p3_spinand.glibc-9.1.0-ramfs-s01a.64.qfn128_demo_defconfig | | SSD222D | QFN128 | 128M | NAND | glibc | NA | dispcam_p3_spinand.glibc-9.1.0-ramfs-s01a.128.qfn128.demo_camera_defconfig | | SSD222D | QFN128 | 128M | NAND | glibc | sdio wifi | dispcam_p3_spinand.glibc-9.1.0-ramfs-s01a.128.qfn128.demo_camera_wifi_defconfig |

2.2. Post-boot flow

In addition to the Fastboot function, in addition to skipping uboot to reduce the boot time during the startup process, there is another way to quickly display the panel by dividing the original ko initialization place into two parts:

\1. The necessary parts of the panel and UI are placed in the init stage.

\2. Other parts are still in the original demo stage.

Subsequent chapters 2.2 to 2.4 introduce the principles and methods of this part.

The normal versions of lib and ko are placed in the following paths:

Lib: /config/lib

Ko: /config/modules/4.9.84/

The Fastboot version can be seen split as follows:

Ko related is split into: /lib/modules/4.9.84/ and /config/modules/4.9.84/

Lib related is split into: /lib and /config/lib

Let's look at the implementation of init.sh again to understand the following content easily:

This stage of the post-boot process includes the mounting of partitions and the loading of modules. It is roughly divided into two stages: the init stage and the demo stage:

init phase: (refer to /etc/init.sh)

At this stage, the necessary environment configuration of the system is carried out.

  • Load system environment configuration necessary drivers

    Load the kernel, misc, mi drivers in turn

  • Run app

    The demo needs to run in the background and is stored in dram

demo stage: (refer to demo.sh)

Other operations for demo running at this stage

  • load secondary drive

    Load the kernel, misc, mi drivers in turn

  • Run demo

    The demo is stored in flash


2.3. Module Loading Configuration

This section explains the corresponding configuration files for loading modules, which can be flexibly configured according to requirements.

init stage:

  • Features

    Modules are stored in the ramfs partition, and are stored in dram when the system is running (lib/modules/4.9.84)

  • Configuration file storage directory

    ./project/kbuild/customize/4.9.84/p3/disp-fastboot/kernel_mod_list
    
    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/misc_mod_list
    
    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/.mods_depend
    
    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/mi_mod_list_late
    

    or

    ./project/kbuild/customize/4.9.84/p3/dispcam-fastboot/kernel_mod_list
    
    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/misc_mod_list
    
    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/.mods_depend
    
    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/mi_mod_list_late
    
  • Configuration file

    Used to configure the drivers loaded at each stage, just add the driver name to the corresponding file

    kernel_mod_list: The kernel driver initialized by the system, such as nls_utf8.ko

    misc_mod_list: misc driver initialized by the system, such as mhal.ko

    mi_mod_list : The mi driver initialized by the system, such as mi_sys.ko, this file is not available for SSD21X/SSD22X. It is obtained by subtracting .mods_depend and mi_mod_list_late.

  • How to use the configuration file

    Add the driver name of the corresponding driver to the corresponding configuration file

demo stage:

  • Features

    The modules are stored in the config partition (flash) and do not occupy memory space (/config/modules/4.9.84)

  • Configuration file storage directory

    ./project/kbuild/customize/4.9.84/p3/disp-fastboot/kernel_mod_list_late
    
    ./project/kbuild/customize/4.9.84/p3/disp-fastboot/kernel_mod_list_late_nand (nand actually needs to be modified here, it will be copied to kernel_mod_list_late when compiling)
    
    ./project/kbuild/customize/4.9.84/p3/disp-fastboot/kernel_mod_list_late_nor (nor actually needs to be modified here, it will be copied to kernel_mod_list_late when compiling)
    
    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/misc_mod_list_late
    
    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/mi_mod_list_late
    

    or

    ./project/kbuild/customize/4.9.84/p3/dispcam-fastboot/kernel_mod_list_late
    
    ./project/kbuild/customize/4.9.84/p3/dispcam-fastboot/kernel_mod_list_late_nand (nand actually needs to be modified here, it will be copied to kernel_mod_list_late when compiling)
    
    ./project/kbuild/customize/4.9.84/p3/dispcam-fastboot/kernel_mod_list_late_nor (nor actually needs to be modified here, it will be copied to kernel_mod_list_late when compiling)
    
    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/misc_mod_list_late
    
    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/modules/4.9.84/mi_mod_list_late
    
  • Configuration file

    Used to configure the drivers loaded at each stage, just add the driver name to the corresponding file

    kernel_mod_list_late: The kernel driver required for demo operation, for example: usb-storage.ko

    misc_mod_list_late: misc driver required for demo operation, for example: fbdev.ko

    mi_mod_list_late: mi driver required for demo running, for example: mi_ai.ko

  • How to use the configuration file

    Add the driver name of the corresponding driver to the corresponding configuration file


The dynamic link library can be stored in the ramfs partition and the config partition. The former occupies memory space and the latter is stored in flash.

Store in ramfs partition:

  • Configuration filename

    mi_lib_list/ex_lib_list

  • Configuration file path

    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/ex_libs/dynamic/ex_lib_list
    
    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/mi_libs/dynamic/mi_lib_list
    
    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/mi_libs/dynamic/.libs_depend
    

    or

    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/ex_libs/dynamic/ex_lib_list
    
    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/mi_libs/dynamic/mi_lib_list
    
    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/mi_libs/dynamic/.libs_depend
    
  • How to use

    Add the corresponding library name to the configuration file

Store in the config partition:

  • Configuration file name: no profile

  • Configuration file path

    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/ex_libs/dynamic/ex_lib_list
    
    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/mi_libs/dynamic/mi_lib_list
    
    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/mi_libs/dynamic/.libs_depend
    

    or

    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/ex_libs/dynamic/ex_lib_list
    
    ./project/release/dispcam-fastboot/p3/common/glibc/9.1.0/mi_libs/dynamic/mi_lib_list
    
    ./project/release/disp-fastboot/p3/common/glibc/9.1.0/mi_libs/dynamic/.libs_depend
    
  • How to use

    By subtracting .libs_depend and mi_lib_list, the result that mi_lib needs to be placed in config is obtained.

    The result that ex_libs needs to be placed in config is obtained by subtracting the files placed by default in ex_libs and ex_lib_list.


3. Use of drivers and libraries

3.1. Introduction

This chapter will introduce the required drivers and the use of some dynamic link libraries according to the required functions.


3.2. By Driver

Category Driver Remarks
usb basic driver usb-comon.ko usb basic driver
usb-core.ko usb host basic driver
ehci-hcd.ko usb2.0 host controller driver
xhci-hcd.ko usb3.0 host controller driver
U disk usb-storage.ko usb disk driver (depending on usb basic driver)
mouse mousedev.ko mouse input driver
usbhid.ko usb mouse (depends on usb basic driver)
NIC of_mdio.ko Dependencies
kdrv_emac.ko Platform related underlying network card driver
sstar_100_phy.ko
sunrpc.ko Remote Procedure Call (RPC) protocol for remote command execution, used by Network File System (NFS)
libphy.ko Network base driver
fixed_phy.ko
mtd device ubi.ko ubi driver
mmc card mmc_core.ko mmc base driver
mmc_block.ko
kdrv_sdmmc.ko sd card driver
Watchdog mdrv_wdt.ko Watchdog driver
Fonts nls_utf8.ko utf8 font driver
hard disk sd_mod.ko scsi interface disk support
libahci.ko Serial ata interface related driver
ahci_platform.ko
libahci_platform.ko
libata.ko
mdrv-sata-host.ko sata underlying driver
iic mii.ko i2c driver
filesystem grace.ko, nfs.ko nfs network filesystem
grace.ko, nfsv2.ko nfs network file system (version2)
ubifs.ko ubi file system (flash)
jffs2.ko jffs2 file system (flash)
squashfs Compresses read-only filesystems
fat.ko fat filesystem
vfat.ko vfat file system (U disk)
cifs.ko cifs file system (samba)
ntfs.ko ntfs file system

3.3. Sort by library

toolchain related librt-2.28.so real-time extension library, including semaphore, synchronous io, etc.
libm-2.28.so Math related library
ld-2.28.so link library,
libresolv-2.28.so Provides network domain name package resolution related functions
libdl-2.28.so Load dynamic
libstdc++.so Standard library
libc-2.28.so
libpcprofile.so
libpthread-2.28.so Thread related library
MI related libmi_common.so mi essential library
libmi_sys.so mi essential library, responsible for building the basic mi framework, providing buf management,
libmi_sensor.so sensor related library
libmi_vif.so vif related library
libmi_vpe.so vpe related library
libmi_venc.so Provides video decoding function
libmi_rgn.so Provides drawing functions
libmi_disp.so Provide video splicing, video output function, docking panel, hdmi, etc.
libmi_vdec.so Provides video decoding function
libmi_vdf.so Provides video algorithm functions, including motion detection, occlusion detection, virtual fence, etc.
libmi_shadow.so Provides vdf docking interface
libmi_iqserver.so Provides network debugging iq function, docking isp module
libmi_ldc.so Provides fisheye lens alignment support
libmi_ive.so Provides the use of hardware operators
libmi_isp.so Provides advanced image debugging interface
libmi_ai.so audio input related library
libmi_ao.so Audio output related library
libmi_gfx.so Provides data movement functions
libmi_hdmi.so hdmi related library
libmi_panel.so panel related library
libmi_fb.so Provide fb device support
libmi_cipher.so Provides data encryption and decryption functions
others libcus3a.so Provides advanced isp functions such as autofocus
libMD_LINUX.so vdf related library, providing mobile monitoring function
libOD_LINUX.so vdf related library, providing occlusion detection function
libVG_LINUX.so vdf related library, providing virtual fence function
libAEC_LINUX.so audio algorithm library, providing aec function
libAED_LINUX.so audio algorithm library, providing babycry detection, high decibel detection
libAPC_LINUX.so audio algorithm library, providing noise reduction, equalization, automatic gain control, high-pass filtering
libSRC_LINUX.so audio algorithm library, providing resampling function
libg711.so audio algorithm library, providing g711 codec
libg726.so audio algorithm library, providing g726 codec

Note: Toolchain-related libraries are required libraries, please load the mi library as required, and others need to be loaded according to the corresponding mi module.

4. Customization Instructions

4.1. fastboot memory statistics

Take zk_full_fastboot as an example to count the memory usage of the public version of fastboot

RAMdisk occupies memory:

The corresponding occupied memory is almost 0x77FFFF=7.4M. In fact, it should correspond to the size of the rootfs partition.

So linux available memory = MemTotal - Ramdisk Memory

Note: DDR SIZE = MMA SIZE + MemTotal + kernel txt + MMAP IP


4.2. Main implementation process

The way fastboot is implemented is mainly reflected in:

./project/image/configs/p3/rootfs_fastboot_dispcam.mk

or

./project/image/configs/p3/rootfs_fastboot_disp.mk

In this makefile, this makefile puts all the booting behaviors under /etc/profile. The approximate process is as follows:

\1. Put the modules that must be used for booting into /etc/init.sh

\2. Then start the app at the end of init.sh, sdk\verify\application\zk_full_fastboot\image.mk

Note:

The res necessary to display the first panel when the app starts up is placed in the customer_app of the rootfs, and other ress are placed in the customer as shown in the figure below. The advantage of this is that it can reduce the size of the rootfs and speed up the booting.

\3. After the app is up, go to mount the unnecessary partitions and mount:


4.3. Software customization content

When importing fastboot, customers mainly need to consider the following points:

4.3.1 The client's app size is different from the public version

app is very important to fastboot, because the larger the app is, the larger the ramdisk will be, the larger the rootfs partition will be, the more memory will be used, and the longer it will take to decompress the ramdisk. So if the customer's app is very large, fastboot cannot play its advantages.

At present, the app is placed under rootfs, so if the customer's app size is different from the public version, you can change the size of the rootfs partition by modifying the following partition files:

nand:

./project/image/configs/p3/spinand.ramfs.partition.dispcam.config

nor:

./project/image/configs/p3/nor.ramfs.partition.dispcam.config

Note that the total size of the partition cannot exceed the total size of the flash, so after the rootfs is increased, it needs to be reduced from other partitions accordingly; at the same time, the partition size must be aligned with nor 64kb and nand 128k.


4.3.2 The customer's app memory usage is different from the public version

At present, our DDR memory is mainly composed of mma and linux memory:

DDR SIZE ~= MMA SIZE + linux MemTotal

Therefore, customers can adjust the memory usage by increasing or decreasing the size of mma according to the actual usage of mma. The actual usage of mma can be dumped by the following command in the maximum usage scenario:


4.3.3 The customer's app behavior is different from the public version

fastboot and normal startup is that some non-essential modules of fastboot are delayed to start, so the module that has not been started such as usb or wifi cannot be used immediately after the panel appears, and it needs to be processed in the ui of the app.


4.3.4 Processing of dlopen

When compiling the app, only the necessary dynamic libraries are kept, and other dynamic libraries are loaded by dlopen: reduce the size of rootfs. This requires planning which ones to put in init.sh and which ones to demo.sh.

An example of the public version of zk_full_fastboot is as follows:

The following contents of the Makefile are dynamic libraries that must be retained, and others are loaded using dlopen.

The implementation method of dlopen:


4.4. Flash-driven custom content

The public version of the flash driver does not run to 104M by default. If the default software of the public version (54M) cannot meet the boot time, it is necessary to specially adjust the default speed of the corresponding flash driver. At the same time, according to the following hardware content, the PCB needs to be checked by the original factory.


4.5. Hardware customization content

\1. Fastboot boot speed is improved, you need flash to run to 104M to boot faster. This requires that the FLASH-related PCB needs to be checked by the original factory.

\2. The speed of different Flash manufacturers is quite different. The public version test uses:

Nor: MX25L12833F

Nand: W25N01GV and MX35LF1GE4AB


5. Boot time statistics

5.1. Commands to count time

cat /sys/devices/virtual/mstar/msys/booting_time


5.2. Boot time data