SD card fails for Kernel (error -110), but works in uboot

[Thomas K]

Dear ladies and gentlemen,

are using an OSD3358-512M-BSM in the same configuration as in the Pocketbeagle on a custom board.  The board loads uboot fine, but the SD card is not accessible for the kernel. Once loaded, the kernel complains:

sdhci-omap 48060000.mmc: error -110 requesting status

and the rootfs is not accessible. The complete output through UART is attached.

Among others we have used this image:

https://rcn-ee.com/rootfs/bb.org/testing/2023-04-06/buster-console-armhf/BBB-blank-debian-10.13-console-armhf-2023-04-06-1gb.img.xz

The SD card is connected to the MMC0 pins like in the pocketbeagle with pull-up resistors of 10k to SYS_VDD1_3P3V.

Concerning u-boot we tried the default version and a custom compiled one with the empty eeprom patch and without. Since u-boot is accessible through the UART-pins, we were able to program the eeprom to an identical value of a pocketbeagle which boots the images just fine.

What we tried so far:

– different SD-cards by different manufacturers of different sizes

– different images on the SD card

– different SD-card frequencies through the device tree settings (50 MHz down to 12.5 MHz)

– kernel 4.14, 4.19 and 5.10

– verify the SD clock signal, since the pocketbeagle and our board has no serial resistance in the clock line. The trace length is only 20 mm, but still. Scope captures are attached and look okay, although our clock is certainly not better than on the pocketbeagle.

– verify the 3.3 V for the SD card (=SYS_VDD1_3P3V), it is sitting at 3.4 V just nicely without glitches.

Since the kernel is read properly by uboot from any of the tried cards, we suspect the problem to be somewhere in the kernel device tree but since the same device tree works with the pocketbeagle and the connections are the same, we are our of ideas and would be very grateful for any suggestions!

Thank you and best regards,

Thomas

Attachments:

1. 

   Clock_board.jpg
   

2. 

   Clock_PocketBeagle.jpg
   

1. boot_log.txt

[Neeraj Dantu]

Thomas,

Can you check the polarity and connection for MMC0_CD(card detect pin) of the SD card interface on your custom board? I suspect the SD card detect signal is either not hooked up the same as Pocketbeagle or the polarity is reversed. See https://github.com/beagleboard/pocketbeagle/blob/master/PocketBeagle_sch.pdf for the configuration of MMC0_CD in Pocketbeagle.

Check the pin and polarity of card detect pin(‘cd-gpios’) defined in the device tree here: https://openbeagle.org/beagleboard/BeagleBoard-DeviceTrees/-/blob/v5.10.x-ti-unified/src/arm/am335x-pocketbeagle.dts#L799.

Best,

Neeraj

[Thomas K]

Dear Neeraj,

thank you very much, this could have been plausible. The connection of the detect pin goes to C14 in our design as well and connected with a pull-up resistor. If the card is not inserted, the voltage is 2.5 V (not 3.3V for unknown reasons …), but cleanly 0 if inserted. We played with the cd-gpios setting (ACTIVE_HIGH, ACTIVE_LOW) interestingly with the same result (error -110). We also uncommented the cd-gpios line also with the same result. Playing with the bus-width changed the behaviour slitghtly which at least confirms the dtb file is properly loaded, but still produces errors.

Thank you and best regards,

Thomas

[Neeraj Dantu]

Thomas,

Looking at the boot log:

[    1.818009] omap_gpio 44e07000.gpio: Could not set line 6 debounce to 200000 microseconds (-22)

[    1.826827] omap_hsmmc 48060000.mmc: Got CD GPIO

[    1.832087] omap_hsmmc 48060000.mmc: Linked as a consumer to regulator.1

 

It looks like the driver is running into an error setting up the card detect GPIO. Here is the GPIO bank corresponding to the driver error: https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/am33xx.dtsi#L155. You can deduce from the datasheet(https://www.ti.com/lit/ds/symlink/am3356.pdf) that SPI0_CS1 is GPIO0_6.

You mentioned that the voltage on card detect pin is not 3.3V. Is there any other circuit on this pin that could effect it?

If you have more than 1 board, please try other boards in case this is a 1 off error.

Best,

Neeraj

[Thomas K]

Dear Neeraj,

we played excessively with the detect pin and polarity, it is okay. The above mentioned GPIO error appears on the pocket beagle as well.

However, we maybe have a voltage issue. After the kernel is loaded, its seems like the data lines are not driven to 3.3 V anymore. We will investigate here further.

Reducing the bus speed did not have any effect.

Reducing the bus width to 1 results in errors like this:

[7.779753] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.

[18.158629] mmc0: Timeout waiting for hardware interrupt.

Best regards,

Thomas

[Neeraj Dantu]

Thomas,

The data lines need to be pulled up to 3.3V on the MMC interface like in the Pocketbeagle for the interface to work. Do you have the pull-ups? It looks like the Pocketbeagle device tree enables the internal pull-ups on these pins: https://openbeagle.org/beagleboard/BeagleBoard-DeviceTrees/-/blob/v5.10.x-ti-unified/src/arm/am335x-pocketbeagle.dts#L238.

Can you also check voltage for VDDSHVx(SYS_VDD3_3P3V)?

Best,

Neeraj

[Thomas K]

Dear Neeraj,

 

sorry for the late reply. The pull-ups are there on the board, 9.8k to SYS_VDD1_3P3V on each line. SYS_VDD1_3P3V looks excellent, we even added some more capacitors, but with no effect.

I cannot check SYS_VDD3_3P3V because this is not connected to anything. Is this the possibly the root cause?

Thank you and best regards!

[Neeraj Dantu]

Thomas,

Can you look at the power consumption of your custom board compared to PocketBeagle? My suspicion is that something getting initialized during kernel boot is drawing too much power from IO may be because of a conflict with the pin definition with Pocketbeagle.

Can you probe the levels of CLK/CMD and DATA when kernel is booting to see what IO levels they are?

Best,

Neeraj

[Author]

Posts