HDMI display works only if the cable is plugged in after the boot

Hi,

With SDK 5.0.2, HDMI display works only if the cable is plugged after the boot. If it is plugged before, the system still boots, but there is no display.

The attached file shows the configuration, and this is working with SDK 4.6:
tegra194-p2822-disp.dtsi (2.9 KB)

I also attach the related dmesg logs:
dmesg-cable_before_boot.log2 (77.5 KB)
dmesg-cable_after_boot.log2 (69.8 KB)

Note: The system has a second HDMI output over a custom add-on which we don’t have ready currently.

Best,

Issue happened on your custom carrier board?
Can issue be reproduced with devkit?

Hi,

Because of the inverse polarity of HDMI detect pin, I don’t think that we see the display on the dev kit.

As this board and the DT configuration works on the SDK 4.6, there should be a change either somewhere else in DT or Ubuntu kernel. If you search the related dmesg log for the word “fail”, you will notice the display-related lines.

I already corrected an Ethernet and a USB issue (sourcing from the DT changes in the new SDK) but couldn’t fix this HDMI display problem.

Best,

There are some known issues in xavier + jp5.0.2 display.

Hi Wayne,

Could you please elaborate a bit on this issue?

Is it related to the device tree or the kernel/driver bug?
Or, does it occur with a specific HW configuration which is not supported yet?

Best,

No, it is our driver issue and still not yet fixed.

Hi Wayne,

According to of/base.c, the “okay” and “ok” strings are treated equally for the attribute “status”. When I changed from:

&headX { status = “okay”; …

to:

&headX { status = “ok”; …

in the tegra194-p2822-disp.dtsi file with SDK 5.0.2, everything worked OK like in SDK 4.6.

I searched whole open source codes in the L4T and couldn’t find a code in which these two strings handled differently. Would it be possible that they are handled differently inside the closed-source NVIDIA graphics driver?

Best,

Hi,

Honestly, I don’t think that would fix this issue…
This issue is intermittent from the beginning. So if you test it more times, it may still happen. And 2nd display head is more easier to hit issue than 1st head.

The criteria to hit this issue is the NV boot logo must show during boot up stage and after entering kernel, it would intermittently crash.
If you disable the logo from printing, then this issue won’t happen either.

We are still debugging this issue.