Hi.
I purchased the AGX ORIN devkit. At the time of purchase, Jetson 5.1.2 was already installed on my EMMC, but I would like to install Jetson 5.1.2 on my SSD (256GB) and use the AGX ORIN devkit.
I used SDKmanager to install the software on the SSD and it failed.
Assuming that the installation errors were caused by settings and operations during installation and compatibility with SSDs, I tried the following.
Prepare another SSD (512GB) and install Jetson 5.1.2 using SDKmanager. Installation error occurred.
Install Jetson5.1.2 on SSD using CUI. "Flash is successful Reboot device Cleaning up…” But nothing appears on the screen.
Install Jetson5.1.2 on EMMC using CUI."Flash is successful Reboot device Cleaning up…” But nothing appears on the screen.
Reinstall Jetson 5.1.2 on EMMC using SDKmanager. Installation succeeded and can be used.
Install Jetson5.1.3 on SSD using SDKmanager. Installation succeeded and can be used.
Plug the SSD into the ORIN NANO Developer Kit and install Jetson 5.1.2 using SDKmanager. Installation succeeded and can be used.
For CUI, I followed the procedure in the following URL. Quick Start — Jetson Linux Developer Guide documentation
I checked the article “Maybe your AGX Orin is a new one that has a smaller eMMC chip so old BSP does not support it.”, but since I was able to reinstall it on EMMC using the SDK, I believe there may be another cause.
Hi,
If the device cannot be flashed/booted, please refer to the page to get uart log from the device: Jetson/General debug - eLinux.org
And get logs of host PC and Jetson device for reference. If you are using custom board, you can compare uart log of developer kit and custom board to get more information.
Also please check FAQs: Jetson AGX Orin FAQ
If possible, we would suggest follow quick start in developer guide to re-flash the system: Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation
And see if the issue still persists on a clean-flashed system.
Thanks!
Hi, DavidDDD
Thank you for your response. I have checked the topic you submitted.
I tried flashing after removing the Ethernet cable,
The installation did not work.
The timing of my disconnecting the Ethernet cable may be different, so I will describe the procedure I performed.
Put AGX into recovery mode.
Start SDKmanager from the host PC.
Disconnect Ethernet cable before checking accpet in STEP02.
Thank you for your prompt reply.
Let me confirm to make sure that , would it be sufficient to start the AGX ORIN Devkit in EMMC and run the commands you suggest?
Please point out if I am wrong.
The results of the EMMC run are attached. AGX_ORIN_EMMC.txt (344 Bytes)
It appears that the SDK Manager has selected the flash_t234_qspi_sdmmc.xml configuration. Given that your SKU is 0005, it suggests that the eMMC size is smaller, which leads to the issue you mentioned. In this situation, you could apply the patch discussed in mentioned topic to resolve the problem.
I will also include the part of the description that has been changed because my work seems to be incomplete.
Referring to the topic, I have added a note at the end of the file. Linux_for_Tegra/p3701.conf.common
# update_local_cfgfile
update_local_cfgfile()
{
# Update "num_sectors" in local cfgfile for the device
# with FAB=501 and BOARDSKU=0004/0005
local local_cfgfile="${1}"
if [ "${board_FAB}" == "501" ] && [[ "${board_sku}" == "0004" || "${board_sku}" == "0005" ]]; then
sed -i 's/num_sectors=\"124321792\"/num_sectors=\"124190720\"/' "${local_cfgfile}"
fi
}
Also, since Flash.sh does not supportupdate_local_cfgfile() in the topic, I added update_local_cfgfile ${localcfgfile} to Flash.sh.
# For T194 device, mb1_b needs to have a different signed image from mb1.
# The solution here is to prepare an image with different name for mb1_b.
# Then the signing utility later will generate a different signed image for mb1_b
if [ "${tegraid}" = "0x19" ]; then
# Create a file to store the partition layout with mb1 fix
localcfgfile_mb1_fix_ext="${localcfgfile##*.}";
localcfgfile_mb1_fix_name="${localcfgfile%.*}";
localcfgfile_mb1_fix="${localcfgfile_mb1_fix_name}_mb1_fix.${localcfgfile_mb1_fix_ext}";
mb1_b_filename="${mb1filename:0:3}_b${mb1filename:3}";
cp "${mb1file}" "${BL_DIR}/${mb1_b_filename}";
# Replace the mb1_b filename (the second MB1FILE)
sed ':a;N;$!ba;s/MB1FILE/'"${mb1_b_filename}"'/2' "${cfgfile}" > "${localcfgfile_mb1_fix}"; chkerr;
mkfilesoft cfgfile "${localcfgfile_mb1_fix}" "";
fi;
# CFGCONV is a flat string holding a bunch of flags for sed, so should not be
# quoted. Maybe need to convert CFGCONV to a list so that we can quote this.
# For now, though, disable SC2086.
cat "${cfgfile}" | limit_boot_chains | sed ${CFGCONV} > ${localcfgfile}; chkerr;
##### ADDED LINE - Replace number of sectors ######
update_local_cfgfile ${localcfgfile}
# FLASH:
#
I started SDKmanager and ran it after disconnecting the Ethernet cable, but it failed to install as well.
Since you can successfully flash through the command line using the Quick Start, there might be an issue with the SDK Manager. In this case, I have two suggested options:
Create a default user and use command line flash:
Follow the instructions for creating a default user by skipping the OEM configuration section as outlined in the documentation.
Follow the Quick Start and flash using command line
Retry using the SDK Manager with UART log recording for further investigation:
To record the UART log, please refer to this documentation.
I understand that the only thing left to do is to implement either the SDK modification or implement it in the CUI.
The quick start in jetpack 5.1.2 doesn’t say how to write to AGX ORIN SSD, so I’m assuming you use another method such as initrdflash.
So I ran it on EMMC as a confirmation without writing to the SSD.
Install from CUI to EMMC.
Disconnect the Ethernet cable and run it. > $ l4t_create_default_user.sh [-u <user>] [-p <pswd>] [-n <host>] [-a]
to set the name, password, and hostname.
After that,
$ tar xf ${L4T_RELEASE_PACKAGE}
$ sudo tar xpf ${SAMPLE_FS_PACKAGE} -C Linux_for_Tegra/rootfs/
$ cd Linux_for_Tegra/
$ sudo . /apply_binaries.sh
$ sudo . /tools/l4t_flash_prerequisites.sh
$ sudo . /flash.sh jetson-agx-orin-devkit internal
It seems that the flashing process was successful. The current issue appears to be related to the monitor.
Do you have experience using ssh ?
You can perform the following tests:
Verify that your cable is a pure DisplayPort (DP) cable and not an adapter.
Use ssh to access the device while it is connected to the monitor and share the following files with us:
/var/log/Xorg.0.log
The output of lsmod saved to a file: lsmod > lsmod.txt
The output of dmesg saved to a file: dmesg > dmesg.txt
Cross checks have been performed, but I have been able to secure another monitor and cable and will be reinstalling in EMMC with CUI to cross check.
I have been able to confirm that the image appears on the monitor in the following two patterns.
・When JetPack 5.1.2 is installed on EMMC using SDKmanager.
・When JetPack 5.1.3 is installed on SSD using SDKmanager.
Nothing on the screen was a bit of a misnomer.
When installing 5.1.2 from SDKmanager to SSD,
the NVIDIA screen at startup → read → no signal.
When installed on EMMC with CUI and using a different monitor and cable
”No DP signal” is displayed on the monitor.
