OpenHarmony is still immature on the RK3588, and SDK compilation often fails. This document records the issues encountered during compilation.

1. Disallowed exec_script call
2. camera_dump.cpp
3. xxxx depend part xxxx need set part deps xxx info to xxxx
4. allocating an object of abstract class type

1. Disallowed exec_script call

This issue arises when the BUILD.gn in OpenHarmony needs to add exec_script, which must be declared in core/gn/ohos_exec_script_allowlist.gni. To address this issue, you can do the following:

diff --git a/core/gn/ohos_exec_script_allowlist.gni b/core/gn/ohos_exec_script_allowlist.gni
index 0a986f49..813976a9 100644
--- a/core/gn/ohos_exec_script_allowlist.gni
+++ b/core/gn/ohos_exec_script_allowlist.gni
@@ -60,6 +60,7 @@ ohos_exec_script_config = {
+ "//device/board/hihope/dayu210/camera/BUILD.gn",

2. camera_dump.cpp

The error log is as follows:

ninja: error: '../../drivers/peripheral/camera/vdi_base/v4l2/src/camera_dump.cpp', needed by 'obj/drivers/peripheral/camera/vdi_base/v4l2/src/camera_host_vdi_impl_1.0/camera_dump.o', missing and no known rule to make it

The reason is that the submission for dayu210 does not match the OpenHarmony SDK, so based on the current version, set it as follows:

diff --git a/dayu210/camera/vdi_impl/v4l2/BUILD.gn b/dayu210/camera/vdi_impl/v4l2/BUILD.gn
index55b0018..c892d56 100755
--- a/dayu210/camera/vdi_impl/v4l2/BUILD.gn
+++ b/dayu210/camera/vdi_impl/v4l2/BUILD.gn
@@ -139,7 +139,7 @@ if (product_name == "rk3568_mini_system") {
host_sources = [
"$camera_path/../v4l2/src/camera_device/camera_device_vdi_impl.cpp",
- "$camera_path/../v4l2/src/camera_dump.cpp",
+ "$camera_path/dump/src/camera_dump.cpp"
"$camera_path/../v4l2/src/camera_host/camera_host_config.cpp",
@@ -158,6 +158,7 @@ if (product_name == "rk3568_mini_system") {
]

host_includes = [
+ "$camera_path/dump/include",
"$camera_path/../../interfaces/include",

3. xxxx depend part xxxx need set part deps xxx info to xxxx

The error log is as follows:

Exception: //device/soc/rockchip/rk3588/hardware/display:display_composer_vendor depend part //third_party/libdrm:libdrm, need set part deps libdrm info to device_rk3588.

According to the article “OpenHarmony 4.0 SDK Porting RK3588 Whitelist”, this is a “third_deps_bundle_not_add” setting issue. The display_composer_vendor needs to be added and set as follows:

diff --git a/compile_standard_whitelist.json b/compile_standard_whitelist.json
index ce4ca863..57fe46b5 100644
--- a/compile_standard_whitelist.json
+++ b/compile_standard_whitelist.json
"third_deps_bundle_not_add": [
 "//arkcompiler/toolchain/tooling:libark_ecma_debugger_test",
@@ -455,9 +529,13 @@
+ "//device/soc/rockchip/rk3588/hardware/display:display_composer_vendor",
+ "//device/soc/rockchip/rk3588/hardware/display:libdisplay_buffer_vendor",
+ "//device/soc/rockchip/rk3588/hardware/display:libhigbm_vendor",

4. Allocating an object of abstract class type

This issue occurs because a virtual function is declared but not implemented in the inherited class. The reason is that the changes in OpenHarmony 4.1 have not been updated in the RK3588’s HDI, so we need to update the RK3588’s HDI to add these virtual function definitions as follows:

diff --git a/rk3588/hardware/display/src/display_gralloc/display_buffer_vdi_impl.cpp b/rk3588/hardware/display/src/display_gralloc/display_buffer_vdi_impl.cpp
index 0affeb9..70c7456 100755
--- a/rk3588/hardware/display/src/display_gralloc/display_buffer_vdi_impl.cpp
+++ b/rk3588/hardware/display/src/display_gralloc/display_buffer_vdi_impl.cpp
@@ -116,6 +116,36 @@ int32_t DisplayBufferVdiImpl::IsSupportedAlloc(conststd::vector<VerifyAllocInfo
return HDF_ERR_NOT_SUPPORT;
 }
+int32_t DisplayBufferVdiImpl::RegisterBuffer(const BufferHandle& handle)
+{
+ DISPLAY_LOGE("%s is not supported", __func__);
+ return DISPLAY_NOT_SUPPORT;
+}
+
+int32_t DisplayBufferVdiImpl::SetMetadata(const BufferHandle& handle, uint32_t key, conststd::vector<uint8_t>& value)
+{
+ DISPLAY_LOGE("%s is not supported", __func__);
+ return DISPLAY_NOT_SUPPORT;
+}
+
+int32_t DisplayBufferVdiImpl::GetMetadata(const BufferHandle& handle, uint32_t key, std::vector<uint8_t>& value)
+{
+ DISPLAY_LOGE("%s is not supported", __func__);
+ return DISPLAY_NOT_SUPPORT;
+}
+
+int32_t DisplayBufferVdiImpl::ListMetadataKeys(const BufferHandle& handle, std::vector<uint32_t>& keys)
+{
+ DISPLAY_LOGE("%s is not supported", __func__);
+ return DISPLAY_NOT_SUPPORT;
+}
+
+int32_t DisplayBufferVdiImpl::EraseMetadataKey(const BufferHandle& handle, uint32_t key)
+{
+ DISPLAY_LOGE("%s is not supported", __func__);
+ return DISPLAY_NOT_SUPPORT;
+}
+
diff --git a/rk3588/hardware/display/src/display_gralloc/display_buffer_vdi_impl.h b/rk3588/hardware/display/src/display_gralloc/display_buffer_vdi_impl.h
index 9cb70a4..8e22852100755
--- a/rk3588/hardware/display/src/display_gralloc/display_buffer_vdi_impl.h
+++ b/rk3588/hardware/display/src/display_gralloc/display_buffer_vdi_impl.h
@@ -38,6 +38,11 @@ public:
virtualint32_t InvalidateCache(const BufferHandle& handle) const override;
virtualint32_t IsSupportedAlloc(conststd::vector<VerifyAllocInfo>& infos,
std::vector<bool>& supported) const override;
+ virtualint32_t RegisterBuffer(const BufferHandle& handle) override;
+ virtualint32_t SetMetadata(const BufferHandle& handle, uint32_t key, conststd::vector<uint8_t>& value) override;
+ virtualint32_t GetMetadata(const BufferHandle& handle, uint32_t key, std::vector<uint8_t>& value) override;
+ virtualint32_t ListMetadataKeys(const BufferHandle& handle, std::vector<uint32_t>& keys) override;
+ virtualint32_t EraseMetadataKey(const BufferHandle& handle, uint32_t key) override;
 };
 } // namespace DISPLAY
 } // namespace HDI

Summary

This document records some common issues encountered, but it is not exhaustive. We often face various problems when compiling OpenHarmony, mainly due to the chaotic state of the community and the lack of support. It relies more on one’s understanding of the underlying software.OpenHarmony is not something particularly novel; many issues can be analyzed and resolved with some effort. Those with experience in Android and Linux development may find it easier to engage with.

# Building a World-Class Operating System

We welcome comments and likes, thank you!!!

For more articles, please follow the public account: Kirin Embedded