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 クロック値にはどのような値を使用することをお勧めしますか?
事前に感謝いたします。
よろしくお願いします
データシートを参照してください。SDR104 / SDR50モードの信号レベルは1.8 Vです。ハードウェアをチェックして、これを再確認してください。
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で動作しているようです。オシロスコープでクロックを測定できます。
迅速なご返信ありがとうございます。
質問1に関しては、私は大きな間違いをしたと思います。申し訳ありません。
そして、以下のように言及していることを確認しました
「 SD/SDIO UHS-Iモード(SDRモードでは最大208MHz、DDRモードでは最大50MHz)」
SO、mmc0 に sdr104 を使用した場合、最大クロックは 208MHz なので、132MHz のクロックを保証することは可能でしょうか?
はい、132M をデフォルトとして設定する dtsi ファイルを参照できます。また、クロック ツリーをダンプして、クロックが 132Mhz かどうかを確認することもできます。
ありがとう、ジョアンシー、
実際にクロック速度の問題であるかどうかさらに調べて、再度質問します。
ありがとうございます。
親愛なるジョアンシー、
ご提供いただいた内容に基づいて、以下のレジスタを使用してテストしました。
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 コミュニティの記事を参考にして修正やテストをしてみましたが、満足のいく結果は得られませんでした。
ご注意ください。
ご協力いただきありがとうございます
ワイヤレスチームに相談したところ、彼らはすでに usdhc 経由で imx6ull で WIFI を検証しており、最大クロックを 150Mhz に設定できるため、imx6ull 側ではこれをサポートできます。また、一部の WIFI チップが自動チューニングに影響することがわかりました。そのため、これらのレジスタを無効にして確認することをお勧めします。これらが根本原因でない場合は、ハードウェアと PCB のデザインを確認することをお勧めします。これを確認できない場合は、回路図のレビューのためにチケットを送信できます。
ワイヤレスチームに相談したところ、彼らはすでに usdhc 経由で imx6ull で WIFI を検証しており、最大クロックを 150Mhz に設定できるため、imx6ull 側ではこれをサポートできます。また、一部の WIFI チップが自動チューニングに影響することがわかりました。そのため、これらのレジスタを無効にして確認することをお勧めします。これらが根本原因でない場合は、ハードウェアと PCB のデザインを確認することをお勧めします。これを確認できない場合は、回路図のレビューのためにチケットを送信できます。
これは前に話したことです。自動調整に関する詳細情報は故障に影響します
これらのパッチが機能するのは嬉しいことですが、実際には新しいBSPはすでに統合されており、私が知る限り、imx6ullとWiFiチップの間に他の問題は存在しないようです。
親愛なるジョアンシー、
親切な案内をありがとうございました。
提供されたリンクを参照してこの問題をデバッグしました。
1.パッチ1
1) 提供されたリンクを参照してパッチを適用します
2. パッチ2
1) dtsファイルに「fsl,sdio-async-interrupt-enabled」を追加する
imx6ul-14x14-evk.dtsi:
&usdhc1 {
fsl,sdio-async-interrupt-enabled; //add this line2)以下の部分が有効になります
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 つ質問があります。
このパッチを適用すれば問題は解決するでしょう。
ありがとう、ジョアンシー、
別の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 バージョンを確認します。
サポートありがとうございます。