Hi strong text****strong textWe are using Jetson nano SoM with Developer Kit Carrier Board.
The Som is p-3448 b01 and the EVB is p3450 b01.
We got original image and dtb on the sd card that according to the log file of the debug console printings shows it uses /dev/mmcblk0p1 and use sdhci0 on smmc0.It wotks fine.
We see the follwing good lines at console:
[ 3.851689] mmc0: SDHCI controller on sdhci-tegra.0 [sdhci-tegra.0] using ADMA 64-bit with 64 bit addr
[ 7.543601] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[ 7.555484] Rootfs mounted over mmcblk0p1
It seems it map mmco to sdhci0 (sdmmc0).
I saw at the NVIDIA Jetson Nano Product Design Guide chapter 9 that it use sdmmc3 and I do not understand how could it be?
Furthermore, we works with 3rd party company that uses also Jetson nano with the Developer Kit Carrier Board and add kernel object.While we put this image and dtb (same names) to the sdCard
and reboot, the cboot and uboot has access to the sd card , BUT - linux kernel starting and failed because it detect error :
[ 15.726988] ERROR: mmcblk0p1 not found
I saw that the cause is line
[ 4.751030] mmc0: SDHCI controller on sdhci-tegra.3 [sdhci-tegra.3] using ADMA 64-bit with 64 bit addr
It seems mmc0 connected to sdhci3!
What can cause this differfence, the sdmmc is physical interface of the SoM jetson nano - so how we works with sdhci0 (sdmmc0) while the documentation describe sdmmc3, as also with our 3rd Party image and dtb?
Is is difference at the Som HW or dtsi issues? I expect thet sdhci is physical interface and there are 4 such interfaces and one is hardwired to the sd slot - so how could it be?
I attached the log of the original image that works and the one of 3rd party that fails on not found /dev/mmcblk0p1 due to map it to sdhci3?
I attached also image of the SoM and EVB so you can see the versions…
There are difference between SoC and module. We sell nvidia jetson nano as a module. The T210 SoC is inside this module.
On the SoC, there are 4 sdmmc controller/pin that can be used for SDIO/SDMMC.
However, on the jetson nano module, there are only 1 interface has pin out for user to use. That is why custom board use sdmmc3 as sdcard slot on their board.
There are two kinds of jetson nano module we provide. First one is sdcard module and another one is eMMC module.
For sdcard module, the sdcard slot is on the “module” but not the “carrier board” There is no emmc on this kind of module either.
And for emmc module, there is only emmc but no sdcard slot on the module.
For sdcard module, the sdcard is using the sdhci-tegra.0. (which is SoC hardware pin sdmmc1).
For emmc module, the emmc is using sdhci-tegra.3. (which is SoC hardware pin sdmmc4).
Both of these kinds of module have sdhci-tegra.2 for end user to use for customization on carrier board.(this is SoC pin sdmmc3)
When we detect the board is sdcard module, we will disable the sdmmc4 controller from device tree.
When we detect the board is emmc module, we will disable the sdmmc1 controller from the device tree.
This detection is based on the eeprom content of this module.
mmcblk0p1 could be from any hardware pin. It is just the first device got enumerated by kernel.
(first one will be mmc0, second one will be mmc1… etc)
I will add that if this is a Nano, and if it mounts on mmcblk0p1 (compare to mmcblk1p1), then this is not an SD card model, it is an eMMC model. This is not a developer’s kit, and would be a module sold separately combined with a third party carrier board (but not a dev kit).
