HDMI on custom Xavier NX carrier board

Dear Experts,

I am working on bringing up the HDMI output for the the Jetson Orin Nano 8GB (picked from the Nvidia Jetson Orin Nano Developer Kit) on top of our custom carrier board that works fines with Xavier NX.

The custom board does not dispose EEPROM,

I tested in both Jetpack-5.1.2 and Jetpack-6.2.

So far the first problem I faced was “Waiting for target to boot-up…” in loop. I resolved this as below :

In Jetpack-5.1.2, I followed this link Jetson Orin NX and Nano Series — Jetson Linux Developer Guide documentation

In Jetpack-6.2 : I did similarly (cvb_eeprom_read_size = <0x0>) for the file JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/bootloader/generic/BCT/tegra234-mb2-bct-misc-p3767-0000.dts.

then flashed the NVMe on the board :

In Jetpack-5.1.2, with command :

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" --showlogs --network usb0 p3509-a02+p3767-0000 internal

(Please note that I used p3509-a02+p3767-0000.conf as it was said the one having all the software patches working for the use-case of Jetson Orin Nano on top of Xavier NX carrier board with HDMI output)

The flashing was NOT successful with the following error :

saving flash command in flashcmd.txt

*** no-flash flag enabled. Exiting now... *** 

User can run above saved command in factory environment without 
providing pkc and sbk keys to flash a device

Example:

    $ cd bootloader 
    $ sudo bash ./flashcmd.txt

Save initrd flashing command parameters to /workspace/Ref/Platforms/Nvidia-Jetson/Software/SDK_installs/JetPack_5.1.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/tools/kernel_flash/initrdflashparam.txt
/tmp/tmp.AVVELzJnPP /workspace/Ref/Platforms/Nvidia-Jetson/Software/SDK_installs/JetPack_5.1.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra
writing boot image config in bootimg.cfg
extracting kernel in zImage
extracting ramdisk in initrd.img
/tmp/tmp.AVVELzJnPP/initrd /tmp/tmp.AVVELzJnPP /workspace/Ref/Platforms/Nvidia-Jetson/Software/SDK_installs/JetPack_5.1.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra
58247 blocks
84699 blocks
/tmp/tmp.AVVELzJnPP /workspace/Ref/Platforms/Nvidia-Jetson/Software/SDK_installs/JetPack_5.1.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra
flashimg0=boot0.img
/workspace/Ref/Platforms/Nvidia-Jetson/Software/SDK_installs/JetPack_5.1.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra
Success
Cleaning up...
Finish generating flash package.
No devices to flash

Full flashing log :
flash_1-4_0_20250312-133324.log (7.4 KB)

Then in Jetpack-6.2, with command :

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1   -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml"   --showlogs --network usb0 p3509-a02-p3767-0000 internal

(Please note that the p3509-a02+p3767-0000.conf in Jetpack-5.1.2 became p3509-a02-p3767-0000.conf in Jetpack-6.2)

The flashing seemed to be successful but NO HDMI output seen :

Writing /mnt/internal/gpt_secondary_3_0.bin (16896 bytes) into  /dev/mtd0:67091968
Copied 16896 bytes from /mnt/internal/gpt_secondary_3_0.bin to address 0x03ffbe00 in flash
[ 206]: l4t_flash_from_kernel: Successfully flash the qspi
[ 206]: l4t_flash_from_kernel: Flashing success
[ 206]: l4t_flash_from_kernel: The device size indicated in the partition layout xml is smaller than the actual size. This utility will try to fix the GPT.
Flash is successful
Reboot device
Cleaning up...
Log is saved to Linux_for_Tegra/initrdlog/flash_1-4_0_20250312-140429.log 

Full flashing log :
flash_1-4_0_20250312-140429.log (48.2 KB)

Could you help to share some insight to resolve the issue, please ?

Thanks and best regards,
K

Hi again,

To update, in Jetpack-5.1.2, I also modified the ./bootloader/t186ref/BCT/tegra234-mb2-bct-scr-p3767-0000.dts file according to the chapter 4.2.3. Adaptation to the Carrier Board with HDMI for the Orin NX/Nano Modules in the Jetson_Linux_Release_Notes_r35.4.1.pdf

--- a/firewall/tegra234-mb2-bct-scr-p3767-0000.dts
+++ b/firewall/tegra234-mb2-bct-scr-p3767-0000.dts
@@ -5,6 +5,11 @@
/ {
tfc {
+ reg@322 { /* GPIO_M_SCR_00_0 */
+ exclusion-info = <2>;
+ value = <0x38009696>;
+ };
+
reg@5138 { /* CBB_CENTRAL_CBB_FIREWALL_QSPI0_BLF, READ_CTL */
exclusion-info = <2>;
value = <0x00100009>;

In Jetpack-6.2, the modification is already available in the bootloader/generic/BCT/tegra234-mb2-bct-scr-p3767-0000.dts file :

/dts-v1/;

#include "tegra234-chip.dtsi"
#include "tegra234-mb2-bct-scr-p3701-0000-override.dts"

/ {
    tfc {

        reg@322 { /* GPIO_CTL, GPIO_M_SCR_00_0 */
            exclusion-info = <2>;
            value = <0x38009494>;
        };

Best Regards,
K.

You should check your UART log. Please take it as common sense when you see “Waiting for target to boot-up…” error on host.

And I guess it is just your usb device tree has some problems so it cannot get detected in that flash stage.

And just to clarify. This is a flash related and could be usb related issue.

Your HDMI totally has nothing to do with current situation. No need to discuss about that untill you fix the flash problem.

Hi @WayneWWW,

I suppose that the “Waiting for target to boot-up…” issue has been a known issue relevant to EEPROM and I resolved it by following the instruction here : Jetson Orin NX and Nano Series — Jetson Linux Developer Guide documentation

No, we cannot tell that unless you share the uart log.

Lots of reasons could lead to “Waiting for target to boot-up…”.

And just to clarify. What is the exact jetpack version that you want to test here?

Please avoid jumping between jp6 and jp5. It would just make the communication complicated.
Your issue happened in one version may not be same on another one.

I prefer the jp6.2 with super mode enabled. Sorry for the jumping as I wanted to double check.

OK. If I read your comment correctly, flash on jp6 has no issue.

Could you share this information out?

  1. lsmod
  2. dmesg
  3. /var/log/Xorg.0.log

Hi @WayneWWW,

Yes I was able to flash the NVMe in the setup of Orin Nano on the custom carrier board and it was only successful if I made the modification in JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/bootloader/generic/BCT/tegra234-mb2-bct-misc-p3767-0000.dts as mentioned in the initial comment. Otherwise, there would be “Waiting for target to boot-up…” in loop.

I will manage to provide the log from DEBUG UART port as soon as possible.

Hi @WayneWWW,

Please find attached the log from DEBUG UART Port. Currently I am not able to interact with the board via this port yet, not sure if there’s problem with the Rx line to the Jetson SOM or the running board does not accept the communication.

JetsonOrinNano_NoGUI.log (63.1 KB)

Your UART log seems not completed one.

Sorry, it must be truncated by control/invisible characters. Below is the newer one.
JetsonOrinNano_CustomCarrier_NoHDMIGUI.txt (432.9 KB)

[12:04:20:816] [ 23.665278] Please complete system configuration setup on the serial port provided by Jetson’s USB device mode connection. e.g. /dev/ttyACMx where x can 0, 1, 2 etc.␍␊

The system is waiting for you to configure account so that it can move forward. You won’t be possible to operate UART console until you bypass this.

There is a method to run l4t-create-default-users.sh on your host PC BSP directory first and then reflash the board. It will make above passed.

Hi @WayneWWW,

Thanks for your quick reply. I tried moving the Orin Nano module and the newly flashed NVMe SSD back to the Nvidia Jetson Orin Developer Kit and could see this :

What seems to be strange to me is that I flashed the NVMe SSD with p3509-a02-p3767-0000.conf configuration which is said for HDMI output but the DP port of the Nvidia Development Kit still shows something.

Hi,

No need to worry about that. That is because Orin Nano devkit hardware supports dual mode so even the wrong software setting is there, it may still have some output.

Hi @WayneWWW,

Please find the required logs after re-flashing with the setting of default username, password.

Boot log :
debug_log.txt (112.1 KB)

lsmod :
lsmod.txt (7.9 KB)

dmesg :
dmesg.txt (69.4 KB)

Hi again,

I changed the monitor and could see the boot messages but then the display got stuck at “Started RealtimeKit Scheduling Policy Service” :

Where is the xorg log?

Also, nvidia-modeset driver is missing from the lsmod.

Please check if it is present under your /lib/modules and why it cannot get probed.