Rockchip チップボードを OpenHarmony に適応させる方法

1 全体的なアイデア

OpenHarmony は上位レベルのユーザーオペレーティングシステムであり、さまざまな基盤となるシステムと互換性があるように設計されています。L2 Linux 標準デバイスの場合、OpenHarmony は Linux や Uboot などの基盤システムにあまり依存せず、ドライバーに関しては、HDF は Linux 標準ドライバーとも互換性があります。

したがって、基盤となるシステムは基本的にオリジナルチップメーカーまたはOEMメーカーを直接使用でき、上位システムはOpenHarmonyを使用してコンパイルされます。

全体的なアイデアとしては、パーティションイメージスプライシングの方法を使用して、移植して適応させることができます。

基盤となるシステム、つまりカーネルと以前のイメージ: uboot、boot (dtb、kenel、ドライバーを含む) などは、チップメーカーまたは OEM メーカーのオリジナルのものを使用します。
上位システム、つまりカーネルの上のイメージ: rootfs、ベンダー (または OEM)、ユーザーデータ、OpenHarmony を使用します。

シングルボード SDK のコンパイルツールチェーンが OpenHarmony のコンパイルツールチェーンと互換性がある場合、基礎となるシステムのブート (dtb、カーネル、ドライバーを含む) 部分用にシングルボード SDK によってコンパイルされたイメージは問題ありません。

互換性がない場合、基盤となるシステムのブート部分は OpenHarmony コンパイルツールチェーンを使用してイメージを再コンパイルする必要があります。zh-cn/device-dev/porting/porting-linux-kernel.md · OpenHarmony/docs - Gitee.comを参照してください。

2つのバージョンオプション

1.1 OpenHarmonyのバージョン選択

新しい安定したバージョンを選択することをお勧めします。今は開発ブランチマスターを選択しないでください。現在の選択は OpenHarmony-v3.1-Beta です。このバージョンにはすでに Rockchip チップ製品「Runhe DAYU200」が含まれているため、移植が容易になります。

1.2 SDKバージョンの選択

純粋な Linux SDK を選択することをお勧めします。

RK チップをベースにした一部のシングルボードは、Android、Ubuntu、Buildroot (純粋な Linux) などの複数のオペレーティングシステムをサポートし、さまざまな SDK に対応しています。純粋な Linux SDK を選択することをお勧めします。Android と Ubuntu は使用しないでください。 Android と Ubuntu カーネルメカニズムが変更されており、移植の難易度と作業負荷が増加しています。たとえば、Android の AVB、ダイナミックパーティション、その他のメカニズムが移植に影響を及ぼします。第 2 に、RK のメインチップの純粋な Linux SDK のコンパイルツールチェーンに互換性があります。 OpenHarmony のツールチェーンを使用します。

3 適応方法

Firefly の RK シリーズを例に挙げると、適応方法は次のとおりです。

この方法は以下の Firefly 製品で動作することが確認されており、OpenHarmony システムが正しく起動し、ランチャーが画面に表示されることが確認されています。

ROC-RK3568-PC、チップはrk3568です
AIO-3568J、チップはrk3568です
AIO-3399J、チップはrk3399です

ステップ1 基本環境を準備する

Pure Linux SDK の Buildroot ファームウェアを使用することを選択し、Firefly 公式 Web サイトから対応する製品の Buildroot ファームウェアをダウンロードして書き込みます。

例えば、

ROC-RK3568-PCのダウンロードリンク: https://www.t-firefly.com/doc/download/107.html

ROC-RK3568-PCの書き込み方法：https://wiki.t-firefly.com/zh_CN/ROC-RK3568-PC/03-upgrade_firmware.html

ステップ 2 コンパイルされたカーネルを変更する

OpenHarmony は通信に IPC バインダーを使用する必要がありますが、これは純粋な Linux SDK では有効になっておらず、IPC バインダーを有効にした後にカーネルを再コンパイルする必要があります。

ソースコードを取得した後、カーネル構成を変更して CONFIG_ANDROID_BINDER_IPC マクロを開き、カーネルを再コンパイルします。

たとえば、Fireflyシリーズの操作方法は次のとおりです。

まず、Firefly公式サイトから該当製品のLinux_SDKソースコードパッケージをダウンロードします(カーネルはバージョン4.19を選択する必要があります)。

次に、製品に対応する構成ファイルを変更し、CONFIG_ANDROID_BINDER_IPC=y を追加します。例えば

kernel/arch/arm64/configs/firefly_linux_defconfig に CONFIG_ANDROID_BINDER_IPC=y を追加します。

次に、公式 Web サイトの指示に従ってコンパイル環境を構成し、カーネル ./build.sh カーネルをコンパイルして、boot.img を取得します。

最後に、パーティションごとに書き込む方法を使用して、コンパイルした boot.img を個別に書き込みます。ボードの書き込みが成功したら、ボードの基本機能がまだ正常であることを確認し、/sys/module/binder/ ディレクトリがあることを確認します。

# ls /sys/module/binder/ -l 
total 0 
drwxr-xr-x 2 root root 0 2022-01-25 07:20 パラメーター
--w------- 1 root root 4096 2022-01-25 07:18 イベント

書き込み中のパーティションテーブルファイルparameter.txtは、手順 2 でダウンロードしたソースコードから取得するか、手順 1 で解凍した Buildroot ファームウェアから取得できます。解凍方法については、https://blog.csdn.net/Neutionwei/article/details/121886647を参照してください。

ステップ 3 OH を変更してコンパイルする

OpenHarmony-v3.1-Beta 標準システムのイメージを入手し、OpenHarmony-v3.1-Beta のコードをダウンロードして、hihope rk3568 製品をコンパイルする必要があります。

コードのダウンロードパス: zh-cn/release-notes/OpenHarmony-v3.1-beta.md · OpenHarmony/docs - Gitee.com

コードを変更します。rk3399 は zpos 関連のコードを削除する必要があり、以下にリストされているコードも削除する必要があります。rk3568 では、このコードの変更は必要ありません。

// コードパス: ./device/hihope/hardware/display/src/display_device/drm_plane.cpp 
// 関数: int32_t DrmPlane::Init(DrmDevice &drmDevice) 
// 次のコードを削除します: 
    ret = drmDevice.GetPlaneProperty(*this , PROP_ZPOS_ID, prop); 
    DISPLAY_CHK_RETURN((ret != DISPLAY_SUCCESS), DISPLAY_FAILURE, DISPLAY_LOGE("cat not get pane crtc prop id")); 

// コードパス: ./device/hihope/hardware/display/src/display_device/ hdi_drm_composition.cpp 
// Function: int32_t HdiDrmComposition::ApplyPlane(HdiDrmLayer &layer, 
// HdiLayer &hlayer, 
// DrmPlane &drmPlane, 
// drmModeAtomicReqPtr pset) 
// 次のコードを削除します。
    ret = drmModeAtomicAddProperty(pset, drmPlane.GetId(), drmPlane.GetPropZposId(),layer.GetZorder()); 
    DISPLAY_LOGI("FB プレーン ID %{public}d、GetPropZposId %{public}d、zpos %{public}d を設定します"、drmPlane.GetId()、drmPlane.GetPropZposId()、layer.GetZorder()); 
    DISPLAY_CHK_RETURN((ret < 0), DISPLAY_FAILURE, DISPLAY_LOGE("zpos フィールドの errno を設定します: %{public}d", errno));

コンパイル方法: Runhe DAYU200 製品をコンパイルします。詳細なコンパイル手順については、OpenHarmony/device_hihopeを参照してください。

bash build/prebuilts_download.sh 
./build.sh --製品名 rk3568 --ccache

コンパイル後、system.img、vendor.img、userdata.imgを取得します。

ステップ 4 パーティションテーブルを調整する

OHのイメージが大きいため、パーティションテーブルの調整が必要です。

パーティションテーブルファイルparameter.txtのCMDLINEの内容を変更し、vendor.img、system.img、およびuserdata.imgのサイズに応じてoem、rootfs、およびuserdataのパーティションサイズを調整し、後続のパーティションの場所を調整します。によると。

たとえば、Firefly ROC-RK3568-PC 製品の調整されたパーティションテーブルです。

mtdparts=rk29xxnand:0x00002000@0x00004000(uboot),0x00002000@0x00006000(その他),0x00020000@0x00008000(ブート),0x00020000@0x00028000(リカバリ),0x0 0010000@0x00048000(バックアップ)、0x00150000@0x00058000(OEM)、0x30ce00@0x001A8000( rootfs)、-@0x4B4e00(ユーザーデータ:成長)

ステップ 5 変更したパーティションテーブルとイメージを書き込む

アップグレードツールを使用して、まず手順 4 で変更したパーティションテーブルファイルparameter.txt をインポートし (右クリック --> 構成のインポート --> ファイルの種類を txt として選択)、次に書き込む各ファイルを選択します。

パラメータ。手順 4 で変更したパーティションテーブルファイルparameter.txtを選択します。
OEM の場合は、手順 3 でコンパイルした Vendor.img を選択します。
rootfs で、手順 3 でコンパイルした system.img を選択します。
userdata、ステップ 3 でコンパイルした userdata.img を選択します

この手順が完了すると、rk3568 シリーズ製品、OpenHarmony が起動し、HDMI 画面に OpenHarmony デスクトップが表示されるようになります。

ステップ 6 マウントパスを変更する

取り付け経路の説明

製品ごとにパーティションのマウントパスが異なるため、パーティションをマウントする際には、製品の実際のパーティションのマウントパスを指定する必要があります。

OpenHarmony hihope rk3568でコンパイルしたイメージを使用していますが、イメージ内のパーティションマウントパス構成はhihope rk3568となっており、弊社製品の実際のパーティションマウントパスに変更する必要があります。

OpenHarmony 上の hihope rk3568 の場合、マウントパスを指定するファイルが 2 つあり、これら 2 つのファイルを変更する必要があります。

最初のファイルは /system/etc/init.without_two_stages.cfg (これはボード上のパスです) で、system.img にパッケージ化されています。コードファイルのパスは device/hihope/rk3568/build/rootfs/init.without_two_stages .cfg です。

"mount ext4 /dev/block/platform/fe310000.sdhci/by-name/vendor /vendor wait rdonly Barrier=1", 
"mount ext4 /dev/block/platform/fe310000.sdhci/by-name/userdata /data wait nosuid nodev noatime バリア = 1、データ = 順序付けられた、noauto_da_alloc"

注: RAM ディスクのない製品は /system/etc/init.without_two_stages.cfg を使用し、RAM ディスクのある製品は /system/etc/init.cfg を使用します。現在テストされている Firefly 製品では、RAM ディスクが有効になっていません。RAM ディスクが有効かどうか不明な場合は、両方の cfg ファイルを変更することをお勧めします。

2 番目のファイル /vendor/etc/fstab.rk3568 (これはボード上のパスです) は、vendor.img にパッケージ化されており、コードファイルのパスは ./device/hihope/rk3568/build/rootfs/fstab.rk3568 です。

# fstab ファイル。
# <src> <mnt_point> <type> <mnt_flags とオプション> <fs_mgr_flags> 
/dev/block/platform/fe310000.sdhci/by-name/system /usr ext4 ro,barrier=1 wait,required 
/dev/block/ platform/fe310000.sdhci/by-name/vendor /vendor ext4 ro,barrier=1 wait,required 
/dev/block/platform/fe310000.sdhci/by-name/userdata /data ext4 nosuid,nodev,noatime,barrier=1 、データ = 注文済み、noauto_da_alloc 待機、予約サイズ = 104857600

修正方法

まず、パーティションのマウントパス、さまざまな製品のパーティションパスのプレフィックスを確認します。次のコマンドを使用して表示できます。見つかったプレフィックスとパーティション名を加えたものが完全なマウントパスです。

# /dev/ -name "by-name" 
/dev/block/platform/fe310000.sdhci/by-nameを検索します

次に、構成ファイルを変更します。コード内で変更してからコンパイルするか、busybox をシステムイメージにパックして vi を通じて変更するか、イメージファイルに基づいて直接変更することができます。方法は次のとおりです。

Linux サーバーで、vendor.img と system.img を取得します。
新しい空のフォルダー (temp など) を作成します。
system.img を一時ディレクトリにマウントします
temp/system/etc/init.without_two_stages.cfg ファイル内のマウントパスを変更し、保存します。各種製品の改造方法は裏面に記載しております。
温度外
一時ディレクトリにvendor.imgをマウントします。
temp/etc/fstab.rk3568 ファイルのマウントパスを変更して保存します。各種製品の改造方法は裏面に記載しております。
温度外

実行コマンドは以下を参照できます。

Tanpengju@OpenHarmony:~/firefly/hihope$ ls 
system.img userdata.img Vendor.img 
Tanpengju@OpenHarmony:~/firefly/hihope$ mkdir temp 
Tanpengju@OpenHarmony:~/firefly/hihope$ sudo mount system.img temp 
Tanpengju@ OpenHarmony:~/firefly/hihope$ ls temp 
bin config data dev etc init lib loss+found proc sys system updater ベンダー
Tanpengju@OpenHarmony:~/firefly/hihope$ sudo vi temp/system/etc/init.without_two_stages.cfg 
Tanpengju@ OpenHarmony:~/firefly/hihope$ sudo umount temp 
Tanpengju@OpenHarmony:~/firefly/hihope$ ls temp/ 
tanpengju@OpenHarmony:~/firefly/hihope$ sudo mount Vendor.img temp 
Tanpengju@OpenHarmony:~/firefly/hihope$ ls temp/ 
etc 紛失+発見
Tanpengju@OpenHarmony:~/firefly/hihope$ sudo vi temp/etc/fstab.rk3568 
Tanpengju@OpenHarmony:~/firefly/hihope$ sudo umount temp

変更が完了したら、変更したsystem.imgとvendor.imgを書き込みます。

書き込み後、ボードのシリアルポートで mount コマンドを使用してパーティションのマウントステータスを確認し、oem パーティションと userdata パーティションが /vendor ディレクトリと /data ディレクトリに正常にマウントされていることを確認します。

製品別の修正点

Firefly ROC-RK3568-PC および Firefly AIO-3568J では、主にパーティション名が変更されます。

# /system/etc/init.without_two_stages.cfg文件
"mount ext4 /dev/block/platform/fe310000.sdhci/by-name/oem /vendor wait rdonly Barrier=1", 
"mount ext4 /dev/block/platform/ fe310000.sdhci/by-name/userdata /data wait nosuid nodev noatime Barrier=1,data=owned,noauto_da_alloc"

# /vendor/etc/fstab.rk3568文件
# fstab ファイル。
# <src> <mnt_point> <type> <mnt_flags とオプション> <fs_mgr_flags> 
/dev/block/platform/fe310000.sdhci/by-name/rootfs /usr ext4 ro,barrier=1 wait,required 
/dev/block/ platform/fe310000.sdhci/by-name/oem /vendor ext4 ro,barrier=1 wait,required 
/dev/block/platform/fe310000.sdhci/by-name/userdata /data ext4 nosuid,nodev,noatime,barrier=1 、データ = 注文済み、noauto_da_alloc 待機、予約サイズ = 104857600

Firefly AIO-3399J は、主にパーティションのパスと名前を変更します。

# /system/etc/init.without_two_stages.cfg文件
"mount ext4 /dev/block/platform/fe330000.sdhci/by-name/oem /vendor wait rdonly Barrier=1", 
"mount ext4 /dev/block/platform/ fe330000.sdhci/by-name/userdata /data wait nosuid nodev noatime Barrier=1,data=owned,noauto_da_alloc"

# /vendor/etc/fstab.rk3568文件
# fstab ファイル。
# <src> <mnt_point> <type> <mnt_flags とオプション> <fs_mgr_flags> 
/dev/block/platform/fe330000.sdhci/by-name/rootfs /usr ext4 ro,barrier=1 wait,required 
/dev/block/ platform/fe330000.sdhci/by-name/oem /vendor ext4 ro,barrier=1 wait,required 
/dev/block/platform/fe330000.sdhci/by-name/userdata /data ext4 nosuid,nodev,noatime,barrier=1 、データ = 注文済み、noauto_da_alloc 待機、予約サイズ = 104857600

ステップ 7 タッチスクリーンの適応

まず、タッチスクリーンに対応するデバイスを見つけます。cat /proc/bus/input/devices を使用して、タッチスクリーンに対応するデバイスを見つけます。たとえば、ここではタッチスクリーンが 4 番目のデバイスで、レコード名は「himax-touchscreen」です。

# cat /proc/bus/input/devices 
I: Bus=0019 Vendor=524b Product=0006 Version=0100 
N: Name="fe6e0030.pwm" 
P: Phys=gpio-keys/remotectl 
S: Sysfs=/devices/platform /fe6e0030.pwm/input/input0 
U: Uniq= 
H: Handlers=kbd events0 cpufreq 
B: PROP=0 
B: EV=3 
B: KEY=100 0 0 40408800 1c16c0 0 0 0 

I: Bus=0019 Vendor=0000 Product =0000 バージョン=0000 
N: 名前="rk805 pwrkey" 
P: Phys=rk805_pwrkey/input0 
S: Sysfs=/devices/platform/fdd40000.i2c/i2c-0/0-0020/rk805-pwrkey/input/input1 
U: Uniq= 
H: Handlers=kbdevent1 cpufreq 
B: PROP=0 
B: EV=3 
B: KEY=100000 0 0 0 
P: Phys=fusb302/typec
 
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="Typec_Headphone" 
S: Sysfs=/devices/platform/fdd40000.i2c/i2c-0/0-0022/input/input2 
U: Uniq= 
H: Handlers=event2 
B: PROP=0 
B: EV=21 
B: SW=4 

I: Bus=0000 Vendor=0000 Product=0000 Version=0000 
N: Name="himax-touchscreen" 
P: Phys= 
S: Sysfs=/devices/virtual/input/input3 
U: Uniq= 
H: Handlers=kbd events3 cpufreq 
B: PROP=2 
B: EV=b 
B: KEY=10 0 0 0 0 0 0 0 400 0 0 0 2000000 0 40000800 40 0 0 0 
B: ABS=6658000 0 

I: Bus=0019 Vendor =0001 製品=0001 バージョン=0100 
N: Name="adc-keys" 
P: Phys=adc-keys/input0 
S: Sysfs=/devices/platform/adc-keys/input/input4 
U: Uniq= 
H: Handlers=kbdevent4 cpufreq 
B: PROP=0
B: EV=3 
B: KEY=40000800 40000 1000000 0 0

次に、タッチスクリーンデバイスの名前を udev ルールに設定して、udev がその名前のデバイスをタッチスクリーンデバイスとして自動的に認識するようにします。/etc/udev/rules.d/touchscreen.rules ファイルの最後に次の文を追加します。ここで、「himax-touchscreen」は前の手順で照会した名前であり、ハードウェア環境によって異なります。

ATTR{名前}=="ヒマックス タッチスクリーン"、ENV{ID_INPUT}="1"、ENV{ID_INPUT_TOUCHSCREEN}="1"

変更された touchscreen.rules ファイルは次のとおりです。

# cat /etc/udev/rules.d/touchscreen.rules 
ATTRS{name}=="VSoC タッチスクリーン", ENV{ID_INPUT}="1", ENV{ID_INPUT_TOUCHSCREEN}="1" 
ATTRS{name}=="VSoCキーボード"、ENV{ID_INPUT}="1"、ENV{ID_INPUT_KEYBOARD}="1" 
DRIVERS=="hid-multitouch"、ENV{ID_INPUT}="1"、ENV{ID_INPUT_TOUCHSCREEN}="1" 
ATTR{名前} =="himax-タッチスクリーン"、ENV{ID_INPUT}="1"、ENV{ID_INPUT_TOUCHSCREEN}="1" 
#

touchscreen.rules を変更した後、有効にするためにデバイスを再起動する必要があります。

4 適応効果

ホタルROC-RK3568-PC：

ホタル AIO-3568J ：

ホタル AIO-3399J：

装着後は表示とタッチが可能になります。