Analysis of the startup process of the Hi3861 chip development board of the OpenHarmony lightweight device

introduction

OpenHarmony is an operating system for the Internet of Everything, covering everything from embedded real-time IoT operating systems to mobile operating systems. The kernels include LiteOS-M, LiteOS-A and Linux. The LiteOS-M kernel is a lightweight IoT operating system kernel built for the IoT field, mainly for processors without MMU. The architecture is shown in Figure 1-1.

 图1-1 LiteOS-M架构图

Hi3861 is a highly integrated 2.4GHz SoC WiFi chip, using high-performance 32bit microprocessor, maximum operating frequency 160MHz, embedded SRAM 352KB, ROM 288KB, Flash 2MB. At present, the OpenHarmony development board manufacturers using LiteOS-M on the market include Shenzhen Kaihong, Runhe Software, and Xiaoxiong Pi. Because the HiSilicon SDK is provided in the form of library files, the startup process of different Hi3861 chip development boards is the same. of.

Hi3861 Boot Introduction

Boot is the software before the operating system starts. The common name is bootloader. The boot of the Hi3861 is divided into four parts: RomBoot, FlashBoot, LoaderBoot, and CommonBoot, as shown in Figure 2-1.

 图2-1 Hi3861 Boot启动流程

● RomBoot functions include: loading LoaderBoot to RAM, further using LoaderBoot to download images to Flash, programming EFUSE, verifying and booting FlashBoot. FlashBoot is divided into AB side, the A side will be started directly if the verification is successful, the B side will be checked if the verification fails, and the B side will be repaired if the verification is successful, the A side will be repaired and then booted, otherwise it will be reset and restarted.
● FlashBoot functions include: upgrade firmware, verify and boot firmware.
● LoaderBoot functions include: downloading images to Flash, and programming EFUSE (eg: secure boot/Flash encryption related keys, etc.).
● CommonBoot is a function module shared by Flashboot and LoaderBoot.

Introduction to related documents

The LiteOS-M code of Hi3861 is provided in the form of library files in the SDK. Although we cannot see the source code, it does not mean that we cannot analyze the startup process. We can start by analyzing the two files, map file and asm. These two files are generated by compiling and linking tools. The asm file is the assembler source file, and the calling relationship between functions can be viewed. The map file includes global symbols, function addresses, and occupied space and locations. The main function of map and asm files is to analyze the cause of the crash when the development board crashes. We do not need to know too much assembly when analyzing the function jump relationship. We only need to know the basic jump statement and assignment statement. The two files are located in the out directory and the operating system firmware level directory, as shown in Figure 3-1.

 图3-1 Hi3861 asm和map文件位置图

A compiled firmware usually has the following parts:
1) RO segment includes read-only code segment (code segment/.text segment) and constant segment (RO Data segment/.constdata segment).
2) The RW segment (.data segment) refers to the variable segment that has been initialized to a non-zero value.
3) The ZI segment (.bss segment) refers to the variable segment that is not initialized or initialized to 0.
The functions and string constants of our source code are located in the text section.

LiteOS-M startup process introduction

1) Both the embedded processor and the operating system have a similar structure. The startup process is generally similar. From the power-on of the chip, Boot transfers control to the operating system. The Hi3861 jumps from Boot to the operating system code as follows:

This part is to use the address as a function as a jump, because FlashBoot and kernel are two sets of code programs, and there is no dependency reference relationship between them, but they are in the same address space, so the direct address jump, which is also from Boot to kernel General jump method.
2) Chip startup starts from the reset interrupt handler of the interrupt vector table, then copies the data from Flash to RAM, clears the bss data segment, initializes the clock, and jumps to the main function. By looking at the main function of the asm file, we can see that the functions called are shown in Figure 4-1. From Figure 4-1, we can know that the functions called include setting the serial port, verifying the version number, configuring the board, and initializing the Kernel. , application initialization and operating system scheduling, where the main function is located in the liblitekernel_flash.a (main.o) file.

 图4-1 main函数调用关系

LOS_KernelInit is responsible for initializing the kernel data structure. As shown in Figure 4-2, the main functions are OsMemSystemInit (memory initialization), OsHwiInit (interrupt initialization), and OsTaskInit (task initialization). The main purpose of these processes is to initialize kernel-related variables. Prepare global information to facilitate API function calls. API function calls must be completed after these initializations are completed.
3) Since AppInit has been separated from the sdk, you can see the source code. The AppInit function is located in libwifiiot_app.a (app_main.o), and some screenshots are shown in Figure 4-3. The source code is app_main.c, and the functions called include getting SDK version number, peripheral initialization, ipc initialization, flash partition, WiFi initialization, tcp/ip initialization, and then jump to the OpenHarmony-specific function OHOS_Main.
OHOS_Main is located in libwifiiot_app.a(ohos_main.o), and the source code is ohos_main.c, which mainly completes the calls related to the OpenHarmony system and user applications. The main function inside is OHOS_SystemInit, as shown in Figure 4-4, in which the user's own writing is called. The related code of the application task, as shown in Figure 4-5, realizes that the task list is filled in before LOS_start, so as to ensure that the user tasks or timing functions participate in the system scheduling.

 图4-2 LOS_KernelInit函数调用关系

 图4-3 app_main函数调用关系

 图4-4 OHOS_Main函数调用关系

 图4-5 OHOS_SystemInit函数调用关系

User application startup principle

1) The function MODULE_INIT(run) that appears in Figure 4-5 is the code that calls the final calling user program.
This is a macro definition, the expanded calling relationship: \base\startup\bootstrap_lite\services\source\core_main.h definition, from MODULE_CALL, MODULE_BEGIN, MODULE_END, the final call address is __zinitcall_##name##_start, MODULE_INIT(run ) The address of the function called is __zinitcall_run_start.
By looking at the link file, it is concluded that __zinitcall_run_start contains .zinitcall.run0.init), as shown in Figure 5-1.

 图5-1 __zinitcall_run_start链接关系

Looking at the map file, we found that our own application file is in .zinitcall.run2.init, as shown in Figure 5-2.

 图5-2 led_exapmle文件在map中的位置

2) From the operating point of view, the application led_exapmle is called during startup, the so-called location is .zinitcall.run2.init, but our associated function in the application is SYS_RUN(LedExampleEntry), and the expansion relationship of SYS_RUN is shown in Figure 5-3 , which is finally zinitcall.run2.init, which matches the call when the program is running. The calling relationship of the application is that the specified segment is generated during the compilation and linking stage, and the specified segment is called during initialization, which realizes the decoupling of the operating system code of LiteOS-M and the application code.

 图5-3 SYS_RUN的展开关系

Summarize

This article tells you how to get the startup process of Hi3861 chip development board LiteOS-M by analyzing the map file and asm file without some source code. The overall process is that after the configuration of the minimum hardware system is completed, LOS_KernelInit is responsible for initializing the system to a suitable state, AppInit calls OpenHarmony and application-related code, and finally LOS_Start is responsible for running the operating system.