I am using Tx2i with L4T 28.2.1 .
The Jetson boot stucks at boot if hdmi to the display at boot time. If connection is made after boot, the display works fine with correct resolution.
I found there is a patch but its not applicable to 28.2.1.
Can some one help how this issue can be resolved ?
R28.2.1 was the very first release for the TX2i. Is there any reason you couldn’t use the most recent R32.x? You can see L4T releases here:
I think your patch would already be there. If you can’t use a more recent release, is there some particular software or hardware creating that limitation?
Yes, this is the custom board and the manufacturer is providing this in BSP.
I tested the same display with an other board which is running recent R32.x and its working fine. So it seems like a Patch is required for L4T 28.2.1that can resolve this issue.
On forum i have seen People have faced similar issue with L4T 28.1 which was fixed by the patch.
R28 itself was the very first non-preview 64-bit ARM release. I expect many bugs. It is likely the best/easiest fix is to use a newer release. There are sometimes reasons for not going to a new major release, e.g., you need a specific release of CUDA, but there would be major reliability improvements by going to R32.x. Even an upgrade within R28.x would be quite useful. You might consider cloning the rootfs before doing anything major, but if you want to immediately debug you will have to attach a serial console boot log; once with the failure if HDMI is connected at boot time, and another without the monitor attached until booted (you’d want such a log to include the moment power is applied all the way up until the HDMI is plugged in).
The problem is there are no logs when display is connected at boot time because boot stucks at initial stages.
The output on UART7 is very minimal, and stops as soon as kernel boot starts.
The 2 releases R28.2.1 and R32.x are very different. It wont be easy porting them since its very different. I would like to know if there is any patch available for this version since it seems like a known issue in previous versions.
Serial console should still work during boot stages (there is no dependence upon video drivers, and in fact much of the system can crash and burn and serial console will still work). Boot stages have serial console logs which are independent of the logs from the Linux kernel. Is serial console logging also missing? That too is a clue if it is the case. However, no matter how much log appears in that case, it is important to know exactly at which point the logging fails or stops, so a complete boot log, no matter how short, is useful.
If the serial logs can identify the exact problem, then someone from NVIDIA might be able to find a patch or description of that as a known problem. Without that I don’t think even NVIDIA could identify a patch.
I understand that porting is sometimes nearly impossible due to restrictions, but what part of porting is the most difficult? Are you working with a given release of CUDA that isn’t available on 32.x? There is L4T R28.5, and this shouldn’t be much of an issue versus install on R28.2.1. You could at least get the most patches for R28.x that way.
Yes the Board configuration is not similar to the evaluation kit. We do not have enough documents to build it from scratch on newer version.
The major problem will be translation of dtb of R28.x to R32.x which is quite different.
Is there any tool that can help?
There isn’t a tool, however, there are newer releases of R28.x. There would not be any API difference, and you could use the old device tree. Is it correct that all is installed on eMMC? If so, then this can be cloned for preservation outside of the Jetson.
This states that official fix is in R32.x
Maybe @WayneWWW (or anyone from NVIDIA) could answer if this fix was a patch to kernel and/or device tree such that it could be migrated back to your release. If it is a binary file change, then you would have to go to R32.x, but if part of the kernel, then there is a small chance it can be back-ported. I have no knowledge of the actual patch which was added to R32.x.
Sorry for late reply. Could someone share a brief summary of current status?
I really don’t suggest to use rel-28.x as this is really too old that no one is really maintaining this anymore. Just focus on rel-32.
There is a problem whereby the monitor works if hot plugged after boot, but not if connected from cold boot. There was apparently a patch somewhere along the line to fix this, which I think is in R32.x, but I have no knowledge of which patch it might have been. Some sort of cold boot monitor detect patch.
Serial console log is required to check this issue.