esp-hosted-fg SDIO questions

[gdaneels]

Hi,

I am trying out the esp-hosted first generation with SDIO.

I have 3 questions:

• I am using the ESP32 Wrover Kit (with the ESP-WROVER-B module onboard). On the troubleshoot page, it says it is best to use this board (because the required pull-ups are present). However, when I read the Espressif's docs, I also read that there are 2 more issues (Pull-up conflicts on GPIO13 and conflicts between bootstrap and SDIO on GPIO12). Do we have to resolve these issues on our Wrover Kit as well (as suggestd on the page), or are these not a problem for the esp-hosted-fg?

• When compiling the kernel module out-of-the-box (for iMX6UL, kernel 5.4.210+gf2663e3, yocto build (dunfell)), I get the error that LINUX_VERSION_CODE and KERNEL_VERSION are not defined (see attached log). This is easily fixed by including <linux/version.h> in esp.h (see attached patch). Am I the only experiencing this issue?

• Concerning SDIO support, I've read on the issues threads and in the docs, that SDIO support will come for ESP32-C6. Is there any update on this? This support will be for both the first and next generation esp-hosted? In addition, is there any particular reason there will not be any SDIO support for the ESP32-C3 and ESP32-S3 (or will they also be supported)?

Thanks in advance.

linux-version.log
esp_linux_version_patch.txt

[mantriyogesh]

1. Yes the issues have to be addressed even for ESP32-Wrover-Kit if the SDIO is not detected / working with your Linux.
   We recommend to add external pull-ups and lower the jumper wires length (< 6cm). Ideally PCB with external pulls will be beneficial. The problem is of SDIO protocol. It is prone to signal integrity.
2. Okay, we did not face this issue, but we will add this line as it is better to do if it fails on some Linux platforms.
3. SDIO support with ESP32-C6 is taking time because of underlying (ESP-IDF) DMA related issues. ESP32-C3 and ESP32-S3 do not have 'SDIO slave' devices. you can use in 'SPI slave' mode for them.

[gdaneels]

Hi @mantriyogesh,

Thanks for the answer.

I do have additional questions about the first question/answer, to have a clear picture of what I have to do to prepare the WROVER-kit (ESP-WROVER-B module onboard) correctly.

First question, the ESP-HOSTED implementation uses 4-bit SD mode, as we have to connect the 4 data lines, correct?

Second question, you state:

We recommend to add external pull-ups and lower the jumper wires length (< 6cm).

Do you mean I have to add additional external pull-ups to the CMD and DATA (DAT0 - DAT3) lines, even when the WROVER kit should have these pull-ups onboard? As the pull-ups are already there, I would think I do not have to add them. In the SDIO hardware setup picture, I don't see any extra resistors added?

Third question, should one always resolve these issues ("Conflicts Between Bootstrap and SDIO on DAT2" and Pull-up Conflicts on GPIO13") first before trying the ESP-HOSTED-FG over SDIO? Or is it possible that is also works without fixing them? In other words, are all WROVER kits always affected by these issues, or it depends from board to board?

Fourth question, to resolve "Conflicts Between Bootstrap and SDIO on DAT2", I can just burn the efuse, that's not a problem. But what option should I choose to resolve this issue "Pull-up Conflicts on GPIO13"? The given options are:

I guess the first 2 are not an options as we want to use 4-bit SDIO mode? What approach did you take, what is your advised option here to be compatible with ESP-HOSTED-FG?

Thanks in advance.

[mantriyogesh]

If you have exact same board, you can use the same board without any pull-ups, as same board without any modifications worked for us with Raspberry Pi.
Can you please send the setup diagram?

Can you please send the complete textual logs for esp and host (dmesg or /var/log/kern.log) to understand current situation?
It is possible that host is not correctly creating sd mmc instance.

[gdaneels]

Hi @mantriyogesh,

Indeed, we have the same WROVER kit.

Some snippets of our dmesg:

root@00049F06F55B:~# dmesg | grep sdhci
[ 0.960236] sdhci: Secure Digital Host Controller Interface driver
[ 0.960249] sdhci: Copyright(c) Pierre Ossman
[ 0.960260] sdhci-pltfm: SDHCI platform and OF driver helper
[ 0.963458] sdhci-esdhc-imx 2190000.usdhc: Got CD GPIO

root@00049F06F55B:~# dmesg | grep mmc
[ 0.997576] mmc0: SDHCI controller on 2190000.usdhc [2190000.usdhc] using ADMA
[ 1.032706] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
[ 1.068758] mmc1: host does not support reading read-only switch, assuming write-enable
[ 1.071084] mmc1: new high speed SDHC card at address 0001
[ 1.072769] mmcblk1: mmc1:0001 SD32G 28.8 GiB
[ 1.095968] mmcblk1: p1 p2 p3
[ 4.459119] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 18.077425] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

mmc1 is used for another attached microSD card. We should see activity for mmc0, but that is not happening.

These are the ESP32 logs:

root@00049F06F55B:~# dmesg | grep esp
[ 22.770194] esp_reset, ESP32: Resetpin of Host is 67
[ 22.770457] esp_reset, ESP32: Triggering ESP reset.

I do see the reset of the happening at the ESP32 side.

The complete dmesg file.

This is the ESP32 log (after the reset): esp32.txt. It seems that the ESP32 sdio slave is not detected.

[mantriyogesh]

I don't think it is mmc1 node. Please revisit your device tree changes and enable mmc which you are trying to connect with ESP32.

[mantriyogesh]

Just to be sure, add/enable sdmmc node mapped to sdio port you connected with ESP. add that note as hot pluggable. you may also want to use 'broken-cd;' or similar sdio parameters to your device tree.

once your mmc is detectedfor esp, you can just power off -> power on and the mmc detection prints should be displayed in /var/log/kern/log or dmesg.

Please note, these are prerequisite to get the platform up for ESP-Hosted.
Without platform not set, ESP-Hosted cannot be in effect.

[gdaneels]

I don't think it is mmc1 node. Please revisit your device tree changes and enable mmc which you are trying to connect with ESP32.

Indeed, that is what I mean. The sdmmc node that should be enabled is mmc0, not mmc1 (as this used by another sd card slot). So the log shows that nothing happens for mmc0, meaning there is something wrong with the detection of the ESP32 over SDIO. When I try this slot with a normal (micro)SD card, the card is detected without a problem. So I guess there is still an issue in my device tree so SDIO devices are not detected (indeed, maybe something with the CD line that is not there).

At the moment, my device tree looks like this:

&usdhc1 {
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_usdhc1>;
  no-1-8-v;
  broken-cd;
  status = "okay";
};

This was inspired by this Yocto port issue. I am still in the process of checking that there are conflicts/issues in the device tree. Do you notice important (device tree) properties missing?

[mantriyogesh]

Actually, all SoCs will have different instance names.
Better to check your dtsi and datasheet, accordingly you can change the device tree.

Even the device tree properties could be implemented by different SoCs differently. No single size fits all.

[gdaneels]

Hi,

I've got an update: I found out that I still had to enable the pull-ups flag SDIO_SLAVE_FLAG_INTERNAL_PULLUP in the sdio_init() function at the ESP32 side. I think it might be useful this is also mentioned in the docs (when using the wrover kit). I created a pull request to add this to the docs.

I am now running the raw TP test over SDIO, but the output is not what I was expecting:

• esp32-sdio.txt: this "restart new send" keeps happening with incrementing pkt_len
• imx6-sdio.txt, here I see 3 issues:

1. There seems to be an "Unsupported tag in event" of EVENT 2,
2. the throughput is limited to ~1600 kbit/s
3. I see some problems with Bluetooth.

Obviously something is still wrong, any ideas what could be the issue?

Thanks in advance.

[mantriyogesh]

Data throughput may be affected by the debug prints added.

I think better to do Raw throughput test, which will show you max throughput you can attain with current setup at transport
If it is small than expected, might have to check if & why packets dropped.

[mantriyogesh]

Unsupported tag event , seems fishy.
I doubt if the transport is yet correct.

Possible to add Rx and TX in esp and host if any packets are getting dropped.

On different note wrt data rate,
What is the frequency in use at host sdio?

[mantriyogesh]

If raw throughput is less (fails the test)
I think better to check Rx and TX debugs at both sides and match packets.
If Bluetooth disabled from esp (for debug), you can lower packets to compare.

[gdaneels]

Hi,

I disabled all debugging output (and Bluetooth support).

Data throughput may be affected by the debug prints added.

I think better to do Raw throughput test, which will show you max throughput you can attain with current setup at transport If it is small than expected, might have to check if & why packets dropped.

When running the raw throughput test from ESP32 to iMX6, I get:

        [  451.524415] 316-317 sec       16732 kbits/sec
        [  451.524415] 
        [  452.564440] 317-318 sec       17542 kbits/sec
        [  452.564440] 
        [  453.604442] 318-319 sec       16060 kbits/sec
        [  453.604442] 
        [  454.644478] 319-320 sec       17405 kbits/sec
        [  454.644478] 
        [  455.684470] 320-321 sec       16276 kbits/sec

From iMX6 to ESP32, I get:

        60-61 sec       42636.56 kbits/sec
        61-62 sec       42408.44 kbits/sec
        62-63 sec       42750.62 kbits/sec
        63-64 sec       42454.06 kbits/sec
        64-65 sec       42670.78 kbits/sec
        65-66 sec       34789.06 kbits/sec
        66-67 sec       42317.19 kbits/sec
        67-68 sec       42522.50 kbits/sec
        68-69 sec       42613.75 kbits/sec
        69-70 sec       40959.84 kbits/sec
        70-71 sec       42568.12 kbits/sec
        71-72 sec       42579.53 kbits/sec
        72-73 sec       42328.59 kbits/sec
        73-74 sec       38382.03 kbits/sec
        74-75 sec       36043.75 kbits/sec
        75-76 sec       42488.28 kbits/sec
        76-77 sec       35963.91 kbits/sec
        77-78 sec       42693.59 kbits/sec

Are these numbers to be expected? From ESP32 to iMX6 is significantly lower than the other direction.

Concerning the clock speed, looking at:

root@00049F06F55B:~# cat /sys/kernel/debug/mmc0/ios
clock:          25000000 Hz
actual clock:   22000000 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:    0 (legacy)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)

Should this be higher, 50 MHz?

I've also set the speed flag to SDIO_SLAVE_FLAG_HIGH_SPEED (instead of SDIO_SLAVE_FLAG_DEFAULT_SPEED) in sdio_init() at the ESP32 side, but this did not seem to have any effect on the clock in /sys/kernel/debug/mmc0/ios

.flags = SDIO_SLAVE_FLAG_INTERNAL_PULLUP | SDIO_SLAVE_FLAG_HIGH_SPEED,

[mantriyogesh]

Hello @gdaneels

Yes the throughput will be lower at Linux Rx because of kernel slow path.
You can change it to high speed.

Linux to Esp will be higher always.

[mantriyogesh]

Your might wish to check your SoC's Device tree as well to check what is max limit configured there.

[mantriyogesh]

please use STATION_MODE_LISTEN_INTERVAL as 3 when you come to Wi-Fi as station mode testing.
We will check-in this change. this will little bit improve upon Wi-Fi throughput.

File:
esp_hosted_fg/host/linux/host_control/c_support/ctrl_config.h

[mantriyogesh]

JFYI, ESP32-C6 support for SDIO is added for Linux.