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
refer to the data sheet， Signaling level of SDR104/SDR50 mode is 1.8 V. Pls check your HW and double confirm this
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?
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
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
Thank you joanxie,
I'll check more to see if it's actually a clock speed issue and ask again.
Thanks.
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
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
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
Thank you for fast reply.
I'll let you know after check refer to your guide.
Have a nice day and weekend!
this is what I talked about before, the detailed information about auto-tuning affect the failure
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-f...
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 line2) 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,
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
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.