Custom board with only hdmi0 Port conected

WayneWWW · October 8, 2019, 1:58am

Hi,

Sorry for late reply. If you see error “egradc 15210000.nvdisplay: sanitize_flip_args: WIN 2 invalid size:w=0,h=0,out_w=0,out_h=0”, then it is probably the hardware design issue.

If you are using any of the strapping pins that come to the module pins and are not careful to ensure you are not influenced by the hardware when reset goes inactive (when the system boots), it may have serious issues. This is highlighted in the OEM DG in the strapping section. If you use the pins and if they have pull-up/downs on those lines or the device connected pulls up/down on the lines, they will need to buffer the signals. All the straps are on output pins from the module, so you can add a simple buffer (see OEM DG 13.7 strapping pins) to the Tegra pin will not “see” the pull-up/downs.

Trumany · October 8, 2019, 3:22am

Hi alfredosalvarani,

Did you copy the reference design of HDMI part to your own board? Basically it should be kept same to reference. If possible, please share the schematic of this part in your design.

alfredosalvarani · October 8, 2019, 1:28pm

WayneWWW:

Hi,

Sorry for late reply. If you see error “egradc 15210000.nvdisplay: sanitize_flip_args: WIN 2 invalid size:w=0,h=0,out_w=0,out_h=0”, then it is probably the hardware design issue.

If you are using any of the strapping pins that come to the module pins and are not careful to ensure you are not influenced by the hardware when reset goes inactive (when the system boots), it may have serious issues. This is highlighted in the OEM DG in the strapping section. If you use the pins and if they have pull-up/downs on those lines or the device connected pulls up/down on the lines, they will need to buffer the signals. All the straps are on output pins from the module, so you can add a simple buffer (see OEM DG 13.7 strapping pins) to the Tegra pin will not “see” the pull-up/downs.

We’ve checked it again and didn’t found any issue on strapping pins on our design, but we didn’t use the port 15210000, it isn’t on logs anymore.

I’m sending:

Boot and dmesg log DT file (tegra186-quill-p3310-1000-c03-00-base.dts)

Now, I can see some activity on HDMI0_DDC_SCL and HDMI0_DDC_SDA pins, but the monitor still in power saving mode.

Do you have any new ideia?

UPDATE: I’v captured the i2c communication on DDR_SDA on HDMI port and I’m sharing the data with you.
log_boot_dmesg.txt (99.2 KB)
tegra186-quill-p3310-1000-c03-00-base.dts.txt (5.19 KB)
i2c_hdmi.txt (1.1 KB)

alfredosalvarani · October 8, 2019, 2:00pm

We copied part of it, I’m sharing the hdmi schematic:

Trumany · October 9, 2019, 3:22am

Hi, seems no level shift on HPD line? HPD level shift can be non-inverting or inverting. On devkit it is inverting, please note whether your sw changed if you choose non-inverting one.

WayneWWW · October 9, 2019, 4:52am

Hi,

If you want to configure the inverting or non-inverting, you could use below node in device tree

→ TEGRA_DC_OUT_HOTPLUG_LOW (default) or TEGRA_DC_OUT_HOTPLUG_HIGH

Please search this keyword in your device tree source and you will find it.

alfredosalvarani · October 9, 2019, 12:10pm

Sorry, the level shift is in another place of the schematic, I’m sharing it now.
With this information, can you say if my design is correct?

alfredosalvarani · October 9, 2019, 12:23pm

I’ll take a look on this, but don’t know if it will solve my case. :-(
Did you review my DT and my logs?

Another question: I’m working in DP0 pins (H36, H35, G37, G36, F38, F37, H39, H38, B35, B34 and B36), and on DT I’m working in node nvdisplay@15220000 and dpaux@155c0000, is this right? Where can I find this information?

And finally: I can see we are in very different time zones, is any support in a time zone near to me? (Brazil GMT-3h)

alfredosalvarani · October 9, 2019, 2:21pm

Good news, with TEGRA_DC_OUT_HOTPLUG_HIGH flag I can see video output on monitor, but the screen freeze on a blank screen with the mouse pointer showing, I don’t know if Xorg and/or Gnome had a full initialization.
From serial interface we can see this log (a lot):

[  411.197526] tegradc 15220000.nvdisplay: sanitize_flip_args: WIN 3 invalid size:w=0,h=0,out_w=0,out_h=0

From this post HDMI & USB problem on TX2 with a custom board - Jetson TX2 - NVIDIA Developer Forums I see there’s a hardware problem because we use UART0 and UART1, see attached schematic.
It’s not easy to us, to disable these level shift at boot, so I need some solution like on this old post:
kernel-4.4/drivers/platform/tegra/mc/isomgr.c: isomgr_init() fails to initialize - Jetson TX2 - NVIDIA Developer Forums
How can I apply this solution on LT4 32?:

emc-strap {
select = <0x9 0xa 0xa 0xa>;
};

Thanks!

WayneWWW · October 14, 2019, 7:59am

If you cannot change the hardware design, then you could try the workaround (emc-strap).

alfredosalvarani · October 14, 2019, 11:21am

Yes, but I don’t kwon how to do this on L4T 32.
Whatever, We open the UART0_RTS connection and now we have video working on HDMI0. But if you can tell me, I wish to know how to do this workaround.
Now my next step is bring USB to live…

WayneWWW · October 15, 2019, 2:13am

Hi,

To use that workaround, you need to convert the bpmp-dtb back to dts file by using dtc tool, then you add that part to dts file and build it back to dtb again.

bbasu should point this out in below link

https://devtalk.nvidia.com/default/topic/1009011/jetson-tx2/kernel-4-4-drivers-platform-tegra-mc-isomgr-c-isomgr_init-fails-to-initialize/post/5159107/#5159107

Please note that your bpmp-dtb may not be this one since it is old release. You could check the flash log to know what is the file you are using.