We’ve been using Jetpack 4.5.1/L4T32.5.1 with Xavier NX and our custom carrier for some years now.
I’m trying to update to Jetpack 5.1.3/L4T 35.5.0 and have almost got it working. :-)
The Xavier NX HDMI/DP output is connected to our FPGA via an HDMI bridge. In other words, the Xavier NX is not connected to a real monitor, instead it is connected to a ITE Tech IT68013FN. I’ve pasted sections of the schematics below.
To make the HDMI bridge work we have to initialise its EDID via I2C during boot. After initialising the EDID, xrandr tells us we have a display.
This all just seems to work with JP451/L4T32.5 but there is something different about JP513/L4T35.5 that means the system is not working as before.
The HDMI isn’t working correctly on the first boot after a power on. I’m not sure exactly what the problem is, sorry! If I reboot (with the EDID initialised) the HDMI will come to life and start working. In other words, the EDID needs to initialised when Ubuntu starts.
This is the console from the first boot after power on: poweron-boot.txt (75.4 KB)
This is the console from a reboot where the EDID will be initialised: reboot.txt (73.3 KB)
There is no problem when using an Orin NX but everything else the same, i.e. JP513 and our carrier.
I’m sorry if this doesn’t make any sense, obviously I’m struggling to understand the various bits of hardware and software that are involved in getting our system to work!
Any thoughts or advice would be greatly appreciated. :-)
I’m wondering if it has something to do with hotplug. Unfortunately, I don’t understand the mechanics behind hotplug and therefore don’t have any ideas of things to try.
I was also thinking, the obvious difference between JP451 and JP513 is the device-tree. But again unfortunately, I don’t understand what the device-tree is doing with respect to HDMI, displays and hotplug.
I tried running our EDID initialisation after a power-up and it triggers some response from Linux and the devices but doesn’t fix the problem:
nvidia@CHARM250268:~$ sudo /usr/sbin/v4_hdmi_init
[sudo] password for nvidia:
nvidia@CHARM250268:~$ [ 85.681864] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 85.681874] tegradc 15200000.display: dc timeout waiting for DC to stop
[ 85.733855] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 85.733865] tegradc 15200000.display: dc timeout waiting for DC to stop
[ 85.785845] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 85.785854] tegradc 15200000.display: timeout waiting for postcomp init state to promote
[ 85.837884] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 85.837895] tegradc 15200000.display: timeout waiting for win assignments to promote
[ 85.837901] tegradc 15200000.display: tegra_nvdisp_head_enable, failed head enable
[ 85.898551] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 85.898560] tegradc 15200000.display: dc timeout waiting for DC to stop
[ 85.949848] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 85.949856] tegradc 15200000.display: dc timeout waiting for DC to stop
[ 86.001866] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 86.001875] tegradc 15200000.display: timeout waiting for postcomp init state to promote
[ 86.053859] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 86.054931] tegradc 15200000.display: timeout waiting for win assignments to promote
[ 86.054938] tegradc 15200000.display: tegra_nvdisp_head_enable, failed head enable
[ 86.105849] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 86.105856] tegradc 15200000.display: dc timeout waiting for DC to stop
[ 86.157851] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 86.157860] tegradc 15200000.display: dc timeout waiting for DC to stop
[ 86.209861] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 86.209870] tegradc 15200000.display: timeout waiting for postcomp init state to promote
[ 86.261885] tegradc 15200000.display: dc_poll_register 0x41: timeout
[ 86.261895] tegradc 15200000.display: timeout waiting for win assignments to promote
[ 86.261900] tegradc 15200000.display: tegra_nvdisp_head_enable, failed head enable
I’ll see if I can find a way to run our EDID initialisation earlier in the boot sequence.
You mean, in a normal scenario where there’s an HDMI connector and the user is connecting a monitor, you would always expect the monitor to be connected before power-up?
In our special case, I can’t connect or disconnect anything, it’s all part of the carrier. The only thing I can do is talk to the IT68013FN via I2C.
If I understand “We expect the display EDID is always ready when driver probes” correctly you’re saying that the cases where it works for us, are only working by luck!?
First, I have to say that I actually don’t know your exact issues. It sounds like the variable to me is just the timing of the EDID init of your monitor/panel. I don’t know what is the exact error case happened on your side. There is no such “init timing” for a common monitor. It is always there and could be able to get read through i2c when display driver is up.
Second, Jetson Xavier HDMI driver supports hotplug. So it can work even if you don’t connect the monitor since boot.
I haven’t managed to get XAvier NX and JP513 functioning as I expected.
When we fit the Orin NX to our carrier and program with JP513 the system works as I expect.
I previously generated pinmux configurations for the Orin and the Xavier without giving any thought to the display configuration. For the Orin, I generated the pinmux from the HDMI page of the spreadsheet; this seemed to make sense as we use HDMI and it works! :-)
I’ve just noticed the HDMI configuration in the Orin pinmux spreadsheet configures some of the DP pins differently to the Xavier pinmux spreadsheet.
The HDMI page of the Orin spreadsheet selects the GPIO and I2C functions of the DP pins:
I can’t get the Xavier to work as I expect (and as it works with JP451).
I was just comparing it to the Orin which does work, and is using JP513. I thought comparing the 2 devices might help shed some light on what’s happening and what I need to do.
Orin and Xavier are using totally different driver and even display structure.
It is pointless to compare the result between them.
What can be configured on Xavier may not work on Orin and vice versa.
Orin display driver is handled by a firmware called DCE firmware running on DCE core and it is not open source, while Xavier display driver is just that kernel driver which is totally open source.
If you look into the dmesg, you will notice your Orin gives nothing related to display as Xavier.
I’m not expecting an answer, but I thought I’d update this thread with what I tried in case I come back here…
I created a service for our app that initialises the IT68013FN EDID. I did what the Internet told me to do get the service to run early. I’m pretty sure the service has run and initialises the EDID but I need to do a reboot to force the display to correctly recognise the EDID.
I also tried to understand IT68013FN manual but failed! The EDID initialise app was written by someone else back in 2021 and hasn’t changed since.
Here’s my service file for the record:
nvidia@CHARM250268:~/fpga_tools$ cd /etc/systemd/system/
nvidia@CHARM250268:/etc/systemd/system$ cat v4_hdmi_init.service
[Unit]
Description=Start v4_hdmi_init
Before=basic.target
DefaultDependencies=no
[Service]
Type=oneshot
ExecStart=/usr/sbin/v4_hdmi_init
[Install]
WantedBy=basic.target
nvidia@CHARM250268:/etc/systemd/system$ systemd-analyze critical-chain v4_hdmi_init.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
v4_hdmi_init.service +729ms
└─systemd-journald.socket @1.258s
└─system.slice @1.181s
└─-.slice @1.180s
nvidia@CHARM250268:/etc/systemd/system$
I don’t have a cable that I can disconnect and connect. Rather DP.HPD is connected to the IT68013FN chip. I think the IT68013FN manipulates DP.HPD to simulate dis/connecting the cable. I think the IT68013FN simulates dis/connecting the cable after the EDID is initialised. I know something happens when the EDID initialised because I see errors in dmesg after running v4_hdmi_init.
As I understand it, the IT68013FN has 2 I2C interfaces. The first is a programming I2C interface that is used to initialise the EDID, and other things. The second is the DDC I2C HDMI interface that is behaving like the monitor. I tried to read the IT68013FN manual to see if I could make it simulate a dis/connect but it is so complicated I didn’t understand! :-(
But, obviously, I’m guessing most of this! I don’t really understand what DP.HPD is and how the IT68013FN is manipulating it.
I’m just about to try JP465 to see how it behaves.
Second boot, EDID is ready in (1) so this time it can work.
Does enabling that chip part of role of Jetson kernel driver? For example, what is v4_hdmi_init? I don’t know this thing.
Honestly, I don’t really care much about how your chip works here. It is your duty to make it work. Jetson side only wants the EDID is ready in bootloader stage and also kernel stage.
I appreciate that and I’m trying. I’m also grateful for your help! :-)
I asked a question here for a couple of reasons:
In the past I’ve struggled for days before asking a question only to discover the problem was obvious to you (and your colleagues) and I wished I’d asked sooner.
I have 2 examples where our system works and 1 where it doesn’t so I’m trying to understand what’s different, I thought/hoped the difference might be obvious to you.
Unfortunately, you haven’t been able to spot an obvious mistake on my part but I’m grateful that you engaged. I wasn’t really expecting you to say anything more until I come up with something more concrete for you.
Updating the JP we use with the Xavier NX is really important to us for several reasons. The 2 biggest reasons are:
Just to clarify. Please just save your tongue and only replies things that helpful to the issue itself.
We are not doing some kind of arbitrary chat here. You don’t need to tell why you need to upgrading JP. They are not related to the issue. It is just dummy information to us. Everyone here thinks their project is important and I have no doubt to it.
