Hi @WayneWWW , based on your comment in the below ticket , i have raised this new ticket with the logs attached.
I could not see the dsiplay when i flashed 5.1.4 build on Jetson xavier NX .
I have attached the display logs here
pr_1.txt (7.1 KB)
@ShaneCCC
Is this a custom carrier board or NV devkit?
Why mentioned jp5.1.4 specifically? Did it ever work on previous jp5 releases?
Also, your log still looks like totally incomplete. Do you really know how to dump serial console log?
screen -L -Logfile pr.txt /dev/ttyUSB0 115200 command to get the logsHi,
Just to do some clarification…
I don’t think devkit situation would be same as your custom carrier board. I am talking about the log itself but not whether a display GUI is showing up or not.
Please try to be more precise for what you are talking about. For example, if you system crash, then the monitor may not show up. However, if you don’t plug in a power cable at all, then monitor will not show up either. Such two cases are totally different but both of them have “monitor not show up case”. Normal people won’t consider them to be same. But it sounds like you just did such comment for your devkit and custom board case. I don’t know what is your way to tell devkit and custom board situation are same. There is no evidence to show that from your comment.
Your method to dump serial console seems to be wrong. Why did you make UART serial console to be a “type C”? I didn’t see anyone ever doing such thing on their custom board.
Also, why your log are all incomplete even in pr_2.txt? Did you customized anything to the log level?
OK @WayneWWW ,
Read this.
b) My system is not crashed since i could access it using this cable (type-c usb cable) after giving it a username and password by using l4t_user create bash file.
Yes, I am not talking about anything crashing on your machine. It was just an example to tell that you should not take everything to be “same” just because some common error (e.g. blanked screen).
- Can you suggest any other method to collect logs ? I have not customized anything to the log level and our hardware team says type-c USB cables are available when compared to micro usb so we are using this for debug.
If you are a totally newbie here, please read above link to understand how to dump a log on Xavier NX devkit first. I am not sure why you are using “micro usb” here because even NV devkit is not using that one to dump log. We are using specific pin to dump log from UART. They are not USB signal.
That was why I feel it is weird that there are someone ever spent extra effort to make a UART pin to be type C port.
It is more like actually you are not dump full log from UART but dumping from USB signal, which won’t have full log.
Got it , I will go through the link and update you with the logs from devkit .
hi @WayneWWW
I have attached the logs taken through UART pins .
uart_dmesg.txt (14.4 KB)
Where are these log coming from? Custom board or devkit? Log is still not completed and it is in a very weird way.
If you ever read how other users’ log uart log look like, you would know what I am talking about.
from devkit
I just randomly pick another post which has UART log from other users. You better checking how the log looks like first and you just read the logs you shared. You will notice your log seems all messing up.
I don’t know how you made these happened. You better reflashing the board without doing anything first and check if the log is normal (e.g. do not do anything with Jetson IO too). If the log is not normal, try other hardware (cable/module/carrier board/host) and see if it would become normal.
ok i will surely do that though i did reflashing more than thrice but i have few observations from my side
So the problem is raised only when the HDMI is connected from the start.
HI,
Just to clarify.
(2) sounds a problem related to software. But you need to fix problem in (1) so that I can tell what is wrong there.
Also (1) is not something that will “mess up all the log”. I never heard any issue that their UART log is just messed up because they connect a HDMI and boot up.
Maybe you should share the log without monitor first so that I can see such magical situation.
sure i will share the logs without the monitor
logs_before_display.txt (59.7 KB)
No… I need the UART log. Not the dmesg. Do you really understand what you are doing here?
Also, you told us the log is from devkit, then why modifying kernel and dts for devkit?
[ 0.000000] Linux version 5.10.216-tegra (spavan@XCALWS0718LT) (aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot 2020.08) 9.3.0, GNU ld (GNU Binutils) 2.33.1) #1 SMP PREEMPT Thu Jan 23 14:28:47 IST 2025
[ 0.006520] DTS File Name: /home/spavan/Builds/xavier/5.1.4/Linux_for_Tegra/sources/kernel/kernel-5.10/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t19x/jakku/kernel-dts/tegra194-p3668-0001-p3509-0000.dts
[ 0.006594] DTB Build time: Jan 23 2025 14:28:43
yes , i will share UART logs , give me sometime , I shared dmesg so that if we could get any clue from them.
And yes logs are from the devkit , sorry i did not get about the modification you mentioned.
The dmesg you just shared indicates that your kernel and dtb have been rebuilt by you. Built time is 1/23/2025.
If you are really using a Devkit, then such modification is not necessary. This modification is just like a blackbox to me and I won’t know what did you modify on your side. Maybe it is related to display or maybe not. I won’t know.
You should clarify why you need to do that on a devkit or just flash your BSP back to default one from sdkmanager. That is what I tried to say here.
What you did is basically like “I am using devkit, but all the logs indicate the software are not default devkit software”. Nobody knows what you did there.
okay , got it @WayneWWW . I have followed few steps given by my team to build .
So you want me to flash using sdkmanager ?
build_steps.txt (1.8 KB)