Custom board, hdmi display not showing

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
,
21

I get it.

The device tree should be correct, i followed the topics you shared and added the os_gpio_hotplug_a line to the display@13800000. The content of the device tree blob are correct following this topic HDMI Output cannnot work in AGX Orin based CustomBoard 35.3.1 - #4 by WayneWWW. It has been modified by the blob modifier tool. And finally the pinmux file is adjusted to make sure it follows the developper guide (Welcome — Jetson Linux<br/>Developer Guide 34.1 documentation).

22

How did you update these things to your board? That is the point that I asked those 3 questions.

You can have 100 versions of binary on your host side, but if none of them flashed to your board, then it would be in vain too.

23

There is another thorough post which includes almost every check.

Sorry that some posts are in Chinese due to customer is from China.

24

Thank you! Will check it out tomorrow.

For now, im sorry if i dont seem to understand! It’s kind of hard to know what to do and not to do when following topics since you almost never know if its worked correctly or not.

25

I mean after you update your dtb, pinmux. How did you flash them to your board?

Did you really do this thing or you don’t know what I am talking about?

26

I did by using same command as him, ./flash.sh on devkit then i switch the module on custom board.

So the whole process is to rebuild kernel when the source files are modified, then always reflash manually to be sure that modification are made.

27

Please do not flash like that. That one is not correct because “-r” will re-use the previous system image. Which means something are not updated…

You should remove the -r. It will take more time but it will ensure everything in system image is new (kernel and dtb are from system image).

28

My mistake, i never added the -r option, just didnt see it when reading the topic

Also

By quicky passing through the topic you just shared there is one thing i did not do and its changing the function of GPIO pin

This was not mentionned anywhere else on the topics ive read.

29

This is actually just in the first post of the link you shared.

30

I admit. I completly missed it.

I did the modification and am currently reflashing my board.

1 Like
31

Hi!

So I verified that the pinmux and device tree were correctly modified and flashed by checking the flash log. Also i verified that the dcb_blob was the same as the one you shared.

Here is the flash log :
flash.log (488.3 KB)

With the important part being :
[ 0.8078 ] Kernel DTB used: kernel_tegra234-p3701-0000-p3737-0000.dtb
[ 0.8514 ] Pre-processing config: tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi

I applied the hotplug patch by adding to device tree node display@13800000 :
os_gpio_hotplug_a = <&tegra_main_gpio TEGRA234_MAIN_GPIO(M, 0) GPIO_ACTIVE_HIGH>;
I applied to the aformentionned files those modifications :

Finally, once i checked everything, i reflashed the jetson on the devkit and switched back to my custom board to test the hdmi. I tried removing hdmi cable then powering the jetson and then replug the hdmi → nothing appears. Then i tried plugging the hdmi before opening the jetson → nothing. I do get this message when plugging hdmi:

Sorry if i make you repeat!

I’m getting used to the nvidia jetson configuration system now but im still a newbie.

So what should i do next?

Loic

32

Hi Loic,

Could you share the board schematic of the HDMI part for review?

33

Hi!

Here are the schematics, we physically swap the Lane 0 and 2 of HDMI to respect design guide by removing resistances and soldering cables.

Capture d’écran 2023-07-31 154018

CorrectionHDMILane
CorrectionHDMILane1744×965 176 KB

34

Hi,

Yea, I found it like 2 days ago and it seems pretty similar to my use case like you say! Thing is with them it was the aux line which were swapped. I double checked my case and it is correctly connected ( the dp_aux_ch2_p is connected to the Clock signal from connector, meanwhile the dp_aux_ch2_N is connected to Data).

image
image1097×440 43.1 KB

So i guess it’s back to checking hardware.

Tho, one thing i realised is that my GPIO state is always “hi” even when I unplugged the HDMI. I used this command to read gpio PM.00 state: cat /sys/kernel/debug/gpio | grep PM.00. Is it normal?

Thank you!

Loic

35

Hi @loic.boileau

Sorry that actually I spent most of time on another post as this

This user’s case is similar as yours. And turns out his hardware design has problem. Thus, I am confident that the software should work if pinmux, dcb and dts are correct.

Please go through the post and if they are all ready, go back to review your hardware.

36

Hi!

So we revised our hardware and realise the GPIO07 was causing the problem, it stopped the 5V to reach the i2c lines which made it not work. So we enabled the tri-state for the gpio07 pin and now we can see the boot display! Yay!

However, we get a new error after booting :

gaus@tegra-ubuntu:~$ [ 22.802321] nvidia-modeset: ERROR: GPU:0: The requested.
[ 22.819142] nvidia-modeset: ERROR: GPU:0: The requested configuration of dis.
[ 24.392869] nvidia-modeset: ERROR: GPU:0: The requested configuration of dis.
[ 24.409964] nvidia-modeset: ERROR: GPU:0: The requested configuration of dis.

Here is the Xorg.0.log :
Xorg.0.log (9.0 KB)

This screen I’m using has a VGA-HDMI adaptor. So I decided to also try it on another display, the error looks the same.
Here is he Xorg.0.log attached to the screen.
Xorg.0.log (8.9 KB)

Glad we passed through the hard part!

Loict

37

Is that “another display” a native HDMI or still VGA-HDMI adapter?

38

native HDMI, sorry for not being clear

Could it be because of the debug_uefi.bin im using instead of normal uefi?

39

I don’t think that is related to debug UEFI.

But you could try to use default one first.

Please share full dmesg. Xorg log is not sufficient to debug now.

40

Just did, it did not change anything.

Here is the full dmesg and boot log.

boot.log (91.3 KB)
dmesg.txt (69.0 KB)