SDMMC3 can‘t work

,

Can you measure the gpio of H,1 and see if it is toggled correctly after you hotplug the sdcard?

CRC error is generally due to regulator provided is not proper.

As you expected, the voltage of H.1 has not changed due to the hot swap of the SD card(It is always powered on ). We have tried to delete vmmc-supply and use nvidia,vmmc-always-on, which may avoid the CRC error. But this brings us new errors(as shown in the log).
dmesg_novmmcsupply.log (68.2 KB)

Can you give some guidance or suggestions, maybe it is very important to us.

For that GPIO, did you configure it with the pinmux spreadsheet before?

We did not use the pinmux form for configuration, but thought it could be modified in dtb…Can you provide an introduction to the use of this form?
I’m sorry to disturb you so late.

Hi,

Please refer to the NX adaptation guide first. You shall find it inside the developer guide.

hi,
Maybe I’m not smart, and I haven’t found a specific modification method in the development guide. Can you give me some clear guidance?

I made the following modifications in Excel about pinmux (I hope that my modification is correct), and used it to generate three dtb files.

Then I used Linux_for_Tegra/kernel/pinmux/t19x/pinmux-dts2cfg.py to generate the cfg file under the guidance of the development documentation. But I don’t know how to replace these files. Because there are a lot of cfg files in the path of the next step of the development document.

And it seems that this method needs to re-burn part of the NX partition. Do we have a more convenient way?

Check your flash log and board config and you shall find out which file is needed to get replaced.

Board config is just the one your are using for flash.sh. For example,

sudo ./flash.sh board123 mmcblk0p1

Then the board config is board123.conf

BTW, why do you set that GPIO as “input”? This GPIO is to control the VDD on the load switch, so it should be output…

It may be difficult for us to change pinmux, and we don’t think this is the main reason why we can’t use sdmmc3.

Here we have tried to use normally open to avoid the use of H.1 pin. But it is not behaving normally. Can we enable sdmmc3 without adjusting the pinmux of H.1?

What is the exact difficultly here to let you not able to change the pinmux? Cannot find the file? or don’t know what to change in the spreadsheet?

No, I generated a cfg file for it and found a file that may be in use, but I cannot burn it. I rebuilt the kernel and plan to refresh it completely. But there were many failures during the burning process, which made me very annoyed. I don’t have much time to spend here, the task deadline is approaching.

[ 156.5953 ] Writing partition APP with system.img
[ 283.8243 ] [.....................                           ] 043%
Error: Return value 3
Command tegradevflash_v2 --pt flash.xml.bin --create
Failed flashing t186ref.

This is the log of failure to burn, it always fails here.

Hope you can provide a faster and more reliable method.

There is no reliable and faster method.

If you really want to save your time, describe what you’ve changed clearly.

For example, what file did you change, what command are you using to flash. Try to figure the meaning of each process by yourself if possible.
The place where the error happens is the “APP” partition. Which means the file system flashing error. However, the change in pinmux is not in file system. Thus, it is more like a unrelated issues to me.

Now I seem to have successfully changed the pinmux properties of H.1. Because it can now reverse the state based on whether the card exists. But now the use of the SD card does not seem to get better, the following is the log
dmesg_changepinmux.log (153.9 KB)

Another user just made his jetson nano sdcard slot done.

The device tree configuration is similar in both NX and nano. You can refer to it too.

If this does not work, maybe you should also check the hardware side. This user problem is also resolved by re-check hardware.

Dear Moderator,
After applying some of the changes you recommended, I found that it seems to be better again. At least there is no CRC problem anymore. And the error message looks similar. Can you help me again?
This is my change in dtb(Although I didn’t know what I was doing, I still applied it to my machine. ):

diff --git a/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi
index 221cb16..37d9369 100644
--- a/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi
+++ b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi
@@ -34,7 +34,17 @@
                        gpio = <&tegra_main_gpio TEGRA194_MAIN_GPIO(G, 2) 0>;
                        enable-active-high;
                };
-
+               p3668_vdd_sdmmc3_sw: regulator@106 {
+                       compatible = "regulator-fixed";
+                       reg = <106>;
+                       regulator-name = "vdd-sdmmc3-sw";
+                       regulator-min-microvolt = <3300000>;
+                       regulator-max-microvolt = <3300000>;
+                       gpio = <&tegra_main_gpio TEGRA194_MAIN_GPIO(H, 1) 0>;
+                       // regulator-always-on;
+                       enable-active-high;
+                       regulator-boot-on;
+               };
                p3668_vdd_1v8_sd: regulator@104 {
                        compatible = "regulator-fixed";
                        reg = <104>;
@@ -42,6 +52,7 @@
                        regulator-min-microvolt = <1800000>;
                        regulator-max-microvolt = <1800000>;
                        enable-active-high;
+
                };
        };
 };
diff --git a/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3668-common.dtsi b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3668-common.dtsi
index a94051d..d271774 100644
--- a/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3668-common.dtsi
+++ b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3668-common.dtsi
@@ -27,6 +27,7 @@
 #include "tegra194-p3668-pcie-plugin-manager.dtsi"
 #include "tegra194-plugin-manager-p3668.dtsi"
 
+
 / {
        nvidia,fastboot-usb-vid = <0x0955>;
        nvidia,fastboot-usb-pid = <0xee1e>;
@@ -262,7 +263,31 @@
                nvidia,enable-hwcq;
                status = "okay";
        };
+       sdhci_sd3: sdhci@3440000 {
+               mmc-ocr-mask = <0x3>;
+               cd-inverted;
+               cd-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 2) 0>;
+               nvidia,cd-wakeup-capable;
+               mmc-ocr-mask = <3>;
+               cd-inverted;
+               uhs-mask = <0x0>;
+               // nvidia,vmmc-always-on;
+               vmmc-supply = <&p3668_vdd_sdmmc3_sw>;
+               status = "okay";
 
+
+               keep-power-in-suspend;
+               non-removable;
+               tap-delay = <3>;
+               sd-uhs-sdr104;
+               sd-uhs-sdr50;
+               sd-uhs-sdr25;
+               sd-uhs-sdr12;
+               mmc-ddr-1_8v;
+               mmc-hs200-1_8v;
+               no-sdio;
+               no-mmc;
+       };
        sdhci_sd: sdhci@3400000 {
                mmc-ocr-mask = <0x0>;
                cd-inverted;
diff --git a/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-power-tree-p3668.dtsi b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-power-tree-p3668.dtsi
index 6f62ee7..ffcad78 100644
--- a/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-power-tree-p3668.dtsi
+++ b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-power-tree-p3668.dtsi
@@ -26,7 +26,9 @@
        sdhci@3400000 {
                vmmc-supply = <&p3668_vdd_sdmmc1_sw>;
        };
-
+       sdhci@3440000 {
+               vmmc-supply = <&p3668_vdd_sdmmc3_sw>;
+       };
        ether_qos@2490000 {
                vddio_sys_enet_bias-supply = <&battery_reg>;
                vddio_enet-supply = <&battery_reg>;

And there is log:
dmesg_addchangemjnm.log (249.4 KB)

Thank you very much for your explanation.

hi,
We can use sdmmc3 now. In before,we can’t use it because of hardware connection problems. Thank you again for your help.

We still have some questions about sdmmc3, can we continue to ask you? Although it is now possible to start Jetson Xavier NX from sdmmc3, we don’t know much about this method. For example, can you directly use the flash.sh to refresh sdmmc3?

I think you should provide what hardware problem you solved here because it really took lots of time on that.

That’s because we used some unconventional means to get the card slot. It’s like removing it from a non-removable module. This method caused damage to the card slot and the trouble we encountered later. We have not been able to find that it is broken because it seems normal.

For the booting from sd, you can check this post here to understand some concept.

A brief answer to your question

can you directly use the flash.sh to refresh sdmmc3?

No, it cannot.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.