SD Card Boot Issue TX2

I have imaged a board using L4T 32.2 to utilize a SD Card (mmcblk1p1). When I boot with said SD card plugged in it is identifying as mmcblk2p1 and results in the TX2 dropping to a recovery shell. Modifying the flash.sh within L4T 32.2 to forcefully set the target device to mmcblk2p1 results in the board being able to boot.

So to summarize, the SD Card is correctly image but not being identified by the bootloader by the correct device number. Is there a way to correct this (is it a known issue)?

This is with a TX2 8GB in a NVidia Dev Kit.

Only “mmcblk0p1” (eMMC first partition, 1-based) and “mmcblk1p1” (SD card first partition, 1-based) are accepted as a rootfs. Is there a reason why it is “mmcblk2”? The dev kit should not be referring to mmcblk2 for the SD card.

I am not sure why it is referring to it as mmcblk2, is there some way to check how it is being assigned?

So far as I know every Jetson with internal eMMC uses mmcblk0 for that, and mmcblk1 for SD cards. Normally one names this during the flash process. Even if you wanted rootfs to be SD card, then much of the content would still go to mmcblk0 (eMMC). So far as I know this is independent of which JetPack/L4T/SDKM is used and is dependent upon the hardware itself. If I am wrong and something is different for R32.2 someone please correct me.

How did you determine something is looking for mmcblk2p1?

When attempting to boot it should mmcblk1p1 as unavailable. When it drops to the shell the sdcard has shown up as mmcblk2 (as shown in /dev as well as fdisk).

Can you flash with an earlier release, e.g., 32.1 (JetPack/SDKM4.2) and see if the issue still exists? If the issue doesn’t exist, then you know it is a software problem. Earlier releases are all listed here (you have to login there, then go to the link again since forwarding does not work…one URL is based L4T release, the other based on JetPack release):
https://developer.nvidia.com/linux-tegra
https://developer.nvidia.com/embedded/jetpack-archive

I have previously had success with the jetpack releases prior to 4.1.1. This appears to be a new behavior.

For R32.2, do you have a log of the flash, and a serial console boot log (just the serial console boot log would be very helpful)? It seems like you’ve run into something odd I’ve not seen before.

If you were to flash R32.2 again, but use command line (TX2 in recovery mode with the micro-B USB connected), and if the “Linux_for_Tegra/rootfs/” directory is already populated, then it would be simple to flash like this and to simultaneously create a log:

sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | gawk '{gsub("[0-9][0-9]+[/][0-9[0-9]+ bytes sent..",".");print}' | tee log.txt

(the gawk part just reduces logging of the progress bar for smaller logs…if you don’t have gawk, then “sudo apt-get install gawk”)

I am not sure if I am able to post the logs from the flash process. What I can say is that I have run into this on 2 separate TX2 modules in a combination of 2 carrier boards (same model different revision) and 1 devkit. I have also heard from others (through PM on the forum) that they are having this issue.

Looking at the boot logs, I see boot device found (mmcblk1p1) followed immediately by ERROR mmcblk1p1 not found.

If you use a serial console during boot, then the serial console can log everything. Renaming the log with a “.txt” filename suffix allows posting (if you hover your mouse over the quote icon in the upper right of one of your existing posts, then it allows attaching via the “paper clip” icon…you cannot attach during creation of a new post).

FYI, if it uses mmcblk1p1 and claims error I am suspicious of hardware error, but that might be the SD card and not the carrier or module. If you add the SD card to your host PC, then what do you see from (adjust the device name…mmcblk1p1 is just a contrived example on a non-Jetson host):

sudo gdisk -l /dev/mmcblk1
# Or if "/dev/sdb":
sudo gdisk -l /dev/sdb

Running gdisk from the host foes not show errors. The kernel logs do appear to be identifying mmc2 as address 0007 when the SD card is connected.

It may help to figure out if you can show the output of:

ls -l /dev/mmcblk*