Regarding the default state of I2C when using HDMI output on Orin NX

I am currently using a custom board with Orin NX and am planning to utilize HDMI for output. I believe the necessary tasks for this include GPIO initial configuration and replacing items like DCB in the overlay DTB. Therefore, I have carried out the following:

  • Changed the PINMUX_CONFIG in the conf file to one configured for HDMI
  • Changed the PMC_CONFIG in the conf file to one configured for HDMI
  • (Set BPFDTB_FILE=“tegra234-bpmp-3767-0001-3509-a02.dtb” in the conf file)
  • Added “tegra234-dcb-p3767-0000-hdmi.dtbo” to the OVERLAY_DTB_FILE in the conf file
  • Set DCE_OVERLAY_DTB_FILE=“tegra234-dcb-p3767-0000-hdmi.dtbo” in the conf file

As a result, I was able to confirm that HDMI output is functioning.

However, after a while following boot, when there is no communication, it appears that the I2C line of HDMI ( 98,100 pin of Jetson_Orin_NX_series_and_Orin_Nano_series_Pinmux_Config_Template.xlsm ) drops to low (while it seems to operate in the default high state during the initial communication after boot). I could not determine from the developer documentation whether this is due to my configuration being insufficient or if it is a specification.

Is this phenomenon due to a specification ?
Or are there any remaining settings that need to be applied to resolve this issue?

Thank you for your assistance.

Hi koichi.tanoiri,

What’s your Jetpack version in use?

To use HDMI on your custom board for Orin NX, please refer to the configuration in board config p3509-a02-p3767-0000.conf

Could it be caused from some driver request and use this pin to pull it low?
Please confirm the pin you used does not be used from other drivers.

Hello, Kevin. Thank you for your response.

I am using Jetson 36.3.

Yes, I referred to that configuration for this task. While I cannot fully confirm that the PINMUX_CONFIG and PMC_CONFIG are identical due to some differences in our board, it seems that the settings for pins 98 and 100 are the same.

In the current device tree, compared to the sample one, I have made changes such as disabling USB 3.0 and reassigning another I2C device to locations where I2C was originally assigned, but I have not added any conflicting configurations with the HDMI lines. ( If there are processes that need to be removed from the device tree when switching from DP to HDMI, that could be the cause. When switching from DP to HDMI, I only made the changes mentioned above, such as the overlay DTB. )
It is difficult to identify any suspicious drivers based on these differences. Is there a good way to check which processes have accessed the target GPIO?

Thank you.

You have to review the pinmux configuration in spreadsheet for each pins to match your custom board design, and them updated the PINMUX/GPIO/PMC dtsi.

With the that board configuration, HDMI should be enabled by default.

You can run sudo gpioinfo on your board to check the usage for each pins.

Hi,

What is the exact issue here? The HDMI output is functioning but you notice I2C signal does not meet your requirement after a while?

Thank you for your response. I will check the usage, and I will share the results once I have them.

Hello, Wayne. Yes, as you mentioned, I am concerned that the state of the I2C pins is not as intended.
As for the HDMI video output, it seems to be working fine.

Do you have the signal measured from your side to share?

We have pulled up the Orin’s HDMI DDC SCL and SDA lines to High externally, but at some point, they entered a state that appeared to be at a mid-level voltage. Here is the signal information from that time. Both SCL and SDA were in a similar condition.

After that, we tried physically disconnecting the Orin’s HDMI DDC SCL and SDA lines to see what would happen, and the lines remained high.

Could you share the waveform for both SDA and SCL?

Could you read the correct data with this “mid-level” voltage?

Which I2C interface are you using?

Thank you for confirming.

Are you expecting to capture SCL and SDA simultaneously, with a horizontal range wide enough to read their values? (When captured individually with the current range, there are no significant differences in potential, etc.) In that case, I’m not sure if I can capture the communication at the specific timing you want, but is it acceptable to capture the communication waveform during the mid-level voltage at any arbitrary timing?

Regarding this, since the X server is reading the EDID correctly and HDMI output is functioning without issues, I am assuming that the communication is also working fine. If you have a better method of determining this, I would appreciate it if you could share it with me.

Regarding this matter, I might not fully understand what you want to check. As mentioned in the top comment, I am using pins 98 and 100, which correspond to I2C6_CLK and I2C6_DAT, but is that the area you want to verify?

Thank you.

Hi,

This is a known issue. Currently there is no solution to fix this.

Thank you for your response.

Is it correct to understand that this issue is planned to be fixed in a future L4T update?
If so, could you provide an estimate of when the fix might be included in the L4T update?

Currently I don’t see any plan but this is a known issue to us.

I understand that this is an issue known to Nvidia. Could you provide more details on the following?

  • Are you aware of the specific timing or conditions under which this issue occurs?
  • Can Orin guarantee proper operation even when this mid-level voltage state occurs? Or does this mean that Orin currently cannot support HDMI output and only supports DP output?

Additionally, is it correct to assume that there is a main topic tracking this known problem? If so, could you please provide the details of the relevant issue?

Thank you.