Profile Data
| Member | Action | Date |
|---|---|---|
Marc Dorval
|
Updated
Linux SDIO detection on Wi-Fi Knowledge Base
Linux SDIO part detection on the SDIO busUnder Linux, SDIO parts are bound to the mmc bus. Before using a Wi-Fi part connected to the SDIO bus of a Linux system, it is necessary that the system detects the HW on the bus. When detection succeeds, the kernel has retrieved the VID/PID for the device. Looking for a driver matching the VID/PID is only possible if the VID/PID has been retrieved from the device.
Linux systems will try to detect SDIO parts on the bus at boot, and every time the mmc bus is bound. Unbinding/binding the mmc bus is what we will use to trace mmc messages related to SDIO detection. SDIO Detection messageThe following message should be visible in dmesg once boot is complete: mmcX new high speed SDIO card at address 0001 one-line check:
If this message is not found, it is necessary to debug SDIO detection, going through the following steps:
These steps are detailed below.
Retrieving the current device treeRefer to Linux Device Tree Debugging for information on retrieving the device tree content in a file. Debugging device tree issues by comparison
Making sure SDIO is enabled in Device TreeIn order for the Linux system to try detecting a part on the SDIO bus, the SDIO bus needs to be part of the Device Tree used at boot. one-line check (SDIO pins selection):
Typical result:
sdio_pins = "/soc/gpio@7e200000/sdio_pins";
sdio_pins {
If this returns an empty line, SDIO detection is not even triggered. Refer to your system documentation to know how to add SDIO to the device tree.
Checking which mmc bus is used for SDIOone-line check (SDIO mmc bus selection):
The result should contain: mmc1 = "/soc/sdio@7e300000"; or (depending on the kernel, i.e. the device tree version) mmc = "/soc/mmc@7e300000"; If this returns an empty line, SDIO is not connected to any mmc bus. Refer to your system documentation to know how to add SDIO to the device tree. Checking the mmc bus commands during the SDIO detection phase
This is the trickiest part, since it involves tracking message normally issued at boot, when the system is attempting SDIO detection. In reality, these are issued every time the mmc bus is bound to the system, so unbinding/binding the mmc bus will trigger a new detection attempt. We use this to avoid activating the traces at boot time, since this is not easy to do. Preparing the kernel event traces (to be executed with root privileges):
Not tracing mmc CMD53 (once working in high-speed mode, to avoid being overloaded with traces once detected):
Tracing the kernel events on mmc1 (adapt the mmc to your own use case):
Unbinding/Binding the mmc bus to trigger a reset and reload the driver:
Typical traces (limited view zooming on 'cmd_opcode' due to extra long lines):
Stopping mmc request traces (once the traces have been retrieved): This step is necessary to stop tracing, which is otherwise still active. No additional traces are shown because SDIO traffic only uses CMD53 once detection is complete, and CMD53 are filtered out. It is better to stop tracing completely.
Checking the SDIO detection result
If detection is correct, the 'mmcX new high speed SDIO card at address 0001' message is present in dmesg. Otherwise, check for errors related to the mmc item corresponding to your part. SDIO pins used for the detection phaseThe SDIO detection as shown above only uses SD_CMD and SD_CLK pins, and is generally performed with a 400kHz SD_CLK. SD_DAT[3:0] are not used yet, so SDIO detection may succeed even though SD_DAT[3:0] are not properly routed. Host stopping clock after CMD0Some hosts will stop the SD-CLK clock right after issuing the CMD0 (MMC_GO_IDLE) command. This is because the SDIO specification does not require a response to CMD0. In this case, the SDIO detection flow will get interrupted after CMD0, and will not show CMD5, CMD52, etc. To solve this, apply the patch described at the end of this article in 'Specifics of using a processor which stops the clock after CMD0' Max SDIO speed too highDuring the last steps of SDIO detection, the SoC sets the SDIO part to 'high-speed' mode on 4 data bits, then configures its own hardware to the maximum selected SDIO speed (controllable in the device tree) only at the very end of the SDIO detection, after a long series of about 26 CMD52 commands. There is a SDIO speed limitation with BRD8022/BRD8023 due to the onboard switches. For this reason, we need to reduce the SDIO clock speed. 25 MHz is generally a good choice, given that choices are limited and vary depending on the platform. In case there are issues related to the max clock speed, the last CMD52 commands will return with 'cmd_err=-110' (which means 'TIMEOUT'), and will be followed by a short burst of about 4 CMD55 commands. Whenever the SDIO detection loop fails, it is repeated with a slower clock speed (400, 300, 200, 100 kHz, respectively), but is still ending with the max clock. If the max clock is too high, all 4 loops will eventually fail, therefore the traces will show 4 repeated patterns of: CMD52 In this case, check your device tree documentation to check how to reduce the maximum SDIO clock. Checking the SDIO clock speedsudo cat /sys/kernel/debug/mmc1/ios Output: clock: 50000000 Hz
Checking GPIO allocationsudo cat /sys/kernel/debug/gpio Output: GPIOs 0-53, platform/3f200000.gpio, pinctrl-bcm2835: gpio-12 ( |wakeup ) out lo gpio-13 ( |reset ) out hi GPIOs 100-101, platform/soc:virtgpio, brcmvirt-gpio, can sleep: gpio-100 ( |? ) out lo Check that wakeup and reset are properly allocated SDIO Simplified Specification referenceWhen looking for reference information on SDIO detection please download the `SDIO Simplified Specification` PDF from https://www.sdcard.org/downloads/pls/index.html (Version 3.0 from July, 25, 2018 at the time of writing) On pages 18/19, Figure 3.2 : Card Initialization Flow in SD mode (SDIO Aware Host) corresponds to our use case. The following abstracts show the path WF200 should take during init.
If your startup traces don't follow this path, you probably have a HW issue, which could be related to
Specifics of using a processor which stops the clock after CMD0There is a specific way of handling the SD_CLK in some (i.e. OMAP, at least) processors, which are stopping SD_CLK a couple cycles after the end of the CMD0 command, without waiting for a response. Our part attempts to send a response to CMD0 and needs a valid clock to do so, so detection fails right after CMD0 (all commands report a timeout). You need to apply the attached patch in your case, and add the 'mmc-reply-go-idle' property in your device tree:
|
10 days ago |
|
Marc Dorval
|
Updated KBA: WF200 Linux Driver kernel releases support on Wi-Fi Knowledge Base Show more |
13 days ago |
|
Marc Dorval
|
Updated KBA: WF200 Linux Driver kernel releases support on Wi-Fi Knowledge Base Show more |
13 days ago |
|
Marc Dorval
|
Updated KBA: WF200 Linux Driver kernel releases support on Wi-Fi Knowledge Base Show more |
13 days ago |
|
Marc Dorval
|
Updated KBA: WF200 Linux Driver kernel releases support on Wi-Fi Knowledge Base Show more |
13 days ago |
|
Marc Dorval
|
Updated
Linux SDIO detection on Wi-Fi Knowledge Base
Linux SDIO part detection on the SDIO busUnder Linux, SDIO parts are bound to the mmc bus. Before using a Wi-Fi part connected to the SDIO bus of a Linux system, it is necessary that the system detects the HW on the bus. When detection succeeds, the kernel has retrieved the VID/PID for the device. Looking for a driver matching the VID/PID is only possible if the VID/PID has been retrieved from the device.
Linux systems will try to detect SDIO parts on the bus at boot, and every time the mmc bus is bound. Unbinding/binding the mmc bus is what we will use to trace mmc messages related to SDIO detection. SDIO Detection messageThe following message should be visible in dmesg once boot is complete: mmcX new high speed SDIO card at address 0001 one-line check:
If this message is not found, it is necessary to debug SDIO detection, going through the following steps:
These steps are detailed below.
Retrieving the current device treeRefer to Linux Device Tree Debugging for information on retrieving the device tree content in a file. Debugging device tree issues by comparison
Making sure SDIO is enabled in Device TreeIn order for the Linux system to try detecting a part on the SDIO bus, the SDIO bus needs to be part of the Device Tree used at boot. one-line check (SDIO pins selection):
Typical result:
sdio_pins = "/soc/gpio@7e200000/sdio_pins";
sdio_pins {
If this returns an empty line, SDIO detection is not even triggered. Refer to your system documentation to know how to add SDIO to the device tree.
Checking which mmc bus is used for SDIOone-line check (SDIO mmc bus selection):
The result should contain: mmc1 = "/soc/sdio@7e300000"; or (depending on the kernel, i.e. the device tree version) mmc = "/soc/mmc@7e300000"; If this returns an empty line, SDIO is not connected to any mmc bus. Refer to your system documentation to know how to add SDIO to the device tree. Checking the mmc bus commands during the SDIO detection phase
This is the trickiest part, since it involves tracking message normally issued at boot, when the system is attempting SDIO detection. In reality, these are issued every time the mmc bus is bound to the system, so unbinding/binding the mmc bus will trigger a new detection attempt. We use this to avoid activating the traces at boot time, since this is not easy to do. Preparing the kernel event traces (to be executed with root privileges):
Not tracing mmc CMD53 (once working in high-speed mode, to avoid being overloaded with traces once detected):
Tracing the kernel events on mmc1 (adapt the mmc to your own use case):
Unbinding/Binding the mmc bus to trigger a reset and reload the driver:
Typical traces (limited view zooming on 'cmd_opcode' due to extra long lines):
Stopping mmc request traces (once the traces have been retrieved): This step is necessary to stop tracing, which is otherwise still active. No additional traces are shown because SDIO traffic only uses CMD53 once detection is complete, and CMD53 are filtered out. It is better to stop tracing completely.
Checking the SDIO detection result
If detection is correct, the 'mmcX new high speed SDIO card at address 0001' message is present in dmesg. Otherwise, check for errors related to the mmc item corresponding to your part. SDIO pins used for the detection phaseThe SDIO detection as shown above only uses SD_CMD and SD_CLK pins, and is generally performed with a 400kHz SD_CLK. SD_DAT[3:0] are not used yet, so SDIO detection may succeed even though SD_DAT[3:0] are not properly routed. Host stopping clock after CMD0Some hosts will stop the SD-CLK clock right after issuing the CMD0 (MMC_GO_IDLE) command. This is because the SDIO specification does not require a response to CMD0. In this case, the SDIO detection flow will get interrupted after CMD0, and will not show CMD5, CMD52, etc. To solve this, apply the patch described at the end of this article in 'Specifics of using a processor which stops the clock after CMD0' Max SDIO speed too highDuring the last steps of SDIO detection, the SoC sets the SDIO part to 'high-speed' mode on 4 data bits, then configures its own hardware to the maximum selected SDIO speed (controllable in the device tree) only at the very end of the SDIO detection, after a long series of about 26 CMD52 commands. There is a SDIO speed limitation with BRD8022/BRD8023 due to the onboard switches. For this reason, we need to reduce the SDIO clock speed. 25 MHz is generally a good choice, given that choices are limited and vary depending on the platform. In case there are issues related to the max clock speed, the last CMD52 commands will return with 'cmd_err=-110' (which means 'TIMEOUT'), and will be followed by a short burst of about 4 CMD55 commands. Whenever the SDIO detection loop fails, it is repeated with a slower clock speed (400, 300, 200, 100 kHz, respectively), but is still ending with the max clock. If the max clock is too high, all 4 loops will eventually fail, therefore the traces will show 4 repeated patterns of: CMD52 In this case, check your device tree documentation to check how to reduce the maximum SDIO clock. Checking the SDIO clock speedsudo cat /sys/kernel/debug/mmc1/ios Output: clock: 50000000 Hz actual clock: 25000000 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) Checking GPIO allocationsudo cat /sys/kernel/debug/gpio Output: GPIOs 0-53, platform/3f200000.gpio, pinctrl-bcm2835: gpio-12 ( |wakeup ) out lo gpio-13 ( |reset ) out hi GPIOs 100-101, platform/soc:virtgpio, brcmvirt-gpio, can sleep: gpio-100 ( |? ) out lo Check that wakeup and reset are properly allocated SDIO Simplified Specification referenceWhen looking for reference information on SDIO detection please download the `SDIO Simplified Specification` PDF from https://www.sdcard.org/downloads/pls/index.html (Version 3.0 from July, 25, 2018 at the time of writing) On pages 18/19, Figure 3.2 : Card Initialization Flow in SD mode (SDIO Aware Host) corresponds to our use case. The following abstracts show the path WF200 should take during init.
If your startup traces don't follow this path, you probably have a HW issue, which could be related to
Specifics of using a processor which stops the clock after CMD0There is a specific way of handling the SD_CLK in some (i.e. OMAP, at least) processors, which are stopping SD_CLK a couple cycles after the end of the CMD0 command, without waiting for a response. Our part attempts to send a response to CMD0 and needs a valid clock to do so, so detection fails right after CMD0 (all commands report a timeout). You need to apply the attached patch in your case, and add the 'mmc-reply-go-idle' property in your device tree:
|
16 days ago |
|
Marc Dorval
|
Updated
Linux SDIO detection on Wi-Fi Knowledge Base
Linux SDIO part detection on the SDIO busUnder Linux, SDIO parts are bound to the mmc bus. Before using a Wi-Fi part connected to the SDIO bus of a Linux system, it is necessary that the system detects the HW on the bus. When detection succeeds, the kernel has retrieved the VID/PID for the device. Looking for a driver matching the VID/PID is only possible if the VID/PID has been retrieved from the device.
Linux systems will try to detect SDIO parts on the bus at boot, and every time the mmc bus is bound. Unbinding/binding the mmc bus is what we will use to trace mmc messages related to SDIO detection. SDIO Detection messageThe following message should be visible in dmesg once boot is complete: mmcX new high speed SDIO card at address 0001 one-line check:
If this message is not found, it is necessary to debug SDIO detection, going through the following steps:
These steps are detailed below.
Retrieving the current device treeRefer to Linux Device Tree Debugging for information on retrieving the device tree content in a file. Debugging device tree issues by comparison
Making sure SDIO is enabled in Device TreeIn order for the Linux system to try detecting a part on the SDIO bus, the SDIO bus needs to be part of the Device Tree used at boot. one-line check (SDIO pins selection):
Typical result:
sdio_pins = "/soc/gpio@7e200000/sdio_pins";
sdio_pins {
If this returns an empty line, SDIO detection is not even triggered. Refer to your system documentation to know how to add SDIO to the device tree.
Checking which mmc bus is used for SDIOone-line check (SDIO mmc bus selection):
The result should contain: mmc1 = "/soc/sdio@7e300000"; or (depending on the kernel, i.e. the device tree version) mmc = "/soc/mmc@7e300000"; If this returns an empty line, SDIO is not connected to any mmc bus. Refer to your system documentation to know how to add SDIO to the device tree. Checking the mmc bus commands during the SDIO detection phase
This is the trickiest part, since it involves tracking message normally issued at boot, when the system is attempting SDIO detection. In reality, these are issued every time the mmc bus is bound to the system, so unbinding/binding the mmc bus will trigger a new detection attempt. We use this to avoid activating the traces at boot time, since this is not easy to do. Preparing the kernel event traces (to be executed with root privileges):
Not tracing mmc CMD53 (once working in high-speed mode, to avoid being overloaded with traces once detected):
Tracing the kernel events on mmc1 (adapt the mmc to your own use case):
Unbinding/Binding the mmc bus to trigger a reset and reload the driver:
Typical traces (limited view zooming on 'cmd_opcode' due to extra long lines):
Stopping mmc request traces (once the traces have been retrieved): This step is necessary to stop tracing, which is otherwise still active. No additional traces are shown because SDIO traffic only uses CMD53 once detection is complete, and CMD53 are filtered out. It is better to stop tracing completely.
Checking the SDIO detection result
If detection is correct, the 'mmcX new high speed SDIO card at address 0001' message is present in dmesg. Otherwise, check for errors related to the mmc item corresponding to your part. SDIO pins used for the detection phaseThe SDIO detection as shown above only uses SD_CMD and SD_CLK pins, and is generally performed with a 400kHz SD_CLK. SD_DAT[3:0] are not used yet, so SDIO detection may succeed even though SD_DAT[3:0] are not properly routed. Host stopping clock after CMD0Some hosts will stop the SD-CLK clock right after issuing the CMD0 (MMC_GO_IDLE) command. This is because the SDIO specification does not require a response to CMD0. In this case, the SDIO detection flow will get interrupted after CMD0, and will not show CMD5, CMD52, etc. To solve this, apply the patch described at the end of this article in 'Specifics of using a processor which stops the clock after CMD0' Max SDIO speed too highDuring the last steps of SDIO detection, the SoC sets the SDIO part to 'high-speed' mode on 4 data bits, then configures its own hardware to the maximum selected SDIO speed (controllable in the device tree) only at the very end of the SDIO detection, after a long series of about 26 CMD52 commands. In case there are issues related to the max clock speed, the last CMD52 commands will return with 'cmd_err=-110' (which means 'TIMEOUT'), and will be followed by a short burst of about 4 CMD55 commands. Whenever the SDIO detection loop fails, it is repeated with a slower clock speed (400, 300, 200, 100 kHz, respectively), but is still ending with the max clock. If the max clock is too high, all 4 loops will eventually fail, therefore the traces will show 4 repeated patterns of: CMD52 In this case, check your device tree documentation to check how to reduce the maximum SDIO clock. Checking GPIO allocationsudo cat /sys/kernel/debug/gpio Output: GPIOs 0-53, platform/3f200000.gpio, pinctrl-bcm2835: gpio-12 ( |wakeup ) out lo gpio-13 ( |reset ) out hi GPIOs 100-101, platform/soc:virtgpio, brcmvirt-gpio, can sleep: gpio-100 ( |? ) out lo Check that wakeup and reset are properly allocated SDIO Simplified Specification referenceWhen looking for reference information on SDIO detection please download the `SDIO Simplified Specification` PDF from https://www.sdcard.org/downloads/pls/index.html (Version 3.0 from July, 25, 2018 at the time of writing) On pages 18/19, Figure 3.2 : Card Initialization Flow in SD mode (SDIO Aware Host) corresponds to our use case. The following abstracts show the path WF200 should take during init.
If your startup traces don't follow this path, you probably have a HW issue, which could be related to
Specifics of using a processor which stops the clock after CMD0There is a specific way of handling the SD_CLK in some (i.e. OMAP, at least) processors, which are stopping SD_CLK a couple cycles after the end of the CMD0 command, without waiting for a response. Our part attempts to send a response to CMD0 and needs a valid clock to do so, so detection fails right after CMD0 (all commands report a timeout). You need to apply the attached patch in your case, and add the 'mmc-reply-go-idle' property in your device tree:
|
17 days ago |
|
Marc Dorval
|
Updated
Linux SDIO detection on Wi-Fi Knowledge Base
Linux SDIO part detection on the SDIO busUnder Linux, SDIO parts are bound to the mmc bus. Before using a Wi-Fi part connected to the SDIO bus of a Linux system, it is necessary that the system detects the HW on the bus. When detection succeeds, the kernel has retrieved the VID/PID for the device. Looking for a driver matching the VID/PID is only possible if the VID/PID has been retrieved from the device.
Linux systems will try to detect SDIO parts on the bus at boot, and every time the mmc bus is bound. Unbinding/binding the mmc bus is what we will use to trace mmc messages related to SDIO detection. SDIO Detection messageThe following message should be visible in dmesg once boot is complete: mmcX new high speed SDIO card at address 0001 one-line check:
If this message is not found, it is necessary to debug SDIO detection, going through the following steps:
These steps are detailed below.
Retrieving the current device treeRefer to Linux Device Tree Debugging for information on retrieving the device tree content in a file. Debugging device tree issues by comparison
Making sure SDIO is enabled in Device TreeIn order for the Linux system to try detecting a part on the SDIO bus, the SDIO bus needs to be part of the Device Tree used at boot. one-line check (SDIO pins selection):
Typical result:
sdio_pins = "/soc/gpio@7e200000/sdio_pins";
sdio_pins {
If this returns an empty line, SDIO detection is not even triggered. Refer to your system documentation to know how to add SDIO to the device tree.
Checking which mmc bus is used for SDIOone-line check (SDIO mmc bus selection):
The result should contain: mmc1 = "/soc/sdio@7e300000"; or (depending on the kernel, i.e. the device tree version) mmc = "/soc/mmc@7e300000"; If this returns an empty line, SDIO is not connected to any mmc bus. Refer to your system documentation to know how to add SDIO to the device tree. Checking the mmc bus commands during the SDIO detection phase
This is the trickiest part, since it involves tracking message normally issued at boot, when the system is attempting SDIO detection. In reality, these are issued every time the mmc bus is bound to the system, so unbinding/binding the mmc bus will trigger a new detection attempt. We use this to avoid activating the traces at boot time, since this is not easy to do. Preparing the kernel event traces (to be executed with root privileges):
Not tracing mmc CMD53 (once working in high-speed mode, to avoid being overloaded with traces once detected):
Tracing the kernel events on mmc1 (adapt the mmc to your own use case):
Unbinding/Binding the mmc bus to trigger a reset and reload the driver:
Typical traces (limited view zooming on 'cmd_opcode' due to extra long lines):
Stopping mmc request traces (once the traces have been retrieved): This step is necessary to stop tracing, which is otherwise still active. No additional traces are shown because SDIO traffic only uses CMD53 once detection is complete, and CMD53 are filtered out. It is better to stop tracing completely.
Checking the SDIO detection result
If detection is correct, the 'mmcX new high speed SDIO card at address 0001' message is present in dmesg. Otherwise, check for errors related to the mmc item corresponding to your part. SDIO pins used for the detection phaseThe SDIO detection as shown above only uses SD_CMD and SD_CLK pins, and is generally performed with a 400kHz SD_CLK. SD_DAT[3:0] are not used yet, so SDIO detection may succeed even though SD_DAT[3:0] are not properly routed. Max SDIO speed too highDuring the last steps of SDIO detection, the SoC sets the SDIO part to 'high-speed' mode on 4 data bits, then configures its own hardware to the maximum selected SDIO speed (controllable in the device tree) only at the very end of the SDIO detection, after a long series of about 26 CMD52 commands. In case there are issues related to the max clock speed, the last CMD52 commands will return with 'cmd_err=-110' (which means 'TIMEOUT'), and will be followed by a short burst of about 4 CMD55 commands. Whenever the SDIO detection loop fails, it is repeated with a slower clock speed (400, 300, 200, 100 kHz, respectively), but is still ending with the max clock. If the max clock is too high, all 4 loops will eventually fail, therefore the traces will show 4 repeated patterns of: CMD52 In this case, check your device tree documentation to check how to reduce the maximum SDIO clock. Checking GPIO allocationsudo cat /sys/kernel/debug/gpio Output: GPIOs 0-53, platform/3f200000.gpio, pinctrl-bcm2835: gpio-12 ( |wakeup ) out lo gpio-13 ( |reset ) out hi GPIOs 100-101, platform/soc:virtgpio, brcmvirt-gpio, can sleep: gpio-100 ( |? ) out lo Check that wakeup and reset are properly allocated SDIO Simplified Specification referenceWhen looking for reference information on SDIO detection please download the `SDIO Simplified Specification` PDF from https://www.sdcard.org/downloads/pls/index.html (Version 3.0 from July, 25, 2018 at the time of writing) On pages 18/19, Figure 3.2 : Card Initialization Flow in SD mode (SDIO Aware Host) corresponds to our use case. The following abstracts show the path WF200 should take during init.
If your startup traces don't follow this path, you probably have a HW issue, which could be related to
Specifics of using an OMAP processorThere is a specific way of handling the SD_CLK in OMAP processors, which are stopping SD_CLK a couple cycles after the end of the CMD0 command, without waiting for a response. Our part attempts to send a response to CMD0 and needs a valid clock to do so, so detection fails right after CMD0 (all commands report a timeout). You need to apply the attached patch in your case, and add the 'mmc-reply-go-idle' property in your device tree:
|
17 days ago |
|
Marc Dorval
|
Updated
Linux SDIO detection on Wi-Fi Knowledge Base
Linux SDIO part detection on the SDIO busUnder Linux, SDIO parts are bound to the mmc bus. Before using a Wi-Fi part connected to the SDIO bus of a Linux system, it is necessary that the system detects the HW on the bus. When detection succeeds, the kernel has retrieved the VID/PID for the device. Looking for a driver matching the VID/PID is only possible if the VID/PID has been retrieved from the device.
Linux systems will try to detect SDIO parts on the bus at boot, and every time the mmc bus is bound. Unbinding/binding the mmc bus is what we will use to trace mmc messages related to SDIO detection. SDIO Detection messageThe following message should be visible in dmesg once boot is complete: mmcX new high speed SDIO card at address 0001 one-line check:
If this message is not found, it is necessary to debug SDIO detection, going through the following steps:
These steps are detailed below.
Retrieving the current device treeRefer to Linux Device Tree Debugging for information on retrieving the device tree content in a file. Debugging device tree issues by comparison
Making sure SDIO is enabled in Device TreeIn order for the Linux system to try detecting a part on the SDIO bus, the SDIO bus needs to be part of the Device Tree used at boot. one-line check (SDIO pins selection):
Typical result:
sdio_pins = "/soc/gpio@7e200000/sdio_pins";
sdio_pins {
If this returns an empty line, SDIO detection is not even triggered. Refer to your system documentation to know how to add SDIO to the device tree.
Checking which mmc bus is used for SDIOone-line check (SDIO mmc bus selection):
The result should contain: mmc1 = "/soc/sdio@7e300000"; or (depending on the kernel, i.e. the device tree version) mmc = "/soc/mmc@7e300000"; If this returns an empty line, SDIO is not connected to any mmc bus. Refer to your system documentation to know how to add SDIO to the device tree. Checking the mmc bus commands during the SDIO detection phase
This is the trickiest part, since it involves tracking message normally issued at boot, when the system is attempting SDIO detection. In reality, these are issued every time the mmc bus is bound to the system, so unbinding/binding the mmc bus will trigger a new detection attempt. We use this to avoid activating the traces at boot time, since this is not easy to do. Preparing the kernel event traces (to be executed with root privileges):
Not tracing mmc CMD53 (once working in high-speed mode, to avoid being overloaded with traces once detected):
Tracing the kernel events on mmc1 (adapt the mmc to your own use case):
Unbinding/Binding the mmc bus to trigger a reset and reload the driver:
Typical traces (limited view zooming on 'cmd_opcode' due to extra long lines):
Stopping mmc request traces (once the traces have been retrieved): This step is necessary to stop tracing, which is otherwise still active. No additional traces are shown because SDIO traffic only uses CMD53 once detection is complete, and CMD53 are filtered out. It is better to stop tracing completely.
Checking the SDIO detection result
If detection is correct, the 'mmcX new high speed SDIO card at address 0001' message is present in dmesg. Otherwise, check for errors related to the mmc item corresponding to your part. SDIO pins used for the detection phaseThe SDIO detection as shown above only uses SD_CMD and SD_CLK pins, and is generally performed with a 400kHz SD_CLK. SD_DAT[3:0] are not used yet, so SDIO detection may succeed even though SD_DAT[3:0] are not properly routed. Max SDIO speed too highDuring the last steps of SDIO detection, the SoC sets the SDIO part to 'high-speed' mode on 4 data bits, then configures its own hardware to the maximum selected SDIO speed (controllable in the device tree) only at the very end of the SDIO detection, after a long series of about 26 CMD52 commands. In case there are issues related to the max clock speed, the last CMD52 commands will return with 'cmd_err=-110' (which means 'TIMEOUT'), and will be followed by a short burst of about 4 CMD55 commands. Whenever the SDIO detection loop fails, it is repeated with a slower clock speed (400, 300, 200, 100 kHz, respectively), but is still ending with the max clock. If the max clock is too high, all 4 loops will eventually fail, therefore the traces will show 4 repeated patterns of: CMD52 In this case, check your device tree documentation to check how to reduce the maximum SDIO clock. Checking GPIO allocationsudo cat /sys/kernel/debug/gpio Output: GPIOs 0-53, platform/3f200000.gpio, pinctrl-bcm2835: gpio-12 ( |wakeup ) out lo gpio-13 ( |reset ) out hi GPIOs 100-101, platform/soc:virtgpio, brcmvirt-gpio, can sleep: gpio-100 ( |? ) out lo Check that wakeup and reset are properly allocated SDIO Simplified Specification referenceWhen looking for reference information on SDIO detection please download the `SDIO Simplified Specification` PDF from https://www.sdcard.org/downloads/pls/index.html (Version 3.0 from July, 25, 2018 at the time of writing) On pages 18/19, Figure 3.2 : Card Initialization Flow in SD mode (SDIO Aware Host) corresponds to our use case. The following abstracts show the path WF200 should take during init.
If your startup traces don't follow this path, you probably have a HW issue, which could be related to
Specifics of using an OMAP processorThere is a specific way of handling the SD_CLK in OMAP processors, which are stopping SD_CLK a couple cycles after the end of the CMD0 command, without waiting for a response. Our part attempts to send a response to CMD0 and needs a valid clock to do so, so detection fails right after CMD0 (all commands report a timeout). You need to apply the attached patch in your case, and add the 'mmc-reply-go-idle' property in your device tree:
|
17 days ago |
|
Marc Dorval
|
Updated
Linux SDIO detection on Wi-Fi Knowledge Base
Linux SDIO part detection on the SDIO busUnder Linux, SDIO parts are bound to the mmc bus. Before using a Wi-Fi part connected to the SDIO bus of a Linux system, it is necessary that the system detects the HW on the bus. When detection succeeds, the kernel has retrieved the VID/PID for the device. Looking for a driver matching the VID/PID is only possible if the VID/PID has been retrieved from the device.
Linux systems will try to detect SDIO parts on the bus at boot, and every time the mmc bus is bound. Unbinding/binding the mmc bus is what we will use to trace mmc messages related to SDIO detection. SDIO Detection messageThe following message should be visible in dmesg once boot is complete: mmcX new high speed SDIO card at address 0001 one-line check:
If this message is not found, it is necessary to debug SDIO detection, going through the following steps:
These steps are detailed below.
Retrieving the current device treeRefer to Linux Device Tree Debugging for information on retrieving the device tree content in a file. Debugging device tree issues by comparison
Making sure SDIO is enabled in Device TreeIn order for the Linux system to try detecting a part on the SDIO bus, the SDIO bus needs to be part of the Device Tree used at boot. one-line check (SDIO pins selection):
Typical result:
sdio_pins = "/soc/gpio@7e200000/sdio_pins";
sdio_pins {
If this returns an empty line, SDIO detection is not even triggered. Refer to your system documentation to know how to add SDIO to the device tree.
Checking which mmc bus is used for SDIOone-line check (SDIO mmc bus selection):
The result should contain: mmc1 = "/soc/sdio@7e300000"; or (depending on the kernel, i.e. the device tree version) mmc = "/soc/mmc@7e300000"; If this returns an empty line, SDIO is not connected to any mmc bus. Refer to your system documentation to know how to add SDIO to the device tree. Checking the mmc bus commands during the SDIO detection phase
This is the trickiest part, since it involves tracking message normally issued at boot, when the system is attempting SDIO detection. In reality, these are issued every time the mmc bus is bound to the system, so unbinding/binding the mmc bus will trigger a new detection attempt. We use this to avoid activating the traces at boot time, since this is not easy to do. Preparing the kernel event traces (to be executed with root privileges):
Not tracing mmc CMD53 (once working in high-speed mode, to avoid being overloaded with traces once detected):
Tracing the kernel events on mmc1 (adapt the mmc to your own use case):
Unbinding/Binding the mmc bus to trigger a reset and reload the driver:
Typical traces (limited view zooming on 'cmd_opcode' due to extra long lines):
Stopping mmc request traces (once the traces have been retrieved): This step is necessary to stop tracing, which is otherwise still active. No additional traces are shown because SDIO traffic only uses CMD53 once detection is complete, and CMD53 are filtered out. It is better to stop tracing completely.
Checking the SDIO detection result
If detection is correct, the 'mmcX new high speed SDIO card at address 0001' message is present in dmesg. Otherwise, check for errors related to the mmc item corresponding to your part. SDIO pins used for the detection phaseThe SDIO detection as shown above only uses SD_CMD and SD_CLK pins, and is generally performed with a 400kHz SD_CLK. SD_DAT[3:0] are not used yet, so SDIO detection may succeed even though SD_DAT[3:0] are not properly routed. Max SDIO speed too highDuring the last steps of SDIO detection, the SoC sets the SDIO part to 'high-speed' mode on 4 data bits, then configures its own hardware to the maximum selected SDIO speed (controllable in the device tree) only at the very end of the SDIO detection, after a long series of about 26 CMD52 commands. In case there are issues related to the max clock speed, the last CMD52 commands will return with 'cmd_err=-110' (which means 'TIMEOUT'), and will be followed by a short burst of about 4 CMD55 commands. Whenever the SDIO detection loop fails, it is repeated with a slower clock speed (400, 300, 200, 100 kHz, respectively), but is still ending with the max clock. If the max clock is too high, all 4 loops will eventually fail, therefore the traces will show 4 repeated patterns of: CMD52 In this case, check your device tree documentation to check how to reduce the maximum SDIO clock. Checking GPIO allocationsudo cat /sys/kernel/debug/gpio Output: GPIOs 0-53, platform/3f200000.gpio, pinctrl-bcm2835: gpio-12 ( |wakeup ) out lo gpio-13 ( |reset ) out hi GPIOs 100-101, platform/soc:virtgpio, brcmvirt-gpio, can sleep: gpio-100 ( |? ) out lo Check that wakeup and reset are properly allocated SDIO Simplified Specification referenceWhen looking for reference information on SDIO detection please download the `SDIO Simplified Specification` PDF from https://www.sdcard.org/downloads/pls/index.html (Version 3.0 from July, 25, 2018 at the time of writing) On pages 18/19, Figure 3.2 : Card Initialization Flow in SD mode (SDIO Aware Host) corresponds to our use case. The following abstracts show the path WF200 should take during init.
If your startup traces don't follow this path, you probably have a HW issue, which could be related to
Specifics of using an OMAP processorThere is a specific way of handling the SD_CLK in OMAP processors, which are stopping SD_CLK a couple cycles after the end of the CMD0 command, without waiting for a response. Our part attempts to send a response to CMD0 and needs a valid clock to do so, so detection fails right after CMD0 (all commands report a timeout). You need to apply the attached patch in your case, and add the 'mmc-reply-go-idle' property in your device tree:
|
17 days ago |
Level 5
Level 4
Level 3
Level 1