tokita.shinichi
2024年5月21日 11時00分
お世話になります。
WLAN+BTコンボモジュールを使用する場合に、WLANは使用しますが、Bluetoothは使用しないため無効化したいと考えています。
製品マニュアルの3.6.6. BT デバイスを使用するを参照すると、bluezのインストール、Bluetoothデーモンの起動、bluetoothctlによるpower onとこれらの手順を踏むことで使用可能になりますが、これらを実行しない場合はbleutoothの電波は発生せずに無効化された状態と考えてよいのでしょうか。
また、デバイスツリーでarmadillo_iotg_g4-aw-xm458.dtboをオーバーレイしないことでも無効化できることは承知していますが、こちらは諸事情(M7コアの動作との兼ね合い)により使用したくありません。
以上、宜しくお願いいたします。
コメント
tokita.shinichi
返信ありがとうございます。
> > WLAN+BTコンボモジュールを使用する場合に、WLANは使用しますが、Bluetoothは使用しないため無効化したいと考えています。
> > 製品マニュアルの3.6.6. BT デバイスを使用するを参照すると、bluezのインストール、Bluetoothデーモンの起動、bluetoothctlによるpower onとこれらの手順を踏むことで使用可能になりますが、これらを実行しない場合はbleutoothの電波は発生せずに無効化された状態と考えてよいのでしょうか。
>
> それで大丈夫です。
承知しました。回答ありがとうございます。
> > また、デバイスツリーでarmadillo_iotg_g4-aw-xm458.dtboをオーバーレイしないことでも無効化できることは承知していますが、こちらは諸事情(M7コアの動作との兼ね合い)により使用したくありません。
>
> そのdtboはm7コアの動作に影響しない実装なので、こちらはちょっと不明なのですが、
> 具体的に教えてもらえれば回避する方法をお伝えできると思います。
こちらですが、armadillo_iotg_g4-aw-xm458.dtboのオーバーレイをしない場合に、M7コアでSDMAを使用したUART通信を行うと、Linuxがハングアップしてしまい約1分後に(おそらくWathcdogタイマーにより)再起動してしまう現象を確認しています。
原因が不明ですが、armadillo_iotg_g4-aw-xm458.dtboをオーバーレイする場合には発生しませんでしたので、この場合のBluetoothの無効化について質問させていただきました。
M7コアで動作させたプログラムはNXPから提供されるSDK(MCUXpresso SDK for EVK-MIMX8MP)のサンプル(uart_sdma_transfer)です。(拡張IFのUART4を使用しています)
回避策としてオーバーレイするようにしましたが、こちらの原因についてご存じでしょうか。ご教授願います。
以上、宜しくお願いいたします。
at_dominique.m…
tokita.shinichiさん
マルティネです。
大澤さんに代わって、M7コアの部分を返事します。
> > そのdtboはm7コアの動作に影響しない実装なので、こちらはちょっと不明なのですが、
> > 具体的に教えてもらえれば回避する方法をお伝えできると思います。
> こちらですが、armadillo_iotg_g4-aw-xm458.dtboのオーバーレイをしない場合に、M7コアでSDMAを使用したUART通信を行うと、Linuxがハングアップしてしまい約1分後に(おそらくWathcdogタイマーにより)再起動してしまう現象を確認しています。
> 原因が不明ですが、armadillo_iotg_g4-aw-xm458.dtboをオーバーレイする場合には発生しませんでしたので、この場合のBluetoothの無効化について質問させていただきました。
> M7コアで動作させたプログラムはNXPから提供されるSDK(MCUXpresso SDK for EVK-MIMX8MP)のサンプル(uart_sdma_transfer)です。(拡張IFのUART4を使用しています)
> 回避策としてオーバーレイするようにしましたが、こちらの原因についてご存じでしょうか。ご教授願います。
はい、Linux と M7 コアから同時に一つの sdma engine を使用することはできません。
こちらでも再現しましたが、Linux の uart1 も M7 コアの uart4 も同じ sdma1 をアクセスしていますので、コンフリクトが出る際にいくつかの不具合を確認できます：
- 通信する以前に、M7 コアで sdma/uart4 を有効にした際に uart1 をアクセス（armadillo_iotg_g4-aw-xm458.dtbo の有効か、「cat /dev/ttymxc0」など）すると、「imx-uart 30860000.serial: We cannot prepare for the RX slave dma!」のエラーが出力されます。
- M7 で uart4 を通信する際に、そのアクセスがあるかないかで linux がハングしてしまうらしいです。
アクセス中にバグが発生しない理由までは確認できてませんが、sdma1 を M7 コアからアクセスする場合は Linux で無効化してください。
rtos用の dtbo に以下を追加すると無効化になります：
&sdma1 {
status = "broken";
};その無効化されている状態でしたら、armadillo_iotg_g4-aw-xm458.dtbo を外してもしなくても linux がハングしなくなりますので、BT の無効化が楽になるかと思います。
よろしくお願いします。
tokita.shinichi
マルティネ様
回答ありがとうございます。
ご教授頂きましたように、SDMA1をデバイスツリーから無効化して試してみたのですが、M7コアでUART4が動作しませんでした。
具体的には拡張IFのUART4をUSBシリアル変換経由でPCにコンソール接続していましたが、SDMA1を無効化したことで、UART通信ができなくなりました。
使用したSDKのサンプル(uart_sdma_tarnsfer)のreadmeに以下の記載がありました。
#### Please note this application can't support booting by uboot! and accordingly it does not support Flash target! ####
This example aims to show the basic usage of the IP's function, some of the used Resources are assigned to Cortex-A core by uboot.
使用するリソースの一部はAコアに割り当てられるとあるため、LinuxでSDMA1を無効化したことで動作しなくなったのではないかと考えております。
こちらの原因についてはご存じでしょうか。
当初の質問からは外れていますが、宜しければご教授いただければ幸いです。
以上、宜しくお願いいたします。
at_dominique.m…
tokita.shinichiさん
お世話になっています、
マルティネです。
> ご教授頂きましたように、SDMA1をデバイスツリーから無効化して試してみたのですが、M7コアでUART4が動作しませんでした。
すみません、linux 側ばかりを確認して M7 での出力を確認してませんでした。
> 具体的には拡張IFのUART4をUSBシリアル変換経由でPCにコンソール接続していましたが、SDMA1を無効化したことで、UART通信ができなくなりました。
> 使用したSDKのサンプル(uart_sdma_tarnsfer)のreadmeに以下の記載がありました。
>
> #### Please note this application can't support booting by uboot! and accordingly it does not support Flash target! ####
> This example aims to show the basic usage of the IP's function, some of the used Resources are assigned to Cortex-A core by uboot.
>
> 使用するリソースの一部はAコアに割り当てられるとあるため、LinuxでSDMA1を無効化したことで動作しなくなったのではないかと考えております。
> こちらの原因についてはご存じでしょうか。
このワーニングは、M7 コアで init 処理できないのではなく、uboot もここで使われてる機能の一部を使ってるから uboot からこのアプリケーションを起動すると動かない可能性があります、とのことです。
Linux で有効にすると何かが動いてしまうかもしれませんが、多分逆です… uboot に使用されている arch/arm/dts/imx8mp.dtsi を確認したところ sdma1 が有効になっていますので、そちらも無効にすると再び動くようになると思います。
（となると、uboot のビルドも必要になりますね…標準の uboot では sdma を使ってませんので、他に影響なければ今後のアップデートでデフォルトで無効にした方が分かりやすいかもしれません）
確認したわけではないので、明日実際に確認してみてまた連絡します。
よろしくおねがいします。
at_dominique.m…
tokita.shinichiさん
マルティネです。
> このワーニングは、M7 コアで init 処理できないのではなく、uboot もここで使われてる機能の一部を使ってるから uboot からこのアプリケーションを起動すると動かない可能性があります、とのことです。
>
> Linux で有効にすると何かが動いてしまうかもしれませんが、多分逆です… uboot に使用されている arch/arm/dts/imx8mp.dtsi を確認したところ sdma1 が有効になっていますので、そちらも無効にすると再び動くようになると思います。
> （となると、uboot のビルドも必要になりますね…標準の uboot では sdma を使ってませんので、他に影響なければ今後のアップデートでデフォルトで無効にした方が分かりやすいかもしれません）
確認したところ、uboot で sdma を無効化するまでに手元の Armadillo では uart の受信 (外 -> M7 コア）を全く動かせなかったです（linux で有効や wlan の dtbo 関係なく）
uboot と linux で無効化したら正常に動くようになりました。NXP の mcuxsdk/examples/evkmimx8mp/driver_examples/uart/sdma_transfer をそのまま使って、pinmux の部分だけを修正した物で確認を行いました。
Armadillo のブートローダーを更新する必要がありますので、
以下のマニュアルのリンクどおりにビルドする前に uboot-imx/arch/arm/dts/imx8mp-evk-u-boot.dtsi ファイルにこちらを追加してください：
&sdma1 {
status = "broken";
};ビルド手順はこちらです：
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
標準 u-boot で sdma1 を使うことはないので、デフォルトで無効化しようと考えています。
（linux の方はこのままになりますので、sdma1 の無効化対応は今後も必要になります）
よろしくお願いします。
tokita.shinichi
マルティネ様
検証ありがとうございます。
ご教授頂いた方法ですが、u-bootの方も無効化しましたが、こちらではlinuxだけ無効化した場合と同じくUART4の動作を確認できませんでした。
> uboot と linux で無効化したら正常に動くようになりました。NXP の mcuxsdk/examples/evkmimx8mp/driver_examples/uart/sdma_transfer をそのまま使って、pinmux の部分だけを修正した物で確認を行いました。
sdma_transferの修正はこちらも同じだと思います。
> ビルド手順はこちらです：
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
ビルド後に6.24.1. ブートディスクの作成からSDブートで試しました。
M7コア側のプログラム実行は以下のようにlinuxからremoteprocで行っています。
armadillo:~# echo -n /home/atmark/ > /sys/module/firmware_class/parameters/path armadillo:~# echo -n iuart_sdma_transfer.elf > /sys/class/remoteproc/remoteproc0/firmware armadillo:~# echo start > /sys/class/remoteproc/remoteproc0/state
どこか違いありますでしょうか。
以上、宜しくお願いいたします。
at_dominique.m…
tokita.shinichiさん
マルティネです。
> M7コア側のプログラム実行は以下のようにlinuxからremoteprocで行っています。
> armadillo:~# echo -n /home/atmark/ > /sys/module/firmware_class/parameters/path > armadillo:~# echo -n iuart_sdma_transfer.elf > /sys/class/remoteproc/remoteproc0/firmware > armadillo:~# echo start > /sys/class/remoteproc/remoteproc0/state
>
> どこか違いありますでしょうか。
M7 コアのアプリケーションを u-boot から起動しています。
( https://github.com/atmark-techno/armadillo-x2-rtos-demo のままです）
armadillo:/boot# cat boot.txt
# SPDX-License-Identifier: MIT
# load and boot cortex core.
# The commands below are for standard TCM mode
load mmc ${mmcdev}:${mmcpart} 0x48000000 /boot/rtos.bin
cp.b 0x48000000 0x7e0000 20000;
bootaux 0x7e0000
# boot into linux
run loadimage && run mmcboot
armadillo:/boot# mkbootscr boot.txt
Wrote boot.scr
armadillo:/boot# persist_file -rv .
removed '/target/boot/boot.scr'
'/mnt/boot/boot.scr' -> '/target/boot/boot.scr'今回は linux からの起動は確認していませんでしたが、linux からの起動と uboot からの起動では Mコアの初期化がどこかで異なって、以前に linux から直接に（uboot で起動せずに）起動した時にも不具合がありました。
私の経験では、uboot で一度起動した後でしたら、linux からも起動できるようになります。
後は、今回は armadillo のデモではないですが、デモのままの armadillo_iotg_g4-rtos-demo.dtbo もインストールして /boot/overlays.txt でロードしています。（sdma の例では rpmsg が使われていないので linux でいくつかのエラーメッセージが表示されていますが、無視していいです。その dtbo か同様の dtbo がなけれあ、M コアで使用しているメモリ領域が予約されてないので不具合の可能性があります）
その dtbo に加えて、linux で sdma1 を無効化する dtbo (armadillo_iotg_g4-customize.dts を元に「&sdma1 { status = "broken"; };」を記載した物)と、usb uart が手元になかったので armadillo の uart3 をlinux で有効にして同じ armadillo の M7 の uart4 に接続しました(armadillo_iotg_g4-customize.dts を元に「&uart3 { status = "okay"; };」を記載した物）
armadillo:/boot# cat overlays.txt fdt_overlays=armadillo_iotg_g4-rtos-demo.dtbo armadillo_iotg_g4-aw-xm458.dtbo sdma1_disable.dtbo uart3_enable.dtbo
一からまとめると：
- mcuxpresso をダウンロードして、 sdma_transfer の pin を修正して armgcc/build_release.sh でビルドしました。armgcc/release/iuart_sdma_transfer.bin をarmadillo の /boot/rtos.bin にコピー
- armadillo-x2-rtos-demo の boot.txt, armadillo_iotg_g4-rtos-demo.dtbo を armadillo の /boot にコピーして、mkbootscr boot.txt と overlays.txt を修正
- customize.dts で sdma1 無効、uart3 有効して customize.dtbo を armadillo にコピーして overlays.txt に追加
- (ファイルコピーが終わったので、永続化：persist_file -r /boot)
- 電源落ちてる時に CON11 の pin 11 (uart4 TX) -> 10 (uart3 RX),と 8 (uart3 TX) -> 13 (uart4 RX) を接続
- u-boot の dts で sdma1 を使用しないように修正して mkswu の swdesc_boot で書込み
という状況で /dev/ttymxc2 に送る文字が戻ります
uboot から起動した後で linux の remoteproc で操作しようとしてみましたが、新しいカーネルで不具合が入ったので stop できなくなりました…
https://git.kernel.org/linus/69ca89d80f2c8a1f5af429b955637beea7eead30 を revert すると stop が再びできて、uboot で起動した後に stop して、 elf で起動しても正常に動きました。
（その問題は明日もう少し確認して、今月のアップデートで修正します、すみません…）
おそらく uart3 のところは関係なくて、uboot で起動することが鍵になると思いますが、ひとまずそれだけを試していただけますか？
よろしくお願いします。
tokita.shinichi
お世話になっております。
別件でこちらに手をつけられず、返信が大変遅れてしまい申し訳ありません。
こちらでもsdma1を無効化したubootでiuart_sdma_transfer.binを起動したところ、正常に動作しました。
その後Linuxを起動し、remoteprocでstop、iuart_sdma_transfer.elfで起動しても正常に動作しました。
回避策としてubootからM7側のプログラムを起動することが有効であることはわかりましたが、現状のアプリケーションとしてはLinuxのremoteprocから起動するようになっており、こちらではuboot, Linuxの両方のsdma1を無効化した場合は、remoteprocから起動したM7側のプログラムが動作しなかったため、そのまま解決には至っていません。こちらの原因についてご存じでしょうか。ご教授願います。
> 今回は linux からの起動は確認していませんでしたが、linux からの起動と uboot からの起動では Mコアの初期化がどこかで異なって、以前に linux から直接に（uboot で起動せずに）起動した時にも不具合がありました。
> 私の経験では、uboot で一度起動した後でしたら、linux からも起動できるようになります。
今回の件と関係あるかわかりませんが、確かにubootで起動せずにlinuxで起動した場合、動作しなかったため、以下のアプリケーションノートを参考にゲート登録をスキップするように変更していました。
https://www.nxp.jp/docs/en/application-note/AN5317.pdf
Index: clk-composite-8m.c
===================================================================
--- clk-composite-8m.c
+++ clk-composite-8m.c
@@ -224,7 +224,8 @@
div->flags = CLK_DIVIDER_ROUND_CLOSEST;
/* skip registering the gate ops if M4 is enabled */
- if (imx_src_is_m4_enabled()) {
+// if (imx_src_is_m4_enabled()) {
+ if (1) {
gate_hw = NULL;
} else {
gate = kzalloc(sizeof(*gate), GFP_KERNEL);以上、宜しくお願いいたします。
at_dominique.m…
tokita.shinichiさん
マルティネです。
逆の順番で回答します。
> 今回の件と関係あるかわかりませんが、確かにubootで起動せずにlinuxで起動した場合、動作しなかったため、以下のアプリケーションノートを参考にゲート登録をスキップするように変更していました。
> https://www.nxp.jp/docs/en/application-note/AN5317.pdf
こういうアプリケーションノートもありましたね。リンクありがとうございます。
多分ですが、m4 だけが使う物を無効化して電力を少し節約しようとしているだけだと思いますが、こういうときには不便ですね。
> 回避策としてubootからM7側のプログラムを起動することが有効であることはわかりましたが、現状のアプリケーションとしてはLinuxのremoteprocから起動するようになっており、こちらではuboot, Linuxの両方のsdma1を無効化した場合は、remoteprocから起動したM7側のプログラムが動作しなかったため、そのまま解決には至っていません。こちらの原因についてご存じでしょうか。ご教授願います。
imx_src_is_m4_enabled() は他の何ヶ所かに使われてますが、i.MX8MP に影響しそうなところがなさそうですね…
clk側ではなく drivers/soc/imx/soc-imx8m.c の imx_src_is_m4_enabled() を常に true をリターンしたら何か変わると思っていましたが、多分同じ動作になります。
u-boot の bootaux コマンド（arch/arm/mach-imx/imx_bootaux.c）に特別な処理がなさそうなので、linux が余計な設定を行わなければ起動できそうですが、なんでしょうね。
すみません、詳しく調べない限りはこれ以上わかりません。
原因が分からなくても、u-boot で別の何もしないイメージを m4 コアにロードさせて、linux を起動してから remoteproc で停止してファームウェアを切り替えればこの問題を回避できると思いますが、いかがでしょうか。
よろしくお願いします。
tokita.shinichi
マルティネ様
回答ありがとうございます。
> 原因が分からなくても、u-boot で別の何もしないイメージを m4 コアにロードさせて、linux を起動してから remoteproc で停止してファームウェアを切り替えればこの問題を回避できると思いますが、いかがでしょうか。
こちら試してみましたが、ubootでM7コアにロードして起動するのがsdma1を使用するiuart_sdma_transfer.binではなく、何もしない(hello_world.bin)に変更したところ、linuxのremoteprocで停止後に、iuart_sdma_transfer.elfを起動したところ動作しませんでした。
そのため、ubootからのM7コアの起動でsdma1を使用しておくことが必要なのではと思います。
ubootから上記のようなプログラムをM7コアで起動しておけば回避できそうではあるため、実装できるか検討してみます。
以上、ありがとうございました。
at_ohsawa
2024年5月21日 17時06分
> お世話になります。
>
> WLAN+BTコンボモジュールを使用する場合に、WLANは使用しますが、Bluetoothは使用しないため無効化したいと考えています。
> 製品マニュアルの3.6.6. BT デバイスを使用するを参照すると、bluezのインストール、Bluetoothデーモンの起動、bluetoothctlによるpower onとこれらの手順を踏むことで使用可能になりますが、これらを実行しない場合はbleutoothの電波は発生せずに無効化された状態と考えてよいのでしょうか。
それで大丈夫です。
> また、デバイスツリーでarmadillo_iotg_g4-aw-xm458.dtboをオーバーレイしないことでも無効化できることは承知していますが、こちらは諸事情(M7コアの動作との兼ね合い)により使用したくありません。
そのdtboはm7コアの動作に影響しない実装なので、こちらはちょっと不明なのですが、
具体的に教えてもらえれば回避する方法をお伝えできると思います。