- jetpack version：
- Collect logs referring to the link below Tegra Combined UART — NVIDIA Jetson Linux Developer Guide
- log
thor_logs.zip (9.0 MB)
Hi 1516775545,
Are you using the devkit or custom board for Thor?
From the log you shared, it seems the board booting as expected.
Could you please identify the specific timestamp or line in the log where the system freeze occurred?
custom board for thor！
When rebooting manually via the reboot command, the values are rst_source: 0x0 and rst_level: 0x0.When the system freezes and restarts abnormally, the values are rst_source: 0x33 and rst_level: 0x1.
The partial logs of system freeze and reboot are shown below, and the full logs are enclosed in the compressed package <thor_logs.zip>
RAW.txt:
From the current log, I can see the system became unresponsive before the reset, and the reset itself looks more like a consequence of the hang. I also observed storage-related errors and an RCU stall before reboot.
Is the current issue specific to your custom carrier board?
If so, do you have custom design on PCIe for the NVMe?
Another Jetson Thor device also experiences unexpected automatic reboots. Partial logs of system hang and reboot are provided below, and the complete logs are available in the compressed package.
thor_logs2.zip (904.2 KB)
@KevinFFF if you think this is plausible and if so @1516775545 could test an dt overlay:
The DT node, OOT driver, and crashes seem to be the same watchdog: TKE_WDT0 (Timer Kernel Engine Watchdog Timer 0.)
1. The driver exists and supports T264
watchdog-tegra-t18x.c in nvidia-oot explicitly handles nvidia,tegra-wdt-t264:
// nvidia-oot/drivers/watchdog/watchdog-tegra-t18x.c:860
{ .compatible = "nvidia,tegra-wdt-t264", .data = &t264_wdt_silicon},
2. The node is disabled in dtb
Neither tegra264.dtsi nor any board overlay sets the watchdog to "okay" — your search returns no hits.
The node stays disabled across all T264 boards. The driver never probes, never kicks TKE_WDT0.
3. ATF configured TKE_WDT0 with POR-reset enabled...
// arm-trusted-firmware.t264/plat/nvidia/tegra/drivers/watchdog/wdt.c:33-34
/* enable full system Power On Reset (level 1b) at 5th expiry */
reg |= TKE_WDT0_SYSPORRSTEN_BIT;
...with a ~2.15 second period → 5th expiry fires a level-1b reset after ~10.75 seconds of no kicks.
4. ...but the Linux driver would have DISABLED that POR
The DT has nvidia,disable-por-reset, and the driver honours it:
// watchdog-tegra-t18x.c:687-689
if (!of_property_read_bool(np, "nvidia,disable-por-reset"))
twdt_t18x->config |= WDT_CFG_SYS_PORST_EN;
When this flag is present (as it is in the T264 node), the driver does not set WDT_CFG_SYS_PORST_EN —
so the WDT would only generate FIQ/IRQ on expiry, not a destructive reset. Since the driver never
loads, ATF's configuration stands, and the WDT causes the full rst_source: 0x33, rst_level: 0x1 POR.
5. The doc Linux_for_Tegra/source/nvidia-oot/Documentation/devicetree/bindings/watchdog/nvidia,tegra-wdt-t264.yaml
in its example has 'status = "disabled"', suggesting this was intentional for the base DTSI and may have been
expected to be overridden by board overlays — but none of the Thor board overlays do that.
So you could add a board overlay or amend the tegra264.dtsi as shown below to enable the watchdog as diagnostic experiment to see if it helps.
&watchdog@8110000 {
status = "okay";
};
This enables the watchdog-tegra-t18x OOT driver to probe, which:
- Should take ownership of TKE_WDT0 from ATF
- Reconfigures it without the POR-reset bit (respecting nvidia,disable-por-reset)
- Kicks the WDT every timeout-sec = 120 seconds via /dev/watchdog
- Prevents the unserviced ATF configuration from firing rst_source: 0x33
The timeout-sec = <120> is fixed at 120 seconds in the binding (minimum: 0x78, maximum: 0x78), which
also explains why the binding locks that value — it matches the expected OS heartbeat interval.
Linux_for_Tegra/source/hardware/nvidia/t264/nv-public/tegra264.dtsi
watchdog@8110000 {
compatible = "nvidia,tegra-wdt-t264";
reg = <0x0 0x08110000 0x0 0x10000>, /* WDT0 */
<0x0 0x08010000 0x0 0x10000>, /* TMR0 */
<0x0 0x08000000 0x0 0x10000>; /* TKE */
interrupts = <GIC_SPI 773 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 774 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 775 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 776 IRQ_TYPE_LEVEL_HIGH>; /* TKE shared int */
nvidia,watchdog-index = <0>;
nvidia,timer-index = <0>;
nvidia,shared-interrupt = <0>; /* Shared interrupt to use for WDT. */
timeout-sec = <120>;
nvidia,wdt-error-threshold = <5>;
nvidia,extend-watchdog-suspend;
nvidia,disable-debug-reset;
nvidia,disable-por-reset;
- status = "disabled";
+ status = "okay";
};
Hi 1516775545,
From this log, the reboot still ends with watchdog reset (rst_source: 0x33, rst_level: 0x1), which means the system became unresponsive before reboot.
Compared with the previous log, this one shows more WLAN/CNSS/MHI initialization errors before the reboot, such as duplicate MHI symbol export, QMI connection not established, and multiple WLAN bring-up failures. Based on the current log, this case looks more related to WLAN software integration/init issue than the previous NVMe path.
If possible, reproducing once with WLAN disabled to confirm whether the reboot is related to the WLAN bring-up path.
Please also check if the dt overlay suggestion from whitesscott could help for your case.