Nvidia Nano EMMC not detecting Partition on sdmmc3 SD Card

[user145557]

Hello,

We have an Nano EMMC module flashed and boots.

Our external sdmmc3 is detected as /dev/mmcblk1

We have partitioned and formatted the SD card on another computer and have mounted it on another computer.

We have also mounted the SD Card (plugged into a USB Dongle) and inserted into the EMMC carrier board, and have mounted it as /dev/sdb1

When executing lsusb when the SD card is plugged into the External SD slot (sdmmc3) , it is detected as /dev/mmcblk1 (disk) , but we do not see the sub partition at all.

also when executing fdisk /dev/mmcblk1 -u , the command stalls

What do we need to do to fix the problem ?

[WayneWWW]

Any error message from the kernel log (dmesg)?

[linuxdev]

Btw, you should be using gdisk instead of fdisk when working with UEFI. What do you see from:

• lsblk -f /dev/mmcblk1
• sudo gdisk -l /dev/mmcblk1

[sgroesz]

Attached is the dmesg and the devicetree in use.

new_devicetree.dts (321.3 KB)
dmesg_error.txt (111.2 KB)

Compared to here: Micro-SD card on custom jetson nano - #74 by mjnm
We are missing a cd-gpios line and our vmmc-supply is different, but I don’t know enough to know how to set these, or even if these settings are related to the problem or not.

We weren’t able to create the partitions on the Nano so we partitioned and formatted the sd card on the Ubuntu 18.04 host system and the SD card works fine there.

Hardware wise, card detect is connected to pin 118 on the SoM. VDD for the SD card is provided by a standalone 3v3 regulator.

gdisk -l /dev/mmcblk1 hangs
lsblk -f /dev/mmcblk1 just shows the mmcblk1 device without any partitions

[WayneWWW]

Hi,

Yes, those settings are related to the issue. vmmc-supply and cd-gpios are basically the most important things for adding an extra sdcard slot. cd-gpios are the “card detect pin”, so you need to provide pin 118 to it. As for vmmc-supply, you need to give a 3v3 always-on regulator to it.

I also have a question regarding to your device tree

It seems that your device tree is out-of-order, especially the properties inside sdhci@700b0400. It looks like you are not building it from the kernel source.

If what I am saying is true, please try to use the standard way to create the dtb. That kind of dtb will be more easier for others to check.

[sgroesz]

Wayne - what is the correct way to modify the settings for the emmc sdio? We have previously used the pinmux tool to create a dtsi file, but that doesn’t seem to be the same way to modify, eg, setting “status = “okay”” under sdhci@700b0400.

[WayneWWW]

What is your method to modify device tree now? I am just curious because such dts comes out sometimes from some users and I am not sure how you guys make the dtb become like that.

The official way is download and build the dtb with the public source code and the method is listed on the document.

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/kernel_custom.html#wwpID0E0WD0HA

[sgroesz]

that dts file was created from the /proc/device-tree:

dtc -I fs -O dts -o new_devicetree.dts /proc/device-tree

I think that is why it looks strange.

The dtb was created from the kernel source

[sgroesz]

I tried to compile the dtb with the correct settings from source. Using L4T sources and tools version 32.6.1.

I used the attached two dtsi files from the pinmux tool along with the 3 patch files to show the changes I made to the device tree sources in addition to the pinmux dtsi files.

I also attach the result which seems to be not correct.

The attached .dts file was generated by:
dtc -I dtb -O dts -o tegra210-p3448-0002-p3449-0000-b00.dts tegra210-p3448-0002-p3449-0000-b00.dtb

As far as I can tell, pin 118 on the Nano module corresponds to port S, 5. But it doesn’t seem my patches were applied, so I must be changing the wrong files?

20210713-gpio.dtsi (1.9 KB)
20210713-pinmux.dtsi (38.1 KB)
tegra210-p2530-common.dtsi.32.6.1.patch (374 Bytes)
tegra210-porg-fixed-p3448-0000-a00.dtsi.32.6.1.patch (524 Bytes)
tegra210-porg-plugin-manager.dtsi.32.6.1.patch (388 Bytes)
tegra210-p3448-0002-p3449-0000-b00.dts (318.6 KB)

[WayneWWW]

Looks like you didn’t get what I said.

I don’t have your schematic so I won’t really know your exact design. If your pin 118 is “card detection” pin, then you should add one “cd-gpios” under your sdmmc3 node and assign this gpio to this cd-gpios property. Not modify the regulator and give pin 118 to it. The regulator with “gpio = <&gpio TEGRA_GPIO(Z, 3) 0>;” means they use GPIO Z3 to control the power. If such design does not exist on your board, then you should just find some 3.3v regulator that does not have gpio and is “regulator-boot-on”.

Also, there is no standard answer for “which files” to modify a device tree if you really understand how device tree works.
For example, I have several platforms (TX1/TX2/Nano/TX2-NX/Xaver AGX/Xavier NX) here, it is not wise to “memorize” what files I need to use for each platform. Once you know which dtb will get flashed, open the source code and start to trace code. That will be more efficient to ask other people “which files should I modify??”.

If you don’t want to trace code, then you just write what you need inside the last dts file and make sure it would take effect in the final dtb file. That’s all.

[sgroesz]

If your pin 118 is “card detection” pin, then you should add one “cd-gpios” under your sdmmc3 node and assign this gpio to this cd-gpios property

What is cd-gpios property for pin 118? According to the pinmux spreadsheet, the Nano signal name for pin 118 is GPIO01. The GPIO name is GPIO3 PS.05.

so

  cd-gpios = <0x5b 0xa8 0x0>;

what is setting for Pin 118?

This is where I got the idea to make the changes to the files:

Micro-SD card on custom jetson nano

Set status as “okay” in /hardware/nvidia/platform/t210/common/kernel-dts/t210-common-platforms/tegra210-p2530-common.dtsi sdhci@700b0400 { mmc-ocr-mask = <0>; default-drv-type = <1>; uhs-mask = <0x1c>; power-off-rail; nvidia,update-pinctrl-settings; status = "okay"; }; Set status as “okay”, add " nvidia,vmmc-always-on;", the correct cd-gpio and others properties in both files (I made the changes in both files but I think it’s enough changing just the dts): hardware/nvidia/platfor…

[WayneWWW]

Check the original source code. Original source code are all human-readable strings. If you just read the dts converted from dtb, it is already hex value and you won’t really able to know what is that if you are a beginner to write a dts file.

For example, from the post you just shared. This guy is using GPIO V0. For your case, you are using GPIO S5.

sdhci@700b0400 {
		status = "okay";
		cd-gpios = <&gpio TEGRA_GPIO(V, 0) 0>;

[sgroesz]

Ok i’ve attached the latest dts file and the patch files I used. The result is the same - we can see mmcblk1 but we see I/O errors in dmesg and attempting to communicate with the device still hangs.

dmesg_20220216.txt (62.9 KB)
tegra210-p3448-0002-p3449-0000-b00.dts (318.6 KB)
tegra210-porg-p3448-common.dtsi.32.6.1.patch (384 Bytes)
tegra210-sdhci.dtsi.32.6.1.patch (434 Bytes)

3v3 is supplied entirely by an external regulator and not supplied by the Nano module.

What we have so far is we are confident the system can see the SD card. Removing and inserting the SD card causes MMCBLK1 to disappear and reappear. The OS also reports the correct size of the SD card. However, we are unable to mount or create any partitions. lsblk will list mmcblk1 as a 59.5G disk with no partitions. gdisk -l /dev/mmblk1 and blkid commands hang.

What else can I try, software/configuration wise, to get the SD card working?

the dts file was generated with:

dtc -I dtb -O dts -o tegra210-p3448-002-p3449-0000-b00.dts tegra210-p3448-0002-p3449-0000-b00.dtb

[WayneWWW]

Please add nvidia,vmmc-always-on;

vmmc-supply is still needed even if this is not provided by jetson.

Also, please attach the full dts converted back from dtb.

[sgroesz]

when we add nvidia,vmmc-always-on; the SD card is not detected at all. also, while applying the bl_update_payload with the vmmc-always-on added, the patch seems to hang for a few moments but does eventually complete. We don’t see that behavior when vmmc-always-on is left out

I also fixed my post above to fix the link to the full dtb file.

[WayneWWW]

Please add always-on back and share the log. Your dmesg always has timeout issue. With that kind of log, even you said your sdcard is able to get detected, it is still in bad state.

If that power source is always and cannot be controlled by the sdhci driver, then it needs to tell the driver it is a always-on one.

This kind of configuration has been conducted by lots of users before. You can search “sdmmc3” over the forum.

[sgroesz]

Attached are the logs, patch files and DTS when we attempt to enable vmmc-always-on.

dmesg_20220217_957.txt (61.3 KB)
tegra210-p3448-0002-p3449-0000-b00_vmmc-always-on.dts (318.6 KB)
tegra210-sdhci.dtsi.32.6.1.patch (460 Bytes)
tegra210-porg-p3448-common.dtsi.32.6.1.patch (384 Bytes)
20210713-pinmux.dtsi (38.1 KB)
20210713-gpio.dtsi (1.9 KB)

The result is as I described previously - the SD card doesn’t show up at all.

[WayneWWW]

Is there a schematic to share?

[sgroesz]

I annotated the Nano SoM pin number next to the signal name.

[WayneWWW]

Hi,

So you still have a SDMMC-VDD-EN gpio pin to control the power? So actually it is not a always on power source?