Open gdaneels opened 1 year ago
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.
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.
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.
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.
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.
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?
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.
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:
Obviously something is still wrong, any ideas what could be the issue?
Thanks in advance.
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.
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?
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.
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,
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.
Your might wish to check your SoC's Device tree as well to check what is max limit configured there.
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
JFYI, ESP32-C6 support for SDIO is added for Linux.
Hi,
I am trying out the esp-hosted first generation with SDIO.
I have 3 questions:
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
andKERNEL_VERSION
are not defined (see attached log). This is easily fixed by including<linux/version.h>
inesp.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