HDMI output with jetpack 6.2.1

Dear Jetson Hardware Experts,

With SDK Manager, I installed JetPack 6.2.1 (with L4T: R36, REVISION: 4.4) and I am able to run a Jetson Orin NX 8G with a carrier board devkit.
I used the following 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 jetson-orin-nano-devkit external

The issue is that my custom carrier board has an HDMI connector instead of a DisplayPort connector. I am not able to get any video output through HDMI.

I tried the following 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 external

I also tried several other solutions I found on the forum, without success.

My design is similar to the one described in the design guide, excerpt below:

I modified my custom carrier board to drive the hotplug pin DP1_HPD (pin 96), and I do not observe any I2C communication on the oscilloscope on pins DP1_AUX_P and DP1_AUX_N (pins 98 and 100).

Could you please provide further support on this?

Thanks and best regards.

p3509+p3767 config already supported the HDMI mode for a Orin NX/Nano. Please use that to flash.
or refer to it to know what files are needed to enable HDMI.

I use the p3509-a02-p3767-0000.conf file to flash. However, I do not see any I2C communication regardless of the hotplug polarity, if it is indeed pin 96.

Is there a way to force the video output so that it always sends data ?

Are you using a native HDMI monitor there with EDID?

Please share the xorg log too.

Thank you for your replies.

Yes, I have already extracted the EDIDs from the displays I am using.
At the moment, I have tried with an OLED55C35LA, a VE228H, and a T240 LS24TWHSUV.

Here is the xorg log file
Xorg.txt (18.2 KB)

And some other information:

ls /sys/class/drm
card0  card1  card1-HDMI-A-1  renderD128  renderD129  version
cat /sys/class/drm/card1-HDMI-A-1/modes
nothing

I also get this kind of message in dmesg:

WARNING: CPU: 0 PID: 0 at drivers/gpio/gpio-tegra186.c:632 tegra186_gpio_irq+0x1f4/0x270

dmesg.txt (132.3 KB)

Can you please tell me what is the correct value for this file ?
bootloader/generic/BCT/tegra234-mb2-bct-scr-p3767-0000.dts

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

or

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

Hi,

Please stop changing anything to the SCR.

I already told before. That thing is not needed to get changed. The default value is already correct one on rel-36.4.4.

If you really see things from gpio-tegra186, then please go back to review your hardware design. Compare it with xavier NX devkit p3509 design.

24.109] (–) NVIDIA(GPU-0): DFP-0: disconnected
[ 24.109] (–) NVIDIA(GPU-0): DFP-0: Internal TMDS

Your HDMI is still disconnected from your xorg log.

Hi,

I removed my modifications. I flashed the board with the default files.

dmesg.txt (55.3 KB)
Xorg0.txt (18.2 KB)

I no longer get this message:

WARNING: CPU: 0 PID: 0 at drivers/gpio/gpio-tegra186.c:632 tegra186_gpio_irq+0x1f4/0x270

However, I still see these lines:

[    23.872] (--) NVIDIA(GPU-0): DFP-0: disconnected
[    23.872] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS

I compared my design with the Xavier NX devkit p3509 and did not find any errors.

What makes me think this is a SW issue is that I measured the voltage at the input of pin 96.
I see 1.8 V when the HDMI cable is unplugged and 0 V when the HDMI cable is plugged in.

However, I do not see any voltage change on pins 98 and 100.

So, the voltage at the hotplug pin input is correct, but the Jetson does not start the I2C communication. Could this really be a HW issue ?

Do you have Xavier NX devkit on your side?

Please be aware that this software has been in use for a long time. Orin display configuration only has limited options. You could only check from hardware if this software setting does not work.

Unfortunately, I don’t have a Xavier NX devkit.

Thanks for your help, I will keep looking.

If you have ideas of things I can check, I am interested

I’m wondering about some details. If you monitor “dmesg --follow”, and then either plug in or unplug the HDMI (you can monitor via serial console or ssh), is there a log entry showing the event? If so, then hot plug detect works.

If hot plug detect works, can you measure the HDMI cable voltage between pin 17 (ground) and pin 18 (should be +5V whenever an i2c read is performed)? This powers the i2c circuitry in the monitor (power source is the Jetson so monitors can be queried even when turned off).

If those two conditions are met, then there should be a short burst of i2c data on the DDC wire (3.3V) during a read of the EDID data. The pin numbers for the EDID content (and also DDC and its ground) can be found here:
https://en.wikipedia.org/wiki/HDMI

If hot plug detect fails, or if the 5V is not provided by the Jetson, then your device tree is likely incorrect. If those are correct, then probably DDC content will occur, but having the data wires set wrong would interfere with this. Checking with an oscilloscope for something like the DDC clock and data could tell you if your hardware is doing what it should even if the EDID data is ignored.

Note that normally only EDID modes are allowed in a Jetson, and that other hand picked modes won’t be honored. It is very important to know if the device tree has set up the HDMI pins correctly.

Hi,

With the command dmesg --follow and plugging/unplugging the HDMI cable, I don’t see anything.

I assume that hotplug pin 96 is correctly connected because, when I change from:

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

to:

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

in the file tegra234-mb2-bct-scr-p3767-0000.dts, I get this kind of message:

WARNING: CPU: 0 PID: 0 at drivers/gpio/gpio-tegra186.c:632 tegra186_gpio_irq+0x1f4/0x270

You can see the complete logs in the dmesg.txt file of my third post.

But with the default files, I don’t observe any reaction. Besides, I haven’t found the documentation that explains the configuration of reg@322. If you have it, that would be great.

Nevertheless, I can confirm the presence of 5 volts, and I can guarantee that the Jetson does not send any I2C commands.

Regarding the connections, I am stuck on the file kernel/dtb/tegra234-dcb-p3767-0000-hdmi.dtbo.
I converted it with the command:

./dtc -I dtb -O dts -o tegra234-dcb-p3767-0000-hdmi.dts ./dtb/tegra234-dcb-p3767-0000-hdmi.dtbo

Then, I get a nvidia,dcb-image, which I believe is a Display Control Block (DCB) blob, but I cannot decode it manually (I cannot find any documentation for a DCB version 5), nor with the dcb_tool utility:

./dcb_tool -r tegra234-dcb-p3767-0000-hdmi.dts
=== Reading DCB blob ===
Segmentation fault (core dumped)

tegra234-dcb-p3767-0000-hdmi.dts.txt (25.5 KB)

Finally, there is no data or clock coming out of the Jetson pins (63/65, 69/71, 75/77, and 81/83).

Hi,

Just want to clarify that.

It seems you focus too much on that tegra234-mb2-bct-scr-p3767-0000.dts. This thing is just firewall setting. Changing that from 9494 to 9696 only means you enable some cores that able to access that pin. But those cores don’t need to access that actually.

That thing really does not matter. I think the software change you should check is whether your pinmux setting for the HPD pin is really GPIO or not.

And if the os_gpio_hotplug is there in your device tree. It is by default there, but I am uncertain if you removed it by accident.

All these things should be covered in the p3509 config already.

Also, no need to dig into default “tegra234-dcb-p3767-0000-hdmi.dtbo”.

This thing won’t be wrong, unless you changed the content by yourself before.

In my current situation, I am indeed using the p3509-a02-p3767-0000.conf configuration, and I only made one modification :
in the file tegra234-mb2-bct-misc-p3767-0000.dts

- 			cvb_eeprom_read_size = <0x100>;
+ 			cvb_eeprom_read_size = <0x0>;

I confirm that I do have the HPD configuration in tegra234-p3768-0000+p3767-0001-nv.dts:

	display@13800000 {
	...
		os_gpio_hotplug_a = <0xf3 0x60 0x0>;

and in the tegra234-mb1-bct-gpio-p3767-hdmi-a03.dtsi file :

	gpio@2200000 {
	...
		gpio_main_default: default {
			gpio-input = <
				...
				TEGRA234_MAIN_GPIO(M, 0)

If I am not mistaken, the HPD pin is 96, as can be seen in the screenshot from my first message.
When I check the state with the command:

gpioget gpiochip0 96

I always get 0, whereas the voltage going into the pin does vary between 0V and 1.8V depending on whether the HDMI cable is plugged or unplugged. Could this be an issue ?

Has HDMI been tested with a Jetson Orin NX and JetPack 6.2.1 ?

If I am not mistaken, the HPD pin is 96, as can be seen in the screenshot from my first message.

No, you made a mistake here. the pin number on the SOM is never the GPIO # in the software.

List out the GPIO info and get the number for GPIO M,0 is the correct way.

Indeed,

Here is what I get with two commands:

gpioinfo
gpiochip0 - 164 lines:
        ...
        line  76:      "PM.00"       kernel   input  active-high [used]
cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 348-511, parent: platform/2200000.gpio, tegra234-gpio:
 ...
 gpio-424 (PM.00               )

gpioinfo.txt (12.8 KB)

But I cannot get its state:

gpioget gpiochip0 76
gpioget: error reading GPIO values: Invalid argument

The above pretty much guarantees hot plug detect does not work. PINMUX is highly likely wrong. Regardless of whether you modify this via the spreadsheet or other means, whatever you have when plugin/unplug does not log is wrong (or a wire is cut; this is essentially also what the result of an incorrect device tree does, to cut a wire). The actual software for use with HPD is quite well known to function, so whatever method you are using to change the device tree is very likely wrong. Maybe it is something indirect; for example: a power rail might also need to be active to a correct voltage for HPD to work even if the pin itself is marked correctly for function (that’s just a contrived example, but it illustrates the idea).

Hello again,

After several in-depth investigations, I am still facing an issue and a difficulty.

To be clear, I started from a clean installation of JetPack 6.2.1, and the only modification I made to the files is in tegra234-mb2-bct-misc-p3767-0000.dts:

	cvb_eeprom_read_size = <0x0>;

I used the well-known command with p3509-a02-p3767-0000.conf:

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 external

And the HDMI video output still does not work.


As for the difficulty, I cannot link the I2C index in the files with the Jetson pins.

I extracted from the TRM DP-10508-002:

  • I2C instance I2C4 ⇒ Verilog ball names DP_AUX_CH1
  • I2C instance I2C6 ⇒ Verilog ball names DP_AUX_CH0
  • I2C instance I2C7 ⇒ Verilog ball names DP_AUX_CH2

with

  • block name i2c4 ⇒ 0x03190000
  • block name i2c6 ⇒ 0x031b0000
  • block name i2c7 ⇒ 0x031c0000

But when I look at tegra234-p3768-0000+p3767-0001-nv.dts:

aliases {
	i2c3 = "/bus@0/i2c@3190000";
	i2c5 = "/bus@0/i2c@31b0000";
	i2c6 = "/bus@0/i2c@31c0000";
};
__symbols__ {
	dp_aux_ch1_i2c = "/bus@0/i2c@3190000";
	dp_aux_ch0_i2c = "/bus@0/i2c@31b0000";
	dp_aux_ch2_i2c = "/bus@0/i2c@31c0000";
}

Although the assignment of the I2C buses with the DP_AUX pins seems consistent, I still get different indices for I2C.


I managed to use the dcb_tool by rewriting the files:

./dcb_tool -r tegra234-dcb-p3767-0000-hdmi.dtsi 

Output:

=== Reading DCB blob ===

########## Tegra DCB BLOB ###############
########### Display Devices #############
Display Devices::
	Display Devices : [0]
		Type               : [TMDS]
		CCB                : [0]
		Heads              : 0:[Y] 1:[Y]
		Sor                : [0 ]
		HDMI capable       : [1]
		Connector          : [0]
		Bus                : [0]

############### CCB Entries ###############
CCB::
*CCB entries that have both I2C and AUX ports unused (value = 31) are not displayed
	CCB Index : 0
		I2C Port           : [6]
		AUX Port           : [0]

########### Connector entries #############
Connectors::
	Connector Index : 0x0
		Type               : [HDMI]
		Hotplug            : A:[Y]

I see that the I2C port used is 6.

  • If I use the TRM index, this corresponds to pin DP_AUX_CH0.
  • If I use the DTS file index, this corresponds to pin DP_AUX_CH2.

However, as far as I know, I am using pins 98 and 100 of the Jetson, which correspond to DP_AUX_CH1. And indeed, these are the pins used on the P3509 carrier board.

Could you explain how to map the TRM information to the physical Jetson pins? This applies both for I2C and for pin 96, which is used as HDMI hotplug.


Then, I realized that pins 98 and 100, which should function as the HDMI I2C bus, have an incorrect voltage.

On my custom carrier board, when these pins are left floating, I measure a voltage of 40 mV.
As the I2C master, shouldn’t the Jetson be driving these pins at 3.3 V?

It looks like these pins are always configured for DP. How can I check this?


Thank you in advance for your answers and for the time you are taking to look into my request.

A quick clarification. You still have some mistakes and also in wrong direction.

The Orin display only has one option from hardware. There is no other dpaux or i2c you could choose to use.
The one mentioned in the design guide: pin 98 and 100 are the only option you could use for your design.

Also, that pin is DP_AUX_CH0 but not DP_AUX_CH 1 or 2. The name “DP1_AUX” in the design guide is the module pin name. Not the name from the SoC. If you open the pinmux spreadsheet and check the “customer usage”, then you will see it if DP_AUX_CH0_P/N. And that thing is i2c6 too with pinmux change.

So this part in the DCB image is totally correct. This pin is i2c6 and also dpaux0.

CCB::
*CCB entries that have both I2C and AUX ports unused (value = 31) are not displayed
	CCB Index : 0
		I2C Port           : [6]
		AUX Port           : [0]

The HDMI dcb dtsi has been validated for this pin 98/100 design for many many partners and also other users in the past 2 years. This item by default is definitely correct.