Dear NVIDIA team，
Due to several PCN updates for AGX Orin, eMMC chips from multiple manufacturers and models have been adopted. This makes it impossible for me to confirm the exact eMMC model on each individual device.
I would like to identify the eMMC manufacturer and model during the firmware flashing process. Could anyone share a feasible method to retrieve this information?
*** Please note that this reply is generated by LLM automatically ***
To identify the eMMC manufacturer and model during the firmware flashing process on the Jetson AGX Orin, you can use the following methods:
mmc command: You can use the mmc command to retrieve information about the eMMC device. Specifically, you can use the mmc extcsd read command to read the Extended CSD (eCSD) register, which contains information about the eMMC device, including the manufacturer and model.Here’s an example of how to use the mmc command:
$ mmc extcsd read /dev/mmcblk0
This will output a list of information about the eMMC device, including the manufacturer and model.
mtd command: You can use the mtd command to retrieve information about the eMMC device. Specifically, you can use the mtd info command to retrieve information about the eMMC device, including the manufacturer and model.Here’s an example of how to use the mtd command:
$ mtd info /dev/mmcblk0
This will output a list of information about the eMMC device, including the manufacturer and model.
mmc driver logs, which will contain information about the eMMC device, including the manufacturer and model.Here’s an example of how to parse the kernel logs:
$ dmesg | grep mmc
This will output a list of logs related to the mmc driver, including information about the eMMC device.
nvme command: If you are using an NVMe storage device, you can use the nvme command to retrieve information about the device. Specifically, you can use the nvme id-ctrl command to retrieve information about the device, including the manufacturer and model.Here’s an example of how to use the nvme command:
$ nvme id-ctrl /dev/nvme0
This will output a list of information about the NVMe device, including the manufacturer and model.
Comparison of methods:
mmc command is the most straightforward method to retrieve information about the eMMC device.mtd command provides more detailed information about the eMMC device, but it may require more expertise to parse the output.nvme command is specific to NVMe storage devices and provides detailed information about the device.Conclusion:
To identify the eMMC manufacturer and model during the firmware flashing process on the Jetson AGX Orin, you can use the mmc command, mtd command, parse the kernel logs, or use the nvme command (if using an NVMe storage device). The mmc command is the most straightforward method, while the mtd command and parsing the kernel logs provide more detailed information.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
The latest AGX Orin eMMC PCN is PCN211462, which was released at 2024/9.
All relevant overlay patch for JetPack 5.x or JetPack 6.x ere provided at PCN download center, and you can identify them by 699 level part number.
May I know which JetPack SW you’re using on your product?
Any JetPack version works, the latest release is also acceptable.
I just want to read eMMC model information from the host side. Per PCN notice, Kingston eMMC is newly added instead of replacing the original Micron version. Modules we received may come with either Micron or Kingston eMMC. My goal is to distinguish the two eMMC specifications during firmware flashing.
Why wants to do that? The SW can be flashed on both modules, any specific reason?
We found during testing that there is a 900MB capacity difference between two types of eMMC modules. Kingston eMMC has 900MB less capacity than the previous version.
We have a previously cloned system.img file. However, flashing it to an EMMC storage with 900MB less capacity will cause errors. A modified version of system.img is required instead. We aim to resolve this urgent production issue. Currently, we can only access the Orin system for verification to determine the proper image to flash.
My Orin is distant from my x86_64 hosts, so I can’t currently test recovery mode methods. Following may be helpful.
If the Orin is booted NOT in recovery mode you could
ssh user@JETSON_IP 'sudo blockdev --getsize64 /dev/mmcblk0'
If Orin is in recovery mode try
cd Linux_for_Tegra
sudo ./bootloader/tegrarcm_v2 --chip 0x23 0 --oem platformdetails storage storage_info.bin
# This writes storage_info.bin. To extract the size in human-readable form, pass it to tegraparser_v2:
sudo ./bootloader/tegraparser_v2 --storageinfo storage_info.bin --generategpt --pt flash.xml
# The flash XML will contain the actual partition layout with sizes derived from the device's reported capacity. (tegraflash_internal.py:3097 and
# tegraflash_impl_t234.py:1215 show this pattern.)
If you've got eeprom (board info, parsed with chkbdinfo):
cd Linux_for_Tegra
sudo ./bootloader/tegrarcm_v2 --chip 0x23 0 --oem platformdetails eeprom cvm cvm.bin
xxd -g 1 cvm.bin
# or use the board info parser:
./bootloader/chkbdinfo -a cvm.bin # all info
./bootloader/chkbdinfo -i cvm.bin # board ID
# Or see what this provides:
sudo ./flash.sh --no-flash --read-info jetson-agx-orin-devkit mmcblk0p1
Would one of these answer which board it is?
./chkbdinfo
usage: chkbdinfo [options] <input file>
Where [options] are:
[--partnumber|-p] --------- Dump Board Part Number
[--class|-c] -------------- Dump Board Class
[--assetid|-a] ------------ DUMP Asset ID
[--id|-i] ----------------- Dump Board ID
[--sku|-k] ---------------- Dump Board SKU
[--fab|-f] ---------------- Dump Board FAB number
[--revision|-r] ----------- Dump Board Revision
[--wifi|-w] --------------- Dump WiFi MAC
[--btmac|-b] -------------- Dump BT MAC
[--gigabitethernet|-g] ---- Dump Gigabit Ethernet MAC
[--version|-v] ------------ Dump Board Info Version
[--chipsku|-C] ------------ Dump ChipSku ID
[--chipminorrev|-M] ------- Dump ChipMinorRevision ID
[--bootromrevision|-O] ---- Dump BootRomRevision ID
[--ramcode|-R] ------------ Dump RamCode ID
Thank you for your reply. I can obtain the information you mentioned. The commands you provided can read the device’s SN and the specific model of the Orin, but they cannot identify the exact eMMC model on the Orin.
I haven’t used this particular command before, and it failed to execute:
Linux_for_Tegra/bootloader$ sudo ./tegrarcm_v2 --chip 0x23 0 --oem platformdetails storage ./storage_info.bin
File rcm_state open failed
ERROR: failed to read rcm_state
In any case, thank you again for the information you provided.
Shortest route / fastest method I could find to identify from Orin in recovery mode.
sudo ./flash.sh --no-flash --read-info jetson-agx-orin-devkit mmcblk0p1
cd bootloader
sudo bash ./readinfocmd.txt
cd ..
serial="$(
sudo ./bootloader/chkbdinfo -a bootloader/cvm.bin | tr -d '[:space:]'
)"
mfg_code="${serial:0:3}"
printf 'serial=%s\n' "$serial"
printf 'mfg_code=%s\n' "$mfg_code"
Then
Serial Number Format
142 # Made in China
161 # Made in USA
179 # Vietnam I'm guessing that since Foxconn Vietnam is newest fabricator that it is the smaller MMC.
serial="$(
sudo ./bootloader/chkbdinfo -a bootloader/cvm.bin | tr -d '[:space:]'
)"
mfg_code="${serial:0:3}"
case "$mfg_code" in
142)
mfg_country= 60GB image
;;
161)
mfg_country= 60GB image
;;
179)
mfg_country= 51GB image
;;
*)
mfg_country="Unknown"
;;
esac
Based on past experience, the same Orin manufacturing factory may use different eMMC suppliers. All the Orin modules we have received are with supplier code 142, but the eMMC chips come from multiple vendors, including Micron, Western Digital (WD), and SK Hynix.
To run this, save probe-orin-mmc-size.sh to Linux_for_Tegra and tegraflash_impl_t234.py to bootloader. This only queries Orin and does no writes to it.
Put Orin into recovery mode.
cd Linux_for_Tegra
sudo bash probe-orin-mmc-size.sh
# You can modify the PYEOF heredoc in probe-orin-mmc-size.sh to grab the value you want.
# Here's the current print
=== storage_info.bin ===
-rw-r--r-- 1 root root 72 May 27 11:04 bootloader/storage_info.bin
--- printable strings ---
--- hex dump (first 80 lines) ---
00000000 03 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 |................|
00000010 00 02 00 00 00 00 00 00 00 00 00 00 03 00 00 00 |................|
00000020 00 f8 01 00 00 00 00 00 00 02 00 00 00 00 00 00 |................|
00000030 01 00 00 00 03 00 00 00 00 00 69 07 00 00 00 00 |..........i.....|
00000040 00 02 00 00 00 00 00 00 |........|
00000048
=== Storage capacity summary ===
Entry Type Device Inst Sectors Sec SZ Capacity
------------------------------------------------------------------------------------------
0 3 QSPI/SPI NOR 0 131,072 512 67,108,864 bytes (0.07 GB / 0.06 GiB)
1 0 eMMC BOOT partitions 3 129,024 512 66,060,288 bytes (0.07 GB / 0.06 GiB)
2 1 eMMC USER area 3 124,321,792 512 63,652,757,504 bytes (63.65 GB / 59.28 GiB)
>>> eMMC user area capacity:
63,652,757,504 bytes
62,160,896 KiB (1 KiB = 1024 bytes)
63,652,757 KB (1 KB = 1000 bytes)
60,704 MiB (1 MiB = 1024 KiB)
63,652 MB (1 MB = 1000 KB)
59.281 GiB (binary, as Linux reports)
63.653 GB (decimal, as manufacturers report)
≈ 64 GB nominal
Modified bootloader/tegraflash_impl_t234.py as follows
# Inside tegraflash_dump(), after the 'try_custinfo' elif block, before the final 'else' clause, added
elif dump_args[0] == 'storage':
# Query MB2 applet for storage device info (eMMC size, type, etc.)
# and write to storage_info.bin.
# Mirrors tegraflash_get_storage_info() but callable from --cmd sequences
# without needing a full flash run.
if len(dump_args) > 1:
self.tegrarcm_values['--storage_info'] = dump_args[1]
self.tegraflash_get_storage_info()
tegraflash_impl_t234.py.txt (168.4 KB)
probe-orin-mmc-size.sh.txt (3.6 KB)