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¶

SSD201/SSD202 public version has 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 202 (128M memory) is shown in blue in the following table.

The subsequent practical examples are all performed in configs/nvr/i2m/8.2.1/spinand.ram-glibc-squashfs.011a.128.

2.2. Post-boot flow¶

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:

The necessary parts of the panel lighting and UI are placed in the init stage.
Other parts are still in the original demo stage.

Packaging differences:

The normal version of lib/ko is packaged in the miservice partition, and then mounted to the /config directory after the kernel is up. The corresponding ko will be insmoded after the partition is mounted.
The FastBoot version lib/ko will be packaged to the rootfs partition according to the actual needs, some of which are fast-start applications that need to be quickly dependent, and some of which can be deferred or packaged to miservice, where the ko in rootfs will be in init. The sh stage is insmoded, which saves the waiting time for mounting and achieves the acceleration effect.

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.

Fastbot version rootfs packaging reference: project\image\configs\i2m\rootfs_fastboot.mk, package the ko/lib that needs to be started in advance to the rootfs partition, and then integrate the corresponding insmod ko/start app operation into the init.sh file.

As follows, put the insmod action of the mi-related ko specified in .mod_depend into init.sh to do it:

3. Customization Instructions¶

3.1. fastboot memory statistics¶

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

RAMdisk occupies memory:

Corresponding occupied memory: 0x67ffff = 6.66M, which should correspond to the rootfs partition size.

So linux available memory = MemTotal - Ramdisk Memory

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

3.2. Main implementation process¶

The way fastboot is implemented is mainly reflected in: project\image\configs\i2m\rootfs_fastboot.mk

In this mk, all the booting behaviors are placed under /etc/profile. The approximate process is as follows:

Put the modules (ko/bin and other resources) that must be used for booting into /etc/init.sh for execution
Start the app at the end of init.sh, sdk\verify\application\zk_mini_sercurity_fastboot\image.mk

Note: The res necessary for the first panel to be displayed when the app is started is placed in the customer_app of the rootfs, and other ress are placed under the customer. The advantage of this is that it can reduce the size of the rootfs and speed up the startup.
After the app is up, go to mount the unnecessary partitions and mount them

3.3. Software customization content¶

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

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

The size of the 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, 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\i2m\spinand.ramfs-squashfs.p2.partition.config

Nor: project\image\configs\i2m\nor.ramfs.partition.config

Note: 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.

3.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:

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

The biggest difference between 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.

3.3.4 Processing of dlopen¶

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.

The public version example Zk Demo is as follows:

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

Example of using dlopen:

3.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.

3.5. Customized Content¶

Fastboot's boot speed is improved, and the flash needs to run to 104M to boot faster. This requires that the FLASH-related PCB needs to be checked by the original factory.
The speed of different Flash manufacturers is quite different.
If Fastboot needs to open the bootlogo, you must run uboot to open the bootlogo. The specific changes are as follows:

a. setenv ota_upgrade_status 1, control whether to run uboot through ota_upgrade_status

b. setenv autoestart 0, disable the uboot network function, speed up the boot time

c. Open Flash Quad Read Mode: CONFIG_MS_SPINAND_QUAD_READ (requires flash support)

4. Boot time statistics¶

Boot Phase	Time (ms)
IPL~UBOOT IPL gbf78c2e - runUBOOT()	65
UBOOT~KERNEL runUBOOT() - Starting kernel	1168
KERNEL~KO INSMOD FINISH Starting kernel - mknod: /dev/mi_poll: File exists	2061
INSMOD FINISH - APP START DONE mknod: /dev/mi_poll: File exists - FB_AllocHWSurface 1303	667
Total：	3961

Test environment:

flash model: MX35LF1GE4AB [128M](C2-12)
Software version: TAKOYAKI_DLS00V008

Test Conditions:

Open the boot logo: setenv ota_upgrade_status 1
uboot opens quadmode: # define SUPPORT_SPINAND_QUAD (1)
Disable uart eth: setenv autoestart 0