if you don’t mind can you please look at attached UART boot logs and tell us where things are going wrong. I am not too familiar with the bootloader and its logs. I am getting a blank screen just a few seconds after boot (with a quick flash of txt that says: …display: FB device numbering does not match device numbering of extend…. display: failed to register fb). is this an issue with our tegra194*.dtb file? if there is a file that is missing or needs to change please let us know. This is a production custom board. Is the issue due to loading xusb.bin as indicated at the end of the file? nx_uart.log (108.9 KB)
The exact error message displayed on screen for a fraction of second is:
tegradc 1520000.display: hdmi: can’t get adapter for ddc bus 3
tegradc 1520000.display: FB device numbering does not match device numbering of extend
display interfaces
tegradc 1520000.display: failed to register fb
Hi WayneWWW, thank you for gettin back to us, the message in my post (failed to register fb …) is what is displayed on the screen, it happens very fast, I had to take a video of it to be able to capture and read it and they don’t show in the uart logs. I have captured the uart logs again (see attached). I have stopped the uart logs about 10-20 seconds after the screen goes black since nothing was appended to them. nx_uart.log (72.2 KB)
My point is your log became shorter than before. In the log you shared yesterday, you are still able to enter kernel.
However, in the latest log you shared, it even not passed the UEFI.
“tegradc 1520000.display: failed to register fb” is a log that printed from kernel but not UEFI.
If you cannot give a stable error to reproduce, then we cannot help you much.
We don’t deal with multiple errors in one topic.
I mean you cannot reproduce an error in kernel on day 1, and then reproduce another issue in UEFI on day 2 and ask all of them in the same topic.
Thank you WayneWWW
Point taken and you are correct, the two logs are not the same. After I saw your message I rebooted our Jetson device a few times, without making any changes to it, and in all instances the last log that I posted was displayed on the screen, I know that these logs don’t show that kernel is loading (just UEFI). I am not sure why the UART logs from the device don’t show any messages from kernel but what is displayed on the screen ("failed to register fb”) show the message from kernel. All this happens within a second after the NVIDIA boot logo screen is done and then the device stops and tries to boot again.
I cleaned our entire project and did a new build and flashed the device and the same results. You can ignore the first log that I posted but the error message remains the same. The same error message is displayed on the screen. I have attached the logs again. Note that the device reboots in the attach logs after it fails.
Can you give us any hints as what may be causing this? Also could there be something that is suppressing the kernel logs?
To see what the kernel actually used on command line see this: cat /proc/cmdline
Note that part of what goes into that command line is from the device tree’s “chosen->bootargs” (see “cat /proc/device-tree/chosen/bootargs”).
Also, you should be able to log from serial console without using screenshots.
Just as a general mention, which probably is related to this, but not necessarily, is that if you use any wiring layout which is different than the reference carrier board, that the device tree itself needs to change. For example, the DDC wire of HDMI uses an i2c protocol, and i2c uses a power bus regulator, so if i2c is routed incorrectly, or if the bus powering the i2c is incorrect, then DDC would fail. It just seems likely that you are looking at a device tree failure for that particular electrical layout. Finding the first error would help, but without the full serial console boot log you won’t be able to tell what the boot stage errors are.
Thank you linuxdev, this is helpful. We are using a usb-to-TTL connector to read the UART logs from our device, but, it seems, for some reason we are not able to see all the logs. Let us investigate to see what is happening there, it looks like that without the logs we won’t be able to get far.
Hi @WayneWWW ,
We have been able to reproduce this. I think this issue has to do with the way we package everything in the rootfs. you are correct, devkit works fine. I am now able to reproduce this issue. I am not sure if it is a xusb.bin issue or a display issue, you can see in the attached log at 5.6 seconds the device waits (at this time I am seeing the boot screen where it says you can press escape to enter setup) and then after that the device reboots again ( I have stopped the logs during this reboot). uart2.log (116.5 KB)
We are using the tegra194-p3668-0001-p3509-0000.dtb, is this the file you are referring to when you say to “modify your device tree one by one”
Can you give us some hints at what may be wrong here
Sorry that it has been 2 weeks since your last update. May I clarify you latest status?
I don’t see any error from display driver anymore but I do see problem from usb driver.
The firmware is read from initrd but not from rootfs, so did you ever customize the initrd by yourself?
Also, if the device reboots, then you should at least capture that log. However, I don’t see that reboot log at all.
I mean there would be some error printed before a unexpected reboot happened. But it looks like you just cut this important info.
Hi WayneWWW, we did not, in this case we are directly flashing the Xavier NX to V 35.4.1with a custom initrd, the initrd is responsible for creating the rootfs (including creating a new boot directory which contains extlinux.conf). Once the initrd is done then we reboot the device and then it boots from the newly created boot directory
I have to say that what you said may not be right. This video=efifb:off issue is added after rel-35.3.1 because rel-35.3.1 has something new added to the kernel config and that something new causes the issue.
I am totally okay with the solution here but you may need to make sure you are really using the version you want.
Yes I was correcting it and you beat me to it, within 1 minute. Thank you for all your help WayneWWW your comments helped us to finally find this solution. Both you and Linuxdev
