Part of this is just that U-Boot has macros which expand and can search for boot devices. If you change the environment variable, then the search order will differ. You can examine this and alter it in a serial console boot prompt. An example of what it looks like in serial console if you hit a key at the right moment:
[0004.291] I> Kernel EP: 0x84600000, DTB: 0x80000000
U-Boot 2016.07-g0eb73f4 (Mar 13 2019 - 00:20:34 -0700)
TEGRA186
Model: NVIDIA P2771-0000-500
DRAM: 7.8 GiB
MC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@2490000
Hit any key to stop autoboot: 0
Tegra186 (P2771-0000-500) #
If you were to then run the command “boot” then boot would continue. If you run the command “help”, then you’ll see many commands explained. In your case you will find the environment handling commands of extra interest, and the “echo” command. Try “help env”. Look at commands “printenv” and “saveenv”.
If you alter something in U-Boot, but do not save, then the change will take effect for only one boot. It is safe to try different settings and then “boot”. If you find something you like, then you can “saveenv” to make it permanent.
To see what is in your environment use “printenv”. If you want to see a particular variable, then you can use a number of commands to look at it, but I tend to just use “echo $variable”. For example, “echo $vendor” should reply “nvidia”.
Remember I mentioned using “boot” to continue boot? This triggers macro expansion of “$bootcmd”. Check “echo $bootcmd”. This becomes “run distro_bootcmd”. If you “echo $distro_bootcmd”, then you will see this expands to:
for target in ${boot_targets}; do run bootcmd_${target}; done
You’re now getting close, look at “echo $boot_targets”:
mmc1 mmc0 usb0 pxe dhcp
The boot will cycle from “mmc1” to “mmc0” to “usb0” to “pxe” to “dhcp”. The first one which has the correct trigger condition will become the partition booted. If you have multiple boot devices from that list, then the first one considered “acceptable” will boot. I don’t remember what all is used to determine “acceptable”, but I think anything “ext4”, perhaps with a “/boot” directory, is accepted.
If you have just eMMC, but SD is searched for, then eMMC would boot. When SD has the right content, and is searched prior to eMMC, then SD will be used.
A very important but subtle thing to understand is that when you flash a pointer to a device to start with is from the flash command line. Look at the two following manual flash commands for a TX2:
sudo ./flash.sh jetson-tx2 mmcblk0p1
sudo ./flash.sh jetson-tx2 mmcblk1p1
Some boot content will always remain on the Jetson no matter where you tell the flash to look for configuration. In the first case everything will be on the TX2. In the latter case part of the boot information will be on the TX2, and some will now be instead on the SD. If you flash to mmcblk0p1, then the system can boot regardless of whether the is an SD card. If you flash to mmcblk1p1, then no configuration will ever be found if the SD card is missing. Flashing to mmcblk0p1 still allows macro expansion, but it isn’t until boot finds the device configured that the macro expansion even matters. I always recommend flashing to mmcblk0p1 even if you only plan to use SD since you could use the eMMC as a kind of rescue. Once to put that initial pointer in from flash to point at mmcblkp1 there will never again be a boot without that SD card.
Depending on whether search looks at mmcblk0 or mmcblk1 you might find either of two extlinux.conf files. The actual kernel argument for “rootfs=” is what determines root device for the Linux kernel even if U-Boot used a different device to find the configuration and U-Boot environment.