Armadilloフォーラム

Bluetoothを使用しない場合の電波発生状態について

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コアの動作との兼ね合い)により使用したくありません。

以上、宜しくお願いいたします。

コメント

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コアの動作に影響しない実装なので、こちらはちょっと不明なのですが、
具体的に教えてもらえれば回避する方法をお伝えできると思います。

tokita.shinichi

2024年5月21日 18時44分

返信ありがとうございます。

> > 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…

2024年5月22日 13時19分

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

2024年5月28日 17時55分

マルティネ様

回答ありがとうございます。
ご教授頂きましたように、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…

2024年5月30日 18時45分

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…

2024年5月31日 10時21分

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

2024年6月5日 16時25分

マルティネ様

検証ありがとうございます。
ご教授頂いた方法ですが、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…

2024年6月5日 18時12分

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 で起動することが鍵になると思いますが、ひとまずそれだけを試していただけますか?

よろしくお願いします。