> - The initial APIs of this module are supported since API version 8. Newly added APIs will be marked with a superscript to indicate their earliest API version.
> - The APIs of this module are system APIs and cannot be called by third-party applications.
This module provides JS APIs for obtaining the root directories of the storage and public files.
| placeholderColor | Color | - | Placeholder color. |
| placeholderFont | {<br/>size?: Length,<br/>weight?: number\|[FontWeight](ts-universal-attributes-text-style.md),<br/>family?: string,<br/>style?: [FontStyle](ts-universal-attributes-text-style.md)<br/>} | - | Placeholder text style.<br/>- **size**: font size. If the value is of the number type, the unit fp is used.<br/>- **weight**: font weight. For the number type, the value ranges from 100 to 900, at an interval of 100. The default value is **400**. A larger value indicates a larger font weight.<br/>- **family**: font family. Use commas (,) to separate multiple fonts, for example, **'Arial, sans-serif'**. The priority of the fonts is the sequence in which they are placed.<br/>- **style**: font style. |
| enterKeyType | EnterKeyType | EnterKeyType.Done | How the Enter key is labeled. |
| caretColor | Color | - | Color of the caret (also known as the text insertion cursor). |
| maxLength<sup>8+</sup> | number | - | Maximum number of characters in the text input. |
| inputFilter<sup>8+</sup> | {<br/>value:[ResourceStr](../../ui/ts-types.md)<sup>8+</sup>,<br/>error?: (value: string)<br/>} | - | Regular expression for input filtering. Only inputs that comply with the regular expression can be displayed. Other inputs are ignored. The specified regular expression can match single characters, but not strings. Example: ^(? =.\*\d)(? =.\*[a-z])(? =.\*[A-Z]).{8,10}$. Strong passwords containing 8 to 10 characters cannot be filtered.<br/>- **value**: indicates the regular expression to set.<br/>- **error**: returns the ignored content when regular expression matching fails. |
- EnterKeyType enums
| Name | Description |
| -------- | -------- |
| EnterKeyType.Go | The Enter key is labeled "Go." |
| EnterKeyType.Search | The Enter key is labeled "Search." |
| EnterKeyType.Send | The Enter key is labeled "Send." |
| EnterKeyType.Next | The Enter key is labeled "Next." |
| EnterKeyType.Done | The Enter key is labeled "Done." |
- InputType enums
| Name | Description |
| -------- | -------- |
| InputType.Normal | Normal input mode. |
| InputType.Password | Password input mode. |
| InputType.Email | Email address input mode. |
| InputType.Number | Digit input mode. |
## Events
| Name | Description |
| -------- | -------- |
| onChange(value: string) => void | Triggered when the input changes. |
| onSubmit(callback: (enterKey: EnterKeyType) => void) | Triggered when the Enter key on the physical or soft keyboard is pressed. |
| onEditChanged(callback: (isEditing: boolean) => void)<sup>(deprecated) </sup> | Triggered when the input status changes. |
| onEditChange(callback: (isEditing: boolean) => void) <sup>8+</sup> | Triggered when the input status changes. |
| onCopy<sup>8+</sup>(callback:(value: string) => void) | Triggered when the copy button on the pasteboard, which displays when the text box is long pressed, is clicked.<br/>**value**: text to be copied. |
| onCut<sup>8+</sup>(callback:(value: string) => void) | Triggered when the cut button on the pasteboard, which displays when the text box is long pressed, is clicked.<br/>**value**: text to be cut. |
| onPaste<sup>8+</sup>(callback:(value: string) => void) | Triggered when the paste button on the pasteboard, which displays when the text box is long pressed, is clicked.<br/>**value**: text to be pasted. |
### TextInputController<sup>8+</sup>
TextInput组件的控制器。
Implements the controller of the **<TextInput>** component.
### Objects to Import
#### 导入对象
```
controller: TextInputController = new TextInputController()
```
#### caretPosition
caretPosition(value: number): void
caretPosition(value: number): void
Sets the cursor in a specified position.
设置光标移动到指定位置。
- 参数
- Parameters
| Name | Type | Mandatory | Default Value | Description |
| value | number | Yes | - | Position of the input cursor.<br/>**value**: indicates the length from the start of the string to the position where the input cursor is located. |
The **device** directory of OpenHarmony is the adaptation directory for the basic SoC. You can skip the porting process and directly develop system applications if complete SoC adaptation code is already available in the directory. If there is no corresponding SoC porting implementation in the directory, complete the porting process by following the instructions provided in this document. The following figure shows the process of porting OpenHarmony to a third-party SoC.
**Figure 1** Key steps for SoC porting<aname="fig24801925498"></a>
**Figure 1** Key steps for SoC porting<aname="fig24801925498"></a>
@@ -73,13 +73,13 @@ kernel_version = "3.0.0" --- Kernel version, which corresponds to
Run the `hb set` command, enter the project root directory, and press `Enter`. The `hb` command traverses all `config.json` files in the `//vendor/<product_company>/<product_name>` directory and provides product compilation options. In the `config.json` file, `product_name` indicates the product name, `device_company` and `board` are used to locate the `//device/board/<device_company>/<board>` directory and find the matching `<any_dir_name>/config.gni` file. If multiple file matches are found, it indicates that the board has been adapted to multiple kernels. In this case, `kernel_type` and `kernel_version` in the `config.json` file can be used to uniquely match the `config.gni` file and thereby determine the board with which kernel needs to be compiled and adapted. If the information shown below is displayed, the `hb set` configuration is correct.
You can run the `hb env` command to view the selected precompilation environment variables.
Before running the `hb build` command, complete the LiteOS-M kernel adaptation. For details, see [Kernel Porting](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md#%E5%86%85%E6%A0%B8%E7%A7%BB%E6%A4%8D).
Before running the `hb build` command, complete the LiteOS-M kernel adaptation. For details, see [Kernel Porting](https://gitee.com/openharmony/docs/blob/master/en/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md#%E5%86%85%E6%A0%B8%E7%A7%BB%E6%A4%8D).
## Kernel Porting
...
...
@@ -263,7 +263,7 @@ In this example, the configuration file of `defconfig` is saved in `$(PRODUCT_PA
When the configuration is complete, run the `make menuconfig` command in the `kernel/liteos_m` directory to select `SoC Series`/`SoC`/`Board`.
The result is automatically saved in `$(PRODUCT_PATH)/kernel_configs/debug.config` and will be exported when `make menuconfig` is executed.
In the mini system, adapting the C library is a complex process. For details, see *Solution to Smooth Switchover Between musl and newlib for LiteOS-M Kernel*. The toolchain uses the `newlib` C library of the [gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2](https://gitee.com/link?target=https%3A%2F%2Fdeveloper.arm.com%2F-%2Fmedia%2FFiles%2Fdownloads%2Fgnu-rm%2F10.3-2021.10%2Fgcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2). In light of this, the `newlib` C library is used for system porting. Select `newlib` in `make menuconfig` of the kernel, as shown below.
In the **startup.S** file, you must ensure that the entry function \(for example, **reset\_vector**\) of the interrupt vector table is stored in the RAM start address specified by the link configuration files. The link configuration files of IAR, Keil, and GCC projects are **xxx.icf**, **xxx.sct**, and **xxx.ld**, respectively. The startup file provided by the vendor does not need to be modified if the **startup.S** file has initialized the system clock and returned to the **main** function. Otherwise, the preceding functions need to be implemented.
...
...
@@ -31,7 +31,7 @@ You can define configuration items in the **device/xxxx/target\_config.h** fil
The following table shows some typical configuration items:
@@ -14,9 +14,9 @@ The kernel used by module chips is LiteOS Cortex-M, which consists of four modul
-**Kernel**: stores hardware-related code in the **arch** directory and other code. The implementation of kernel function sets \(such as task and sem\), for example, task context switching and atomic operations, depends on the hardware-related code in the **arch** directory.
-**Utils**: functions as a basic code block where other modules rely.
**Figure 1** Architecture of the LiteOS Cortex-M kernel<aname="fig10838105524917"></a>
**Figure 1** Architecture of the LiteOS Cortex-M kernel<aname="fig10838105524917"></a>
@@ -12,7 +12,7 @@ For easy description, we divide the OpenHarmony architecture into two parts:
OpenHarmony = Kernel mode layer + User mode layer
The kernel mode layer is the OpenHarmony kernel layer \(purple part in the figure\). It consists of the kernel, such as Linux Kernel and LiteOS, and features, such as Hardware Driver Foundation \(HDF\), running in the kernel mode.
...
...
@@ -35,7 +35,7 @@ Therefore, the OpenHarmony kernel mode layer includes the following:
- OpenHarmony basic kernel-mode code
- OpenHarmony kernel-mode features, such as HDF
The standard LTS Linux kernel and third-party SoC chip platform code constitute the basis of a third-party Linux kernel. The OpenHarmony kernel mode layer can be composed of either of the following:
...
...
@@ -175,7 +175,7 @@ For details about how to use the logs, see [Hilog\_lite](https://gitee.com/open
The configuration \(in **Device Drivers** \> **HDF driver framework support**\) is as follows:
### Building the Image<a name="section1681965561911"></a>
As shown in [Figure 1](#fig155920160203), the part on the left manages WLAN devices, and the part on the right manages WLAN traffic. The HDF WLAN framework abstracts these two parts. The porting process of the driver can be considered as the implementation of the APIs required by the two parts. These APIs are described as follows:
Drivers can be classified as platform drivers or device drivers. The platform drivers are generally in the SoC, such as the GPIO, I2C, and SPI drivers. The device drivers are typically outside of the SoC, such as the LCD, TP, and WLAN drivers.
The Hardware Driver Foundation \(HDF\) is designed to work across OSs. The HDF driver framework provides strong support for drivers to achieve this goal. During HDF driver development, you are advised to use only the APIs provided by the HDF driver framework. Otherwise, the driver cannot be used across OSs. Before driver development, familiarize yourself with the [HDF](../driver/driver-hdf-overview.md).
@@ -18,7 +18,7 @@ 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 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\)**.
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.
...
...
@@ -26,8 +26,8 @@ The LiteOS Cortex-A initialization process consists of seven steps:
The figure below shows the overall initialization 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.
@@ -53,8 +53,8 @@ You can use the Bootloader provided by the chipset vendor or open-source U-Boot
Debug the **init** process, start shell, and run a simple program in the user space to check whether the kernel porting is successful. Below is the OS image structure of the OpenHarmony [small system](../quick-start/quickstart-lite-overview.md) and the Linux user-space program startup process.
**Figure 1** OS image structure and user-space program startup process based on the Linux kernel<aname="fig91631652715"></a>
This document provides guidance on how to port the Linux and LiteOS Cortex-A kernels on the OpenHarmony [small system](../quick-start/quickstart-lite-overview.md) to a development board. It is intended for developers with experience in developing embedded systems. Before following instructions in this document, it is recommended that you familiarize yourself with [OpenHarmony](../../OpenHarmony-Overview.md), including its technical architecture, directory structure, kernel subsystem, and driver subsystem. The following table lists the development boards that have been adapted to the small system.
**Table 1** Development boards compatible with the OpenHarmony small system
**Table 1** Development boards compatible with the OpenHarmony small system
@@ -56,9 +56,10 @@ This document provides guidance on how to port the Linux and LiteOS Cortex-A ker
In addition to the aforementioned development boards, LiteOS Cortex-A and Linux 4.19 can be ported to development boards that meet the requirements described in the table below.
**Table 2** Requirements for porting OpenHarmony small system kernels
**Table 2** Requirements for porting OpenHarmony small system kernels
2. Mount the **nfs** directory and put the executable file **cctest** into the **test** directory \(listed in [Table 2](#table1452412391911)\) to the **nfs** directory.
@@ -145,7 +145,7 @@ The following steps show how to configure and modify the toolchains for cross-co
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-thirdparty-cmake.md#section6686144293611). The following describes how to use the test cases of the yxml library.
**Table 3** Directory structure of the test directory
**Table 3** Directory structure of the test directory
@@ -8,11 +8,11 @@ This document uses the process of porting a development board named **MyProduct
### Defining a Product<a name="section145mcpsimp"></a>
Create a config.json file in the directory with the name "//vendor/MyProductVendor/{product_name}. This file is used to describe the SoC used by the product and the required subsystems. configure the file as follows:
Create a **config.json** file in the directory **//vendor/MyProductVendor/*{product_name}***. This file is used to describe the SoC used by the product and the required subsystems.
For example, if **product_name** is **MyProduct**, configure the **//vendor/MyProductVendor/MyProduct/config.json** file as follows:
//vendor/MyProductVendor/MyProduct/config.json
```
{
"product_name": "MyProduct",
...
...
@@ -39,29 +39,29 @@ Create a config.json file in the directory with the name "//vendor/MyProductVend
The main configurations are as follows:
product_name：The product name.Required
**product_name**: product name. This parameter is required.
version：version.Required
**version**: version. This parameter is required.
type：Configured at the system level, select from (mini, small, standard).Required
**type**: system level, which can be **mini**, **small**, or **standard**. This parameter is required.
target_cpu ：The CPU type of the device (depending on the actual situation, the target_cpu here may also be arm64, riscv, x86, etc..).Required
**target_cpu**: CPU type of the device (depending on the actual situation, the target_cpu here may also be arm64, riscv, x86, etc..). This parameter is required.
ohos_version：Operating system version.Optional
**ohos_version**: operating system version. This parameter is optional.
device_company：device manufacturer name.Required
**device_company**: device manufacturer name. This parameter is required.
board：Board name.Required
**board**: board name. This parameter is required.
enable_ramdisk：Whether to start ramdisk.Required
**enable_ramdisk**: whether to enable the RAM disk. This parameter is required.
kernel_type and kernel_version: kernel_type with kernel_version is fixed in the standard and does not need to be written.Optional
**kernel_type** and **kernel_version**: fixed in the standard system. They are optional.
subsystems:The subsystem that the system needs to be enabled. Subsystems can simply understand a piece of function that is built independently. Required
**subsystems**: subsystem to enable. A subsystem can be treated as an independently built functional block. This parameter is required.
product_company：Not reflected in the configuration, but in the directory name, the next directory of the vendor is product_company, build.gn script can still be accessed.
**product_company**: device manufacturer name. It is not set in the configuration, but in the directory name, next to the vendor name. It can be accessed from **build.gn script**.
You can find available subsystems in **//build/subsystem\_config.json**. You can also customize subsystems.
You can find predefined subsystems in**//build/subsystem\_config.json**. You can also customize subsystems.
You are advised to copy the configuration file of Hi3516D V300 and delete the **hisilicon\_products** subsystem, which is used to compile the kernel for Hi3516D V300.
...
...
@@ -285,8 +285,8 @@ For details about driver development, see [TOUCHSCREEN](../driver/driver-periph
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.
To support a chip, implement a **ChipDriver** for it. The major task is to implement the following interfaces provided by **HDF\_WLAN\_CORE** and **NetDevice**.
