1 Background:
we expect use flash.sh --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?
FYI
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
``./nvmassfusegen.sh'' as in ONLINE method:
BOARDID=<boardid> BOARDSKU=<sku> FAB=<fab> \
FUSELEVEL=fuselevel_production ./nvmassfusegen.sh \
<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):
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.
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:
sudo BOARDID=<BOARDID> FAB=<FAB> BOARDSKU=<BOARDSKU> BOARDREV=<BOARDREV>
./tools/kernel_flash/l4t_initrd_flash.sh ...
For the value of these, please refer to the table at the bottom of this file.
Appendix:
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?
3
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.
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.
It’s Board ID(3767) version(300) sku(0003) revision(L.3) for Orin Nano.
As per Q2.
They’re just some code names for engineering purpose. I don’t think we are obligated to disclose the detail.
Hi
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.
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.
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 flash.sh -r -k dtb …
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.
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 “./flash.sh -r -k dtb tx2 mmcblk0p1”. But, on orin nx device, the tools change to “./tools/kernel_flash/l4t_initrd_flash.sh”, is it possible to use l4t_initrd_flash.sh update the A_kernel-dtb partition ONLY? How?
PART 2
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?
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.
