iMX8MM dropping SDIO clock to 12MHz causes the SDHCI crash
[ 641.123790] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 641.130232] mmc0: sdhci: Sys addr: 0x54968d04 | Version: 0x00000002
[ 641.136671] mmc0: sdhci: Blk size: 0x00000004 | Blk cnt: 0x00000001
[ 641.143110] mmc0: sdhci: Argument: 0x15804004 | Trn mode: 0x00000013
[ 641.149548] mmc0: sdhci: Present: 0x01d88a0a | Host ctl: 0x00000013
[ 641.155986] mmc0: sdhci: Power: 0x00000002 | Blk gap: 0x00000080
[ 641.162425] mmc0: sdhci: Wake-up: 0x00000008 | Clock: 0x0000028f
[ 641.168863] mmc0: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000
[ 641.175301] mmc0: sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[ 641.181739] mmc0: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502
[ 641.188178] mmc0: sdhci: Caps: 0x07eb0000 | Caps_1: 0x8000b407
[ 641.194616] mmc0: sdhci: Cmd: 0x0000353a | Max curr: 0x00ffffff
[ 641.201054] mmc0: sdhci: Resp[0]: 0x00001000 | Resp[1]: 0x00000000
[ 641.207492] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
[ 641.213930] mmc0: sdhci: Host ctl2: 0x00000088
[ 641.218372] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x5608d208
[ 641.224809] mmc0: sdhci: ============================================
NXP team, can someone point to what could be the reason
Don't see any issue with iMX8MQ or iMX6/7
Actually you should see it on both, our recent test was run on imx8mnevk board with L5.4.3 BSP where we saw this issue. So, the problem is reproducible using either of the boards.
Regards
Ramesh
Hi Ramesh,
Could you send us your full log file test on our NXP BSP and board?
From the screenshot customer send, there are errors reported from brcmfmac/sdio.c. So are you using i.MX8MM DDR4 EVK with cyw43455 wifi module, not i.MX8MM LPDDR4 EVK with qca9377 wifi module? Tell us.
Our experts use i.MX8MM DDR4 EVK, Linux 5.4.3_1.0.0 BSP version with cyw43455 wifi module loaded, download from Embedded Linux for i.MX Applications Processors | NXP . When drop mmc0(sdio) clock from 208MHz to 12MHz using your method, wait for several times, the timeout issue will not happen. Log is as attached.
So there are some hareware/software differences between us?
Have a nice day
Best Regards
Rita
Hi Rita,
The last test was run on NXP IMX8MNEVK / DDR4 with a cyw43455-sdio card, using image built from NXP's L5.4.3 BSP. But the test method is different from my earlier method. In this case, a dts entry is added to set the max-frequency for the SDHC interface & the corresponding .dtb file is used during bootup. Once you bring up the wlan interface up, you should hit the condition. Please find the dmesg log from the test attached. I am also attaching the .dts & .dtb files used in the test.
Regards
Ramesh
Hi Ramesh,
We found that your cyw43455 wifi firmware version (version 7.45.206) is different with NXP offical release(version 7.45.184). So suggest you to use wifi firmware from offical release, namely brcmfmac43455-sdio.bin from imx-firmware/cyw-wifi-bt/1MW_CYW43455 at master · NXP/imx-firmware · GitHub . Also from log, seems you add Murata’s customized layer "meta-murata-wireless" which gets hooked into the i.MX build, are you using the official Linux 5.4.3_1.0.0 BSP download from Embedded Linux for i.MX Applications Processors | NXP ?
We need confirm with you that is the 12MHz means SDR12 mode? Is it always happens on your side?
Have a nice day
Best Regards
Rita
Hi Rita,
With the .dts file that I attached earlier, you don't see the issue ? I will revert back with answers for your other comments.
Regards
Ramesh
We found that your cyw43455 wifi firmware version (version 7.45.206) is different with NXP offical release(version 7.45.184). So suggest you to use wifi firmware from offical release, namely brcmfmac43455-sdio.bin from imx-firmware/cyw-wifi-bt/1MW_CYW43455 at master · NXP/imx-firmware · GitHub . Also from log, seems you add Murata’s customized layer "meta-murata-wireless" which gets hooked into the i.MX build, are you using the official Linux 5.4.3_1.0.0 BSP download from Embedded Linux for i.MX Applications Processors | NXP ?
We need confirm with you that is the 12MHz means SDR12 mode? Is it always happens on your side?
Could you also send us the log file?
Reference board i.MX 8M Mini Evaluation Kit | NXP
Also on this hardware iMX8M Mini uCOM Developer's Kit V2 - Embedded Artists
Dont see the issue on iMX8M Quad Developer's Kit V2 - Embedded Artists or other iMX series
Do you mean you meet this question in our i.MX8MM EVK board? If yes, I will do confirm it for you.
Sorry did not understand your question.
The SDHCI crashes, is there any driver update or fix from the crash dump i've provided above ?
Are there any known issues with iMX8MM in particular ?
Could you tell me which version BSP are you using?
#define SDHCI_HOST_VERSION 0xFE
is from sdhci.c file
also if you see the crash dump
it says Version 02
Is there some place I can look for ?
Can you tell us which mode did you configured for the SDHC system? I have sent your question to our expert team. And our expert are confirming it for you.
Mode is 4bit SDIO mode
Operation freq is 12Mhz.
Can this be treated as priority. Looks like a bug in the driver implementation of SDHC.
Hi Vikram,
Could you tell us which version BSP are you using? L5.4.3_1.0.0 or L4.19.35_1.1.0 or other version. We need know this for further confirming.
Have a nice day
Rita
This is the BSP version is 4.14.98-2.2.0
Hi Vikram,
This is the update from our expert. Hope this can do help for you.
After doing a bit o research I have found in the Release Notes that BSP version 4.14.98-2.2.0 is not GA tested for iMX8MM. My recommendation for the customer is to switch to a GA release such as 4.14.98-2.0.0_ga or newer (4.19.35 or 5.4) and try dropping the SDIO clock to 12MHz on that release.
Have a nice day
Best Regards
Rita
Hi Rita,
This same test was run on using NXP's L5.4.3 BSP release and the problem is still observed. When the mmc clock is changed to 12Mhz, this message is observed with a dump:
Timeout waiting for hardware interrupt
drivers/mmc/host/sdhci.c:sdhci_timeout_data_timer <== Here is the source & function. Attaching a screenshot for ref.
Can you please help?
I will confirm it for you.
Hi Rita,
Just checking to see if you heard anything on this?
Regards
Ramesh