AGX Xavier Industrial Display Port Issue

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Xavier
,
1

Hi,
We have a custom carrier board for Jetson AGX Xavier Industrial Module.

There is only a Display Port connected to the module on HDMI_DP2 port.
In device-tree file:
sor, sor1, sor3, display@15200000, display@15210000 and display@15230000, sor-2/hdmi-display nodes are disabled.

sor2 and sor2/dp-display nodes are enabled and sor2 active,panel is choosen as 0x45e which is phande value of sor2/dp-display node.

I have attached the full dts file. extracted_dts.txt (482.0 KB)

I have changed the pinmux file according to our carrier board.

However the monitor that is mounted to the DP2 port can not be detected by the system. Following is the dmesg | grep display output from the records.

[ 1.041124] tegradccommon 15200000.display-hub: Nvhost Channel map failed
[ 6.913522] tegradccommon 15200000.display-hub: host1x channel mapped
[ 6.913742] tegradc 15220000.display: Adding to iommu group 29
[ 6.925637] tegradccommon 15200000.display-hub: dc_common syncpt # 1 allocated
[ 6.925688] tegradccommon 15200000.display-hub: dma mapping done
[ 7.131123] tegradc 15220000.display: disp0 connected to head2->sor1
[ 7.142860] tegradc 15220000.display: tegra_dc_parse_panel_ops: panel: dp-display is not active
[ 7.142867] tegradc 15220000.display: err:-19 parsing panel_ops

I have attached the opening log file. xavier_opening_log_file.txt (81.6 KB)

JetPack version is 5.1.2.

What can be the reason of this problem?

Best Regards,

2

Just a reminder. display@152xxxxx order is not same as sorX.

You think display@15200000 is for sor0 and display@15210000 is for sor1 …etc.
But it is wrong. They have their own mapping in the device tree.

Your tegradc 15220000 is mapping to a SOR that totally not enabled at all.

3

Where can I find the mapping in the device-tree?

At the opening log it says disp0 connected to head2->sor1. From this message I have thought that the mapped sor is sor1, is it?

4

nvidia,dc-connector node.

5

Thank you for the information. it was mapped to sor1. I have changed device-tree and now the behaviour is changed. There are new meesages related to the display at the opening as given below. But still, the monitor is not recognized.
Is there anything else that can be done?

~$ sudo dmesg | grep display
[ 1.165616] tegradccommon 15200000.display-hub: Nvhost Channel map failed
[ 6.958443] tegradccommon 15200000.display-hub: host1x channel mapped
[ 6.958686] tegradccommon 15200000.display-hub: dc_common syncpt # 1 allocated
[ 6.958980] tegradccommon 15200000.display-hub: dma mapping done
[ 6.962160] tegradc 15220000.display: Adding to iommu group 29
[ 6.968001] tegradc 15220000.display: disp0 connected to head2->sor1
[ 6.973237] tegradc 15220000.display: parse_dp_settings: No dp-lt-settings node
[ 6.980982] tegradc 15220000.display: DT parsed successfully
[ 6.993958] tegradc 15220000.display: Display dc.(ptrval) registered with id=0
[ 7.036600] tegradc 15220000.display: vblank syncpt # 8 for dc 2
[ 7.049616] tegradc 15220000.display: vpulse3 syncpt # 9 for dc 2
[ 7.050179] tegradc 15220000.display: dc_dp_out_hotplug_init: couldn’t get regulator vdd_hdmi_5v0
[ 7.060463] tegradc 15220000.display: dc_probe: failed hotplug init, -517
[ 7.236999] tegradc 15220000.display: disp0 connected to head2->sor1
[ 7.257046] tegradc 15220000.display: parse_dp_settings: No dp-lt-settings node
[ 7.264496] tegradc 15220000.display: DT parsed successfully
[ 7.279298] tegradc 15220000.display: Display dc.(ptrval) registered with id=0
[ 7.340993] tegradc 15220000.display: vblank syncpt # 11 for dc 2
[ 7.356485] tegradc 15220000.display: vpulse3 syncpt # 12 for dc 2
[ 7.378320] tegradc 15220000.display: probed
[ 7.477307] tegradc 15220000.display: fb registered
[ 7.532653] tegradc 15220000.display: blank - powerdown
[ 49.457421] tegradc 15220000.display: blank - powerdown

6

I am not sure whether you notice that again.

We already provide 2 original heads that have dp configuration in original dtb. Please just compare what is missing on your side and add it back with correct info.

7

Hi Wayne,
I have compared the edited device-tree with the devkit’s device tree, I couldn’t see difference. In order to be sure and to try other alternatives, I have flashed the board with JETPACK 4.6.4 and edited the device-tree for DP output. All of the settings are as devkit’s DP settings except the following properties which are commented. (There is not any SWITCH on our custom carrier board.)
nvdisplay@15210000 {

// extcon-cables = <0x77 0x2 0x78 0x2>;
// extcon-cable-names = typec0, typec1;
// #extcon-cells = <0x1>;
}

and

sor2{
// nvidia,typec-port = [01];
}
The full DTS file is as following.
edited_dts__20231121__1032.txt (358.9 KB)

However there is not any display output on the monitor. Following messages are about display which appears at the startup…

$ sudo dmesg | grep display

[ 0.872002] iommu: Adding device 15210000.nvdisplay to group 46
[ 0.876681] platform 15210000.nvdisplay: IOVA linear map 0x00000000c6000000(2a000000)
[ 0.876765] t19x-arm-smmu: Adding 15210000.nvdisplay to ISO SMMU client
[ 1.706707] Could not get extcon-dev /host1x/nvdisplay@15210000:typec1(1)
[ 3.608346] Could not get extcon-dev /host1x/nvdisplay@15210000:typec1(1)
[ 3.760128] Could not get extcon-dev /host1x/nvdisplay@15210000:typec1(1)
[ 3.773697] Could not get extcon-dev /host1x/nvdisplay@15210000:typec1(1)
[ 4.736377] Could not get extcon-dev /host1x/nvdisplay@15210000:typec1(1)
[ 5.983891] Could not get extcon-dev /host1x/nvdisplay@15210000:typec1(1)
[ 5.998256] Could not get extcon-dev /host1x/nvdisplay@15210000:typec1(1)

The full opening log is as following.
xavier_opening_log_file_20231121__1032.txt (49.1 KB)

How can we resolve this issue?
Best Regards,

8

I was editing the dtb file located in /boot/dtb folder on the board. I have recognized that changes are not being implemented in JETPACK 4.6.4. version. (It was being effective in JETPACK 5.1.2)
I have flashed the whole board and the behaviour is changed. Following messages are about display which appears at the startup…

tegra-ubuntu:~$ sudo dmesg | grep display
[ 0.890612] iommu: Adding device 15210000.nvdisplay to group 46
[ 0.894816] platform 15210000.nvdisplay: IOVA linear map 0x00000000c6000000(2a000000)
[ 0.894910] t19x-arm-smmu: Adding 15210000.nvdisplay to ISO SMMU client
[ 1.803851] tegradc 15210000.nvdisplay: disp0 connected to head1->/host1x/sor2
[ 1.803914] tegradc 15210000.nvdisplay: parse_dp_settings: No dp-lt-settings node
[ 1.804086] tegradc 15210000.nvdisplay: DT parsed successfully
[ 1.804133] tegradc 15210000.nvdisplay: Display dc. (ptrval) registered with id=0
[ 1.809922] tegradc 15210000.nvdisplay: vblank syncpt # 8 for dc 1
[ 1.809936] tegradc 15210000.nvdisplay: vpulse3 syncpt # 9 for dc 1
[ 1.826180] tegradc 15210000.nvdisplay: probed
[ 1.826780] tegradc 15210000.nvdisplay: fb registered
[ 1.830354] tegradc 15210000.nvdisplay: blank - powerdown
[ 37.640754] tegradc 15210000.nvdisplay: blank - powerdown

The full startup log is as following.
xavier_opening_log_file_20231121__1628.txt (63.0 KB)

9

When you hotplug the DP cable, do you see any new log coming out from dmesg?

10

There is no new log on dmesg output when I hotplug the cable.

From several questions asked in forum about display issue, I am suspecting from HPD pin but not sure. According to general Display Port definitions it seems that HPD pin is an active-high signal. Is it also active-high in jetpack?

Is there a way to disable HPD detection and to drive a default video output from DP port?

Also in several questions about this issue, some dtsi files(for example tegra194-p2822-disp.dtsi) and source files(.c) talked about to being changed. However I couldn’t find those files in my JETPACK folder. Where I have to look for the source files?

(Note: PINMUX setting of HPD signal is set as DP_AUX_CH2_HPD.)

11

Hi,

  1. If you saw nothing from the dmesg after you hotplug the cable, then I think it is related to pinmux. Your pinmux is still GPIO but not SFIO. Make sure your cfg file does not have that pin set in gpio section.
    It is most likely the case because SOR2 was by default using as GPIO for HDMI on devkit.

  2. The source code needs to be downloaded from the website.
    https://developer.nvidia.com/embedded/jetson-linux-archive

  3. Is there a way to disable HPD detection and to drive a default video output from DP port?

No way.

12
  1. I have checked the cfg file. When searched as hpd there is an entry under the #### Pinmux for used pins #### title as following. It is not in GPIO section.

pinmux.0x02440040 = 0x00000450; # dp_aux_ch2_hpd_pm2: dp, tristate-enable, input-enable, io_high_voltage-disable

The full cfg file is as following. tegra19x-mb1-pinmux-p2888-0000-a04-p2822-0000-b01.txt (24.0 KB)

By the way, I have replaced the following cfg file, is it the correct one?
/bootloader/t186ref/BCT/tegra19x-mb1-pinmux-p2888-0000-a04-p2822-0000-b01.cfg

  1. As I remember, previously I have downloaded some versions from that website. I have downloaded the latest version again Driver Package (BSP)

This is a compressed file in which there are files as same as my current JETPACK folder. So where is the *.c files in this compressed file system? I want to make some changes in source code and to see it’s effect on the startup log.

  1. Ok.

  2. I have checked the devkit schematics and saw that HDMI_DP2 port is used as HDMI and sor2 is used for this output in the device-tree. We are also using HDMI_DP2 port as DP in our cusotm carrier board. Hence I have choosen sor2 as DP output. We have to choose sor2 as DP output, isn’t it?

Best Regards,

13

I have checked the 0x02440040 address with devmem2 command and the result is as following.

sudo devmem2 0x02440040 w
/dev/mem opened.
Memory mapped at address 0x7f7b000000.
Value at address 0x2440040 (0x7f7b000040): 0x42

So, there shoud be 0x450 according to cfg file however there is 0x42. It seems that I have changed wrong cfg file, is it? Which cfg file should I change in /bootloader/t186ref/BCT/ folder?

Best Regards,

14

Please check this register too.

0x02212640

15

You should read your flash log to tell which cfg file got flashed. This is the most precise way. I don’t “memorize” every cfg as it is mostly pointless.

16

I have checked the cfg file from flash log and replaced the correct file which was tegra19x-mb1-pinmux-p2888-0008-b01-p2822-0000-jaxi.cfg.

However flashing halt at a stage where last message from the board terminal was as following.
[0265.144] I> TBoot-CPU Recovery hang
Full log output is as following.
flash_error__20231122__1132.txt (11.6 KB)

What can cause to the halt of the flash process?

As a second try, I have changed only pinmux.0x02440040 settings from the original CFG file and it has been successfully flashed to the board. And there are 0x450 value at the address 0x02440040 now.
Also there is display output at the DP port.

There are 0x1 at the address 0x02212640.

17

So does this issue resolved or not?

18

Yes, the issue resolved. Thank you very much for your support.

Do I have to open new topic for the halt during flash problem, or can we examine it, here?

Best Regards,

19

Please file a new topic.

1 Like
20

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.