i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) Hello NXP community members, I have a custom board with an IMX6ULL and Qualcomm BT+Wifi combo chip on it. This project is based on Yocto kirkstone, linux-imx 5.15.71 kernel version. The communication method between mx6ull and qca9377 is sdio. I have a few questions about the occasional communication errors that occur during sdio communication between mx6ull and qca9377. 1. Set dts to use sdio clock speed of 132MHz 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 info # 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. Sometimes the sdio communication error log like below is printed 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. set dts to use sdio clock speed of 50MHz. 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 info # 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 communication error log is not displayed. 1. The sdio communication between mx6ull and qca9377 seems unstable when the sdio clock is set to 132MHz. Is there a way to improve it by modifying the dts value? 2. If not possible, what value do you recommend using for the sdio clock value? Thank you in advance. Best regards i.MX6 All i.MX6UL Linux Yocto Project Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) refer to the data sheet， Signaling level of SDR104/SDR50 mode is 1.8 V. Pls check your HW and double confirm this Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) Dear Joan Xie, Thank you for fast reply. Let me explain a little more. <HW> - Soc is NXP mx6ull processor (MCIMX6Y2DVM09AB) - mmc0 is connected to Qualcomm BT/WiFi Combo chip (sdio connection) -> 132MHz, 1.8V - mmc1 connected to 8G eMMC -> 132MHz, 1.8V <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) <mmc1> # cat /sys/kernel/debug/mmc1/ios 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: 3 (8 bits) timing spec: 9 (mmc HS200) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) <Description> - Communication with the eMMC connected to mmc1 is running at 132MHz, 1.8V and there are no issues. - The sdio communication with the BT/WiFi chip connected to mmc0 is also driven at 132MHz, 1.8V, but intermittent sdio communication errors occur. More questions is loke below: 1. For eMMC(mmc1), it seems to be guaranteed for HS200 (132MHz/1.8V), but for SDIO(mmc0) it seems to be guaranteed only up to 104MHz in SDR104 mode. Check please? 2. If so, is the maximum sdio clock speed guaranteed by the mx6ull chip up to 104MHz? (I would like to confirm whether the MX6ULL chip can guarantee SDIO 132MHz clock speed.) Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) Thank you for your fast reply. About question 1, I think I was a big mistaken. Sorry about that. And I checked that you mentioned like below ""SD/SDIO UHS-I mode (up to 208 MHz in SDR mode, up to 50 MHz in DDR mode)" So, if we use sdr104 in mmc0, the maximum clock is 208MHz, so is it possible to guarantee a 132MHz clock? Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) 1. For eMMC(mmc1), it seems to be guaranteed for HS200 (132MHz/1.8V), but for SDIO(mmc0) it seems to be guaranteed only up to 104MHz in SDR104 mode. Check please?
>refer to the data sheet, can up to the UHS-I SDR104 mode 104MB/s max, not 104Mhz max, refer to the RM: SD/SDIO UHS-I mode (up to 208 MHz in SDR mode, up to 50 MHz in DDR mode)
2. If so, is the maximum sdio clock speed guaranteed by the mx6ull chip up to 104MHz? (I would like to confirm whether the MX6ULL chip can guarantee SDIO 132MHz clock speed.)
>you can refer to the data sheet, for SDR104, the frequency can up to the 200Mhz, we have tested SDR104 on the mmc0 up to the 198Mhz, refer to your log, it seems your mmc1 works under HS200？you can measure the clock by oscilloscope Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) yes, you can refer to the dtsi file, which set the 132M as default, you also can dump the clock tree to check if the clock is 132Mhz or not Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) Thank you joanxie, I'll check more to see if it's actually a clock speed issue and ask again. Thanks. Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) I debugged the above content in SW. Please answer my questions after confirming the details. 1. Chip Errata for the i.MX 6ULL "ERR010450 MMC: EMMC can only run under or equal to 150 MHz" https://www.nxp.com/docs/en/errata/IMX6ULLCE.pdf 2. SW debug 1) error value define include/uapi/asm-generic/errno.h:67:#define EILSEQ 84 /* Illegal byte sequence */ 2) EILSEQ setting location - cmd drivers/mmc/host/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) host->cmd->error = -ETIMEDOUT; else host->cmd->error = -EILSEQ; - data drivers/mmc/host/sdhci.c: sdhci_data_irq() if (intmask & SDHCI_INT_DATA_TIMEOUT) host->data->error = -ETIMEDOUT; else if (intmask & SDHCI_INT_DATA_END_BIT) host->data->error = -EILSEQ; 3) log [418.109795] [sdhci_cmd_irq()] intmask = 0xa0001 [418.114178] [sdhci_data_irq()] intmask = 0x200002 [418.118999] AR6000: SDIO bus operation failed! MMC stack returned : -84 [418.125847] __HIFReadWrite, addr:0X000800, len:00000044, Read , Sync [418.144284] 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 3. SDHCI register 1) intmask value of sdhci_cmd_irq() is 0xa0001 Bit 0 (0x00001)😞 SDHCI_INT_RESPONSE -> Command response OK Bit 17 (0x20000)😞 SDHCI_INT_INDEX -> Command index error Bit 19 (0x80000)😞 SDHCI_INT_CRC -> Command CRC error 2) intmask value of sdhci_data_irq() is 0x200002 Bit 1 (0x00002)😞 SDHCI_INT_DATA_END -> Data OK Bit 21 (0x200000)😞 SDHCI_INT_DATA_CRC -> Data CRC error 4. guess the casue According to imx6ull Errata ERR010450, "SDR104 at 1.8 V can only work below or equal to 150 MHz." If it can operate at up to 150MHz, it seems likely that cmd/data CRC errors will occur at 132MHz due to timing margins caused by temperature/voltage fluctuations, etc. 5. Question Currently, we are in a situation where we cannot adjust the value through HW tuning and must respond through SW. It seems that lowering the sdio clock value can reduce or eliminate the CRC error rate. What is NXP's opinion? Thank you. Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) Dear joanxie, Based on what you provided, I tested using the register below. sdhci-esdhc-imx.c #define ESDHC_MIX_CTRL_SMPCLK_SEL (1 << 23) #define ESDHC_MIX_CTRL_AUTO_TUNE_EN (1 << 24) #define ESDHC_MIX_CTRL_FBCLK_SEL (1 << 25) SMPCLK_SEL 0 AUTO_TUNE_EN 1 FBCLK_SEL 1 1. test 1 1) set AUTO_TUNE_EN 1 -> 0 2) log [ 39.150703] AR6000: Unregistering with the bus driver 3) wlan0 registration fail $ ifconfig wlan0 up ifconfig: SIOCGIFFLAGS: No such device 2. test 2 1) set FBCLK_SEL 1 -> 0 2) log [ 39.160750] AR6000: Unregistering with the bus driver 3) also wlan0 registration fail $ ifconfig wlan0 up ifconfig: SIOCGIFFLAGS: No such device 3. test 3 1) set AUTO_TUNE_EN 1 -> 0 && FBCLK_SEL 1 -> 0 2) System freezes during boot as shown in the log below [ 18.834619] wlan: loading driver v4.5.25.65 [ 18.894917] hifDeviceInserted: Dumping clocks (50000000,132000000) I tried modifying and testing it by referring to articles in the NXP community, but I was not satisfied with the results. Please note. Thanks for your help Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) I consulted from wireless team, they have already verified WIFI with imx6ull via usdhc, and can set max clock is 150Mhz, so for imx6ull side, can support this, and I found some WIFI chip would affect autotunning, so I suggest that you can disable these registers to check, if these aren't your root cause, I suggest that you need check your HW and pcb design, if you couldn't confirm this, you can submit a ticket for SCHEMATIC review Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) I consulted from wireless team, they have already verified WIFI with imx6ull via usdhc, and can set max clock is 150Mhz, so for imx6ull side, can support this, and I found some WIFI chip would affect autotunning, so I suggest that you can disable these registers to check, if these aren't your root cause, I suggest that you need check your HW and pcb design, if you couldn't confirm this, you can submit a ticket for SCHEMATIC review Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) Dear joanxie, Thank you for fast reply. I'll let you know after check refer to your guide. Have a nice day and weekend! Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) this is what I talked about before, the detailed information about auto-tuning affect the failure
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) Dear joanxie, Thank you for your kind guide. I debugged this issue by referring to the link you provided. 1. patch 1 1) patch using refer to the link you provided https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/uSDHC-auto-tuning-and-possible-SDIO-failures/ta-p/1352855 2. patch 2 1) add "fsl,sdio-async-interrupt-enabled" on dts file imx6ul-14x14-evk.dtsi:
&usdhc1 {
fsl,sdio-async-interrupt-enabled; //add this line 2) below part is enabled 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; After patching the above, the problem was not reproduced through debugging. (sdio clock changing test(50MHz->100MHz->132MHz), ping test, iperf3 test etc..) Just one more question to confirm patch you guide. If I apply this patch, the problem will be fixed, but is there any possibility that it will have other effects on the sdio communication between mx6ull and the wifi chip? Thank you for your support. Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) it's glad to hear these patch work, but in fact the new bsp already merge the, as I known, I don't hear any other exist issue between imx6ull and wifi chip Re: i.MX6ULL: Issue with 132MHz sdio clock out for BT+WiFi chip(Qualcomm QCA9377) Thank you joanxie, I aslo check another yocto version (imx-6.6.52, fslc-6.1.72) I found similar patch like below on yocto scarthgap imx-6.6.52 version /*
* 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); but not patched on yocto scarthgap fslc-6.1.72 version. I will check other yocto version using your guidance. Thank you for support.
View full article
