Carrier Board Design With External Emmc

Hi there,

Currently making a custom carrier board design for the Jetson NX Xavier to utilize an external emmc module for a school project in a capstone. The extra emmc was added to create more storage for the custom board designed and to experiment on memory designs for school.

I’m aware that the configurations that Nvidia provides by default is either an sd card, emmc, or nvme SSD. In our case we have the emmc configuration.

I have a breakout to the external emmc that we wish to add with pins allocated as follows:
DATA:
219: SDMMC_DAT0
221: SDMMC_DAT1
223: SDMMC_DAT2
225: SDMMC_DAT3
227: SDMMC_CMD
229: SDMMC_CLK
POWER
206: GPIO07_SDMMC_ON (Runs an external power circuit with delivery of 3.3v)
208: GPIO08_SDMMC_CD (Confirmation pin when system is activated)

As for the device tree I can see that sdhci@3460000 is being utilized since this our default boot medium. How would I look at configuring sdhci@3400000 to utilize the new emmc module that was added along with the pins that were mentioned before?

I know you have to edit the pinmux file and the .dtsi file in tandem. Below the .dtsi file are shown below.

    sdhci_emmc: sdhci@3460000 {
	uhs-mask = <0x0>;
	nvidia,enable-hwcq;
	status = "okay";
};

sdhci_sd: sdhci@3400000 {
	mmc-ocr-mask = <0x0>;
	cd-inverted;
	cd-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(G, 7) 0>;
	nvidia,cd-wakeup-capable;
	mmc-ocr-mask = <0>;
	cd-inverted;
	vmmc-supply = <&p3668_vdd_sdmmc1_sw>;
	status = "okay";
};

Best,
Anthony.

1 Like

Hi,

I don’t know what you are talking about. We didn’t have the pinout for 3400000.

SDMMC3 is on 3440000.

Hi there!

Thanks for the reply and clarification!
So with this if I wanted to utilize and external emmc on sdhci@3440000 would the .dtsi file look like:

sdhci_emmc: sdhci@3460000 {
	uhs-mask = <0x0>;
	nvidia,enable-hwcq;
	status = "okay";
};
sdhci_emmc: sdhci@3440000 {
	uhs-mask = <0x0>;
	nvidia,enable-hwcq;
	status = "okay";
};

As for the pinmux would I have to change anything on there to accommodate this?

Best,
Anthony.

You should use dtc tool to dump the dtb back to dts and compare what does sdhci@3460000 have. Copy those missing parameters to your sdmmc3.

Where could I find the .dtsi that supports the default sdmmc4? The .dtsi file that I have I posted above and it only has

uhs-mask = <0x0>;
nvidia,enable-hwcq;
status = "okay";

Im sure that’s not the one your referring to?

  1. Device tree is just like a program. It is a binary file compiled from many files/source codes.
    But it could be easily converted back from binary to text file and you can read the text file to see the whole content. That was what I am talking about in previous comment. Try to google search “dtc device tree compiler” and it will guide you how to use it.

  2. Your question is like there are code files A,B,C,D,E,F,G…etc. And you want to know which files are needed to get modified. Honestly, I don’t memorize such things either because you should never “memorize a code”. You should be able to know which code to start to trace and you should trace down it. All the device tree for jetson are public sources. So try to figure out which dtb is getting flashed to your board first. Each platform will only have one kernel dtb running on it. Use the file name to trace the source code.

Ok I found the file and edited parts to support the emmc module on sdmmc3. I ran the flash and nothing is showing up. I have linked the device tree file with sdmmc3 and sdmmc4 code that I took from.

sdhci@3460000 {
		compatible = "nvidia,tegra194-sdhci";
		reg = <0x00 0x3460000 0x00 0x20000>;
		interrupts = <0x00 0x41 0x04>;
		iommus = <0x02 0x17>;
		dma-coherent;
		max-clk-limit = <0xbebc200>;
		ddr-clk-limit = <0x30a32c0>;
		bus-width = <0x08>;
		only-1-8-v;
		ignore-pm-notify;
		keep-power-in-suspend;
		non-removable;
		cap-mmc-highspeed;
		cap-sd-highspeed;
		mmc-ddr-1_8v;
		mmc-hs200-1_8v;
		mmc-hs400-1_8v;
		mmc-hs400-enhanced-strobe;
		nvidia,min-tap-delay = <0x60>;
		nvidia,max-tap-delay = <0x8b>;
		nvidia,en-periodic-cflush;
		nvidia,periodic-cflush-to = <0x0a>;
		resets = <0x05 0x55>;
		reset-names = "sdhci";
		pll_source = "pll_p\0pll_c4_out0_lj";
		nvidia,set-parent-clk;
		nvidia,parent_clk_list = "pll_p\0pll_p\0NULL\0NULL\0NULL\0NULL\0NULL\0NULL\0pll_p\0pll_c4_out0_lj\0pll_c4_out0_lj";
		clocks = <0x04 0x7b 0x04 0x66 0x04 0xed 0x04 0xdb>;
		clock-names = "sdmmc\0pll_p\0pll_c4_out0_lj\0sdmmc_legacy_tm";
		status = "okay";
		vmmc-supply = <0x1b>;
		vqmmc-supply = <0x18>;
		uhs-mask = <0x00>;
		nvidia,enable-hwcq;
		linux,phandle = <0xbf>;
		phandle = <0xbf>;

		prod-settings {
			#prod-cells = <0x04>;

			prod {
				prod = <0x00 0x04 0xfff 0x200 0x00 0x28 0x20 0x20 0x00 0x100 0x1fff004a 0x14080000 0x00 0x10c 0x3f00 0x2800 0x00 0x128 0x43000000 0x00 0x00 0x1ac 0x04 0x00 0x00 0x1c0 0x1fc0 0x40 0x00 0x1c4 0x3ff77 0x400 0x00 0x1e0 0x87f7f000 0xa0a000 0x00 0x1e4 0x20000000 0x20000000 0x00 0x204 0x80000000 0x00 0x00 0x218 0x80000000 0x00>;
			};

			prod_c_ds {
				prod = <0x00 0x100 0x1fff0000 0x14080000>;
			};

			prod_c_hs {
				prod = <0x00 0x100 0x1fff0000 0x14080000>;
			};

			prod_c_cqe {
				prod = <0x00 0xf008 0x01 0x01>;
			};

			prod_c_ddr52 {
				prod = <0x00 0x3c 0x70000 0x40000 0x00 0x120 0xfffe 0x298>;
			};

			prod_c_hs200 {
				prod = <0x00 0x3c 0x70000 0x30000 0x00 0x1c0 0xe000 0x4000>;
			};

			prod_c_hs400 {
				prod = <0x00 0x3c 0x70000 0x50000 0x00 0x100 0xff0008 0x80008 0x00 0x1c0 0xe000 0x4000 0x00 0x1e4 0x7f7f 0x00>;
			};

			prod_c_sdr50 {
				prod = <0x00 0x3c 0x70000 0x20000>;
			};
		};
	};

	sdhci@3440000 {
		compatible = "nvidia,tegra194-sdhci";
		reg = <0x00 0x3440000 0x00 0x20000>;
		interrupts = <0x00 0x40 0x04>;
		iommus = <0x02 0x18>;
		dma-coherent;
		max-clk-limit = <0xc65d400>;
		bus-width = <0x04>;
		cap-mmc-highspeed;
		cap-sd-highspeed;
		sd-uhs-sdr104;
		sd-uhs-sdr50;
		sd-uhs-sdr25;
		sd-uhs-sdr12;
		mmc-ddr-1_8v;
		mmc-hs200-1_8v;
		mmc-ocr-mask = <0x00>;
		cd-inverted;
		cd-gpios = <0x13 0x37 0x00>;
		nvidia,cd-wakeup-capable;
		nvidia,min-tap-delay = <0x60>;
		nvidia,max-tap-delay = <0x8b>;
		nvidia,vqmmc-always-on;
		pwrdet-support;
		pinctrl-names = "sdmmc_e_33v_enable\0sdmmc_e_33v_disable";
		pinctrl-0 = <0x1c>;
		pinctrl-1 = <0x1d>;
		ignore-pm-notify;
		resets = <0x05 0x54>;
		reset-names = "sdhci";
		pll_source = "pll_p\0pll_c4_muxed";
		nvidia,set-parent-clk;
		nvidia,parent_clk_list = "pll_p\0pll_p\0pll_p\0pll_p\0pll_p\0pll_c4_muxed\0pll_c4_muxed\0pll_c4_muxed\0pll_c4_muxed\0pll_c4_muxed\0NULL";
		clocks = <0x04 0x7a 0x04 0x66 0x04 0xf1 0x04 0xdb>;
		clock-names = "sdmmc\0pll_p\0pll_c4_muxed\0sdmmc_legacy_tm";
		uhs-mask = <0x08>;
		nvidia,en-periodic-calib;
		vmmc-supply = <0x20>;
		status = "okay";
		linux,phandle = <0xf0>;
		phandle = <0xf0>;

		prod-settings {
			#prod-cells = <0x04>;

			prod_c_1_8v {
				prod = <0x00 0x1e0 0x7f00000 0x600000>;
			};

			prod_c_3_3v {
				prod = <0x00 0x1e0 0x7f00000 0x800000>;
			};

			prod {
				prod = <0x00 0x04 0xfff 0x200 0x00 0x28 0x22 0x02 0x00 0x100 0x1fff004a 0x5090000 0x00 0x128 0x42000000 0x00 0x00 0x1ac 0x04 0x00 0x00 0x1c0 0x1fc0 0x40 0x00 0x1c4 0x3ff77 0x400 0x00 0x1e0 0x8007f000 0x7000 0x00 0x1e4 0x20000000 0x20000000 0x00 0x204 0x80000000 0x00>;
			};

			prod_c_ds {
				prod = <0x00 0x100 0x1fff0000 0x5090000>;
			};

			prod_c_hs {
				prod = <0x00 0x100 0x1fff0000 0x5090000>;
			};

			prod_c_ddr52 {
				prod = <0x00 0x3c 0x70000 0x40000 0x00 0x120 0xfffe 0x298>;
			};

			prod_c_hs200 {
				prod = <0x00 0x3c 0x70000 0x30000 0x00 0x1c0 0xe000 0x4000>;
			};

			prod_c_sdr104 {
				prod = <0x00 0x3c 0x70000 0x30000 0x00 0x1c0 0xe000 0x4000>;
			};

			prod_c_sdr12 {
				prod = <0x00 0x3c 0x70000 0x00>;
			};

			prod_c_sdr25 {
				prod = <0x00 0x3c 0x70000 0x10000>;
			};

			prod_c_sdr50 {
				prod = <0x00 0x3c 0x70000 0x20000 0x00 0x1c0 0xe000 0x8000>;
			};
		};
	};

The file that I am currently editing is called tegra194-p3668-all-p3509-0000.dts
Appreciate your help btw, lost in the weeds as of late.

Basically, when it is bring up issue, you need to share kernel log by using dmesg command.

One thing I also wanted to mention is that our system has GPIO 07 connected to a power circuit that when enabled it will deliver 3.3v to the external emmc. GPIO 08 we have wired for detecting when the system turns on(SDMMC_CD).

Hi,

  1. Your log is not completed. Each line got truncated. I don’t know how you dumped it. Maybe adjust your terminal size and dump again.

  2. From the incomplete log, I can tell your sdhci@3440000 is not enabled at all.

  3. I don’t know why a CD pin is wired there. We don’t support a hotplug case for emmc. Actually, you should just copy the content of sdhci@3460000 to your 3440000. That is the only case we support. Again, check it from the decompiled dtb to make sure the full content. I don’t know where you dig in those info. We actually don’t support much external emmc case on this forum. Your case looks like a sdcard sample.

Ok I ported over the changes from @346@344 but still did not work. I have the new log linked in the file.
LOG_V2 (52.9 KB)

Hi,

My previous comments point (1) and (2) are still valid even for your current log.

You should read your log and compare to any other dmesg posted on this forum… and you will notice what I mean.
For example, this is how your kernel command line and kernel version looks like

2 [ 0.000000] Linux version 4.9.140-l4t-r32.4+ga28ca7b3779d (oe-user@oe-host) (gcc version 8.3.0 (GCC) 1
38 [ 0.000000] Kernel command line: console=ttyS1,115200 console=ttys1 fbcon=map:0 video=tegrafb no_cons

These lines are all incomplete and got cut in the middle…

  1. Your sdhci@3440000 looks still not get enabled. How did you update your device tree to the board?
    Please check your /proc/device-tree on the board and see if the content meets your expectation.

LOG_V3.txt (70.7 KB)
In terms of uploading the .dtb to the board I replace it in deployment everytime when I flash the system. Ie remove old file then replace it with the new one. As for the device tree on the board I have checked it and it never comes up as “Okay” even when I set it as Okay. Is this normal for behavior? I hope that the log that I gave has everything.
Thank you for your patience and help :)

I think you should clarify what does that mean “remove old file and replace it”.

Remove which file? At which location? Add what file? At which location?

And what did you do after you remove and replace?

Im currently using the yocto project to build our system. So in our deployment folder I replace the file and then deploy the image with the new file. tegra194-p3668-all-p3509-all-0000.dtb is the file specified.

I am also using the ridge run developer page linked below to compile my dtsi files to dtb.

Hope this clarifies the process

Could you do one test here? Add one arbitrary string to your device tree.

For example, “testseymoura1234” in arbitrary location. Do your update method here.

Boot up the device again and go to check /proc/device-tree and see if this string is showing up there.

Ok seems like our deployment of our dtb is an issue. Once resolved Ill send anther message if we still encounter issues. If not and the changes are fixed Ill mark this ticket as solved.
Again, thanks for the help!

1 Like

I would suggest you do the full flash of the board if your method didn’t take effect.

It is slow, but it will most likely resolve the dtb update issue here.

Ok I have the file being taken now. It currently shows In the device tree! I have redone the changes to the system my porting over the @3460000@3440000 and this is the dmesg log below:
LOG_V4.txt (581.5 KB)

Looks like it is enabled, but immediately got error.

3.957221] mmc1: error -110 whilst initialising MMC card

How did you port over these things from 3460000 to 3440000?