Driver crashes on modprobe

al177 / esp8089

Linux kernel module driver for the ESP8089 WiFi chip

GNU General Public License v2.0

184 stars 114 forks source link

Driver crashes on modprobe #9

Closed tomkcook closed 7 years ago

tomkcook commented 7 years ago

I've got this building for an old-type raspberry pi zero, but when the module loads, it dies with a null pointer dereference somewhere in esp_sdio_init. I've got kgdb connected to the target, but it's rather difficult setting a breakpoint in that function as it's not possible to know its address until the module is loaded... when it's too late.

Do you have any tips for debugging this? Things I can think of that might help:

If there's some way of setting a breakpoint on things that happen just after a module is loaded that I've not managed to find by google.
If it's a problem you've seen before and have some idea what it might be.
If there's some straightforward way of building the driver into the kernel instead of as a module, that would make setting breakpoints a lot easier.

Thanks for any help.

girst commented 7 years ago

I might misremember this, but I think I had the same/similar issue, when I accidentally had the ESP's reset pin already used for some other peripheral.

al177 commented 7 years ago

It could also be the internal pulldown for CH_PD not being sufficient. I've run across a number of ESP-12F modules where it wouldn't come out of reset or would initialize but flake out in the manner you described unless I put a 10k pulldown on CH_PD.

tomkcook commented 7 years ago

Hey, thanks for getting back to me so quickly. It does look like something of that sort -it usually crashes but sometimes it'll just fail with "no such device" and sometimes it fails to initialise in some other way.

If the pull-down on CH_PD is not enough, do you ever need pull-downs on the other pins? I've got 33 ohm resistors in line with them, but should i have a pull-down on each sdio pin as well?

tomkcook commented 7 years ago

A few things to report back:

Pulling CH_PD down to ground with 10k does not work. This reduces the high-level voltage on this line to somewhere around 1V - it looks like the ESP actually has an internal pull-up and these are making a voltage divider. Did you mean an external pull-up?
At any rate, the scope shows a nice, clean square wave on CH_PD. The Pi is holding it low for just over 200ms when it's trying to reset it - the rise time 0-3V is ~6us, the fall time is much faster - about 20ns.
The data, command and clock lines show fairly similar, nice, clean square waves. There's a little ringing visible on the corners, but as square waves go they look pretty good.
I've added the jumper to switch it to the 1-bit interface but get exactly the same result.

Any pointers on debugging this would be greatly appreciated!

tomkcook commented 7 years ago

(slightly) more information: the kernel crash is not happening in esp_sdio_probe but elsewhere as a result of a failure in that function. esp_sdio_probe is failing because the call to esp_download_fw in esp_pub_init_all is returning -84. AFAICT, this value comes out of the MMC driver, being the return value of mmc_io_rw_extended.

tomkcook commented 7 years ago

False alarm, folks: A badly-soldered resistor on the D3 line.

al177 commented 7 years ago

Glad to hear you have it working now!

tomkcook commented 7 years ago

When I get some time, I'll look into why this causes a kernel crash; it should handle it cleanly. That should about 2025 some time...