[0003.622] E> tegrabl_display_get_pdata, failed to parse dtb settings
[0003.629] E> cannot find any other nvdisp nodes
[0003.633] E> no valid display unit config found in dtb
[0003.640] W> display init failed
The subsequent UEFI boot also crashes, which I guess is a separate bug to fix, if display init failed.
@WayneWWW This is on a custom board; we have swapped hotplug polarity on the board. When using the nvidia,out-flags property, things worked correctly with R35.1.
Sorry, I don’t understand what is your exact issue here.
How to reproduce your issue? I am not sure if we are talking about same issue.
On rel-35.2, we disable the bootloader display on head1 and head2 by default. If your issue is you cannot see any boot logo, then it is due to our patch. If this is some other issues, then we need you to elaborate.
@WayneWWW To reproduce, please just try adding that nvidia,out-flags .dts segment and observe the boot crash?
I think you might be confusing the display heads and the SORs? I can indeed see that the bootloader display is only enabled for the very first head. That to me seems fine. But note that both sor & sor1 are enabled in the .dts. It looks like sor is for DP and sor1 is for HDMI. My understanding is that both these SORs go to the very first display head?
Thanks, so to elaborate a bit further: the board has an HDMI connector (nothing else) and there is only one display output involved. The board has the HDMI HPD polarity inverted compared to the reference design.
To deal with the inversion of the HPD polarity, all that is necessary on R35.1 is to add the snippet to the .dts and everything works great (without this addition, the kernel thinks the monitor is plugged when the cable is actually unplugged and vice-versa).
I now have some additional data. I found that if I change tegra194-p3668-0001-p3509-0000.dts and only modify the nvidia,out-flags, then there is no display output, and while there are the BL errors during boot complaining about the DT parsing failing compared to an unmodified .dts, there is no boot crash and otherwise boot carries on OK. Apologies for any confusion that this created.
If I use a more modified .dts that has other changes for our board:
a) myboard-working: this fully boots with no problem, but HDMI not working because of the incorrect HPD polarity setting (kernel things cable is plugged when it is unplugged and vice-versa);
b) myboard-not-working: the only change here is to the flags for the HPD polarity setting … and this now crashes during boot, boot log attached;
Hope this clarifies the issue; please let me know if you need any more info?
May I confirm my understanding of current situation?
You don’t have any working case for HDMI, but what you can do is prevent the UEFI crash happened
When you set nvidia,out-flags to inverted polarity, it will definitely lead to UEFI crash.
Are above correct?
If so, I also wonder, what is the log in case 1 where you use default setting?
It sounds like no matter what device tree setting you set, cboot always tells you “tegrabl_display_init_regulator: hdmi cable is not connected”. Is that correct?
1/ So if out-flags is not inverted in the .dts, actually, HDMI is fully working during the bootloader on our board (I see the nVidia splash screen with no problem at all … it seems that the BL log says “hdmi cable is connected” regardless of whether a cable is really connected or not).
But then, as soon as Linux boots, the HDMI stops working, because Linux takes the HPD polarity into account and the (unchanged) .dts out-flags are still saying to use non-inverted polarity. It seems that the BL does not care about the state of the HPD in practice, but it crashes if it does not understand the inverted flag in the .dts.
2/ With myboard.dts, yes, setting the out-flags to inverted always causes a crash. With tegra194-p3668-0001-p3509-0000.dts, setting the out-flags to inverted does not cause a boot crash, but the parsing error is always seen from the BL and there is no boot splash displayed any more.
Yes, that works as a workaround. Or changing the kernel code to invert the polarity is another alternative. My rationale for raising this thread is so that the crash can be fixed in the bootloader on the nVidia side for the next release. Can a ticket be raised internally about this issue? The bootloader did not crash before with the same out-flags so I think this is a regression…
I didn’t mean we won’t fix this issue. Just hope you could test the workaround first.
There are lots of display patches merged to UEFI between rel-35.1 and rel-35.2 so it is possible to have regression.
Could you help me confirm if it has to be “nvidia,out-flags = <TEGRA_DC_OUT_HOTPLUG_HIGH>;” to reproduce issue or it could be something else?
For example, if I just add this to default DTB on AGX or NX devkit, then I can reproduce this issue? Could you confirm about this?
Sure, so all the testing that I’ve done so far suggests that if you just add:
nvidia,out-flags = <TEGRA_DC_OUT_HOTPLUG_HIGH>;
… to a Xavier NX SoM on R35.2.1 then you should in all cases see the “tegrabl_display_get_pdata, failed to parse dtb settings” error appear in the boot log and no working boot splash from the bootloader.
I do not have a Xavier NX devkit to hand, unfortunately, but I can reproduce this bootloader error message by using the devkit’s .dts on my board and just changing that one line in the .dts, making no other changes.
My thinking is that once the bootloader team fix this tegrabl_display_get_pdata error that is shown in the boot log, then the UEFI crash should also go away. To reproduce the UEFI crash you could maybe try flashing myboard-not-working.dts which I’ve attached here onto a devkit, but I don’t know for certain whether it will show up the issue or not.
I know that the boot crash / bootloader error does not reproduce with TEGRA_DC_OUT_HOTPLUG_LOW (but then, of course the kernel then sees the wrong hotplug polarity on cable unplugged vs. plugged). I don’t have access to the hardware at the moment to try out TEGRA_DC_OUT_CONTINUOUS_MODE.
Yes, this is still an issue to resolve as it is a regression from the previous release.
TEGRA_DC_OUT_CONTINUOUS_MODE makes no difference because it resolves to the same nvidia,out-flags = <0x0> in the compiled .dtb. The only thing that seems to work so far is to have TEGRA_DC_OUTPUT_LOW i.e. nvidia,out-flags = <0x1>.
I think the next step here is that this needs to be passed on to somebody with visibility of what the bootloader code is doing and why it reports failed to parse dtb settings when nvidia,out-flags != <0x1>.