AM62L-EVSE-DEV-EVM: SPL Bootloader reset during cold boot

Part Number: AM62L-EVSE-DEV-EVM

Hi Team,

We are evaluating Processor SDK Linux AM62Ax 11.01.07.05 on an AM62Ax EVM and have observed an intermittent boot issue during cold boot / power cycle conditions.

SDK Version: Processor SDK Linux AM62Ax 11.01.07.05

Boot Configuration

• Board: AM62Ax EVM
• SDK: 11.01.07.05
• Boot Media: SD Card (MMC2)
• Secure Boot Enabled (authentication messages observed)
• Falcon Mode Enabled

Observed Behavior

During cold boot, the board occasionally exhibits the following behavior:

1. SPL starts normally and loads the Falcon payload.
2. ATF (BL31) banner is printed.
3. The system then appears to stall for approximately 1 second.
4. A reset occurs without any explicit error message.
5. The board subsequently boots successfully on the next attempt.

Excerpt from the console log:

Plain Text

U-Boot SPL 2025.01...

SYSFW ABI: 4.0

Trying to boot from MMC2

Authentication passed

Loading falcon payload from MMC2

...

Starting ATF on ARM64 core...

NOTICE: BL31: v2.13.0(release):

NOTICE: BL31: Built : Jul 1 2025

<~1 second gap>

U-Boot SPL 2025.01...

SYSFW ABI: 4.0

Trying to boot from MMC2

Authentication passed

Loading falcon payload from MMC2

...

Starting ATF on ARM64 core...

NOTICE: BL31: v2.13.0(release):

NOTICE: BL31: Built : Jul 1 2025

Additional Observations

• The issue is sporadic and not reproducible on every power cycle.
• We have not observed the issue during warm resets, soft resets, or reset-button initiated reboots.
• The issue appears only after a power cyclereset_bootlog_with_kernel_log_silent.txt 
• Following the reset, the system boots successfully without any intervention.

Questions

1. Has TI seen similar behavior on AM62Ax devices running SDK 11.01.07.05?
2. Is there any known interaction between:
   • Falcon Mode
   • ATF/BL31 initialization
   • DDR initialization during cold boot
   • SD card boot timing that could result in a watchdog-triggered or hardware-induced reset?
3. Are there any recommended debug mechanisms to identify the reset source (watchdog, PMIC, brownout, device manager reset, etc.)?
4. Is this behavior more indicative of a hardware issue (power sequencing, PMIC, DDR initialization stability) or a software issue in SPL/ATF/Falcon boot flow?

Following are the summary of observations so far:
falcon_default_build_log.log 
2. Normally reset is observed when kernel image is loading/verification phase.
3. if we add some delay in early boot cycle then reset shifts even earlier state like, before kernel image loading.
4. If we use smaller kernel image then reset shift farther, during TFA handing over control to kernel.
5.there are 4 led turn on when we give power to board and system start booting and these will be consistent . but in issue case , 3 of these leds goes off momentarily then on and 4th one blinks. 

Any guidance on root-cause analysis or known fixes/workarounds would be greatly appreciated.

Thanks.