diff --git a/en/device-dev/porting/porting-chip-board-driver.md b/en/device-dev/porting/porting-chip-board-driver.md index e7243e626aefd16297e34e48f6233b5838d26a6b..409f68fbcdaed214b93ba239f2acc81c83b92fc8 100644 --- a/en/device-dev/porting/porting-chip-board-driver.md +++ b/en/device-dev/porting/porting-chip-board-driver.md @@ -1,46 +1,49 @@ -# Board-Level Driver Adaptation +# Board-Level Driver Adaptation To implement board-level driver adaptation, perform the following steps: -1. Develop the SDK based on the CMSIS/POSIX APIs provided by OpenHarmony. +1. Develop the SDK based on the CMSIS/POSIX APIs provided by OpenHarmony. - The board-level SDK can be adapted to OS interfaces via CMSIS and POSIX APIs. Currently, the LiteOS Cortex-M kernel is adapted to most CMSIS APIs \(including APIs used for basic kernel management, thread management, timer, event, mutex, semaphore, and queue\), which meets the requirements of porting. POSIX APIs provide basic capabilities for porting, and more POSIX APIs are to be implemented. If the SDK is implemented based on the CMSIS or POSIX APIs, it can directly adapt to the LiteOS Cortex-M kernel. + The board-level SDK can be adapted to OS interfaces via CMSIS and POSIX APIs. Currently, the LiteOS Cortex-M kernel is adapted to most CMSIS APIs \(including APIs used for basic kernel management, thread management, timer, event, mutex, semaphore, and queue\), which meets the requirements of porting. POSIX APIs provide basic capabilities for porting, and more POSIX APIs are to be implemented. If the SDK is implemented based on the CMSIS or POSIX APIs, it can directly adapt to the LiteOS Cortex-M kernel. - If the SDK is developed based on other embedded OSs such as FreeRTOS, or has an abstraction layer for OS interfaces, it is recommended that the OS-dependent APIs be directly adapted to the CMSIS APIs. + If the SDK is developed based on other embedded OSs such as FreeRTOS, or has an abstraction layer for OS interfaces, it is recommended that the OS-dependent APIs be directly adapted to the CMSIS APIs. - Here is an OS interface defined by a product for creating a queue: + Here is an OS interface defined by a product for creating a queue: - ``` - bool osif_msg_queue_create(void **pp_handle, uint32_t msg_num, uint32_t msg_size) - ``` + + ``` + bool osif_msg_queue_create(void **pp_handle, uint32_t msg_num, uint32_t msg_size) + ``` - The CMSIS API used for creating a queue is as follows: + The CMSIS API used for creating a queue is as follows: - ``` - osMessageQueueId_t osMessageQueueNew (uint32_t msg_count, uint32_t msg_size, const osMessageQueueAttr_t *attr); - ``` + + ``` + osMessageQueueId_t osMessageQueueNew (uint32_t msg_count, uint32_t msg_size, const osMessageQueueAttr_t *attr); + ``` - The following example shows how to adapt the OS interface to the CMSIS API: + The following example shows how to adapt the OS interface to the CMSIS API: - ``` - #include "CMSIS_os2.h" - osMessageQueueId_t osMessageQueueNew (uint32_t msg_count, uint32_t msg_size, const osMessageQueueAttr_t *attr); - bool osif_msg_queue_create(void **pp_handle, uint32_t msg_num, uint32_t msg_size) - { - (*pp_handle) = osMessageQueueNew (msg_num, msg_size, NULL); - if((*pp_handle) == NULL){ - return FALSE; - } - return TRUE; - } - ``` + + ``` + #include "CMSIS_os2.h" + osMessageQueueId_t osMessageQueueNew (uint32_t msg_count, uint32_t msg_size, const osMessageQueueAttr_t *attr); + bool osif_msg_queue_create(void **pp_handle, uint32_t msg_num, uint32_t msg_size) + { + (*pp_handle) = osMessageQueueNew (msg_num, msg_size, NULL); + if((*pp_handle) == NULL){ + return FALSE; + } + return TRUE; + } + ``` -2. Compile the SDK independently or modify the SDK based on the OpenHarmony building framework and integrate the SDK code into the **device** directory of OpenHarmony as required. +2. Compile the SDK independently or modify the SDK based on the OpenHarmony building framework and integrate the SDK code into the **device** directory of OpenHarmony as required. - After completing the OS API adaptation, you can integrate the board-level driver to OpenHarmony by the following two methods: + After completing the OS API adaptation, you can integrate the board-level driver to OpenHarmony by the following two methods: - - Compile the SDK independently and link it to the OpenHarmony project in the binary format. - - Modify the SDK building framework based on OpenHarmony. Considering the long-term evolution and subsequent joint debugging, you are advised to compile the SDK based on the GN building framework and link it to the OpenHarmony project in the form of source code. + - Compile the SDK independently and link it to the OpenHarmony project in the binary format. + - Modify the SDK building framework based on OpenHarmony. Considering the long-term evolution and subsequent joint debugging, you are advised to compile the SDK based on the GN building framework and link it to the OpenHarmony project in the form of source code. -3. Verify the basic functions of the SDK. +3. Verify the basic functions of the SDK. diff --git a/en/device-dev/porting/porting-chip-faqs.md b/en/device-dev/porting/porting-chip-faqs.md index 188747865c20ab9ce16bede0a7774c986cb827de..aad6bc08de69cd6a3cde844e7723cce4359a862b 100644 --- a/en/device-dev/porting/porting-chip-faqs.md +++ b/en/device-dev/porting/porting-chip-faqs.md @@ -1,37 +1,18 @@ -# FAQs +# FAQs -## How Do I Mount the Heap Memory to the Kernel? -- The following table describes the macros for configuring the kernel heap memory. You can configure them as required in the **target\_config.h** file. +## How Do I Mount the Heap Memory to the Kernel? -**Table 1** Macros for configuring the kernel heap memory +The following table describes the macros for configuring the kernel heap memory. You can configure them as required in the **target\_config.h** file. - - - - - - - - - - - - - - - -

Macro

-

Description

-

LOSCFG_SYS_EXTERNAL_HEAP

-

Specifies whether the internal kernel heap memory or the user heap memory will be used. The default value is 0 and indicates that the internal heap memory whose size is 0x10000 will be used. If you want to use the external heap memory, set this macro to 1.

-

LOSCFG_SYS_HEAP_ADDR

-

Specifies the start address of the kernel heap memory.

-

LOSCFG_SYS_HEAP_SIZE

-

Specifies the size of the kernel heap memory, that is, size of the memory block specified by LOSCFG_SYS_HEAP_ADDR.

-
+**Table 1** Macros for configuring the kernel heap memory -- Note: +| Macro | Description | +| -------- | -------- | +| LOSCFG_SYS_EXTERNAL_HEAP | Specifies whether the internal kernel heap memory or the user heap memory will be used. The default value is **0** and indicates that the internal heap memory whose size is **0x10000** will be used. If you want to use the external heap memory, set this macro to **1**. | +| LOSCFG_SYS_HEAP_ADDR | Specifies the start address of the kernel heap memory. | +| LOSCFG_SYS_HEAP_SIZE | Specifies the size of the kernel heap memory, that is, size of the memory block specified by **LOSCFG_SYS_HEAP_ADDR**. | -Ensure that the specified heap memory range is not used by other modules. Otherwise, functions of the heap memory will be damaged due to the heap memory corruption. +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> Ensure that the specified heap memory range is not used by other modules. Otherwise, functions of the heap memory will be damaged due to the heap memory corruption. diff --git a/en/device-dev/porting/porting-smallchip-kernel-a.md b/en/device-dev/porting/porting-smallchip-kernel-a.md index cfb6aab2b9b4b3924ad623c82eedafcf56fc6758..7a4b037f4f9682b186907ab528b335a580ac28ec 100644 --- a/en/device-dev/porting/porting-smallchip-kernel-a.md +++ b/en/device-dev/porting/porting-smallchip-kernel-a.md @@ -1,209 +1,97 @@ -# LiteOS Cortex-A +# LiteOS Cortex-A -## Overview +## Overview -### Porting Scenario +### 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 +### Directory Specifications For details about the LiteOS Cortex-A directory specifications, see [LiteOS Cortex-A Overview](https://gitee.com/openharmony/kernel_liteos_a). -## Adaptation Process +## 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: -1. 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. -2. 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. -3. If there are multiple cores, define **struct SmpOps**, the handle to the secondary core operation function. The **SmpOps-\>SmpCpuOn** function needs to implement the feature of waking up a secondary 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\)**. -4. Create a kernel image based on the linker script **board.ld**. -5. 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. -6. 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. -7. 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. +1. 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. +2. 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. +3. If there are multiple cores, define **struct SmpOps**, the handle to the secondary core operation function. The **SmpOps-\>SmpCpuOn** function needs to implement the feature of waking up a secondary 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\)**. +4. Create a kernel image based on the linker script **board.ld**. +5. 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. +6. 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. +7. 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 +**Figure 1** Overall initialization process ![](figures/overall-initialization-process.png "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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

OS_SYS_CLOCK

-

System cycle frequency

-

DDR_MEM_ADDR

-

Start address of the system memory

-

DDR_MEM_SIZE

-

Size of the system memory

-

PERIPH_PMM_BASE

-

Base address of the peripheral register

-

PERIPH_PMM_SIZE

-

Size of the peripheral register

-

OS_HWI_MIN

-

Minimum number of system interrupts

-

OS_HWI_MAX

-

Maximum number of system interrupts

-

NUM_HAL_INTERRUPT_UART0

-

UART0 interrupt ID

-

UART0_REG_BASE

-

UART0 register base address

-

GIC_BASE_ADDR

-

Base address of the GIC interrupt register

-

GICD_OFFSET

-

Offset address of the GICD relative to the GIC base address

-

GICC_OFFSET

-

Offset address of the GICC relative to the GIC base address

-
- -- Implementing the **SystemInit** function to initialize services in the user space. Figure 2 shows a typical initialization scenario. - - **Figure 2** Service startup process - ![](figures/service-startup-process.png "service-startup-process") +- 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 + + | Parameter | Description | + | ----------------------- | ----------------------------------------------------------- | + | OS_SYS_CLOCK | System cycle frequency | + | DDR_MEM_ADDR | Start address of the system memory | + | DDR_MEM_SIZE | Size of the system memory | + | PERIPH_PMM_BASE | Base address of the peripheral register | + | PERIPH_PMM_SIZE | Size of the peripheral register | + | OS_HWI_MIN | Minimum number of system interrupts | + | OS_HWI_MAX | Maximum number of system interrupts | + | NUM_HAL_INTERRUPT_UART0 | UART0 interrupt ID | + | UART0_REG_BASE | UART0 register base address | + | GIC_BASE_ADDR | Base address of the GIC interrupt register | + | GICD_OFFSET | Offset address of the GICD relative to the GIC base address | + | GICC_OFFSET | Offset address of the GICC relative to the GIC base address | + + + +- Implementing the **SystemInit** function to initialize services in the user space. Figure 2 shows a typical initialization scenario. + + **Figure 2** Service startup process + + ![](figures/service-startup-process.png "service-startup-process") - Implementing the **main** function for basic kernel initialization and initialization of services in the board kernel space. [Figure 3](#fig32611728133919) 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. - >![](../public_sys-resources/icon-caution.gif) **CAUTION:** + >![](../public_sys-resources/icon-caution.gif) **CAUTION** >Modules at the same layer cannot depend on each other. - **Figure 3** Kernel startup framework - ![](figures/kernel-startup-framework.jpg "kernel-startup-framework") - - **Table 2** Startup framework layers - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Layer

-

Description

-

LOS_INIT_LEVEL_EARLIEST

-

Earliest initialization.

-

This layer does not depend on the architecture. The board and subsequent modules, such as the Trace module, will initialize the software-only modules on which they depend.

-

LOS_INIT_LEVEL_ARCH_EARLY

-

Early initialization of the architecture.

-

This layer depends on the architecture. Subsequent modules will initialize the modules on which they depend. It is recommended that functions not required for startup be placed at the LOS_INIT_LEVEL_ARCH layer.

-

LOS_INIT_LEVEL_PLATFORM_EARLY

-

Early initialization of the platform.

-

This layer depends on the board platform and drivers. Subsequent modules will initialize the modules on which they depend. It is recommended that functions required for startup be placed at the LOS_INIT_LEVEL_PLATFORM layer.

-

Example: UART module

-

LOS_INIT_LEVEL_KMOD_PREVM

-

Kernel module initialization before memory initialization.

-

This layer involves initialization of the modules that need to be enabled before memory initialization.

-

LOS_INIT_LEVEL_VM_COMPLETE

-

Initialization after the basic memory is ready.

-

This layer involves initialization of the modules that need to be enabled and do not depend on the inter-process communication mechanism and system processes.

-

Example: shared memory function

-

LOS_INIT_LEVEL_ARCH

-

Late initialization of the architecture.

-

This layer depends on the architecture extension function. Subsequent modules will initialize the modules on which they depend.

-

LOS_INIT_LEVEL_PLATFORM

-

Late initialization of the platform.

-

This layer depends on the board platform and drivers. Subsequent modules will initialize the modules on which they depend.

-

Example: initialization of the driver kernel abstraction layer (MMC and MTD)

-

LOS_INIT_LEVEL_KMOD_BASIC

-

Initialization of the kernel basic modules.

-

This layer is used to initialize the basic modules that can be detached from the kernel.

-

Example: VFS initialization

-

LOS_INIT_LEVEL_KMOD_EXTENDED

-

Initialization of the kernel extended modules.

-

This layer is used to initialize the extended modules that can be detached from the kernel.

-

Example: system call initialization, ProcFS initialization, Futex initialization, HiLog initialization, HiEvent initialization, and LiteIPC initialization

-

LOS_INIT_LEVEL_KMOD_TASK

-

Kernel task creation.

-

This layer can be used to create kernel tasks (kernel thread and software timer tasks).

-

Example: creation of the resident resource reclaiming task, SystemInit task, and CPU usage statistics task

-
- + **Figure 3** Kernel startup framework + +![](figures/kernel-startup-framework.jpg "kernel-startup-framework") + +**Table 2** Startup framework layers + + | Layer | Description | + | ----------------------------- | ------------------------------------------------------------ | + | LOS_INIT_LEVEL_EARLIEST | Earliest initialization.
This layer does not depend on the architecture. The board and subsequent modules, such as the Trace module, will initialize the software-only modules on which they depend. | + | LOS_INIT_LEVEL_ARCH_EARLY | Early initialization of the architecture.
This layer depends on the architecture. Subsequent modules will initialize the modules on which they depend. It is recommended that functions not required for startup be placed at the **LOS_INIT_LEVEL_ARCH** layer. | + | LOS_INIT_LEVEL_PLATFORM_EARLY | Early initialization of the platform.
This layer depends on the board platform and drivers. Subsequent modules will initialize the modules on which they depend. It is recommended that functions required for startup be placed at the **LOS_INIT_LEVEL_PLATFORM** layer.
Example: UART module | + | LOS_INIT_LEVEL_KMOD_PREVM | Kernel module initialization before memory initialization.
This layer involves initialization of the modules that need to be enabled before memory initialization. | + | LOS_INIT_LEVEL_VM_COMPLETE | Initialization after the basic memory is ready.
This layer involves initialization of the modules that need to be enabled and do not depend on the inter-process communication mechanism and system processes.
Example: shared memory function | + | LOS_INIT_LEVEL_ARCH | Late initialization of the architecture.
This layer depends on the architecture extension function. Subsequent modules will initialize the modules on which they depend. | + | LOS_INIT_LEVEL_PLATFORM | Late initialization of the platform.
This layer depends on the board platform and drivers. Subsequent modules will initialize the modules on which they depend.
Example: initialization of the driver kernel abstraction layer (MMC and MTD) | + | LOS_INIT_LEVEL_KMOD_BASIC | Initialization of the kernel basic modules.
This layer is used to initialize the basic modules that can be detached from the kernel.
Example: VFS initialization | + | LOS_INIT_LEVEL_KMOD_EXTENDED | Initialization of the kernel extended modules.
This layer is used to initialize the extended modules that can be detached from the kernel.
Example: system call initialization, ProcFS initialization, Futex initialization, HiLog initialization, HiEvent initialization, and LiteIPC initialization | + | LOS_INIT_LEVEL_KMOD_TASK | Kernel task creation.
This layer can be used to create kernel tasks (kernel thread and software timer tasks).
Example: creation of the resident resource reclaiming task, SystemInit task, and CPU usage statistics task | + + + 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. - - >![](../public_sys-resources/icon-note.gif) **NOTE:** + + >![](../public_sys-resources/icon-note.gif) **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 +## Programming Example In the board SDK file: @@ -223,7 +111,7 @@ unsigned int OsSampleModInit(void) LOS_MODULE_INIT(OsSampleModInit, LOS_INIT_LEVEL_KMOD_EXTENDED); ``` -## Verification +## Verification ``` main core booting up... @@ -239,7 +127,7 @@ The system enters the kernel-space shell and the task commands can be properly e ``` OHOS # help -*******************shell commands:************************* +***shell commands:* arp cat cd chgrp chmod chown cp cpup date dhclient dmesg dns format free help hwi diff --git a/en/device-dev/porting/porting-thirdparty-cmake.md b/en/device-dev/porting/porting-thirdparty-cmake.md index 3ae6e23ff8382ef93fd1583487c433e468233695..a505a85d630b92ab4a53fea2a20897f03a1a6016 100755 --- a/en/device-dev/porting/porting-thirdparty-cmake.md +++ b/en/device-dev/porting/porting-thirdparty-cmake.md @@ -1,115 +1,49 @@ -# Porting a Library Built Using CMake +# Porting a Library Built Using CMake + The following shows how to port the double-conversion library. -## Source Code Acquisition +## Source Code Acquisition Acquire the source code of double-conversion from [https://github.com/google/double-conversion](https://github.com/google/double-conversion). The following table lists the directory structure. **Table 1** Directory structure of the source code - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Directory

-

Description

-

double-conversion/cmake/

-

Template used for building with CMake

-

double-conversion/double-conversion/

-

Directory of source files

-

double-conversion/msvc/

-

-

-

double-conversion/test/

-

Source files of the test cases

-

double-conversion/.gitignore

-

-

-

double-conversion/AUTHORS

-

-

-

double-conversion/BUILD

-

-

-

double-conversion/CMakeLists.txt

-

Top-level file used for building with CMake

-

double-conversion/COPYING

-

-

-

double-conversion/Changelog

-

-

-

double-conversion/LICENSE

-

-

-

double-conversion/Makefile

-

-

-

double-conversion/README.md

-

-

-

double-conversion/SConstruct

-

-

-

double-conversion/WORKSPACE

-

-

-
- -## Porting Guidelines +| Directory | Description | +| -------- | -------- | +| double-conversion/cmake/ | Template used for building with CMake | +| double-conversion/double-conversion/ | Directory of source files | +| double-conversion/msvc/ | - | +| double-conversion/test/ | Source files of the test cases | +| double-conversion/.gitignore | - | +| double-conversion/AUTHORS | - | +| double-conversion/BUILD | - | +| double-conversion/CMakeLists.txt | Top-level file used for building with CMake | +| double-conversion/COPYING | - | +| double-conversion/Changelog | - | +| double-conversion/LICENSE | - | +| double-conversion/Makefile | - | +| double-conversion/README.md | - | +| double-conversion/SConstruct | - | +| double-conversion/WORKSPACE | - | + +## Porting Guidelines Cross-compile the double-conversion library by modifying the toolchain to generate executable files for the OpenHarmony platform and then add these files to the OpenHarmony project by invoking CMake via GN. -## Cross-Compilation +## Cross-Compilation -### Compilation Reference +### Compilation Reference The [README.md](https://github.com/google/double-conversion/blob/master/README.md) file in the code repository details the procedures for compiling the double-conversion library using CMake as well as the testing methods. This document focuses on the building, compilation, and testing of the library. If you have any questions during library porting, refer to the **README.md** file. For porting of other third-party libraries that can be independently built with CMake, you can refer to the compilation guides provided by the libraries. -### Cross-Compilation Settings +### Cross-Compilation Settings The following steps show how to configure and modify the toolchains for cross-compiling the libraries built using CMake to compile executable files for the OpenHarmony platform. 1. Configure the toolchains. - Add configuration of the clang toolchains to the top-level file **CMakeLists.txt** listed in [Table 1](#table824211132418). + Add configuration of the clang toolchains to the top-level file **CMakeLists.txt** listed in Table 1. ``` set(CMAKE_CROSSCOMPILING TRUE) @@ -137,92 +71,45 @@ The following steps show how to configure and modify the toolchains for cross-co 2. Perform the compilation. - Run a Linux command to enter the directory \(listed in [Table 1](#table824211132418)\) for storing double-conversion source files and then run the following commands: - - ``` - mkdir build && cd build - cmake .. -DBUILD_TESTING=ON -DOHOS_SYSROOT_PATH="..." - make -j - ``` + Run a Linux command to enter the directory \(listed in Table 1) for storing double-conversion source files and then run the following commands: + + ``` + mkdir build && cd build + cmake .. -DBUILD_TESTING=ON -DOHOS_SYSROOT_PATH="..." + make -j + ``` **OHOS\_SYSROOT\_PATH** specifies the absolute path where **sysroot** is located. For OpenHarmony, set **OHOS\_SYSROOT\_PATH** to the absolute path of the **out/hispark\__xxx_/ipcamera\_hispark\__xxx_/sysroot** directory. This directory is generated after full compilation is complete. Therefore, complete full compilation before porting. -3. View the result. - - After step 2 is complete, a static library file and test cases are generated in the **build** directory. - - **Table 2** Directory structure of compiled files - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Directory

-

Description

-

double-conversion/build/libdouble-conversion.a

-

Static library file

-

double-conversion/build/test/

-

Test cases and CMake cache files

-

double-conversion/build/CMakeCache.txt

-

Cache files during CMake building

-

double-conversion/build/CMakeFiles/

-

-

-

double-conversion/build/cmake_install.cmake

-

-

-

double-conversion/build/CTestTestfile.cmake

-

-

-

double-conversion/build/DartConfiguration.tcl

-

-

-

double-conversion/build/generated/

-

-

-

double-conversion/build/Makefile

-

-

-

double-conversion/build/Testing/

-

-

-
- - -## Library Test +3. View the result. + After step 2 is complete, a static library file and test cases are generated in the **build** directory. + + **Table 2** Directory structure of compiled files + + | Directory | Description | + | -------- | -------- | + | double-conversion/build/libdouble-conversion.a | Static library file | + | double-conversion/build/test/ | Test cases and CMake cache files | + | double-conversion/build/CMakeCache.txt | Cache files during CMake building | + | double-conversion/build/CMakeFiles/ | - | + | double-conversion/build/cmake_install.cmake | - | + | double-conversion/build/CTestTestfile.cmake | - | + | double-conversion/build/DartConfiguration.tcl | - | + | double-conversion/build/generated/ | - | + | double-conversion/build/Makefile | - | + | double-conversion/build/Testing/ | - | + + + +## Library Test 1. Set up the OpenHarmony environment. - Using Hi3516D V300 as an example, compile the OpenHarmony image and burn it to the development board. For details, see [Developing the First Example Program Running on Hi3518](../quick-start/quickstart-lite-steps-hi3516-running.md). + Using Hi3516D V300 as an example, compile the OpenHarmony image and burn it to the development board. For details, see [Developing the First Example Program Running on Hi3518](../quick-start/quickstart-lite-steps-hi3516-running.md). The following screen is displayed after a successful login to the OS. - **Figure 1** Successful startup of OpenHarmony + **Figure 1** Successful startup of OpenHarmony ![](figures/successful-startup-of-openharmony.png "successful-startup-of-openharmony") 2. Mount the **nfs** directory and put the executable file **cctest** into the **test** directory \(listed in [Table 2](#table1452412391911)\) to the **nfs** directory. @@ -231,53 +118,56 @@ The following steps show how to configure and modify the toolchains for cross-co If the double-conversion library is not cross-compiled, you can execute the test cases by running the **make test** command and obtain the result via CMake. However, this command is not applicable to the library after cross-compilation. This way, you can perform the test cases by executing the generated test case files. - After the **nfs** directory is successfully mounted, run the following command to list all items in the test cases: - - ``` - cd nfs - ./cctest --list - ``` + + ``` + cd nfs + ./cctest --list + ``` Some items are as follows: - ``` - test-bignum/Assign< - test-bignum/ShiftLeft< - test-bignum/AddUInt64< - test-bignum/AddBignum< - test-bignum/SubtractBignum< - test-bignum/MultiplyUInt32< - test-bignum/MultiplyUInt64< - test-bignum/MultiplyPowerOfTen< - test-bignum/DivideModuloIntBignum< - test-bignum/Compare< - test-bignum/PlusCompare< - test-bignum/Square< - test-bignum/AssignPowerUInt16< - test-bignum-dtoa/BignumDtoaVariousDoubles< - test-bignum-dtoa/BignumDtoaShortestVariousFloats< - test-bignum-dtoa/BignumDtoaGayShortest< - test-bignum-dtoa/BignumDtoaGayShortestSingle< - test-bignum-dtoa/BignumDtoaGayFixed< - test-bignum-dtoa/BignumDtoaGayPrecision< - test-conversions/DoubleToShortest< - test-conversions/DoubleToShortestSingle< - ... - ``` + + ``` + test-bignum/Assign< + test-bignum/ShiftLeft< + test-bignum/AddUInt64< + test-bignum/AddBignum< + test-bignum/SubtractBignum< + test-bignum/MultiplyUInt32< + test-bignum/MultiplyUInt64< + test-bignum/MultiplyPowerOfTen< + test-bignum/DivideModuloIntBignum< + test-bignum/Compare< + test-bignum/PlusCompare< + test-bignum/Square< + test-bignum/AssignPowerUInt16< + test-bignum-dtoa/BignumDtoaVariousDoubles< + test-bignum-dtoa/BignumDtoaShortestVariousFloats< + test-bignum-dtoa/BignumDtoaGayShortest< + test-bignum-dtoa/BignumDtoaGayShortestSingle< + test-bignum-dtoa/BignumDtoaGayFixed< + test-bignum-dtoa/BignumDtoaGayPrecision< + test-conversions/DoubleToShortest< + test-conversions/DoubleToShortestSingle< + ... + ``` - Run the following command to test **test-bignum**: - ``` - ./cctest test-bignum - ``` + + ``` + ./cctest test-bignum + ``` The test is passed if the following information is displayed: - ``` - Ran 13 tests. - ``` + + ``` + Ran 13 tests. + ``` -## Adding the Compiled double-conversion Library to the OpenHarmony Project +## Adding the Compiled double-conversion Library to the OpenHarmony Project 1. Copy the double-conversion library to the OpenHarmony project. @@ -285,142 +175,118 @@ The following steps show how to configure and modify the toolchains for cross-co **Table 3** Directory structure of the ported library - - - - - - - - - - - - - - - - - - -

Directory

-

Description

-

openHarmony/third_party/double-conversion/BUILD.gn

-

GN file for adding the third-party library to the OpenHarmony project

-

openHarmony/third_party/double-conversion/build_thirdparty.py

-

Script file for GN to call the shell command to convert compilation from GN to CMake.

-

openHarmony/third_party/double-conversion/config.gni

-

Third-party library compilation configuration file, which can be modified to determine whether the test cases will be used during the building

-

openHarmony/third_party/double-conversion/double-conversion/

-

Directory of the third-party library to be ported

-
- -2. Add the GN file to the CMake adaptation file. - - - The following shows the implementation for building using the newly added **BUILD.gn** file. For other third-party libraries that can be independently compiled using CMake, you only need to change the target paths when porting them to OpenHarmony. - - ``` - import("config.gni") - group("double-conversion") { - if (ohos_build_thirdparty_migrated_from_fuchisa == true) { - deps = [":make"] - } - } - if (ohos_build_thirdparty_migrated_from_fuchisa == true) { - action("make") { - script = "//third_party/double-conversion/build_thirdparty.py" - outputs = ["$root_out_dir/log_dc.txt"] - exec_path = rebase_path(rebase_path("./build", ohos_third_party_dir)) - command = "rm * .* -rf && $CMAKE_TOOLS_PATH/cmake .. $CMAKE_FLAG $CMAKE_TOOLCHAIN_FLAG && make -j" - args = [ - "--path=$exec_path", - "--command=${command}" - ] - } - } - ``` - - - The newly added **config.gni** file is used to configure the library in the following example implementation. For other third-party libraries that can be independently compiled using CMake, you only need to change the configuration of **CMAKE\_FLAG** when porting them to OpenHarmony. - - ``` - #CMAKE_FLAG: config compile feature - CMAKE_FLAG = "-DBUILD_TESTING=ON -DCMAKE_CXX_STANDARD=11" - - #toolchain: follow up-layer, depend on $ohos_build_compiler - if (ohos_build_compiler == "clang") { - CMAKE_TOOLCHAIN_FLAG = "-DOHOS_SYSROOT_PATH=${root_out_dir}sysroot/" - } else { - CMAKE_TOOLCHAIN_FLAG = "" - } - - #CMake tools path,no need setting if this path already joined to $PATH. - CMAKE_TOOLS_PATH = "setting CMake tools path..." - ``` - - - The following shows the implementation of the newly added **build\_thirdparty.py** file. For other third-party libraries that can be independently compiled using CMake, you can port them to OpenHarmony without modifications. - - ``` - import os - import sys - from subprocess import Popen - import argparse - import shlex - - def cmd_exec(command): - cmd = shlex.split(command) - proc = Popen(cmd) - proc.wait() - ret_code = proc.returncode - if ret_code != 0: - raise Exception("{} failed, return code is {}".format(cmd, ret_code)) - - def main(): - parser = argparse.ArgumentParser() - parser.add_argument('--path', help='Build path.') - parser.add_argument('--command', help='Build command.') - parser.add_argument('--enable', help='enable python.', nargs='*') - args = parser.parse_args() - - if args.enable: - if args.enable[0] == 'false': - return - - if args.path: - curr_dir = os.getcwd() - os.chdir(args.path) - if args.command: - if '&&' in args.command: - command = args.command.split('&&') - for data in command: - cmd_exec(data) - else: - cmd_exec(args.command) - os.chdir(curr_dir) - - if __name__ == '__main__': - sys.exit(main()) - ``` - - - Add a configuration item in the configuration file to control compiling of the library. By default, library compilation is disabled. - - For example, add the following configuration to the **//build/lite/ohos\_var.gni** file: - - ``` - declare_args() { - ohos_build_thirdparty_migrated_from_fuchisa = true - } - ``` - -3. Build the library. - - - Manual building - - Execute the following command: - - ``` - hb build -T //third_party/double-conversion:double-conversion - ``` - - If the compilation is successful, a static library file and test cases will be generated in the [build](#li15717101715249) directory. + | Directory | Description | + | -------- | -------- | + | OpenHarmony/third_party/double-conversion/BUILD.gn | GN file for adding the third-party library to the OpenHarmony project | + | OpenHarmony/third_party/double-conversion/build_thirdparty.py | Script file for GN to call the **shell** command to convert compilation from GN to CMake | + | OpenHarmony/third_party/double-conversion/config.gni | Third-party library compilation configuration file, which can be modified to determine whether the test cases will be used during the building | + | OpenHarmony/third_party/double-conversion/double-conversion/ | Directory of the third-party library to be ported | + +2. Add the GN file to the CMake adaptation file. + + - The following shows the implementation for building using the newly added **BUILD.gn** file. For other third-party libraries that can be independently compiled using CMake, you only need to change the target paths when porting them to OpenHarmony. + + ``` + import("config.gni") + group("double-conversion") { + if (ohos_build_thirdparty_migrated_from_fuchisa == true) { + deps = [":make"] + } + } + if (ohos_build_thirdparty_migrated_from_fuchisa == true) { + action("make") { + script = "//third_party/double- conversion/build_thirdparty.py" + outputs = ["$root_out_dir/log_dc.txt"] + exec_path = rebase_path(rebase_path("./build", ohos_third_party_dir)) + command = "rm * .* -rf && $CMAKE_TOOLS_PATH/cmake .. $CMAKE_FLAG $CMAKE_TOOLCHAIN_FLAG && make -j" + args = [ + "--path=$exec_path", + "--command=${command}" + ] + } + } + ``` + + - The newly added **config.gni** file is used to configure the library in the following example implementation. For other third-party libraries that can be independently compiled using CMake, you only need to change the configuration of **CMAKE\_FLAG** when porting them to OpenHarmony. + + ``` + #CMAKE_FLAG: config compile feature + CMAKE_FLAG = "-DBUILD_TESTING=ON -DCMAKE_CXX_STANDARD=11" + + #toolchain: follow up-layer, depend on $ohos_build_compiler + if (ohos_build_compiler == "clang") { + CMAKE_TOOLCHAIN_FLAG = "- DOHOS_SYSROOT_PATH=${root_out_dir}sysroot/" + } else { + CMAKE_TOOLCHAIN_FLAG = "" + } + + #CMake tools path,no need setting if this path already joined to $PATH. + CMAKE_TOOLS_PATH = "setting CMake tools path..." + ``` + + - The following shows the implementation of the newly added **build\_thirdparty.py** file. For other third-party libraries that can be independently compiled using CMake, you can port them to OpenHarmony without modifications. + + + ``` + import os + import sys + from subprocess import Popen + import argparse + import shlex + + def cmd_exec(command): + cmd = shlex.split(command) + proc = Popen(cmd) + proc.wait() + ret_code = proc.returncode + if ret_code != 0: + raise Exception("{} failed, return code is {}".format(cmd, ret_code)) + + def main(): + parser = argparse.ArgumentParser() + parser.add_argument('--path', help='Build path.') + parser.add_argument('--command', help='Build command.') + parser.add_argument('--enable', help='enable python.', nargs='*') + args = parser.parse_args() + + if args.enable: + if args.enable[0] == 'false': + return + + if args.path: + curr_dir = os.getcwd() + os.chdir(args.path) + if args.command: + if '&&' in args.command: + command = args.command.split('&&') + for data in command: + cmd_exec(data) + else: + cmd_exec(args.command) + os.chdir(curr_dir) + + if __name__ == '__main__': + sys.exit(main()) + ``` + + - Add a configuration item in the configuration file to control compiling of the library. By default, library compilation is disabled. + + For example, add the following configuration to the **//build/lite/ohos\_var.gni** file: + + ``` + declare_args() { + ohos_build_thirdparty_migrated_from_fuchisa = true + } + ``` + +3. Build the library. + + Execute the following command: + + ``` +hb build -T //third_party/double-conversion:double-conversion + ``` + + If the compilation is successful, a static library file and test cases will be generated in the [build](#li15717101715249) directory. diff --git a/en/device-dev/porting/standard-system-porting-guide.md b/en/device-dev/porting/standard-system-porting-guide.md index 27067313ed3dc72b7a87a539e4311c6f52bc3d2e..acb5bc801f924567ca170acf6ead0f997c799f2c 100644 --- a/en/device-dev/porting/standard-system-porting-guide.md +++ b/en/device-dev/porting/standard-system-porting-guide.md @@ -87,7 +87,7 @@ After the build is complete, you can view the built image file in **//out/{*devi Now, you need to port the Linux kernel to enable it to run successfully. -### 1. Adding a Kernel-built Subsystem to the SoC +### Adding a Kernel-built Subsystem to the SoC Add the following subsystem configuration to the **//build/subsystem_config.json** file: @@ -104,7 +104,7 @@ Add the following subsystem configuration to the **//build/subsystem_config.json Then, open the configuration file **//vendor/MyProductVendor/MyProduct/config.json** and add the new subsystem to the product. -### 2. Building the Kernel +### Building the Kernel The OpenHarmony source code provides the Linux kernel 4.19, which is archived in **//kernel/linux-4.19**. This section uses this kernel version as an example to describe how to build the kernel. @@ -132,7 +132,7 @@ The expected build result described in the table below. | $root_build_dir/packages/phone/images/uboot | Bootloader image.| -### 3. Verifying the Porting +### Verifying the Porting Now start build, and check whether the kernel image is generated as expected. @@ -166,7 +166,7 @@ Now start build, and check whether the kernel image is generated as expected. ## Porting the HDF Driver -### 1. LCD +### LCD This section describes how to port a Liquid Crystal Display (LCD) driver. The hardware driver framework (HDF) designs a driver model for the LCD. To support an LCD, you must compile a driver, generate a model instance in the driver, and register the instance. @@ -220,7 +220,7 @@ root { For details about driver development, see [LCD](../driver/driver-peripherals-lcd-des.md). -### 2. Touchscreen +### Touchscreen This section describes how to port a touchscreen driver. The touchscreen driver is stored in the **//drivers/framework/model/input/driver/touchscreen** directory. To port a touchscreen driver, register a **ChipDevice** model instance. @@ -280,7 +280,7 @@ Implement the following APIs in **ChipDevice**: For details about driver development, see [Touchscreen](../driver/driver-peripherals-touch-des.md). -### 3. WLAN +### WLAN The WLAN driver is divided into two parts. One of the parts manages WLAN devices, and the other part manages WLAN traffic. HDF WLAN provides abstraction for the two parts. Currently, only the WLAN with the SDIO interface is supported.