Hi @WayneWWW
we had to switch to L4T 35.6.2 due to the tegrabc kernel panic bug.
We tested everything and noticed that one thing doesn’t work anymore. The second display port.
It always shows displays as disconnected, no matter what we plug in.
In the previous L4T 35.4.1 it still works. Do you remember a breaking change which requires us to make specific adjustments in the device tree?
patches are put here.
I’ve read the section, but it says it is for DP over USB-C and AGX. Does it still apply to our platform?
I mean the " Bypassing the Seamless Display Issue". Not related to above DP/type C thing.
The patch is already included in L4T 35.6.2 as the document states.
If we revert the patch to get the second display back, we will also get the kernel panics on boot back? We switched from 35.4.1 to 35.6.2 to fix the kernel panics upon boot initially…
The 2nd one related to the bpmp is not included in the BSP.
Reverting that first patch won’t bring anything back.
The powergate-bpmp.c patch is already included in our code, probably from a previous conversation we had. Just with this addition around it: + if (tegra_get_chip_id() == TEGRA194) {
Doubt that changes anything.
So we got all the patches included.
Anything else changed, which could lead to the second display suddenly not working anymore?
Actually I am not aware of anything there. I would say could you try to reproduce same situation on NV devkit first?
Our image won’t run on the devkit, so trying it on the devkit would be the standard Ubuntu without our device tree changes. I am quite sure that it will work there? Otherwise someone would have reported that?
No, I don’t get any report here. That does not matte actually.
The standard steps here are you need to try to reproduce on NV devkit first.
Using same monitor on NV devkit to exclude whether this issue is related to specific monitors.
Well, the issue is on all our boards with all the monitors we have. The issue is gone when I flash the old version again. And it must be bootloader related. Only changing the image does not remove the issue. So our old userland with the new bootloader does not work, even tough our old device tree is loaded then. So it must be an issue somewhere earlier in the nvidia specific bootloader part.
When you ask about the devkit, maybe I forgot an important bit:
Devkit has 1 HDMI and 1 DP.
We have 2x DP, so one HDMI is configured to become a DP.
Does that ring a bell maybe?
One quick test here. If you don’t let bootloader do anything to your monitor, will it work?
For example, do not connect anything during boot. Hotplug those monitors after kernel is ready.
I think It didn’t work, but I’ll check that tomorrow in the office.
IIRC xrandr always shows disconnected, no messages in dmesg when hotplugging. Also no event in udev monitor. Just as if I did not connect anything.
Hi,
Then I think this issue has nothing to do with any bootloader or seamless thing here.
Let’s discuss this once you could provide dmesg and xorg log first.
Okay, I’ll get you the full logs before and after the update on the same machine. Maybe that helps.
Need to be in the office for that, so you get them tomorrow. Thanks!
Hey @WayneWWW, here are the requested files.
I noticed in the new kernel logs, that something can’t be loaded:
[0003.892] I> regulator ‘vdd-hdmi-5v0’ already enabled
[0003.900] I> regulator ‘vdd-hdmi-5v0’ already enabled
[0003.901] E> tegrabl_display_init_regulator: hdmi cable is not connected
[0003.901] E> tegrabl_display_get_pdata, failed to parse dtb settings
[0003.903] E> no valid display unit config found in dtb
[0003.907] W> display init failed
The device trees are identical except of the disable-seamless = <0x01>; being added and the max-link-speed = <0x03>; being removed from pcie@14160000, spmic interrupts changed.
display_logs.zip (156.1 KB)
Some clarification.
I noticed in the new kernel logs, that something can’t be loaded:
This is not kernel log. This is bootloader log. Not part of what we should focus for now.
Part bootloader/part kernel, whatever, it is different after the update now.
We did not change the pinmux, it is untouched. Is there something in the L4T that makes a pinmux update required? Did the xlsx change, which we generate the pinmux from?
Let’s check the register first.
These two are for DP1. Please dump it first.
sudo busybox devmem 0x02440038
sudo busybox devmem 0x02212620
sudo busybox devmem 0x02440038
0x00000150
sudo busybox devmem 0x02212620
0x00000001