For background, I’m working with a Verdin AM62 on our custom carrier board, running SUSE Linux Enterprise Server 15 SP6 with the stock SuSE 6.4.0-150600.21.3 kernel. Just lately we’ve noticed a failure when rebooting the AM62 from command-line, where the system seems to lock up between the Linux kernel exiting and U-Boot starting:
kvm: exiting hardware virtualization
reboot: Restarting system
ERROR: Timeout waiting for thread SP_RESPONSE to fill
ERROR: Thread SP_RESPONSE verification failed (-60)
ERROR: Message receive failed (-60)
ERROR: Failed to get response (-60)
ERROR: Transfer send failed (-60)
At this point, the AM62 stops, and not even the watchdog resets it. So far we’ve only seen this happen once after innumerable reboots across several AM62 SOMs, and I suspect it would not recur if we power-cycled the system… but it’s obviously still a point of concern.
According to TI documentation, this is possibly due to the DM core not coming up soon enough? FWIW I’ve had no luck finding these error messages in the source code for U-Boot or the Linux kernel, so I’m guessing it’s from the ROM code. I’m looking for any clue as to what might trigger this?
Since this SOM isn’t running Torizon Linux, we don’t have tdx-info… but I do have some console output from prior bootloader runs that may be a sufficient substitute:
NOTICE: BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
NOTICE: BL31: Built : 16:09:05, Feb 9 2024
U-Boot SPL 2023.04-ti-gc997b1b09fba (Jun 19 2024 - 16:10:02 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.8--v09.02.08 (Kool Koala)')
SPL initial stack usage: 1920 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
U-Boot 2023.04-ti-gc997b1b09fba (Jun 19 2024 - 16:10:02 +0000)
In: serial@2800000
Out: serial@2800000
Err: serial@2800000
Model: Toradex 0074 Verdin AM62 Dual 1GB IT V1.2A
Serial#: 15600962
i2c_write: error waiting for data ACK (status=0x116)
get_tdx_eeprom: cannot find EEPROM by node
MISSING TORADEX CARRIER CONFIG BLOCKS
i2c_write: error waiting for data ACK (status=0x116)get_tdx_eeprom: cannot find EEPROM by node
am65_cpsw_nuss ethernet@8000000: K3 CPSW: nuss_ver: 0x6BA01103 cpsw_ver: 0x6BA81103 ale_ver: 0x00290105 Ports:2 mdio_freq:1000000
Setting variant to nonwifi
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I understand you’re experiencing a reboot failure on your Verdin AM62 running SUSE Linux Enterprise Server 15 SP6. While this is a challenging issue, I need to clarify that I can only provide support for Toradex-supported operating systems.
Supported Operating Systems
The Verdin AM62 is designed and tested with specific Toradex-supported operating systems(1)(2):
Torizon OS - Toradex’s container-based Linux distribution
Yocto-based BSPs - Toradex’s reference Linux BSP images
The Issue with Third-Party Operating Systems
While your Verdin AM62 hardware is genuine Toradex, running SUSE Linux Enterprise Server 15 SP6 falls outside our supported software stack. The error messages you’re seeing during reboot appear to be related to the TI AM62x SoC’s internal firmware communication, but troubleshooting this on a non-supported OS is beyond what I can assist with.
Recommended Path Forward
For the most reliable operation and full Toradex support, I’d recommend:
Test with Toradex OS: Try reproducing the issue with our supported Torizon OS or Yocto BSP to determine if it’s hardware or software-related
Hardware Validation: This would help isolate whether the issue is with your custom carrier board design or the SoM itself
Alternative Support
Since you’re using SUSE Linux on Toradex hardware, you might want to:
Contact SUSE support for kernel-level reboot issues
Consult TI’s AM62x documentation directly for SoC-specific firmware errors
If you’d like to test with our supported operating systems to help isolate the issue, I’d be happy to guide you through that process.
Best regards,
Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
I actually remembered today that we have a continuously-logging capture of the SOM’s serial console. Upon review, from Dec 4 to Dec 15, I noticed the following message spewing about once per second:
ti-sci 44043000.system-controller: Mbox timedout in resp(caller: sci_clk_determine_rate+0x64/0xe4)
These messages apparently started almost two months after the SOM was booted on Oct 6. I reviewed similar console captures from two other AM62 SOMs from the same lab, and the other two have never reported any such errors (and the console captures go back as far as July 15 2025). Just offhand, this seems like it could be related?
We have since power-cycled the affected SOM, and we’re not seeing any such messages in the current boot session. Apparently they persisted up until someone tried to reboot on the 15th and encountered the SP_RESPONSE errors.
