|HiHope HH-SCDAYU200| RK3568 |Function description:<br>Bolstered by the Rockchip RK3568, the HH-SCDAYU200 development board integrates the dual-core GPU and efficient NPU. Its quad-core 64-bit Cortex-A55 processor uses the advanced 22 nm fabrication process and is clocked at up to 2.0 GHz. The board is packed with Bluetooth, Wi-Fi, audio, video, and camera features, with a wide range of expansion ports to accommodate various video input and outputs. It comes with dual GE auto-sensing RJ45 ports, so it can be used in multi-connectivity products, such as network video recorders (NVRs) and industrial gateways.<br>Use case:<br>[DAYU200 Adaptation Case](porting/porting-dayu200-on_standard-demo.md)|Entertainment, easy travel, and smart home, such as kitchen hoods, ovens, and treadmills.|Code repositories:<br>[device_soc_rockchip](https://gitee.com/openharmony/device_soc_rockchip)<br>[device_board_hihope](https://gitee.com/openharmony/device_board_hihope)<br>[vendor_hihope](https://gitee.com/openharmony/vendor_hihope)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|HiHope HH-SCDAYU200| RK3568 |Function description:<br>Bolstered by the Rockchip RK3568, the HH-SCDAYU200 development board integrates the dual-core GPU and efficient NPU. Its quad-core 64-bit Cortex-A55 processor uses the advanced 22 nm fabrication process and is clocked at up to 2.0 GHz. The board is packed with Bluetooth, Wi-Fi, audio, video, and camera features, with a wide range of expansion ports to accommodate various video input and outputs. It comes with dual GE auto-sensing RJ45 ports, so it can be used in multi-connectivity products, such as network video recorders (NVRs) and industrial gateways.<br>Use case:<br>DAYU200 Adaptation Case|Entertainment, easy travel, and smart home, such as kitchen hoods, ovens, and treadmills.|Code repositories:<br>[device_soc_rockchip](https://gitee.com/openharmony/device_soc_rockchip)<br>[device_board_hihope](https://gitee.com/openharmony/device_board_hihope)<br>[vendor_hihope](https://gitee.com/openharmony/vendor_hihope)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|Hispark_Phoenix|Hi3751V351|Function description:<br>Hi3751 V351 is a main processor designed for FHD smart televisions, conforming to a wide range of global television standards. It supports NTSC/PAL/SECAM demodulation, DTMB/DVB-C/ATSC/ISDB-T demodulation, and DVB-T/T2/S/S2 extension. The SoC running AOSP has a built-in multi-core Arm Cortex-A53 CPU, multi-core Arm Mali-T450 GPU, and 1 GB DDR SDRAM. It can handle USB playback, video formats such as MPEG2, H.264, H.265, RMVB, and AVS+, as well as audio decoding and sound processing [including in-house super wide sound (SWS) processing]. It also supports CVBS/YPbPr/VGA/HDMI 1.4/USB inputs, LVDS/mini-LVDS interfaces, and mainstream TCONLESS panels.|Smart TVs, smart home central control screens, smart displays, commercial display advertising screens, interactive whiteboards, industrial control screens, printer screens, white good screens, and fitness device display screens.|Code repositories:<br>[device_soc_hisilicon](https://gitee.com/openharmony/device_soc_hisilicon)<br>[device_board_hisilicon](https://gitee.com/openharmony/device_board_hisilicon)<br>[vendor_hisilicon](https://gitee.com/openharmony/vendor_hisilicon)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds|
|Unionpi Tiger|Amlogic A311D|Function description:<br>Unionpi Tiger is a piece of intelligent hardware used in scenarios such as image processing, audio and video processing, and deep learning. Its main processor Amlogic A311D supports the GPU and neural network acceleration subsystem, 4K video codec engine, industry-leading HDR image processing, and all standards-based audio/video input/output interfaces. The CPU of the active system uses the big-core and small-core design with a clock speed of up to 2.2 GHz. It integrates four Cortex-A73 cores, two Cortex-A53 cores, and a standalone 5.0T NPU.|Smart home, AI facial recognition, industrial control, smart vehicle-mounted devices, multimedia processing, and AI edge computing.|Code repositories:<br>[device_soc_amlogic](https://gitee.com/openharmony/device_soc_amlogic)<br>[device_board_unionman](https://gitee.com/openharmony/device_board_unionman)<br>[vendor_unionman](https://gitee.com/openharmony/vendor_unionman)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds|
|MILOS_Standard0|NXP i.MX8M Mini|Function description:<br>MILOS_Standard0 is powered by the NXP i.MX8M Mini processor and clocked at up to 1.8 GHz. It integrates a wide range of peripheral input and output ports, including LVDS, MIPI-DSI output, and MIPI-CSI camera ports, as well as GE, multi-channel USB, and multi-serial communications ports.|High-performance instruments and meters (industry and medical care), industrial control and human-machine interaction devices, intelligent transportation, smart fire fighting, and smart buildings.|Code repositories:<br>[device_soc_nxp](https://gitee.com/openharmony/device_soc_nxp)<br>[device_board_osware](https://gitee.com/openharmony/device_board_osware)<br>[vendor_osware](https://gitee.com/openharmony/vendor_osware)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds|
...
...
@@ -18,7 +18,7 @@ Currently, the OpenHarmony community supports 17 types of development boards, as
| Board Model| Chip Model| Function Description and Use Case| Application Scenario| Code Repository and Daily Build|
|Hispark_Taurus|Hi3516DV300|Function description:<br>Hi3516D V300 is the next-generation system on chip (SoC) for smart HD IP cameras. It integrates the next-generation image signal processor (ISP), H.265 video compression encoder, and high-performance NNIE engine, and delivers high performance in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption.|Smart devices with screens, such as refrigerators with screens and head units.|Code repositories:<br>[device_soc_hisilicon](https://gitee.com/openharmony/device_soc_hisilicon)<br>[device_board_hisilicon](https://gitee.com/openharmony/device_board_hisilicon)<br>[vendor_hisilicon](https://gitee.com/openharmony/vendor_hisilicon)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds|
|BearPi-HM Micro|STM32MP157A|Function description:<br>The BearPi-HM Micro development board is equipped with the STM32MP157 chip, works with a 4.3-inch LCD capacitive touchscreen, and comes with Wi-Fi circuits and standards-based E53 interfaces. The E53 interfaces can be used to connect to smart humidifiers, smart desk lamps, smart security facilities, and intelligent smoke detectors.<br>Use case:<br>[BearPi-HM Mircro Adaptation Case](porting/porting-stm32mp15xx-on-smallsystem.md)|Smart home, smart hardware, and central control screens.|Code repositories:<br>[device_soc_st](https://gitee.com/openharmony/device_soc_st)<br>[device_board_bearpi](https://gitee.com/openharmony/device_board_bearpi)<br>[vendor_bearpi](https://gitee.com/openharmony/vendor_bearpi)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|BearPi-HM Micro|STM32MP157A|Function description:<br>The BearPi-HM Micro development board is equipped with the STM32MP157 chip, works with a 4.3-inch LCD capacitive touchscreen, and comes with Wi-Fi circuits and standards-based E53 interfaces. The E53 interfaces can be used to connect to smart humidifiers, smart desk lamps, smart security facilities, and intelligent smoke detectors.<br>Use case:<br>BearPi-HM Mircro Adaptation Case|Smart home, smart hardware, and central control screens.|Code repositories:<br>[device_soc_st](https://gitee.com/openharmony/device_soc_st)<br>[device_board_bearpi](https://gitee.com/openharmony/device_board_bearpi)<br>[vendor_bearpi](https://gitee.com/openharmony/vendor_bearpi)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
## Mini-System Development Boards
...
...
@@ -28,8 +28,8 @@ Currently, the OpenHarmony community supports 17 types of development boards, as
|Multi-modal V200Z-R|BES2600|Function description:<br>The multi-modal V200Z-R development board is a high-performance, multi-functional, and cost-effective AIoT SoC powered by the BES2600WM chip of Bestechnic. It integrates a quad-core Arm processor with a frequency of up to 1 GHz as well as dual-mode Wi-Fi and dual-mode Bluetooth. The board supports the 802.11 a/b/g/n/ and BT/BLE 5.2 standards. It is able to accommodate RAM of up to 42 MB and flash memory of up to 32 MB, and supports the MIPI display serial interface (DSI) and camera serial interface (CSI). It is applicable to various AIoT multi-modal VUI and GUI interaction scenarios.<br>Use case:<br>[Multi-modal V200Z-R Adaptation Case](porting/porting-bes2600w-on-minisystem-display-demo.md)|Smart hardware, and smart devices with screens, such as speakers and watches.|Code repositories:<br>[device_soc_bestechnic](https://gitee.com/openharmony/device_soc_bestechnic)<br>[device_board_fnlink](https://gitee.com/openharmony/device_board_fnlink)<br>[vendor_bestechnic](https://gitee.com/openharmony/vendor_bestechnic)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|Langguo LANGO200|ASR582X|Function description:<br>The LANGO200 IoT development board integrates the high-performance WiFi-BLE dual-mode chip ASR5822, external storage chip, voice playing chip, and analog-to-digital converter. It supports common peripheral interfaces like SPI, and can be connected to an external OLED display and infrared remote control.<br>Use case:<br>[LANGO200 Adaptation Case](porting/porting-asr582x-combo-demo.md)|Connection modules for smart home products.|Code repositories:<br>[device_soc_asrmicro](https://gitee.com/openharmony/device_soc_asrmicro)<br>[device_board_lango](https://gitee.com/openharmony/device_board_lango)<br>[vendor_asrmicro](https://gitee.com/openharmony/vendor_asrmicro)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|Goodix GR5515-STARTER-KIT|GR5515|Function description:<br>The GR5515-STARTER-KIT development board is a Bluetooth 5.1-capable single-mode Bluetooth low energy (BLE) SoC and comes with multifunctional keys and LED indicators.|Smart hardware, such as watches, wristbands, and price tags.|Code repositories:<br>[device_soc_goodix](https://gitee.com/openharmony/device_soc_goodix)<br>[device_board_goodix](https://gitee.com/openharmony/device_board_goodix)<br>[vendor_goodix](https://gitee.com/openharmony/vendor_goodix)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds|
|Niobe407|STM32F407IGT6|Function description:<br>The Niobe407 development board is powered by the STM32F407 chip, which integrates the Arm Cortex-M4 CPU with the FPU and adaptive real-time accelerator and is cloced at up to 168 MHz.<br>Use case:<br>[Niobe407 Adaptation Case](porting/porting-stm32f407-on-minisystem-eth.md)|Smart transportation and industrial control.|Code repositories:<br>[device_soc_st](https://gitee.com/openharmony/device_soc_st)<br>[device_board_talkweb](https://gitee.com/openharmony/device_board_talkweb)<br>[vendor_talkweb](https://gitee.com/openharmony/vendor_talkweb)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|Niobe407|STM32F407IGT6|Function description:<br>The Niobe407 development board is powered by the STM32F407 chip, which integrates the Arm Cortex-M4 CPU with the FPU and adaptive real-time accelerator and is cloced at up to 168 MHz.<br>Use case:<br>Niobe407 Adaptation Case|Smart transportation and industrial control.|Code repositories:<br>[device_soc_st](https://gitee.com/openharmony/device_soc_st)<br>[device_board_talkweb](https://gitee.com/openharmony/device_board_talkweb)<br>[vendor_talkweb](https://gitee.com/openharmony/vendor_talkweb)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|B91 Generic Starter Kit|TLSR9x|Function description:<br>The B91 Generic Starter Kit developed by Telink is a hardware platform that can be used to evaluate TLSR9 chipsets. You can leverage it to develop applications that comply with the 2.4 GHz interface standards, such as BLE, BLE Mesh, Zigbee 3.0, Thread, and 2.4 GHz proprietary protocols.|Connection modules for smart home products.|Code repositories:<br>[device_soc_telink](https://gitee.com/openharmony/device_soc_telink)<br>[device_board_telink](https://gitee.com/openharmony/device_board_telink)<br>[vendor_telink](https://gitee.com/openharmony/vendor_telink)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds|
|cst85_wblink|cst85f01|Function description:<br>The cst85_wblink development board is a high-performance, multi-functional, and cost-effective AIoT SoC development board developed by CHIPSEA based on the cst85f01 chip. The cst85_wblink development board integrates dual-band Wi-Fi and dual-mode Bluetooth and supports standard 802.11 a/b/g/n protocols and Bluetooth/BLE 5.0 protocols. It comes in multiple memory flavors, with up to 992 KB of RAM and up to 16 MB of flash memory. In addition, it supports MIPI DSI and CSI, which makes it a great choice for developing Wi-Fi and Bluetooth applications for IoT and smart devices.<br>Use case:<br>[cst85_wblink Adaptation Case](porting/porting-cst85f01-combo-demo.md)|IoT and smart home.|Code repositories:<br>[device_soc_chipsea](https://gitee.com/openharmony/device_soc_chipsea)<br>[device_board_chipsea](https://gitee.com/openharmony/device_board_chipsea)<br>[vendor_chipsea](https://gitee.com/openharmony/vendor_chipsea)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|Neptune100| W800 |Function description:<br>Based on the WinnerMicro W800 chip, the Neptune 100 development board is a Wi-Fi & Bluetooth dual-mode SoC development board. It supports the standard 802.11 b/g/n protocols and has a complete built-in TCP/IP protocol stack. Its built-in Bluetooth baseband processor supports the Bluetooth/BLE4.2 protocols. It provides various digital interfaces, including the built-in QFlash, SPI, UART, GPIO, I2C, I2S and 7816 interfaces. The development board provides reliable security with support for a wide array of security features: hardware encryption and decryption algorithms, built-in DSP, floating-point arithmetic unit, security engine, code security permission configuration, built-in 2 MB flash memory, firmware encryption storage, firmware signature, secure debugging, and secure upgrade.<br>Use case:<br>[Neptune 100 Adaptation Case](porting/porting-w800-combo-demo.md)|IoT, smart home, and connection products.|Code repositories:<br>[device_soc_winnermicro](https://gitee.com/openharmony/device_soc_winnermicro)<br>[device_board_hihope](https://gitee.com/openharmony/device_board_hihope)<br>[vendor_hihope](https://gitee.com/openharmony/vendor_hihope)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|cst85_wblink|cst85f01|Function description:<br>The cst85_wblink development board is a high-performance, multi-functional, and cost-effective AIoT SoC development board developed by CHIPSEA based on the cst85f01 chip. The cst85_wblink development board integrates dual-band Wi-Fi and dual-mode Bluetooth and supports standard 802.11 a/b/g/n protocols and Bluetooth/BLE 5.0 protocols. It comes in multiple memory flavors, with up to 992 KB of RAM and up to 16 MB of flash memory. In addition, it supports MIPI DSI and CSI, which makes it a great choice for developing Wi-Fi and Bluetooth applications for IoT and smart devices.<br>Use case:<br>cst85_wblink Adaptation Case|IoT and smart home.|Code repositories:<br>[device_soc_chipsea](https://gitee.com/openharmony/device_soc_chipsea)<br>[device_board_chipsea](https://gitee.com/openharmony/device_board_chipsea)<br>[vendor_chipsea](https://gitee.com/openharmony/vendor_chipsea)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|Neptune100| W800 |Function description:<br>Based on the WinnerMicro W800 chip, the Neptune 100 development board is a Wi-Fi & Bluetooth dual-mode SoC development board. It supports the standard 802.11 b/g/n protocols and has a complete built-in TCP/IP protocol stack. Its built-in Bluetooth baseband processor supports the Bluetooth/BLE4.2 protocols. It provides various digital interfaces, including the built-in QFlash, SPI, UART, GPIO, I2C, I2S and 7816 interfaces. The development board provides reliable security with support for a wide array of security features: hardware encryption and decryption algorithms, built-in DSP, floating-point arithmetic unit, security engine, code security permission configuration, built-in 2 MB flash memory, firmware encryption storage, firmware signature, secure debugging, and secure upgrade.<br>Use case:<br>Neptune 100 Adaptation Case|IoT, smart home, and connection products.|Code repositories:<br>[device_soc_winnermicro](https://gitee.com/openharmony/device_soc_winnermicro)<br>[device_board_hihope](https://gitee.com/openharmony/device_board_hihope)<br>[vendor_hihope](https://gitee.com/openharmony/vendor_hihope)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
|RK2206| RK2206 |Function description:<br>The RK2206 development board uses the high-performance and cost-effective RK2206 chip as its main control board. It runs the OpenHarmony mini system and provides built-in Wi-Fi/AP and NFC features as well as LCD and E53 interfaces. The E53 interfaces are compatible with various sensor modules, facilitating diversified IoT applications. The RK2006 development board has been deployed in more than 20 mature use cases and demonstrated in comprehensive courseware.|Smart city, smart home, smart teaching, smart vehicle-mounted devices, and smart healthcare.|Code repositories:<br>[device_soc_rockchip](https://gitee.com/openharmony/device_soc_rockchip)<br>[device_board_lockzhiner](https://gitee.com/openharmony/device_board_lockzhiner)<br>[vendor_lockzhiner](https://gitee.com/openharmony/vendor-lockzhiner)<br>Daily build:<br>http://ci.openharmony.cn/dailys/dailybuilds |
@@ -17,12 +17,12 @@ LiteOS Cortex-A provides the system initialization process and custom configurat
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.
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.
...
...
@@ -52,43 +52,44 @@ As can be seen from preceding figure, kernel basic adaptation involves the follo
- Implementing the **SystemInit** function to initialize services in the user space. Figure 2 shows a typical initialization scenario.
- 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](#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.
- 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.
| LOS_INIT_LEVEL_EARLIEST | Earliest initialization.<br>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.<br/>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.<br/>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.<br/>Example: UART module |
| LOS_INIT_LEVEL_KMOD_PREVM | Kernel module initialization before memory initialization.<br/>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.<br/>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.<br/>Example: shared memory function |
| LOS_INIT_LEVEL_ARCH | Late initialization of the architecture.<br/>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.<br/>This layer depends on the board platform and drivers. Subsequent modules will initialize the modules on which they depend.<br/>Example: initialization of the driver kernel abstraction layer (MMC and MTD) |
| LOS_INIT_LEVEL_KMOD_BASIC | Initialization of the kernel basic modules.<br/>This layer is used to initialize the basic modules that can be detached from the kernel.<br/>Example: VFS initialization |
| LOS_INIT_LEVEL_KMOD_EXTENDED | Initialization of the kernel extended modules.<br/>This layer is used to initialize the extended modules that can be detached from the kernel.<br/>Example: system call initialization, ProcFS initialization, Futex initialization, HiLog initialization, HiEvent initialization, and LiteIPC initialization |
| LOS_INIT_LEVEL_KMOD_TASK | Kernel task creation.<br/>This layer can be used to create kernel tasks (kernel thread and software timer tasks).<br/>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.
| LOS_INIT_LEVEL_EARLIEST | Earliest initialization.<br>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.<br/>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.<br/>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.<br/>Example: UART module |
| LOS_INIT_LEVEL_KMOD_PREVM | Kernel module initialization before memory initialization.<br/>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.<br/>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.<br/>Example: shared memory function |
| LOS_INIT_LEVEL_ARCH | Late initialization of the architecture.<br/>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.<br/>This layer depends on the board platform and drivers. Subsequent modules will initialize the modules on which they depend.<br/>Example: initialization of the driver kernel abstraction layer (MMC and MTD) |
| LOS_INIT_LEVEL_KMOD_BASIC | Initialization of the kernel basic modules.<br/>This layer is used to initialize the basic modules that can be detached from the kernel.<br/>Example: VFS initialization |
| LOS_INIT_LEVEL_KMOD_EXTENDED | Initialization of the kernel extended modules.<br/>This layer is used to initialize the extended modules that can be detached from the kernel.<br/>Example: system call initialization, ProcFS initialization, Futex initialization, HiLog initialization, HiEvent initialization, and LiteIPC initialization |
| LOS_INIT_LEVEL_KMOD_TASK | Kernel task creation.<br/>This layer can be used to create kernel tasks (kernel thread and software timer tasks).<br/>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.
>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.
>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.
@@ -79,93 +79,95 @@ The following steps show how to configure and modify the toolchains for cross-co
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.
**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.
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.
The following screen is displayed after a successful login to the OS.
2. Mount the **nfs** directory and put the executable file **cctest** into the **test** directory \(listed in [Table 2](#table1452412391911)\) to the **nfs** directory.
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.
2. Mount the **nfs** directory and put the executable file **cctest** into the **test** directory \(listed in Table 2) to the **nfs** directory.
- After the **nfs** directory is successfully mounted, run the following command to list all items in the test cases:
```
cd nfs
./cctest --list
```
3. Perform the test cases.
Some items are as follows:
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:
```
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**:
```
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<
...
```
- Run the following command to test **test-bignum**:
```
./cctest test-bignum
```
```
./cctest test-bignum
```
The test is passed if the following information is displayed:
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
...
...
@@ -225,7 +227,7 @@ After step 2 is complete, a static library file and test cases are generated in
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.
- 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.
```
...
...
@@ -288,6 +290,6 @@ After step 2 is complete, a static library file and test cases are generated in
@@ -78,7 +78,7 @@ The following steps show how to configure and modify the toolchains for cross-co
## Library Test
The test procedure for the yxml library is similar to that for the double-conversion library. For details, see the procedure described in [Porting a Library Built Using CMake](../porting/porting-thirdparty-cmake.md). The following describes how to use the test cases of the yxml library.
The test procedure for the yxml library is similar to that for the double-conversion library. For details, see the procedure described in [Porting a Library Built Using CMake](../porting/porting-thirdparty-cmake.md#library-test). The following describes how to use the test cases of the yxml library.
**Table 3** Directory structure of the test directory
...
...
@@ -119,13 +119,13 @@ The following operations are performed based on the assumption that the OpenHarm
2. Copy the content in the **_\*_.xml** file to shell.
Taking the **pi01.xml** file in the [test](#table115941423164318) directory as an example, copy the following content to shell and press **Enter**:
Taking the **pi01.xml** file in the **test** directory as an example, copy the following content to shell and press **Enter**:
```
<?SomePI abc?><a/>
```
3. Check whether the output in the shell is the same as that of the **_\*_.out** file in the [test](#table115941423164318) directory.
3. Check whether the output in the shell is the same as that of the **_\*_.out** file in the **test** directory described in Table 3.
The output is as follows:
...
...
@@ -143,52 +143,52 @@ The following operations are performed based on the assumption that the OpenHarm
## Adding the Compiled yxml Library to the OpenHarmony Project
The procedure for adding the yxml library is almost the same as that for adding the double-conversion library, except that the implementation of **build.gn** and **config.gni** files. For details, see the procedure described in [Porting a Library Built Using CMake](porting-thirdparty-cmake.md#section1651053153715).
The procedure for adding the yxml library is almost the same as that for adding the double-conversion library, except that the implementation of **build.gn** and **config.gni** files. For details, see the procedure described in [Adding the Compiled double-conversion Library to the OpenHarmony Project](../porting/porting-thirdparty-cmake.md#adding-the-compiled-double-conversion-library-to-the-openharmony-project).
- The implementation of the newly added **BUILD.gn** file in the yxml library is as follows:
```
import("config.gni")
group("yxml") {
if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
deps = [":make"]
}
}
if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
| OpenHarmony/third_party/yxml/BUILD.gn | GN file for adding the third-party library to the OpenHarmony project. |
| OpenHarmony/third_party/yxml/build_thirdparty.py | Script file for GN to call the **shell** command to convert compilation from GN to Makefile. |
| OpenHarmony/third_party/yxml/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/yxml/yxml/ | Directory of the third-party library to be ported. |
**Table 4** Directory structure of the ported library
| OpenHarmony/third_party/yxml/BUILD.gn | GN file for adding the third-party library to the OpenHarmony project. |
| OpenHarmony/third_party/yxml/build_thirdparty.py | Script file for GN to call the **shell** command to convert compilation from GN to Makefile. |
| OpenHarmony/third_party/yxml/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/yxml/yxml/ | Directory of the third-party library to be ported. |
@@ -12,7 +12,7 @@ To accommodate different developer habits, OpenHarmony provides two modes for ge
- Installation package mode: Dependency download and installation as well as building operations are performed using commands. Burning and running are performed in DevEco Device Tool.
OpenHarmony also provides the [Docker environment](../get-code/gettools-acquire.md), which can significantly simplify the environment configuration before compilation. You can build your source code in the Docker environment if you are more accustomed to using the installation package mode.
This document exemplifies how to use the IDE mode. For details about the installation package mode, see [Getting Started with Standard System (Installation Package Mode)](../quick-start/quickstart-standard-package-directory.md).
This document exemplifies how to use the IDE mode. For details about the installation package mode, see [Getting Started with Standard System (Installation Package Mode)](quickstart-standard-overview.md).
## Development Environment
...
...
@@ -28,7 +28,7 @@ This document describes how to develop OpenHarmony in the Windows+Ubuntu environ
## Development Boards
In this document, two development board models are used as examples: Hi3516D V300 and RK3568. For details about these development boards, see [Appendix](../quick-start/quickstart-standard-board-introduction.md). You can purchase the development board as required.
In this document, two development board models are used as examples: Hi3516D V300 and RK3568. For details about these development boards, see [Appendix](../quick-start/quickstart-ide-standard-board-introduction-hi3516.md). You can purchase the development board as required.
