Análisis del proceso de inicio de la placa de desarrollo del chip Hi3861 del dispositivo ligero OpenHarmony

Introducción

Como sistema operativo para Internet de Todo, OpenHarmony cubre todo, desde sistemas operativos IoT integrados en tiempo real hasta sistemas operativos móviles, y el kernel incluye LiteOS-M, LiteOS-A y Linux. El kernel LiteOS-M es un kernel de sistema operativo de IoT liviano creado para el campo de IoT. Es principalmente para procesadores sin una MMU. La arquitectura se muestra en la Figura 1-1.

Figura 1-1 Diagrama de arquitectura de LiteOS-M

Hi3861 es un chip WiFi SoC de 2,4 GHz altamente integrado que utiliza un microprocesador de 32 bits de alto rendimiento con una frecuencia operativa máxima de 160 MHz, integrado con 352 KB de SRAM, 288 KB de ROM y 2 MB de Flash. En la actualidad, los fabricantes de placas de desarrollo OpenHarmony que utilizan LiteOS-M en el mercado incluyen Shenkaihong, Runhe Software y Xiongpai.Debido a que el SDK de HiSilicon se proporciona en forma de archivos de biblioteca, el proceso de inicio de las diferentes placas de desarrollo de chips Hi3861 es el mismo. .

Introducción a la bota Hi3861

Boot es el software antes de que se inicie el sistema operativo. El nombre general es bootloader. El inicio de Hi3861 se divide en cuatro partes: RomBoot, FlashBoot, LoaderBoot y CommonBoot, como se muestra en la Figura 2-1.

Figura 2-1 Proceso de arranque de Hi3861

● Las funciones de RomBoot incluyen: cargar LoaderBoot en RAM, usar LoaderBoot para descargar imágenes a Flash, programar EFUSE, verificar y arrancar FlashBoot. FlashBoot se divide en lado A y lado A. Si se verifica correctamente el lado A, se iniciará directamente. Si falla la verificación, irá al lado B. Si la verificación del lado B es exitosa, se reparará el lado A. y luego arrancado De lo contrario, se restablecerá y reiniciará.

● Las funciones de FlashBoot incluyen: actualizar el firmware, verificar y arrancar el firmware.

● Las funciones de LoaderBoot incluyen: descargar imágenes a Flash, grabar EFUSE (por ejemplo: arranque seguro/claves relacionadas con el cifrado de Flash, etc.).

● CommonBoot es un módulo funcional compartido por Flashboot y LoaderBoot.

Documentos relacionados

El código LiteOS-M de Hi3861 se proporciona en forma de archivo de biblioteca en el SDK. Aunque no podemos ver el código fuente, no significa que no podamos analizar el proceso de inicio. Podemos comenzar analizando el archivo de mapa y el archivo asm. Estos dos archivos se generan mediante herramientas de compilación y vinculación. El archivo asm es un archivo fuente de ensamblador. Puede ver la relación de llamadas entre funciones. El archivo de mapa incluye símbolos globales, direcciones de función y espacio ocupado y ubicación. La función principal de los archivos map y asm es analizar la causa del bloqueo cuando la placa de desarrollo falla. Cuando analizamos la relación de salto de función, no necesitamos saber demasiado sobre ensamblaje. Solo necesitamos saber el salto básico. declaración y declaración de asignación.Los dos archivos se encuentran en el mismo directorio que el firmware del sistema operativo en el directorio de salida, como se muestra en la Figura 3-1.

Figura 3-1 Mapa de ubicación de Hi3861 asm y archivos de mapa

Un firmware compilado generalmente tiene las siguientes partes:

1. El segmento RO incluye un segmento de código de solo lectura (segmento de código/segmento .text) y un segmento constante (segmento RO Data/segmento .constdata).

2. El segmento RW (segmento .data) hace referencia al segmento variable que se ha inicializado en un valor distinto de cero.

3. El segmento ZI (segmento .bss) se refiere al segmento variable que no se inicializa o se inicializa en 0.

Las funciones y constantes de cadena de nuestro código fuente se encuentran en la sección de texto.

Introducción al proceso de arranque de LiteOS-M

1. Tanto el procesador integrado como el sistema operativo tienen una estructura similar. El proceso de inicio también es similar. Desde el momento en que se enciende el chip, el arranque transfiere el control al sistema operativo. El Hi3861 salta del arranque al sistema operativo. El código es el siguiente
   
   : la función se usa como un salto, porque FlashBoot y kernel son dos conjuntos de programas de código, no hay dependencia ni relación de referencia entre ellos, pero están en el mismo espacio de direcciones, por lo que la dirección directa salta, que es también una forma común de saltar de Boot a kernel.

2. El inicio del chip comienza desde el controlador de interrupción de reinicio de la tabla de vectores de interrupción y luego copia los datos de Flash a RAM, borra el segmento de datos bss, inicializa el reloj y salta a la función principal. Al observar la función principal del archivo asm, podemos ver que las funciones llamadas se muestran en la Figura 4-1.De la Figura 4-1, podemos saber que las funciones llamadas incluyen configurar el puerto serie, verificar el número de versión, configurar la placa e inicializar el Kernel. , Inicialización de la aplicación y operación de programación del sistema operativo, donde la función principal se encuentra en el archivo liblitekernel_flash.a (main.o).
   
   Figura 4-1 Relación de llamada de función principal

LOS_KernelInit es responsable de inicializar la estructura de datos del kernel, como se muestra en la Figura 4-2, las funciones principales son OsMemSystemInit (inicialización de memoria), OsHwiInit (inicialización de interrupción), OsTaskInit (inicialización de tareas), el propósito principal de estos procesos es inicializar kernel variables relacionadas, preparar información global para facilitar las llamadas a funciones de API. Las llamadas a funciones de API deben completarse después de que se completen estas inicializaciones.

3. Desde AppInit, nos hemos separado del SDK y podemos ver el código fuente. La función AppInit se encuentra en libwifiiot_app.a (app_main.o). Algunas capturas de pantalla se muestran en la Figura 4-3. El código fuente es app_main.c , y las funciones llamadas incluyen obtener el número de versión SDK, inicialización de periféricos, inicialización de ipc, partición flash, inicialización de WiFi, inicialización de tcp/ip y luego saltar a la función OHOS_Main exclusiva de OpenHarmony.

OHOS_Main se encuentra en libwifiiot_app.a (ohos_main.o), el código fuente es ohos_main.c, que completa principalmente las llamadas relacionadas con el sistema OpenHarmony y las aplicaciones de usuario. La función principal interna es OHOS_SystemInit, como se muestra en la Figura 4-4, que llama a la propia escritura del usuario. El código relacionado con la tarea de la aplicación, como se muestra en la Figura 4-5, se da cuenta de que la lista de tareas se completa antes de LOS_start, para garantizar que las tareas del usuario o las funciones de temporización participen en la programación del sistema.

Figura 4-2 Relación de llamada de función LOS_KernelInit

Figura 4-3 Relación de llamada de función app_main

Figura 4-4 Relación de llamada de función OHOS_Main

Figura 4-5 Relación de llamada de función OHOS_SystemInit

Cómo se inicia la aplicación de usuario

1. La función MODULE_INIT(ejecutar) que aparece en la figura 4-5 es para llamar al código que finalmente llama al programa de usuario.

Esta es una definición de macro, la relación de llamada expandida: \base\startup\bootstrap_lite\services\source\core_main.h definición, de MODULE_CALL, MODULE_BEGIN, MODULE_END, la dirección de llamada final es __zinitcall_##name##_start, MODULE_INIT(run ) La dirección de la función llamada es __zinitcall_run_start.

Al mirar el archivo de enlace, se encuentra que __zinitcall_run_start contiene .zinitcall.run0.init), como se muestra en la Figura 5-1.

Figura 5-1 Relación de enlace __zinitcall_run_start

Verifique el archivo de mapa y encuentre que nuestro propio archivo de aplicación está en .zinitcall.run2.init, como se muestra en la Figura 5-2.

Figura 5-2 La ubicación del archivo led_exapmle en el mapa

2. Desde el punto de vista de la ejecución, se llama a la aplicación led_exapmle durante el inicio, la supuesta ubicación es .zinitcall.run2.init, pero nuestra función asociada en la aplicación es SYS_RUN (LedExampleEntry), y la relación de expansión de SYS_RUN se muestra en Figura 5-3 Finalmente Eso es zinitcall.run2.init, que coincide con la llamada cuando el programa se está ejecutando. La relación de llamada del programa de aplicación es que el segmento especificado se genera durante la etapa de compilación y vinculación, y el segmento especificado se llama durante la inicialización, realizando así el desacoplamiento del código del sistema operativo y el código del programa de aplicación de LiteOS-M.
   
   Figura 5-3 La relación de expansión de SYS_RUN

resumen

Este artículo le dice cómo obtener el proceso de inicio de la placa de desarrollo de chips Hi3861 LiteOS-M a través del análisis del archivo de mapa y el archivo asm sin parte del código fuente. El proceso general es que después de completar la configuración del sistema de hardware mínimo, LOS_KernelInit es responsable de inicializar el sistema a un estado adecuado, AppInit llama a OpenHarmony y a los códigos relacionados con la aplicación, y finalmente LOS_Start es responsable de ejecutar el sistema operativo.

---

©Copyright pertenece al autor: Trabajos originales del bloguero de 51CTO Desarrolladores de OpenHarmony, comuníquese con el autor para obtener la autorización de reimpresión; de lo contrario, se perseguirá la responsabilidad legal
Dispositivo liviano OpenHarmony Hi3861 Análisis del proceso de inicio de la placa de desarrollo del
chip /5589272