-[Mini and Small System Development Guidelines](#table3762949121211)
-[Standard System Development Guidelines](#table17667535516)
**Table 1** Mini and small system development guidelines (reference memory < 128 MB)
| Topic| Development Scenario| Related Documentation|
| -------- | -------- | -------- |
| About OpenHarmony| Getting familiar with OpenHarmony| - [About OpenHarmony](https://gitee.com/openharmony)<br>- [Glossary](../glossary.md) |
| Development resources| Preparing for your development| - [Obtaining Source Code](get-code/sourcecode-acquire.md)<br>- [Obtaining Tools](get-code/gettools-acquire.md) |
| Getting started| Getting started with setup, build, burning, debugging, and running of OpenHarmony| [Mini and Small Systems](quickstart/quickstart-lite.md)|
| Getting started| Getting started with setup, build, burning, debugging, and running of OpenHarmony| [Mini and Small Systems](quick-start/quickstart-ide-lite-overview.md)|
| Basic capabilities| Using basic capabilities of OpenHarmony| - [Kernel for Mini System](kernel/kernel-mini-overview.md)<br>- [Kernel for Small System](kernel/kernel-small-overview.md)<br>- [HDF](driver/driver-hdf-overview.md)<br>- [Subsystems](subsystems/subsys-build-mini-lite.md)<br>- [Security Guidelines](security/security-guidelines-overall.md)<br>- [Privacy Protection](security/security-privacy-protection.md)|
| Advanced development| Developing smart devices based on system capabilities| - [WLAN-connected Products](guide/device-wlan-led-control.md)<br>- [Cameras Without a Screen](guide/device-iotcamera-control-overview.md)<br>- [Cameras with a Screen](guide/device-camera-control-overview.md) |
| Porting and adaptation| - Porting and adapting OpenHarmony to an SoC<br>- Porting and adapting OpenHarmony to a third-party library| - [Mini System SoC Porting](porting/oem_transplant_chip_prepare_knows.md)<br>- [Small System SoC Porting](porting/porting-smallchip-prepare-needs.md)<br>- [Third-Party Library Porting for Mini and Small Systems](porting/porting-thirdparty-overview.md) |
| Porting and adaptation| - Porting and adapting OpenHarmony to an SoC<br>- Porting and adapting OpenHarmony to a third-party library| - [Mini System SoC Porting](porting/porting-minichip.md)<br>- [Small System SoC Porting](porting/porting-smallchip-prepare-needs.md)<br>- [Third-Party Library Porting for Mini and Small Systems](porting/porting-thirdparty-overview.md) |
| Contributing components| Contributing components to OpenHarmony| - [HPM Part Overview](hpm-part/hpm-part-about.md)<br>- [HPM Part Development](hpm-part/hpm-part-development.md)<br>- [HPM Part Reference](hpm-part/hpm-part-reference.md) |
| Reference| Referring to development specifications| [FAQs](faqs/faqs-overview.md) |
1. Add the touchscreen driver-related descriptions.
Currently, the input driver is developed based on the HDF and is loaded and started by the HDF. Register the driver information, such as whether to load the driver and the loading priority in the configuration file. Then, the HDF starts the registered driver modules one by one. For details about the driver configuration, see [Driver Development](driver-hdf-development.md#section1969312275533).
Currently, the input driver is developed based on the HDF and is loaded and started by the HDF. Register the driver information, such as whether to load the driver and the loading priority in the configuration file. Then, the HDF starts the registered driver modules one by one. For details about the driver configuration, see [Driver Development](driver-hdf-development.md#how-to-development).
2. Complete the board-level configuration and private data configuration of the touchscreen.
...
...
@@ -96,7 +96,7 @@ Perform the following steps:
3. Implement differentiated adaptation APIs of the touchscreen.
Use the platform APIs to perform operations for the reset pins, interrupt pins, and power based on the communications interfaces designed for boards. For details about the GPIO-related operations, see [GPIO](driver-platform-gpio-des.md#section1635911016188).
Use the platform APIs to perform operations for the reset pins, interrupt pins, and power based on the communications interfaces designed for boards. For details about the GPIO-related operations, see [GPIO](driver-platform-gpio-des.md#overview).
## Development Example<a name="section263714411191"></a>
In the Hardware Driver Foundation \(HDF\), the Universal Asynchronous Receiver/Transmitter \(UART\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
...
...
@@ -186,7 +180,7 @@ The UART module adaptation involves the following steps:
@@ -42,7 +42,7 @@ The security level of each device in a Super Device provides the decision-making
### Constraints
The default security level of OpenHarmony devices is SL1. Device manufacturers can customize a higher security level based on service requirements. For details, see [Customizing Device Security Levels](#customizingdevicesecuritylevels).
The default security level of OpenHarmony devices is SL1. Device manufacturers can customize a higher security level based on service requirements. For details, see [Customizing Device Security Levels](#customizing-device-security-levels).
## Development Guidelines
...
...
@@ -187,7 +187,7 @@ To ensure its integrity and non-repudiation, the security level information must
The DSLM module provides default implementation of security level information synchronization and verification. It is assumed that the security level of all OpenHarmony devices is SL1, and a loose verification scheme is used. For details, see the [source code](https://gitee.com/openharmony/security_device_security_level/tree/master/oem_property/ohos).
You can change the device security level as required. For details about the OpenHarmony device security levels, see [Basic Concepts](#basicconcepts). You can also use more severe verification schemes, including but are not limited to using device-specific credential, periodically downloading updated credentials from a server and strictly authenticating the issuer and validity period of the credentials, and using Trusted Execution Environment (TEE) or even Secure Element (SE) to sign credential files.
You can change the device security level as required. For details about the OpenHarmony device security levels, see [Basic Concepts](#basic-concepts). You can also use more severe verification schemes, including but are not limited to using device-specific credential, periodically downloading updated credentials from a server and strictly authenticating the issuer and validity period of the credentials, and using Trusted Execution Environment (TEE) or even Secure Element (SE) to sign credential files.
> This step must be performed in a secure and reliable environment, for example, a cryptographic machine that meets related security requirements, to ensure that the key used for signature is not disclosed.
> The key pairs involved in this step do not need to be generated each time. Secure key pairs can be reused.
