Cannot connect SD card to Jetson TX2 NX, even with working card detect

@WayneWWW Thanks for the feedback.

I tried the change as described and did not get different results. I’ve attached the DTS file I used, as well as the dmesg output I observe.
dmesg.log (92.6 KB)
sdhci_3440000_test25.dts (239.3 KB)

One thing we found interesting that seems to differ with other posts is the contents of /sys/kernel/debug/mmc1/ios (specifically the signal voltage being 1.8V):

nvidia@nvidia-desktop:~$ sudo cat /sys/kernel/debug/mmc1/ios
[sudo] password for nvidia: 
clock:		0 Hz
vdd:		0 (invalid)
bus mode:	2 (push-pull)
chip select:	0 (don't care)
power mode:	0 (off)
bus width:	0 (1 bits)
timing spec:	0 (legacy)
signal voltage:	1 (1.80 V)
driver type:	0 (driver type B)

Let me know what you think, thanks!

1 Like

Try to remove vqmmc-supply in your DT. Only leave vmmc.

I tried removing vqmmc-supply from the sdhci@3440000 section of my dts, and that didn’t change much. Normally when I boot with an SD card or hotplug one into our PCB, I will see an LED flicker (indicating the SD card has 3.3V power). With vqmmc-supply removed, I don’t ever see the LED light up at all. Still no matter what, the SD card does not show in lsblk.

Additionally, I see the following line many times repeatedly during boot (over UART) when an SD card is plugged in:

[    1.470729] mmc1: CMD CRC or end bit error, int mask 0xc0000     

Should I be editing other sections as well? For instance the other sdhci@xxxxx sections? For reference this is our SD card and we’ve tried multiple physical cards which all work in other computers.

Let me know what you think, thanks!

You can disable unnecessary sdhci node in your DT. Just do not disable the one that is running the emmc should be fine.

Again, if you remove anything, share us the log. No matter that log is changed or not.

Also, this kind of issue is not something new. If the same configuration from other people can work on their TX2 NX but not your board, maybe need to review the hardware schematic.

Sorry, here’s the dmesg log for your inspection. Nothing seems to happen at all relating to the SD with vqmmc-supply removed, not even when I hotplug.

no_vqmmc_dmesg.log (69.6 KB)

I understand that this issue is not new, and I understand your feedback. That being said, I don’t believe our designer has laid out the PCB incorrectly.

This process is very challenging for us, since we are not Firmware Engineers. Hunting down countless different forum posts and trying random DT edits from them is not an effective process for us to fix issues or determine why something is not working.

It would make our lives a lot easier if you could explain a few things for us:

  1. Which DT section is controlling the SD card? Is it sdhci@3440000? Which one is for the mmc?
  2. What is the difference between vmmc-supply and vqmmc-supply?
  3. Is there any documentation on the device tree itself and how you can do basic things like setting up support for an SD card?
  4. Do you have any additional resources you can point us to, or do you have any more suggestions for things to try?

If these questions seem dumb, that’s because we are “dumb”! We need things explained as though we know fairly little about what we’re doing, because we really don’t!

Thank you for your continued support.


  1. sdhci@34x0000 just follows the hardware pin. Since you should use sdmmc3 pin the on module.

sdhci@3400000 → sdmmc1
sdhci@3420000 → sdmmc2
sdhci@3440000 → sdmmc3

  1. From upstream kernel document

vmmc-supply : phandle to the regulator device tree node, mentioned as the VCC/VDD supply in the eMMC/SD specs.
vqmmc-supply : phandle to the regulator device tree node, mentioned as the VCCQ/VDD_IO supply in the eMMC/SD specs. And vqmmc-supply is optional.

  1. Sorry, there is no document. Only the driver code. And kernel driver documentation folder shall have some info regarding each property meaning. I don’t remember the actual location. You can grep “sdhci-tegra” or something like “nvidia,vmmc-always-on” and it should tell the path.

  2. Basically, no matter jetson nano/ jetson NX or jetson TX2-NX, they are all sharing the same case. vmmc-supply and cd-gpios needs to match the board design. If your vmmc-supply is a always-on one, which does not control by any GPIO, then you also need to add “nvidia,vmmc-always-on;”

Here is a post where we did some check with this chao.zhang and his sdcard slot can work.

Thanks for the info. I’m still stuck here unfortunately. Can you tell me if I want the iommus section in the sdhci@34400000.

iommus does not matter to your problem.

I just read your hardware schematic.

Is your 3V3_SD ever controlled by a GPIO or not? I mean what is the SD_EN in the picture?

Hey, yeah so the SD_EN is controlled by gpio07. I have left that untouched in the pinmux configuration currently. When ever I have the dt configured to get the “mmc1: error -110 whilst initialising SD card” in dmesg. I see the LED on 3v3_SD turn on for a split second. With this configuration, the light will flash 4 times whenever the card is hot plugged and I will get 4 new instances of the error message.

Also, I’m looking at the dts from chao.zhang and I see that he has vmmc-supply = <0x17>;
In that dts, phandle 0x17 is this section:

		regulator@111 {
			compatible = "regulator-fixed";
			reg = <0x6f>;
			regulator-name = "vdd-fan";
			regulator-min-microvolt = <0x4c4b40>;
			regulator-max-microvolt = <0x4c4b40>;
			gpio = <0x25 0x8 0x0>;
			linux,phandle = <0x17>;
			phandle = <0x17>;

This is a different section than what you told me to use and also appears to be a 5V regulator. Could you explain that to me please? Am I being stupid and misreading the phandle? Thanks!


Ok, we find the first mistake. If your “sd_en” is controlled by a GPIO from jetson, then it is not a always-on power source.

Which means that “nvidia,vmmc-always-on” is not matching your hardware.

I am just wondering, could you just put load control as always on first? If you have “nvidia,vmmc-always-on” in your device tree, then that 3v3_SD needs to be always there.

And just forget about chao.zhang’s dts. Just read his “vmmc-supply = <&spmic_sd3>;”. I guess his dts file does not match his real result.

Okay so for the record here: I removed the “nvidia,vmmc-always-on” and set vmmc-suply to spmic_sd3 (0x13 in my dts) and I get the repeated error at boot of

mmc1: CMD CRC or end bit error, int mask 0xc0000

However nothing happens when I hot plug and the 3v3_SD light does not come on.

For kicks, I also tried the vmmc-supply that chao.zhang uses in his dts (vdd-fan) and I get the light flashing on hot plug with

mmc1: error -110 whilst initialising SD card

Are you suggesting that I go back to setting the gpio07 pin to output drive1 in the pinmux config?
Do you have any sense of why I would get the intermittent kernel panic on boot with that setting?

No, you still not get the point.

That user (chao.zhang) can use spmic_sd3 regulator + always on setting because his hardware design is a always on 3v3 sd.

But your case is not.

That is why I asked you to directly make your load switch to always give out 3v3 instead of using a gpio to control. This does not matter to the pinmux. I am talking about the hardware schematic.

If the power source is wrong, then your error is expected.

Take your “LED light” as example.

A “always-on” power source means when the jetson board is powered on, your 3V3_SD LED is on. The existence of sdcard does not matter.

Are you saying that a power enable line is not supported at all? There’s no device tree change I can make that will work? When I set that pin to output drive 1 in the pinmux it turns the power enable on reliably…

I understand that the nvidia,vmmc-always-on flag is incorrect if the power is not always on… But if I have a card detect do I not want the power to be toggled on and off by the presence of the card? This is how our TX2 carrier works for the old model.

If pull up that GPIO can make it work, then fine. Just pull the gpio up.

There is also alternative way to do that. But you need to provide the gpio to the regulator.

I think we can adopt the easy way first to make sure the sdcard slot can work.

This is the alternative I am talking about. But I think you are not familiar with regulator framework enough. So we can try easy way first.