JetPack5.1.3, there is a probability that xavier may encounter this error when using the serial port， causing a panic. Can this issue be resolved
dmesg-ramoops-1.log (106.6 KB)
Is this a developer’s kit? Or is there a third party carrier board? You need to state the exact hardware. You might also want to post the content of “/etc/nv_boot_control.conf”. If there has been any modification of the device tree, then that too is important.
Is a third party carrier board.The device tree with respect to serial@3100000 has not been modified.
This is my device tree.
dtb.txt (430.9 KB)
The current situation seems that there is a probability of this problem occurring if the serial port receives gps data during the startup process.
It is possible that the device tree needs an edit to work correctly with the third party carrier board. The device tree changes some configurable pins on the module to different functions to match the traces of the custom carrier board. If this is still configured for a developer’s kit, and if the third party carrier board is not an exact match to the layout of the dev kit, then activity on the serial port might be going to the wrong place. Does the vendor of the third party carrier board provide a device tree, or does it specifically state to use the unmodified NVIDIA developer’s kit software? Quite possibly serial@3100000 needs modification.
I will mention that during boot the device tree can be used. In the case of someone using the serial console port for data, and disabling it once in Linux, that the bootloader would still be using the old serial console information on the UART unless boot code itself was changed. I do not believe that the serial console is related to this, but it is possible some other device tree change is needed, but the error is shown from a loaded Linux kernel, so that particular log has no indication that the error is from a boot stage. On the other hand, the boot environment is inherited by the Linux kernel, so there is a small possibility that if GPS data is received prior to the kernel being loaded, and if the device tree is wrong, maybe the environment changes and results in what you see after boot completes.
So mostly we need to find out if the carrier board is supposed to have device tree changes. The third party vendor would be the one to answer that.
Thank you for your reply.This is the device tree of the third-party carrier board. No changes were made to serial@3100000.
dtb.txt (430.9 KB)
This means that the electrical layout for that serial UART must be the same on the custom carrier board as it is on the NVIDIA developer’s kit. The only people who know what was changed (or not changed) are the people who designed the schematic for that carrier board. If there is someone who supports this other carrier board, then you can check there for any kind of flash software updates, patches, firmware (a device tree is firmware), etc.. Is there any kind of support URL for this particular carrier board?
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.