LiteOS Cortex-A
Overview
Porting Scenario
LiteOS Cortex-A supports the ARMv7-a instruction set architecture. If you are porting the kernel to a chipset that uses ARMv7-a, you can directly perform basic adaptation. Otherwise, you need to add support for the architecture used by the chipset. This process is complex and not covered in this document.
Directory Specifications
For details about the LiteOS Cortex-A directory specifications, see LiteOS Cortex-A Overview.
Adaptation Process
LiteOS Cortex-A provides the system initialization process and custom configuration options required for system running. During porting, pay attention to the functions related to hardware configuration in the initialization process.
The LiteOS Cortex-A initialization process consists of seven steps:
- Add the target_config.h file and compile the macros DDR_MEM_ADDR and DDR_MEM_SIZE, which indicate the start address and length of the board memory, respectively. The prelinker script board.ld.S creates the linker script board.ld based on the two macros.
- Define g_archMmuInitMapping, the global array of MMU mappings, to specify the memory segment attributes and the virtual-to-physical address mappings. The memory mapping will be established based on this array during kernel startup.
- If there are multiple cores, define struct SmpOps, the handle to the slave core operation function. The SmpOps->SmpCpuOn function needs to implement the feature of waking up a slave core. Then, define the SmpRegFunc function and call the LOS_SmpOpsSet interface to register the handle. The registration process is completed by starting the framework using LOS_MODULE_INIT(SmpRegFunc, LOS_INIT_LEVEL_EARLIEST).
- Create a kernel image based on the linker script board.ld.
- Perform operations such as initialization of the interrupt vector table and MMU page table are performed in the assembly files: reset_vector_up.S and reset_vector_mp.S, from which a single-core CPU and a multi-core CPU start, respectively.
- Enable the assembly code in reset_vector.S to jump to the main function of the C programming language to initialize the hardware clock, software timer, memory, and tasks. This process depends on the feature macro configuration in target_config.h. Then, create the SystemInit task to be implemented in the board code, with OsSchedStart() enabled for task scheduling.
- Call the DeviceManagerStart function to initialize the HDF driver. This process is implemented by calling the driver configuration file hdf.hcs and drivers source code in the board code.
The figure below shows the overall initialization process.
Figure 1 Overall initialization process
As can be seen from preceding figure, kernel basic adaptation involves the following parts:
-
Adding the target_config.h file, which contains board hardware parameters and feature parameters described in the following table:
Table 1 Parameters in the target_config.h file
-
Implementing the SystemInit function to initialize services in the user space. Figure 2 shows a typical initialization scenario.
-
Implementing the main function for basic kernel initialization and initialization of services in the board kernel space. Figure 3 shows the initialization process, where the kernel startup framework takes the lead in the initialization process. The light blue part in the figure indicates the phase in which external modules can be registered and started in the startup framework.
CAUTION:
Modules at the same layer cannot depend on each other.Figure 3 Kernel startup framework
Table 2 Startup framework layers
Adaptation for board porting. Focus on layers between LOS_INIT_LEVEL_ARCH and LOS_INIT_LEVEL_KMOD_TASK and try to divide the initialization process into as many phases as possible for refined registration.
NOTE:
Modules at the same layer cannot depend on each other. It is recommended that a new module be split based on the preceding startup phase and be registered and started as required.
You can view the symbol table in the .rodata.init.kernel.* segment of the OHOS_Image.map file generated after the build is complete, so as to learn about the initialization entry of each module that has been registered with the kernel startup framework and check whether the newly registered initialization entry takes effect.
Programming Example
In the board SDK file:
/* Header file of the kernel startup framework */
#include "los_init.h"
......
/* Initialization function of the new module */
unsigned int OsSampleModInit(void)
{
PRINTK("OsSampleModInit SUCCESS!\n");
......
}
......
/* Register the new module at the target layer of the startup framework. */
LOS_MODULE_INIT(OsSampleModInit, LOS_INIT_LEVEL_KMOD_EXTENDED);
Verification
main core booting up...
OsSampleModInit SUCCESS!
releasing 1 secondary cores
cpu 1 entering scheduler
cpu 0 entering scheduler
According to the preceding information displayed during the system startup, the kernel calls the initialization function of the registered module during the startup to initialize the module.
The system enters the kernel-space shell and the task commands can be properly executed.
OHOS # help
*******************shell commands:*************************
arp cat cd chgrp chmod chown cp cpup
date dhclient dmesg dns format free help hwi
ifconfig ipdebug kill log ls lsfd memcheck mkdir
mount netstat oom partinfo partition ping ping6 pmm
pwd reset rm rmdir sem shm stack statfs
su swtmr sync systeminfo task telnet touch umount
uname v2p virstatfs vmm watch writeproc