目的
meta-tensorflow-liteをkikstoneに対応した際に行ったこと、つまずいたことを記録する。
また、今回もtiwtterでかなりアドバイスをいただいた。感謝。
ようやくyocto kirkstoneでqemuriscv64のtensorflow lite v2.8が動いたよ💯💯💯💯💯💯💯💯💯💯💯💯 pic.twitter.com/VxupFga22b
— nb.o (@Nextremer_nb_o) May 7, 2022
meta-tensorflow-liteの対応
kikstoneはyoctoのメジャーバージョンがアップし、4.0になった。
かなり変更があり、自分のレシピにもかなりの影響があった。
- SRC_URIのgit url指定の変更
- SRCREVにコミットIDを指定
- do_fetch以外でのダウンロードの抑制
- CMAKE_SYSTEM_PROCESSORの制御を変更
なお、kirkstoneに対応したmeta-tensorflow-liteは以下で公開した。
SRC_URIのgit url指定の変更
SRC_URIにgit を指定している場合、
- プロトコル（protocol=???）
- ブランチ（branch=???）
meta-tensorflow-liteはhonisterからどちらも指定していたので問題はなかった。
変換用のスクリプトも用意されている。
また、レシピの命名規則などを変換するスクリプト（convert-xxxxxxxx.py）も用意されている。これらは事前にかけておいた方がよい。
（いくつかoverride syntaxの"_"を":"に変更する必要があった箇所があった）
SRCREVのコミットIDの指定
honisterまでのレシピでbitbakeすると以下のエラーが発生した。
ERROR: python3-tensorflow-lite-2.8.0-r0 do_fetch: Bitbake Fetcher Error: FetchError("Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).", None)
どうやら、kirkstoneではSRCREVにタグ名の指定はNGの模様。
コミットIDを指定する必要があった。リリースノートには記載が見当たらず、、、（もしかしたら見逃しているだけかも）
honisterまでのレシピは、以前にissueでいただいたやり方で${PV}をつかった自動化でもあった（レシピのファイル名のバージョンをあげるだけでよい）
次回以降はTensorFlowのバージョンアップの際にコミットIDの変更が必要になった...
do_fetch以外でモジュールをダウンロードする対応
これは影響の大きかった変更点。yocto 4.0のリリースノートにも記載がある。
TensorFlow
LiteはCMakeのconfigureでサブモジュールをダウンロードするため、大きく影響を受けた。
どうすればよいのか悩んでいたところ、twitterでアドバイスをうけた（ほんとうにありがとうございます）。
これ、下記でしのげたりしません？
— みつきん (@yusuke_mitsuki) April 29, 2022
do_configure[network] = "1"
Kirkstoneからはdo_fetch以外でダウンロードを行う場合は、該当タスクにフラグをたてる必要があるとのこと。
ただ、フラグをたてても状況が変わらずだった（サブモジュールのダウンロードができない）。
何が違うのか？ミニマムなサンプルを作成して事象を再現させて確認。
原因は、TensorFLow
LiteのCMakeでExternalProject_Addではなく、FetchContent_Declare、FetchContent_PopulateなどのFetchContentを使用していることが原因だった。
cmake.bbclassでCMAKEのオプションにオプションにFETCHCONTENT_FULLY_DISCONNECTEDが追加されていた（kirkstoneより）。
FETCHCONTENT_FULLY_DISCONNECTEDオプションはFetchContentのダウンロードを抑制するオプションとのこと（知らなかった！）。
このFETCHCONTENT_FULLY_DISCONNECTEDはExternalProject_Addに影響しない模様。
これが動作の違いになっていた。
cmake.bbclass 1⃣でオプションにFETCHCONTENT_FULLY_DISCONNECTED 2⃣の指定がこの挙動を起こしているようです（kirkstoneで追加）。
— nb.o (@Nextremer_nb_o) May 1, 2022
これでFetchContentで一切ダウンロードされない＆[network] = "1"でもオプションが変更されないようです。
1⃣https://t.co/19TDGsoqA2
2⃣https://t.co/6oZgE6aozh
このため、レシピにはEXTRA_OECMAKEでFETCHCONTENT_FULLY_DISCONNECTEDを変更＆do_configureでネットワークからのダウンロードを有効にするようにした。
EXTRA_OECMAKE:append = " -DFETCHCONTENT_FULLY_DISCONNECTED=OFF" do_configure[network] = "1"
CMAKE_SYSTEM_PROCESSORの指定方法の変更
上記のレシピ修正でなんとかaarch64やriscv向けのターゲットでビルドできるようになった。
しかしながら、armv6やarmv7向けのビルドが失敗する。
レシピでHOST_ARCHを変更していたことが原因の模様（honisterまでは問題なかったが、kirkstoneではエラーとなってしまった）。
HOST_ARCHを設定していた理由は、cmake.bbclassのCMAKE_SYSTEM_PROCESSORオプションを制御したかったため。
TensorFlow
Liteのサブモジュールでpytorch/cpuinfoはCMakeのCMAKE_SYSTEM_PROCESSORオプションを意識する。
このため、TensorFlow LiteのCMakeビルドの際にオプションを指定している。
具体的には、初代ラズパイ、ラズパイ0は"armv6"、その他ラズパイ32bitは"armv7"を期待している。
yoctoのcmake.bbclassでは、CMAKE_SYSTEM_PROCESSORオプションにHOST_OS（TARGET_OS）を指定している。
meta-raspberrypiでビルドする際、"raspberrypi"や"raspberrypi4"などのarm
32bitの場合、HOST_OS（TARGET_OS）には"arm"が設定されるため、TensorFlow
Liteのビルドが失敗する。
このため、TARGET_OSをレシピより"armv6"や"armv7"など期待する値に上書きすることで対応していた。
kirkstoneからはこのやり方がエラーとなってしまうため、TARGET_OSは変更せず、TensorFlow
LiteのCMakeLists.txtにパッチを当ててCMAKE_SYSTEM_PROCESSORオプションを設定するように変更した。
（EXTRA_OECMAKEで"-DCMAKE_SYSTEM_PROCESSORを指定してもうまくいかなかった）
最後に
今回もかなり助けられて対応することができた。ほんとに感謝。
まだ、Raspberry Piで動作確認できない（core-image-westonでブート時にディスプレイが表示されない）やTensorFlow Lite v2.9のリリースも近いのでまだまだ確認＆対応していく予定。
0 件のコメント:
コメントを投稿