How to get critical parameters, such as fab, board id, sku, etc, for orin series products

  • 1 Background:
    we expect use --no-flash to build the system.img without device connected to PC. So, the critical parameters have to be setted. We searched the README_massflash.txt ( seeing the following post column), but it does not contain orin series. We also searched the developer guild, but still have no idea.

  • 2 Problem:
    we expect to lookup all these critical parameters for all series of orin (agx, nx, nano) in some tables of spec files.
    is there any spec files in the developer forum, or config files in the source code. If not, how to get them?


   Building the massfuse blob with OFFLINE method requires:
   Same as ONLINE method. See ``Building the Massfuse Blob with ONLINE
   method'' above.

   To generate the massfuse blob with OFFLINE method:

   - Enter the command `cd Linux_for_Tegra`.
   - No actual jetson device attachment is necessary.
   - Just add ``BOARDID=<boardid> BOARDSKU=<sku> FAB=<fab>'' in front of
     ``./'' as in ONLINE method:
     BOARDID=<boardid> BOARDSKU=<sku> FAB=<fab> \
     FUSELEVEL=fuselevel_production ./ \
     <odm fuse options> <device_name>
   Where actual values are:
                                      BOARDID  BOARDSKU  FAB  BOARDREV
     jetson-agx-xavier-industrial     2888     0008      600  A.0 
     jetson-xavier-nx-devkit-tx2-nx   3636     0001      100  B.0 
     jetson-xavier-nx-devkit-emmc     3668     0001      100  N/A 
     jetson-nano-devkit-emmc          3448     0002      200  N/A 
     jetson-agx-xavier-devkit (16GB)  2888     0001      400  H.0 
     jetson-agx-xavier-devkit (32GB)  2888     0004      400  K.0 
     jetson-tx2-devkit                3310     1000      B02  N/A 
     jetson-tx2-devkit-tx2i           3489     0000      300  A.0 
     jetson-tx2-devkit-4gb            3489     0888      300  F.0 
     jetson-tx1-devkit                2180     0000      400  N/A 


Hi, with Orin series, you are required to use JetPack 5.x, and massflash, which is only available in JetPack 4.x and previous verisions, has been deprecated, so please use initrd flash instead.

For AGX Orin, please refer to the following file for board information:


For Orin NX and Orin Nano, board information are not explicitly listed in the aforementioned file, but you can get them in flashing log, which appears in a line as follows (for Orin NX):

Board ID(3767) version(TS2) sku(0002) revision(D.2)


we change the platform from tx2 jetpack 4.6.1 to orin jetpack 5.1.1, so not be familiar with it. how to get the README_initrd_flash.txt?


Not quite sure about your question, are you currently on JetPack 5.1.1?
If you download the latest JetPack and L4T release, it’s located in the path in my previous reply.

You may also refer to this document for flashing your devices:

There is a file cvm.bin that will be generated during flash process. You can use chkbdinfo script in BSP to read this cvm.bin and get the info you want.

This info is read out from the eeprom on the module.

Hi @DaveYYY @WayneWWW
yes, we are on jetpack 5.1.1 now.
and the following column is part of Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt

If no Jetson in recovery mode is connected, please specify these env variables when running the flash command:
 ./tools/kernel_flash/ ... 

For the value of these, please refer to the table at the bottom of this file.


Environment variables value table:

#                                     BOARDID  BOARDSKU  FAB  BOARDREV
#    --------------------------------+--------+---------+----+---------
#    jetson-agx-xavier-industrial     2888     0008      600  A.0 
#    clara-agx-xavier-devkit"         3900     0000      001  C.0 
#    jetson-xavier-nx-devkit          3668     0000      100  N/A 
#    jetson-xavier-nx-devkit-emmc     3668     0001      100  N/A 
#    jetson-xavier-nx-devkit-emmc     3668     0003      N/A  N/A 
#    jetson-agx-xavier-devkit (16GB)  2888     0001      400  H.0 
#    jetson-agx-xavier-devkit (32GB)  2888     0004      400  K.0 
#    jetson-agx-orin-devkit           3701     0001      TS1  C.2 
#    jetson-agx-orin-devkit           3701     0000      TS4  A.0 
#    jetson-agx-xavier-devkit (64GB)  2888     0005      402  B.0 
#    holoscan-devkit                  3701     0002      TS1  A.0 
#    jetson-agx-orin-devkit           3701     0004      TS4  A.0 
#    --------------------------------+--------+---------+----+---------

Other environment variables:
EXTOPTIONS: flash option when generating flash image for external devices
ADDITIONAL_DTB_OVERLAY_OPT: Add additional overlay dtbs for UEFI when generating flash image

our questions are:
1 orin nx and nano are not listed in this file, will nvidia update it later?
2 what are these critical parameters for orin nano?

this operation on condition that target device is connected to host pc, but now, we separate compile system.img from flashing, which means no device connected.
4 last but not least
could you give the full name of “FAB” “SKU” “BOARDREV”, and explain their backgrouds, such as why should we need them and with what each of them is associated?


Do you have access to your Orin-series devices now? You may first flash only one device to see if the system works, and also record the board information, then start mass flashing.

We may need to talk about our internal teams to see if these information can be added in future releases. We’ll check and get back to you if you do need parameters for Orin Nano, but cannot get it currently without a board.

yes, of course, we do access to orin agx and nx now.
and could you answer the questions one by one?
we think here is the email form forum, NOT instant messaging, so please be careful about that.

Hi, I will answer them one-by-one as follows:

  1. Orin NX and Orin Nano are relatively new, and may not be considered when the document was construction. We’ll consult our internal team to see if it’s something that’s needs adding in the future.
  2. It’s Board ID(3767) version(300) sku(0003) revision(L.3) for Orin Nano.
  3. As per Q2.
  4. They’re just some code names for engineering purpose. I don’t think we are obligated to disclose the detail.
1 Like

thanks for your reply.
there are lots differences between orin agx and orin nx.
now, we modified orin nx dts, and use the following command to compile it to dtb successfully.

make -C /home/henry/workspace/orinnx/sources/kernel/kernel-5.10 ARCH=arm64 CROSS_COMPILE=/opt/linaro/gcc-linaro-9.3.0-2020.08-1-aarch64-glibc-stable-final/bin/aarch64-buildroot-linux-gnu- O=/home/henry/workspace/make -C /home/henry/workspace/orinnx/sources/kernel/kernel-5.10 ARCH=arm64 CROSS_COMPILE=/opt/linaro/gcc-linaro-9.3.0-2020.08-1-aarch64-glibc-stable-final/bin/aarch64-buildroot-linux-gnu- O=/home/henry/workspace/orinnx/out/KERNEL LOCALVERSION=-tegra -j12 dtbs/out/KERNEL LOCALVERSION=-tegra -j12 dtbs

we expect to update dtb to the target orin nx device ONLY. what should we do next?
we referred to r35.3.1 developer guide, but did not get answers.

Hi, as specified in /boot/extlinux/extlinux.conf, you can just swap out the .dtb file in /boot/dtb/ and reboot.
But if the change in device tree may affect UEFI, then you’d need to do a whole re-flash.

thanks for your reply.

this method on condition that target can bring up successfully, but our device bring up failed.
we expect some command to flash dtb partion ONLY. such as -r -k dtb …

Hi @Henry.Lou

I don’t get what you want to try here. Even if you flash the dtb to partition, the default dtb is read from the rootfs but not the partition you flashed.

Hi all, thanks for your reply.



We thought that, the “A_kernel-dtb” partition is pointed to the rootfs “kernel_tegra234-p3767-0000-p3768-0000-a0.dtb”. Please refer to the following posted flash.xml file. So, we guess that, updating “A_kernel-dtb” partition has the same effect as updating /boot/dtb/kernel_tegra234-p3767-0000-p3768-0000-a0.dtb.
In the previous experience (i.e. jetpack 4.6.1 for tx2), dtb can be update by “./ -r -k dtb tx2 mmcblk0p1”. But, on orin nx device, the tools change to “./tools/kernel_flash/”, is it possible to use update the A_kernel-dtb partition ONLY? How?


       <partition name="A_kernel-dtb" type="kernel_dtb">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 786432 </size>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 8 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <filename> kernel_tegra234-p3767-0000-p3768-0000-a0.dtb </filename>
        <partition name="A_reserved_on_user" type="data">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 33161216 </size>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 8 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
        <partition name="B_kernel" type="kernel">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 134217728 </size>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 8 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <filename> boot.img </filename>
        <partition name="B_kernel-dtb" type="kernel_dtb">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 786432 </size>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 8 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <filename> kernel_tegra234-p3767-0000-p3768-0000-a0.dtb </filename>

Hi @DaveYYY
The following lines are about modifying orin nx /boot/extlinux/extlinux.conf and boo/dtb/.
first, we modified dts and recompiled tegra234-p3767-0001-p3768-0000-a0.dtb.
then, after orin nx bring up, over write /boot/dtb/kernel_tegra234-p3767-0001-p3768-0000-a0.dtb with tegra234-p3767-0001-p3768-0000-a0.dtb on the host pc.
third, reboot orn nx. But, device entry the uefi mode (seeing the following picture), both usb mouse and keyboard have no reflection. The debug uart has no output either.
How to modify the /boot/extlinux/extlinux.conf in this uefi mode?


Hi, for your first question, the answer is NO.
Back in the JetPack 4 era, it’s indeed the case that device trees are read from kernel-dtb partition, and you can you flash it without modifying the app partition to update your custom device trees. However, in JetPack 5, as specified in extlinux.conf, device trees are read from a file in the APP partition, not the dedicated kernel-dtb partition, so flashing it does not make any change.

For the second question, do you know what caused the board to fail to boot up? You may simply replace the dtb file in the BSP and do a whole re-flash. Or you want to keep the APP partition so you do not want to re-flash it?

1 Like

Hi @Henry.Lou ,
we’ve been tracking this issue internally, and board information should be updated in future releases.

Linux_for_Tegra/jetson_board_spec.cfg contains lots of board parameters.
It may help other developers.

    # jetson-agx-orin-devkit:
    # jetson-agx-orin-devkit 32GB:
    # jetson-agx-orin-devkit 64GB:

    # Holoscan:

    # jetson-orin-nano-devkit:
    # orin-nx 16GB
    # orin-nx 8GB
    # orin-nano 8GB
    # orin-nano 4GB

what’s more, could you give the full name of “boardid fab boardsku boardrev rootdev bup_type”, and explain the their meanings. Because, we care confused of so many parameters when developing on different platforms. If we can understand them, it will help us understand these platforms, and develop products more efficiently.

1 Like


How can I check above information?

Thank you.

Dump the eeprom value on your jeston by using i2cdump command.

For example, sudo i2cdump 0 0x50.

You could also put the board into recovery mode and check the flash log. It will tell you.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.