# Standard System Solution – Rockchip RK3568 Porting Case
This document describes how to port standard system functions based on the DAYU200 development board of the RK3568 chip from Rockchip. The porting processing mainly includes product configuration adding, kernel startup and upgrade, ADM-based conversion of audio, case summary of the camera, TP, LCD, Wi-Fi, BT, vibrator, sensor, and graphics display modules, as well as related function adaptation.
This document describes how to port standard system functions based on the DAYU200 development board of the RK3568 chip from Rockchip. The porting processing mainly includes product configuration adding, kernel startup and upgrade, ADM-based conversion of audio, case summary of the camera, TP, LCD, Wi-Fi, Bluetooth, vibrator, sensor, and graphics display modules, as well as related function adaptation.
## Product Configuration and Directory Planning
...
...
@@ -81,10 +81,10 @@ RK3568 adaptation is to pack **ramdisk** compiled in the mainline version into *
1. Enable secondary boot.
Set **enable_ramdisk** in **productdefine/common/device/rk3568.json**.
Set **enable_ramdisk** in **productdefine/common/device/rk3568.json**.
```
{
```
{
"device_name": "rk3568",
"device_company": "hihope",
"target_os": "ohos",
...
...
@@ -93,32 +93,32 @@ RK3568 adaptation is to pack **ramdisk** compiled in the mainline version into *
"device_build_path": "device/hihope/build",
"enable_ramdisk": true,
"build_selinux": true
}
```
}
```
2. Pack the **ramdsik.img** file compiled in the mainline version to **boot_linux.img**.
View the configuration as follows:
RK supports **uboot** from **ramdisk**. You only need to add **ramdisk.img** to the configuration file of the packed **boot_linux.img**. Therefore, the **its** format of the mainline version is not used. Specifically, add the following content to the kernel compilation script **make-ohos.sh**:
RK supports **uboot** from **ramdisk**. You only need to add **ramdisk.img** to the configuration file of the packed **boot_linux.img**. Therefore, the **its** format of the mainline version is not used. Specifically, add the following content to the kernel compilation script **make-ohos.sh**:
Bind a device service: initializes the device service object and resource object.
Bind a device service: initializes the device service object and resource object.
```
int HdfCameraHostDriverBind(HdfDeviceObject *deviceObject)
...
...
@@ -1091,7 +1104,7 @@ Three code compilation paths **chipset_build_deps**, **camera_device_manager_dep
Take V4l2 as an example. The pipeline connection mode is to configure the connection in the HCS configuration file. The data source is called SourceNode, including hardware device control and data stream transfer.
You can determine whether to add the ISPNode as required because the ISPNode and SensorNode can be unified as the SourceNode in many operations. SinkNode is the key point of data transmission in the pipeline. Data is transmitted back to the buffer queue.
A node in the pipeline is the abstraction of the hardware/software module. Therefore, the hardware module node needs to control the hardware module. Before controlling the hardware module, you need to obtain the **deviceManager** of the corresponding hardware module and transmit the control command/data buffer through the **deviceManager**, therefore, the **deviceManager** has a v4l2 device manager abstract module, which is used to create the manager and controller of each hardware device, such as sensorManager, IspManager, and sensorController. Therefore, the v4l2 device manager is the general manager of each hardware device.
A node in the pipeline is the abstraction of the hardware/software module. Therefore, the hardware module node needs to control the hardware module. Before controlling the hardware module, you need to obtain the **deviceManager** of the corresponding hardware module and transmit the control command/data buffer through the **deviceManager**, therefore, the **deviceManager** has a v4l2 device manager abstract module, which is used to create the manager and controller of each hardware device, such as sensorManager, IspManager, and sensorController. Therefore, the v4l2 device manager is the general manager of each hardware device.
The controller in deviceManager directly interacts with the driver adaptation layer.
...
...
@@ -1099,11 +1112,11 @@ Based on the preceding description, to adapt a chip platform based on the Linux
The following directories are added:
**vendor/hihope/rk3568/hdf_config/uhdf/camera/**: HCS configuration file directory of the current chip product.
-**vendor/hihope/rk3568/hdf_config/uhdf/camera/**: HCS configuration file directory of the current chip product.
**device/hihope/rk3568/camera/**: code adaptation directory of the current chip product.
-**device/hihope/rk3568/camera/**: code adaptation directory of the current chip product.
**drivers/peripheral/camera/hal/adapter/platform/v4l2**: common platform code.
-**drivers/peripheral/camera/hal/adapter/platform/v4l2**: common platform code.
#### HCS Configuration File Adaptation
...
...
@@ -1139,7 +1152,7 @@ Take the RK3568 development board as an example. The HCS file must be stored in
```
The **camera_host_config.hcs** file under **hdi_impl** contains the physical/logical camera configuration and capability configuration. The physical/logical camera configuration needs to be used in the HAL, and the logical camera and capability configuration need to be reported to the upper layer. Add the capability configuration based on the adapted chip product. The used capability values are key-value pairs, which are defined in **//drivers/peripheral/camera/hal/hdi_impl/include/camera_host/metadata_enum_map.h**.
The **camera_host_config.hcs** file under **hdi_impl** contains the physical/logical camera configuration and capability configuration. The physical/logical camera configuration needs to be used in the HAL, and the logical camera and capability configuration need to be reported to the upper layer. Add the capability configuration based on the adapted chip product. The used capability values are key-value pairs, which are defined in **//drivers/peripheral/camera/hal/hdi_impl/include/camera_host/metadata_enum_map.h**.
```
normal_preview :: pipeline_spec {
...
...
@@ -2554,70 +2567,69 @@ Directory structure:
The HDF WLAN driver framework consists of seven parts: Module, NetDevice, NetBuf, BUS, HAL, Client, and Message. You can implement the following functions during HDF adaptation of the Wi-Fi driver:
1) Initialize the driver module that adapts the HDF WLAN framework.
1. Initialize the driver module that adapts the HDF WLAN framework.
The code is stored in **device/hihope/rk3568/wifi/bcmdhd_wifi6/hdf_driver_bdh_register.c**.
The code is stored in **device/hihope/rk3568/wifi/bcmdhd_wifi6/hdf_driver_bdh_register.c**.
```
struct HdfDriverEntry g_hdfBdh6ChipEntry = {
.moduleVersion = 1,
.Bind = HdfWlanBDH6DriverBind,
.Init = HdfWlanBDH6ChipDriverInit,
.Release = HdfWlanBDH6ChipRelease,
.moduleName = "HDF_WLAN_CHIPS"
};
HDF_INIT(g_hdfBdh6ChipEntry);
```
```
struct HdfDriverEntry g_hdfBdh6ChipEntry = {
.moduleVersion = 1,
.Bind = HdfWlanBDH6DriverBind,
.Init = HdfWlanBDH6ChipDriverInit,
.Release = HdfWlanBDH6ChipRelease,
.moduleName = "HDF_WLAN_CHIPS"
};
HDF_INIT(g_hdfBdh6ChipEntry);
```
During driver initialization, the SDIO main control board scans and detects the card, initializes the Wi-Fi chip, and creates and initializes the main API.
During driver initialization, the SDIO main control board scans and detects the card, initializes the Wi-Fi chip, and creates and initializes the main API.
6) Implement the event reporting APIs of the HDF WLAN framework.
6. Implement the event reporting APIs of the HDF WLAN framework.
The Wi-Fi driver needs to report events to the **wpa_supplicant** and **hostapd** applications, such as hotspot scanning results and association completion events of new STAs. For details about all APIs for reporting HDF WLAN events, see **drivers/framework/include/wifi/hdf_wifi_event.h**.
The Wi-Fi driver needs to report events to the **wpa_supplicant** and **hostapd** applications, such as hotspot scanning results and association completion events of new STAs. For details about all APIs for reporting HDF WLAN events, see **drivers/framework/include/wifi/hdf_wifi_event.h**.
The HDF WLAN APIs for reporting events are as follows.
The HDF WLAN APIs for reporting events are as follows.
| API in Header File hdf_wifi_event.h | Description |
@@ -2806,7 +2818,7 @@ HCI defines how to exchange commands, events, and asynchronous and synchronous p
### Hardware Connection
According to the description of the RK3568 chip, the RK3568 chip does not integrate the Wi-Fi/Bluetooth function. The RK3568 chip needs to connect to an external Bluetooth chip to support the Bluetooth function, which complies with the preceding logical architecture. How is the physical connection between the host and the controller? You can view the development board specifications more clearly.
According to the description of the RK3568 chip, the RK3568 chip does not integrate the Wi-Fi/Bluetooth function. The RK3568 chip needs to connect to an external Bluetooth chip to support the Bluetooth function, which complies with the preceding logical architecture. Regarding the physical connection between the host and the controller, you can consult the development board specifications.
![](figures/dayu200/dayu200-bt-02.png)
...
...
@@ -2816,7 +2828,7 @@ Pins 28-36 are UART (serial port). In addition, several pins are used for power
#### What Is vendorlib?
The vendorlib is deployed on the host, and may be considered as a Bluetooth chip driver layer on the host, to shield technical details of different Bluetooth chips. From the perspective of code, the main functions are as follows:
vendorlib is deployed on the host, and may be considered as a Bluetooth chip driver layer on the host, to shield technical details of different Bluetooth chips. From the perspective of code, the main functions are as follows:
1. Provide a channel (file descriptor of the serial port) between Bluetooth chips for the protocol stack.
First function called by **vendorlib**. **vendorlib** only needs to save the callback and MAC addresses of the protocol stack.
The **init** function is the first function called by **vendorlib**. **vendorlib** only needs to save the callback and MAC addresses of the protocol stack.
2.**BT_OP_POWER_ON** processing
2.**BT_OP_POWER_ON**
This operation needs to pull up the level of the power pin. In this function, the rfill device is used for processing, and the driver is not directly called to pull up the level.
...
...
@@ -3006,15 +3018,15 @@ static int HciInitHal()
1. Name of the .so file of vendorlib
The .so file name of vendorlib must be **libbt_vendor.z.so** because it is used when the protocol stack opens the dynamic link library (DLL).
The .so file name of vendorlib must be **libbt_vendor.z.so** because it is used when the protocol stack opens the dynamic link library (DLL).
2. Firmware problem
Pay attention to the chip firmware during development. The firmware of some Bluetooth chips may not need to be upgraded, but it's a must for some chips. During the adaptation of the AP6257S, the firmware is not delivered at the beginning. As a result, the received Bluetooth signals are poor. Pay attention to the following points when delivering firmware:
Pay attention to the chip firmware during development. The firmware of some Bluetooth chips may not need to be upgraded, but it's a must for some chips. During the adaptation of the AP6257S, the firmware is not delivered at the beginning. As a result, the received Bluetooth signals are poor. Pay attention to the following points when delivering firmware:
2.1. For the AP6257S chip, the Bluetooth chip does not have a flash memory. Therefore, the firmware must be delivered again after the chip is powered on and off.
2.1. For the AP6257S chip, the Bluetooth chip does not have a flash memory. Therefore, the firmware must be delivered again after the chip is powered on and off.
2.2. The firmware is processed based on the chip requirements. It is recommended that the reference code of the vendor be found. Take the Broadcom series chips as an example. The firmware delivery process is complex and is driven by a state machine. There are nine states in total:
2.2. The firmware is processed based on the chip requirements. It is recommended that the reference code of the vendor be found. Take the Broadcom series chips as an example. The firmware delivery process is complex and is driven by a state machine. There are nine states in total:
```c
/HardwareConfigurationState*/
...
...
@@ -3074,9 +3086,9 @@ For details, see the **hw_config_cback** function.
3. Pay attention to inter-system API differences.
The APIs of various systems may be slightly different, which requires special attention. Compared with the APIs of Android and OHOS, the definitions of the functions for **vendorlib** to call **xmit_cb** to send HCI commands are slightly different.
The APIs may vary slightly by system, which requires special attention. For example, the definitions of the functions for **vendorlib** to call **xmit_cb** to send HCI commands are slightly different on different systems.
That is, after a command is sent in vendorlib, Android directly calls callback to notify the chip of the returned message, and OHOS notifies the chip of the returned message through the **BT_OP_EVENT_CALLBACK** operation code (see the definition of **bt_opcode_t**). The vendorlib needs to parse the message code in the packet to determine which message is processed by the chip, and then calls the corresponding processing function.
As shown above, after a command is sent in vendorlib, the certain system notifies the chip of the returned message through a callback, while OpenHarmony notifies the chip of the returned message through the **BT_OP_EVENT_CALLBACK** operation code (see the definition of **bt_opcode_t**). vendorlib needs to parse the message code in the packet to determine which message is to be processed by the chip, and then calls the corresponding processing function.
In addition, the OHOS returns the number of bytes in the sent message. If the value is less than or equal to **0**, the message fails to be sent, which is different from the return value of the Android API.
The returned messages are also different. OpenHarmony returns the number of bytes in the message. If the value is less than or equal to **0**, the message fails to be sent.
4. snoop log
Both Android and OHOS record HCI interaction messages. The OHOS system generates the **/data/log/bluetooth/snoop.log** file. You can use Wireshark or other packet analysis tools to view the interaction process between the host and controller, facilitating fault analysis.
Like other systems, OpenHarmony logs HCI records, which are saved in the **/data/log/bluetooth/snoop.log** file. This allows you to use Wireshark or other packet analysis tools to examine the interaction process between the host and controller, facilitating fault analysis.
## Sensor
...
...
@@ -3149,7 +3161,7 @@ Both Android and OHOS record HCI interaction messages. The OHOS system generates
The RK3568 supports the accel sensor. TheOpenHarmony mainline version has the overall driver framework. You only need to implement the specific component driver.
RK3568 supports the accel sensor. The OpenHarmony mainline version has the overall driver framework. You only need to implement the specific component driver.
@@ -1429,7 +1429,7 @@ Now, there are two debugging ideas:
According to the entire debugging process, the camera supports the YUYV and MJPEG formats. By default, preview in **v4l2_main** uses the YUYV format. Change the format to MJEPG and try again.
According to the entire debugging process, the camera supports the YUYV and MJPEG formats. By default, preview in **v4l2_main** uses the YUYV format. Change the format to MJPEG and try again.
Modification:
...
...
@@ -1577,7 +1577,7 @@ Disable the Linux TP driver by disabling **TOUCHSCREEN_GT9XX** in the **<rockchi
```
#### Driver Adaptation
1. Modify content in **vendor/rockchip/rk3399/hdf_config/khdf/device_info/device_info.hcs** as follows or add the following content to the file:
1. Modify content in **vendor/rockchip/rk3399/hdf_config/khdf/device_info/device_info.hcs** as follows or add the following content to the file:
```json
device_touch_chip::device{
...
...
@@ -1595,7 +1595,7 @@ Disable the Linux TP driver by disabling **TOUCHSCREEN_GT9XX** in the **<rockchi
2. Modify content in **vendor/rockchip/rk3399/hdf_config/khdf/input/input_config.hcs** as follows or add the following content to the file:
2. Modify content in **vendor/rockchip/rk3399/hdf_config/khdf/input/input_config.hcs** as follows or add the following content to the file: