Sysrq occurs constantly and trigger reset & crash

[yxs-heron]

I’m using Jetson AGX Orin 64GB with JP 5.1.2. when it is on developer kit carrier board ,it works all

right, but on our carrier board the sysrq message occurs many time even trigger reset & crash .

I find a similar case here Sysrq occurs constantly .

but our debug serial UART HW has no such problem , TX and RX PULLUP to VCC, and no anomalies were

picked up with the oscilloscope .

I can disable the sysrq message by change the bootargs in /boot/extlinux/extlinux.conf (
from
root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb nv-auto-config androidboot.serialno=1421723011636
to
root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb nv-auto-config androidboot.serialno=1421723011636
)

I wan’t to know why this happens, /dev/ttyAMA0 use for what and Which physical hardware is related?

Thank you!

heron
orin_log.txt (2.0 MB)

[carolyuu]

Hi,
Please check the quick start in developer guide and make sure you follow the steps one by one:
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/IN/QuickStart.html
If the device still cannot be flashed/booted, please refer to the page to get uart log from the device:
https://elinux.org/Jetson/General_debug
If you are using custom board, you can compare uart log of developer kit and custom board to get more information.

Thanks!

[yxs-heron]

I changed the bootargs in /boot/extlinux/extlinux.conf and it seems work fine now , the log get from debug UART3 . I wan’t to know why this happens, /dev/ttyAMA0 use for what and Which physical hardware is related? I can not find much more info from TRM by search 31d0000.

[KevinFFF]

@yxs-heron

I wan’t to know why this happens, /dev/ttyAMA0 use for what and Which physical hardware is related?

/dev/ttyAMA0 is used as secondary debug UART.
You can simply remove it from kernel command line or disable it with the following command.

$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service

[yxs-heron]

Thanks ! I find some useful info from TRM by search uarti .

The PIN C58 C56 default set to uarti , if leave PIN C58 C56 float ，Could it cause this kind of problem?

[KevinFFF]

Yes, they are UART-I.

@yxs-heron

The PIN C58 C56 default set to uarti , if leave PIN C58 C56 float ，Could it cause this kind of problem?

It should be fine to leave them float if you don’t need them.