i.MX6ULL: BT+WiFi チップ(Qualcomm QCA9377) の 132MHz sdio クロック出力の問題 NXPコミュニティメンバーの皆様、こんにちは。 IMX6ULL と Qualcomm BT+Wifi コンボ チップを搭載したカスタム ボードを持っています。 このプロジェクトは、Yocto kirkstone、linux-imx 5.15.71 カーネル バージョンに基づいています。 mx6ullとqca9377間の通信方法はsdioです。 mx6ull と qca9377 間の sdio 通信中に時々発生する通信エラーについていくつか質問があります。 ＜現状＞ 1. dtsを132MHzのSDIOクロック速度を使用するように設定する imx6ul-14x14-evk.dtsi &usdhc1 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc1>;
pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
bus-width = <4>;
vmmc-supply = <®_sd1_vmmc>;
pm-ignore-notify;
keep-power-in-suspend;
non-removable;
status = "okay";
};
&iomuxc {
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10071
MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
MX6UL_PAD_GPIO1_IO00__GPIO1_IO00 0x130b0
>;
};
pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
fsl,pins = <
MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170b9
MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100b9
MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170b9
MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170b9
MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170b9
MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170b9
>;
};
pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
fsl,pins = <
MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170f9
MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100f9
MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170f9
MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170f9
MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170f9
MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170f9
>;
};
}; 2. mmc0情報 # cat /sys/kernel/debug/mmc0/ios
clock: 132000000 Hz
actual clock: 132000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type: 0 (driver type B) 3.以下のようなSDIO通信エラーログが出力されることがあります。 AR6000: SDIO bus operation failed! MMC stack returned : -84
__HIFReadWrite, addr:0X001000, len:00000256, Read , Sync
Debug Assert Caught, File /usr/src/debug/kernel-module-qca9377/3.1-r0/git/CORE/SERVICES/HIF/sdio/linux/native_sdio/src/hif.c, Line: 1459, Test:status == A_OK || status == A_ECANCELED "Change sdio clock speed (132MHz -> 50MHz)" 1. 50MHz の SDIO クロック速度 を使用するように dts を設定します 。 imx6ul-14x14-evk.dtsi &usdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc1>;
bus-width = <4>;
vmmc-supply = <®_sd1_vmmc>;
pm-ignore-notify;
keep-power-in-suspend;
non-removable;
status = "okay";
}; 2. mmc0情報 # cat /sys/kernel/debug/mmc0/ios
clock: 50000000 Hz
actual clock: 44000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B) 3. sdio通信エラーログが表示されません。 ＜質問＞ 1.sdio クロックが 132MHz に設定されている場合、mx6ull と qca9377 間の sdio 通信は不安定になるようです。dts 値を変更して改善する方法はありますか? 2. 不可能な場合、SDIO クロック値にはどのような値を使用することをお勧めしますか? 事前に感謝いたします。 よろしくお願いします i.MX6 全て i.MX6UL Linux Yocto Project Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) データシートを参照してください。SDR104 / SDR50モードの信号レベルは1.8 Vです。ハードウェアをチェックして、これを再確認してください。 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) ジョアン・シー様 迅速な返信ありがとうございます。 もう少し説明させてください。 <ハードウェア> - SocはNXP mx6ullプロセッサ（MCIMX6Y2DVM09AB）です - mmc0 は Qualcomm BT/WiFi コンボ チップ (SDIO 接続) にコネクテッド -> 132MHz、1.8V - mmc1 を 8G eMMC にコネクテッド -> 132MHz、1.8V < mmc0 > # cat /sys/kernel/debug/mmc0/ios クロック: 132000000 Hz 実際のクロック: 132000000 Hz vdd: 21 (3.3 ~ 3.4 V) バスモード: 2 (プッシュプル) チップセレクト: 0 (無視) 電源モード: 2 (オン) バス幅: 2 (4 ビット) タイミング仕様: 6 (SD uhs SDR104) 信号電圧: 1 (1.80 V) ドライバタイプ: 0 (ドライバタイプ B) < mmc1 > # cat /sys/kernel/debug/mmc1/ios クロック: 132000000 Hz vdd: 21 (3.3 ~ 3.4 V) バスモード: 2 (プッシュプル) チップセレクト: 0 (無視) 電源モード: 2 (オン) バス幅: 3 (8 ビット) タイミング仕様: 9 (mmc HS200) 信号電圧: 1 (1.80 V) ドライバタイプ: 0 (ドライバタイプ B) <説明> - mmc1 にコネクテッドされた eMMC との通信は 132MHz、1.8V で実行されており、問題はありません。 - mmc0 にコネクテッドされた BT/WiFi チップとの sdio 通信も 132MHz、1.8V で駆動されますが、断続的に sdio 通信エラーが発生します。 その他の質問は以下の通りです: 1.eMMC(mmc1)の場合、HS200(132MHz/1.8V)が保証されているようですが、しかし、SDIO(mmc0)の場合、SDR104モードでは104MHzまでしか保証されないようです。お会計お願いします？ 2. SO、mx6ull チップによって保証される最大 sdio クロック速度は 104MHz までですか? （MX6ULLチップがSDIO 132MHzのクロック速度を保証できるかどうかを確認したいと思います。） gnani4080_0-1766369476736.png Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) 1.eMMC(mmc1)の場合、HS200(132MHz/1.8V)が保証されているようですが、しかし、SDIO(mmc0)の場合、SDR104モードでは104MHzまでしか保証されないようです。お会計お願いします？
>データシートを参照してください。UHS-I SDR104モードでは最大104MB/sまでCAN対応ですが、最大104Mhzまでではありません。RMを参照してください: SD/SDIO UHS-Iモード(SDRモードでは最大208MHz、DDRモードでは最大50MHz)
2. SO、mx6ull チップによって保証される最大 sdio クロック速度は 104MHz までですか? （MX6ULLチップがSDIO 132MHzのクロック速度をCAN保証できるかどうかを確認したいと思います。）
>データシートを参照してください。SDR104の場合、周波数は最大200MHzです。SDR104をmmc0で最大198MHzまでテストしました。ログを参照してください。mmc1はHS200で動作しているようです。オシロスコープでクロックを測定できます。 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) 迅速なご返信ありがとうございます。 質問１に関しては、私は大きな間違いをしたと思います。申し訳ありません。 そして、以下のように言及していることを確認しました 「 SD/SDIO UHS-Iモード（SDRモードでは最大208MHz、DDRモードでは最大50MHz）」 gnani4080_0-1766477971673.png SO、mmc0 に sdr104 を使用した場合、最大クロックは 208MHz なので、132MHz のクロックを保証することは可能でしょうか? Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) はい、132M をデフォルトとして設定する dtsi ファイルを参照できます。また、クロック ツリーをダンプして、クロックが 132Mhz かどうかを確認することもできます。 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) ありがとう、ジョアンシー、 実際にクロック速度の問題であるかどうかさらに調べて、再度質問します。 ありがとうございます。 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) 上記の内容をSWでデバッグしました。 詳細をご確認の上、ご質問にお答えください。 1. i.MX 6ULLのチップエラッタ 「ERR010450 MMC: EMMCは150 MHz以下でのみ動作CAN」 https://www.nxp.com/docs/en/errata/IMX6ULLCE.pdf ghkim_sj_0-1766996300598.png 2. SWデバッグ 1 ) エラー値の定義 include / uapi / asm -generic / errno.h: 67 : #define EILSEQ 84 /* 不正なバイトシーケンス */ 2 ) EILSEQの設定場所 -コマンド ドライバ/ mmc /ホスト/ sdhci.c: sdhci_cmd_irq () if (intmask & (SDHCI_INT_TIMEOUT | SDHCI_INT_CRC | SDHCI_INT_END_BIT | SDHCI_INT_INDEX)) { if (intmask & SDHCI_INT_TIMEOUT) ホスト-> cmd ->エラー= - ETIMEDOUT; それ以外 ホスト-> cmd ->エラー= - EILSEQ; -データ ドライバ/ mmc /ホスト/ sdhci . c : sdhci_data_irq () if (intmask & SDHCI_INT_DATA_TIMEOUT) ホスト->データ->エラー= - ETIMEDOUT; そうでない場合(intmask & SDHCI_INT_DATA_END_BIT) ホスト->データ->エラー= - EILSEQ; 3 ) ログ [ 418.109795 ] [ sdhci_cmd_irq ()] intmask = 0xa0001 [ 418.114178 ] [ sdhci_data_irq ()] intmask = 0x200002 [ 418.118999 ] AR6000: SDIOバス操作に失敗しました！ MMCスタックが返されました: - 84 [ 418.125847 ] __HIFReadWrite、アドレス: 0X000800 、長さ: 00000044 、読み取り、同期 [ 418.144284 ] デバッグアサートをキャッチしました。ファイル/ usr / src / debug / kernel - module - qca9377 / 3.1 - r0 / git / CORE / SERVICES / HIF / sdio / linux / native_sdio / src / hif . c 、行: 1459 、テスト: ステータス== A_OK ||ステータス== A_ECANCELED 3. SDHCIレジスタ 1 ) sdhci_cmd_irq ()の intmask 値は0xa0001です ビット0 （ 0x00001）😞 SDHCI_INT_RESPONSE -> コマンド 応答OK ビット17 (0x20000)😞 SDHCI_INT_INDEX -> コマンドインデックスエラー ビット19 (0x80000)😞 SDHCI_INT_CRC -> コマンドCRCエラー 2 ) sdhci_data_irq ()の intmask 値は0x200002です ビット1 （ 0x00002）😞 SDHCI_INT_DATA_END -> データ 正常 ビット21 (0x200000)😞 SDHCI_INT_DATA_CRC -> データCRCエラー 4.原因を推測する imx6ull Errata ERR010450によると、 「1.8 V の SDR104 は 150 MHz 以下でのみ動作します。」 150MHzまで動作できるのであれば、温度・電圧変動などによるタイミングマージンにより、132MHzではcmd/data CRCエラーが発生する可能性が高くなると思われます。 5.質問 現状ではHWチューニングで値を調整することができず、SWで対応しなければならない状況です。 sdioクロック値を下げるとCRCエラー率を低減、あるいはゼロにできるようです。NXPの見解をお聞かせください。 ありがとう。 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) 親愛なるジョアンシー、 ご提供いただいた内容に基づいて、以下のレジスタを使用してテストしました。 sdhci-esdhc-imx.c #ESDHC_MIX_CTRL_SMPCLK_SEL を定義します (1 << 23) #define ESDHC_MIX_CTRL_AUTO_TUNE_EN (1 << 24) #ESDHC_MIX_CTRL_FBCLK_SEL を定義します (1 << 25) SMPCLK_SEL 0 オートチューン 1 FBCLK_SEL 1 1. テスト1 1) AUTO_TUNE_ENを1→0に設定する 2) ログ [ 39.150703] AR6000: バスドライバーの登録を解除しています 3) wlan0 登録失敗 $ ifconfig wlan0 アップ ifconfig: SIOCGIFFLAGS: そのようなデバイスはありません 2. テスト2 1) FBCLK_SELを1→0に設定する 2) ログ [ 39.160750] AR6000: バスドライバーの登録を解除しています 3) wlan0の登録も失敗します $ ifconfig wlan0 アップ ifconfig: SIOCGIFFLAGS: そのようなデバイスはありません 3. テスト3 1) AUTO_TUNE_EN 1 -> 0 && FBCLK_SEL 1 -> 0 を設定します 2)以下のログに示すように、起動中にシステムがフリーズする [ 18.834619] wlan: ドライバ v4.5.25.65 を読み込んでいます [ 18.894917] hifDeviceInserted: クロックをダンプしています (50000000,132000000) NXP コミュニティの記事を参考にして修正やテストをしてみましたが、満足のいく結果は得られませんでした。 ご注意ください。 ご協力いただきありがとうございます Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) ワイヤレスチームに相談したところ、彼らはすでに usdhc 経由で imx6ull で WIFI を検証しており、最大クロックを 150Mhz に設定できるため、imx6ull 側ではこれをサポートできます。また、一部の WIFI チップが自動チューニングに影響することがわかりました。そのため、これらのレジスタを無効にして確認することをお勧めします。これらが根本原因でない場合は、ハードウェアと PCB のデザインを確認することをお勧めします。これを確認できない場合は、回路図のレビューのためにチケットを送信できます。 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) 親愛なるジョアンシー、 迅速な返信ありがとうございます。 ガイドを参照して確認した後、お知らせします。 良い一日と週末をお過ごしください！ Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) ワイヤレスチームに相談したところ、彼らはすでに usdhc 経由で imx6ull で WIFI を検証しており、最大クロックを 150Mhz に設定できるため、imx6ull 側ではこれをサポートできます。また、一部の WIFI チップが自動チューニングに影響することがわかりました。そのため、これらのレジスタを無効にして確認することをお勧めします。これらが根本原因でない場合は、ハードウェアと PCB のデザインを確認することをお勧めします。これを確認できない場合は、回路図のレビューのためにチケットを送信できます。 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) これは前に話したことです。自動調整に関する詳細情報は故障に影響します
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/uSDHC-auto-tuning-and-possible-SDIO-failures/ta-p/1352855 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) これらのパッチが機能するのは嬉しいことですが、実際には新しいBSPはすでに統合されており、私が知る限り、imx6ullとWiFiチップの間に他の問題は存在しないようです。 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) 親愛なるジョアンシー、 親切な案内をありがとうございました。 提供されたリンクを参照してこの問題をデバッグしました。 1.パッチ1 1) 提供されたリンクを参照してパッチを適用します https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/uSDHC-auto-tuning-and-possible-SDIO-failures/ta-p/1352855 2. パッチ2 1) dtsファイルに「fsl,sdio-async-interrupt-enabled」を追加する imx6ul-14x14-evk.dtsi:
&usdhc1 {
fsl,sdio-async-interrupt-enabled; //add this line 2)以下の部分が有効になります sdhci-esdhc-imx.c: usdhc_auto_tuning_mode_sel()
/*
* If sdio device use async interrupt, it will use DAT[1] to signal
* the device's interrupt asynchronous when use 4 data lines.
* Then hardware auto tuning circuit MUST NOT check the DAT[1] line,
* otherwise auto tuning will be impacted by this async interrupt,
* and change the delay cell incorrectly, which then cause data/cmd
* errors.
* This is the hardware auto tuning circuit limitation.
*/
if (imx_data->boarddata.sdio_async_interrupt_enabled)
auto_tune_buswidth = ESDHC_VEND_SPEC2_AUTO_TUNE_1BIT_EN; 上記のパッチを適用した後、デバッグで問題は再現されませんでした。 (SDIOクロック変更テスト(50MHz->100MHz->132MHz)、pingテスト、iperf3テストなど) ガイドされたパッチを確認するために、もう 1 つ質問があります。 このパッチを適用すれば問題は解決するでしょう。 しかし、mx6ull と WiFi チップ間の SDIO 通信に他の影響が出る可能性はありますか? 再開まで今しばらくお待ちください。 Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) ありがとう、ジョアンシー、 別のyoctoバージョン（imx-6.6.52、fslc-6.1.72) yocto scarthgap imx-6.6.52バージョンで以下のような類似のパッチを見つけました /*
* For USDHC, auto tuning circuit can not handle the async sdio
* device interrupt correctly. When sdio device use 4 data lines,
* async sdio interrupt will use the shared DAT[1], if enable auto
* tuning circuit check these 4 data lines, include the DAT[1],
* this circuit will detect this interrupt, take this as a data on
* DAT[1], and adjust the delay cell wrongly.
* This is the hardware design limitation, to avoid this, for sdio
* device, config the auto tuning circuit only check DAT[0] and CMD
* line.
*/
if (imx_data->init_card_type == MMC_TYPE_SDIO)
auto_tune_buswidth = ESDHC_VEND_SPEC2_AUTO_TUNE_1BIT_EN;
esdhc_clrset_le(host, ESDHC_VEND_SPEC2_AUTO_TUNE_MODE_MASK,
auto_tune_buswidth | ESDHC_VEND_SPEC2_AUTO_TUNE_CMD_EN,
ESDHC_VEND_SPEC2); しかし、yocto scarthgap fslc-6.1.72にはパッチが適用されていませんバージョン。 あなたの指導に従って他の yocto バージョンを確認します。 サポートありがとうございます。
記事全体を表示
