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. Public version related instructions¶
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
2.4. Storage partition configuration of dynamic link library¶
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