eDP Link Training fails

timonske · January 13, 2020, 7:22pm

I’ve go my previous issue resolved and I can now successfully drive a DisplayPort monitor at 2560x1440@60hz over DP0.

With the way my carrier is setup I can switch between a DP Connector and an adapter that connect to an eDP LCD panel. An FFC cable connector from the main carrier to a second peripheral PCB where it either breaks out out to DP or an eDP connection. See the picture below.

While the DP monitor works fine I have issues with link training on two separate eDP panels.
The one I’m using right now has a standard 30pin eDP FFC connection with the standard VESA layout with 2 lanes.

Is there anything specific to DP vs eDP on the Jetson? Apart from things like backlight control I/O of course.
I attached a boot log where the panel is attached. I tried to amp up the voltage swing but in the end fails to establish a connection.

eDP-link-training-fail.txt (135 KB)

WayneWWW · January 14, 2020, 2:15am

Hi timonske,

I remembered once told you about the difference eDP and DP driver flow on your previous topic.

Thus, it makes me confused about your case. If I remembered correctly, actually you are all using eDP with the DP driver flow here.

While the DP monitor works fine I have issues with link training on two separate eDP panels.

May I have your detail about

What is the difference between this DP and those 2 eDP panels? Are those eDP also on DP0?
What if you use single eDP here? Would it pass lt?

WayneWWW · January 14, 2020, 2:29am

I notice your log prints

“[ 8.771422] tegradc tegradc.1: DP: no prod_c_hbr prod settings node in device tree”

Please refer to below file to add the prod_settings to your sor.
hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-a00-auo-1080p-edp.dts

timonske · January 14, 2020, 10:24pm

Hi Wayne,
thank for you quick reply!

Yes I remember that you mentioned DT changes for eDP but I understood those to be only regarding the backlight control pins.

Sorry if my wording about the display setup was confusing. I only ever have a single display or lcd panel connected and am only using DP0 right now. The only difference is the connector I use and of course a standard desktop monitor vs an eDP panel. I attached a picture of how it looks like with a DP connector attached, hopefully that clears things up regarding the hardware setup.

I copied over the prod settings from that file but after flashing I still get this message in the bootlog that prod_c_hbr is missing.

This is how my sor looks like right now:

sor {
			status = "okay";
			nvidia,xbar-ctrl = <2 1 0 3 4>;
			dp-display {
				status = "okay";
			};
			prod-settings {
				prod_c_hbr {
					prod = <
						0x00000590 0x00f00000 0x00400000   //SOR_NV_PDISP_SOR_PLL1_0	23:20=LOADADJ	0x04 
						>;
				};
				prod_c_hbr2 {
					prod = <
						0x00000590 0x00f00000 0x00600000   //SOR_NV_PDISP_SOR_PLL1_0	23:20=LOADADJ	0x06 
						>;
				};
				prod_c_rbr {
					prod = <
						0x00000590 0x00f00000 0x00300000   //SOR_NV_PDISP_SOR_PLL1_0	23:20=LOADADJ	0x03
						>;
				};

			};
		};

This is the other possible setup for the carrier with a DP connection. The other option is an adapter to eDP as seen in the picture of the first post.

WayneWWW · January 15, 2020, 2:23am

No idea why it sill spews this error.

Could you share the result on your side?

/proc/device-tree/host1x/sor# ls
/proc/device-tree/host1x/sor/prod-settings# ls

timonske · January 15, 2020, 2:40am

This is what I get:

root@nano-desktop:/proc/device-tree/host1x/sor# ls
clock-names    nvidia,active-panel             prod-settings
clocks         nvidia,dpaux                    reg
compatible     nvidia,sor1-output-type         reg-names
dp-display     nvidia,sor-audio-not-supported  reset-names
hdmi-display   nvidia,sor-ctrlnum              resets
linux,phandle  nvidia,xbar-ctrl                status
name           phandle
root@nano-desktop:/proc/device-tree/host1x/sor# ls prod-settings/
 name   prod_c_dp  '#prod-cells'

WayneWWW · January 15, 2020, 2:58am

root@nano-desktop:/proc/device-tree/host1x/sor# ls prod-settings/
 name   prod_c_dp  '#prod-cells'

You didn’t successfully put prod_c_hbr here at all.

timonske · January 15, 2020, 1:20pm

Ok, that is odd but the location was correct by putting it in the sor node?
I didn’t do anything different than the previous modifications, flashing was also successful.
I will investigate if something in the compilation process went wrong but it did generate a new dtb without complaining.

WayneWWW · January 16, 2020, 3:14am

Maybe something is missing. Could you tell us the whole steps you are using to update dtb?

timonske · January 18, 2020, 12:11am

I follow the kernel customization guide here closely to compile the kernel https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide%2Fkernel_custom.html%23

I then copy the resulting dtb file into the Linux_4_Tegra/kernel/dtb directory overwriting the existing file. I do the same with the one located in the bootloader directory.
I then flash with the command

sudo ./flash.sh -k DTB jetson-nano-emmc mmcblk0p1

See attached the log of the flash and the compiled dtb file.

I also decompiled the resulting dtb file with dtc and the resulting sor tree looks like it includes the changes:

dp-display {
				compatible = "dp, display";
				status = "okay";
				nvidia,hpd-gpio = <0x56 0xe1 0x1>;
				nvidia,is_ext_dp_panel = <0x1>;
				linux,phandle = <0x6f>;
				phandle = <0x6f>;

				disp-default-out {
					nvidia,out-type = <0x3>;
					nvidia,out-align = <0x0>;
					nvidia,out-order = <0x0>;
					nvidia,out-flags = <0x0>;
					nvidia,out-pins = <0x1 0x0 0x2 0x0 0x3 0x0 0x0 0x1>;
					nvidia,out-parent-clk = "pll_d_out0";
				};

				dp-lt-settings {

					lt-setting@0 {
						nvidia,drive-current = <0x0 0x0 0x0 0x0>;
						nvidia,lane-preemphasis = <0x0 0x0 0x0 0x0>;
						nvidia,post-cursor = <0x0 0x0 0x0 0x0>;
						nvidia,tx-pu = <0x0>;
						nvidia,load-adj = <0x3>;
					};

					lt-setting@1 {
						nvidia,drive-current = <0x0 0x0 0x0 0x0>;
						nvidia,lane-preemphasis = <0x0 0x0 0x0 0x0>;
						nvidia,post-cursor = <0x0 0x0 0x0 0x0>;
						nvidia,tx-pu = <0x0>;
						nvidia,load-adj = <0x4>;
					};

					lt-setting@2 {
						nvidia,drive-current = <0x0 0x0 0x0 0x0>;
						nvidia,lane-preemphasis = <0x1 0x1 0x1 0x1>;
						nvidia,post-cursor = <0x0 0x0 0x0 0x0>;
						nvidia,tx-pu = <0x0>;
						nvidia,load-adj = <0x6>;
					};
				};
			};

			prod-settings {
				#prod-cells = <0x3>;

				prod_c_dp {
					prod = <0x5c 0xf000f10 0x1000310 0x60 0x3f00100 0x400100 0x68 0x2000 0x2000 0x70 0xffffffff 0x0 0x180 0x1 0x1>;
				};

				prod_c_hbr {
					prod = <0x590 0xf00000 0x400000>;
				};

				prod_c_hbr2 {
					prod = <0x590 0xf00000 0x600000>;
				};

				prod_c_rbr {
					prod = <0x590 0xf00000 0x300000>;
				};
			};
		};

dtb-flash.log (10.6 KB)
tegra210-p3448-0002-p3449-0000-b00.zip (42.6 KB)

timonske · January 18, 2020, 9:31pm

Ok so something is going wrong with flashing maybe. I’m not sure if the .dtb file in /boot/ has anything to say but the dtb file there is definitely not the same that is being flashed. There it looks like the default state:

sor {
			compatible = "nvidia,tegra210-sor";
			reg = <0x0 0x54540000 0x0 0x40000>;
			reg-names = "sor";
			status = "okay";
			nvidia,sor-ctrlnum = <0x0>;
			nvidia,dpaux = <0x6e>;
			nvidia,xbar-ctrl = <0x2 0x1 0x0 0x3 0x4>;
			clocks = <0x21 0xde 0x21 0xb6 0x21 0x12f>;
			clock-names = "sor_safe", "sor0", "pll_dp";
			resets = <0x21 0xb6>;
			reset-names = "sor0";
			nvidia,sor-audio-not-supported;
			nvidia,sor1-output-type = "dp";
			nvidia,active-panel = <0x6f>;
			linux,phandle = <0x68>;
			phandle = <0x68>;

			hdmi-display {
				compatible = "hdmi,display";
				status = "disabled";
				linux,phandle = <0x114>;
				phandle = <0x114>;
			};

			dp-display {
				compatible = "dp, display";
				status = "okay";
				nvidia,hpd-gpio = <0x56 0xe1 0x1>;
				nvidia,is_ext_dp_panel = <0x1>;
				linux,phandle = <0x6f>;
				phandle = <0x6f>;

				disp-default-out {
					nvidia,out-type = <0x3>;
					nvidia,out-align = <0x0>;
					nvidia,out-order = <0x0>;
					nvidia,out-flags = <0x0>;
					nvidia,out-pins = <0x1 0x0 0x2 0x0 0x3 0x0 0x0 0x1>;
					nvidia,out-parent-clk = "pll_d_out0";
				};

				dp-lt-settings {

					lt-setting@0 {
						nvidia,drive-current = <0x0 0x0 0x0 0x0>;
						nvidia,lane-preemphasis = <0x0 0x0 0x0 0x0>;
						nvidia,post-cursor = <0x0 0x0 0x0 0x0>;
						nvidia,tx-pu = <0x0>;
						nvidia,load-adj = <0x3>;
					};

					lt-setting@1 {
						nvidia,drive-current = <0x0 0x0 0x0 0x0>;
						nvidia,lane-preemphasis = <0x0 0x0 0x0 0x0>;
						nvidia,post-cursor = <0x0 0x0 0x0 0x0>;
						nvidia,tx-pu = <0x0>;
						nvidia,load-adj = <0x4>;
					};

					lt-setting@2 {
						nvidia,drive-current = <0x0 0x0 0x0 0x0>;
						nvidia,lane-preemphasis = <0x1 0x1 0x1 0x1>;
						nvidia,post-cursor = <0x0 0x0 0x0 0x0>;
						nvidia,tx-pu = <0x0>;
						nvidia,load-adj = <0x6>;
					};
				};
			};

			prod-settings {
				#prod-cells = <0x3>;

				prod_c_dp {
					prod = <0x5c 0xf000f10 0x1000310 0x60 0x3f00100 0x400100 0x68 0x2000 0x2000 0x70 0xffffffff 0x0 0x180 0x1 0x1>;
				};
			};
		};

timonske · January 19, 2020, 7:56pm

I debugged a lot with someone with more experience with device tree and we are very certain its not an issue with the compilation process or the way the modifications are done.
It seems the issue here is related https://devtalk.nvidia.com/default/topic/1064022/jetson-nano/dtb-flash-not-working/

The flash looks successful (using the signed .dtb.encrypted file that is created by flash.sh) but in dmesg it still shows an old .dts file being loaded from 2019.

[    0.424195] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0002-p3449-0000-b00.dts
[    0.424232] DTB Build time: Dec  9 2019 22:51:55

In another thread I found the info that mmcblk0p10 is the partition for the device tree?
When I tried to write the signed dtb file to this partition I got the error that there is no space left, could the partition be too small for the newly compiled device tree?

nano@nano-desktop:~$ sudo dd if=tegra210-p3448-0002-p3449-0000-b00.dtb.encrypt  of=/dev/mmcblk0p10
[sudo] password for nano:
dd: writing to '/dev/mmcblk0p10': No space left on device
385+0 records in
384+0 records out
196608 bytes (197 kB, 192 KiB) copied, 0,0210659 s, 9,3 MB/s

I also flashed it to mmcblk0p2 which was labelled as “DTB” and I can verify that the partition actually contains my dtb file after writing to it with dd but after rebooting it still shows no changes.

WayneWWW · January 20, 2020, 3:03am

Could you try full flash? I just checked and guess this is indeed duplicated with https://devtalk.nvidia.com/default/topic/1064022/jetson-nano/dtb-flash-not-working/.

We just had a fix for it but it will be there until next release.

timonske · January 20, 2020, 4:23am

It always complains that there is no system.img when using the -r option. How do I get that in place?
Or what command exactly would you recommend for a full flash in this case?

WayneWWW · January 20, 2020, 4:32am

Please be aware of what these parameters are doing. If you are not sure then please use the simplest one.

“sudo ./flash mmcblk0p1” -> this would do the true full flash.

When you use “-r”, it would flash the board faster than the command w/o any parameters. This speed comes from avoiding regenerating system.img and it is not a real full flash.

Thus, if you get a complaint that there is no system.img, it means this Linux_for_Tegra may be a fresh one and you cannot use “-r”. You must do full flash first.

linuxdev · January 20, 2020, 9:21pm

Some notes for you…

“Linux_for_Tegra/system.img” is normally created based on the content of “Linux_for_Tegra/rootfs/”, although some boot content is added or edited at the moment of flash (“rootfs/” is nearly, but not quite, an exact copy of what is in the image).

Initially “system.img.raw” is created, and this is then converted to a smaller “sparse” file, “system.img”. Using the “-r” option skips this step and depends on what is already there for “system.img”. FYI, “system.img.raw” could be renamed “system.img”, and this would work, but the larger file size would mean a longer flash time.

Clones can be used for “system.img”. A single “system.img” can be used over and over if “-r” is used. The file will exist if one full flash has been run (without the “-r”) or if you’ve put the file there yourself.

timonske · January 20, 2020, 9:46pm

Thanks for the info. I guess I was mistaken by what the apply_binaries.sh script does. I thought it would make the system.img as well.

I flashed it successfully but unfortunately my Jetson now doesn’t boot any more, soon after the kernel is being loaded it crashes after being stuck for a while, it goes on like that forever. I attached the flash log as well as the bootlog.
bootlog-after-flash.log (30.4 KB)
dtb-flash.log (10.6 KB)

timonske · January 20, 2020, 10:59pm

Edit: ok its booting now with my DT changes, I removed the host1x outer layer from my modified dts and only kept the sor entry. The panel is now added to the proc (albeit disabled for some reason) but the prod-setting still stay the same as before.

Ok it seems to be caused by the device tree changes. I can’t see anything wrong with them though. Could you take a look?
The only file modified is

tegra210-p3448-0002-p3449-0000-b00.dts

I attached it here.
tegra210-p3448-0002-p3449-0000-b00.txt (4.74 KB)

WayneWWW · January 21, 2020, 2:01am

The panel is now added to the proc

Do you mean /proc/device-tree? Could you share what is under your sor and prod-settings now?

timonske · January 21, 2020, 2:08am

This is what I have right now:

nano@nano-desktop:~$ cd /proc/device-tree/host1x/sor
nano@nano-desktop:/proc/device-tree/host1x/sor$ ls
clock-names    nvidia,active-panel             phandle
clocks         nvidia,dpaux                    prod-settings
compatible     nvidia,sor1-output-type         reg
dp-display     nvidia,sor-audio-not-supported  reg-names
hdmi-display   nvidia,sor-ctrlnum              reset-names
linux,phandle  nvidia,xbar-ctrl                resets
name           panel-a-edp-1080p-14-0          status
nano@nano-desktop:/proc/device-tree/host1x/sor$ ls prod-settings/
 name   prod_c_dp  '#prod-cells'
nano@nano-desktop:/proc/device-tree/host1x/sor$ cat panel-a-edp-1080p-14-0/status
disabled

I tried setting dp-display to disabled but it had no effect.
This is what my dts looks like atm:

/*
 * arch/arm64/boot/dts/tegra210-p3448-0002-p3449-0000-b00.dts
 *
 * Copyright (c) 2018-2019, NVIDIA CORPORATION.  All rights reserved.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; version 2 of the License.
 *
 * This program is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 * more details.
 *
 * You should have received a copy of the GNU General Public License along
 * with this program; if not, write to the Free Software Foundation, Inc.,
 * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
 *
 */

#include "tegra210-porg-p3448-common.dtsi"
#include "panels/panel-a-edp-1080p-14-0.dtsi"
#include "porg-platforms/tegra210-porg-pinmux-p3448-0002-b00.dtsi"
#include "porg-platforms/tegra210-porg-gpio-p3448-0002-b00.dtsi"

/ {
	model = "NVIDIA Jetson Nano Developer Kit";
	compatible = "nvidia,jetson-nano", "nvidia,tegra210";
	nvidia,dtsfilename = __FILE__;
	

        sor {
            status = "okay";
            nvidia,active-panel = <&panel_a_edp_1080p_14_0>;
            panel-s-edp-uhdtv-15-6 {
                status = "disabled";
            };
            panel-a-edp-1080p-14-0 {
                status = "okay";
            };
            dp-display {
                status = "disabled";
            };
            prod-settings {
                prod_c_hbr {
                    prod = <
                        0x00000590 0x00f00000 0x00400000   //SOR_NV_PDISP_SOR_PLL1_0    23:20=LOADADJ   0x04
                        >;
                };
                prod_c_hbr2 {
                    prod = <
                        0x00000590 0x00f00000 0x00600000   //SOR_NV_PDISP_SOR_PLL1_0    23:20=LOADADJ   0x06
                        >;
                };
                prod_c_rbr {
                    prod = <
                        0x00000590 0x00f00000 0x00300000   //SOR_NV_PDISP_SOR_PLL1_0    23:20=LOADADJ   0x03
                        >;
                };
 
            };
        };
 

	sdhci@700b0600 { /* SDMMC4 for EMMC */
		status = "okay";
	};

	sdhci@700b0000 { /* SDMMC1 for SD card */
		status = "disabled";
	};

	spi@70410000 { /* QSPI */
		status = "disabled";
	};

	gpio@6000d000 {
			/* gpio-name for 40-pin header, gpio-name given as COL(10) x ROW(20) */
			gpio-line-names = "",   "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "SPI1_MOSI",    "SPI1_MISO",    "SPI1_SCK",     "SPI1_CS0",     "SPI0_MOSI",    "SPI0_MISO",    "SPI0_SCK",     "SPI0_CS0",
			"SPI0_CS1",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "GPIO13",      "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"UART1_RTS",    "UART1_CTS",    "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "I2S0_FS",    "I2S0_DIN",    "I2S0_DOUT",   "I2S0_SCLK",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "GPIO01",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "GPIO07",   "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "GPIO12",       "",     "",     "",     "",     "",
			"GPIO11",      "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "GPIO09",     "",     "",     "",
			"",     "",     "",     "",     "",     "",     "",     "",     "",     "",
			"",     "",     "SPI1_CS1",     "",     "",     "",     "",     "",     "",     "";
	};
};