Booting issue on Verdin AM62 S 512MB WB IT

I am facing a boot issue with one Verdin AM62 S 512MB WB IT SOM on a Mallow carrier board.

I am using my own Yocto build based on tdx-reference-multimedia-image. The same image boots correctly on multiple other Verdin AM62 SOMs using the same carrier board, SD card, and power supply.

Issue description:

  1. When booting this SOM from an SD card, the kernel starts but ends with:

    Kernel panic - not syncing: No working init found

  2. I stopped at U-Boot and manually executed run bootcmd_mmc1, but the same init not found error occurs.

  3. I then erased the eMMC from U-Boot and booted again from the SD card. After erasing the eMMC, the system booted successfully from the SD card.

  4. However, after rebooting the board, there is no UART output at all (no ROM, SPL, or U-Boot logs).

  5. I also tried to boot the Toradex Easy Installer. From the Easy Installer U-Boot, I booted again from the SD card.

  6. The SD card contains a .wic.xz image of my Yocto build, which I wrote directly to the eMMC using dd.

After rebooting, the board still produces no output on the UART console.

Additional notes:
The same SD card and Yocto image work correctly on other Verdin AM62 SOMs.

UART wiring, carrier board, and power supply are verified and known-good.

After the final reboot, there is no serial output at all.

Question:
What could be the possible root cause for this behavior? Could this indicate an eMMC, PMIC, or SOM hardware issue?

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


Based on your description, this appears to be a complex boot issue with your Verdin AM62 SoM on the Mallow carrier board. Let me help you troubleshoot this systematically.

Analysis of Your Boot Sequence

Your issue progression suggests a few potential causes:

1. Initial “No working init found” Error

This typically indicates either:

  • Corrupted root filesystem on the SD card
  • Incorrect root filesystem parameters in U-Boot
  • eMMC interference with the boot process

2. Complete UART Silence After eMMC Operations

The fact that you lose all UART output (including ROM/SPL) after eMMC operations is concerning and points to potential hardware issues.

Troubleshooting Steps

Step 1: Verify U-Boot Environment Variables

When you can access U-Boot, check these critical variables(1):

> printenv boot_targets
> printenv root_devtype
> printenv root_devnum
> printenv fdtfile

Ensure boot_targets includes mmc1 for SD card boot and verify the root filesystem parameters are correct(1).

Step 2: Check Root Filesystem Parameters

The “No working init found” error often relates to incorrect bootargs. Verify your tdxargs variable(1):

> printenv tdxargs
> printenv bootargs

Step 3: Hardware Diagnostics

Given the complete UART silence after eMMC operations, this could indicate:

Power Supply Issues: Similar symptoms have been reported with poor quality power supplies(2). Even if your power supply works with other modules, this specific SoM might be more sensitive.

eMMC Hardware Failure: The eMMC might be corrupted or failing, causing boot conflicts.

PMIC Issues: Power management IC problems can cause complete boot failure without any UART output.

Step 4: Recovery Attempts

  1. Try a different power supply - This has resolved similar issues in the past(2)

  2. Use Toradex Easy Installer Recovery Mode:

    • Boot into recovery mode using the recovery button
    • Completely erase and reflash the eMMC with a known-good Toradex image
    • Test if the module boots normally with the reference image
  3. Test with minimal configuration:

    • Remove all unnecessary peripherals
    • Use only essential connections (power, UART, SD card)

Step 5: Verify SD Card and Image

  • Test your SD card on a PC to ensure it’s not corrupted
  • Try a different SD card with the same image
  • Verify your Yocto build by testing it on a working Verdin AM62 module first

Potential Root Causes

Based on the symptoms and similar cases:

  1. Hardware failure - Most likely given the complete UART silence
  2. Power supply quality issues(2) - Even with “good” supplies, some modules are more sensitive
  3. eMMC corruption - Could cause boot conflicts even when booting from SD
  4. PMIC configuration issues - Might be triggered by the eMMC operations

Recommendation

Since you have complete UART silence after the eMMC operations, this strongly suggests a hardware issue rather than a software configuration problem. I recommend:

  1. Testing with a different, high-quality power supply
  2. If the issue persists, this SoM may need hardware diagnosis or replacement
  3. Contact Toradex support for potential RMA if the module is under warranty

The fact that other identical modules work fine with the same setup indicates this is likely a hardware-specific issue with this particular SoM.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hi @ToradexAI,

I have a Verdin AM62 (512 MB, WB IT, 4 GB eMMC) module that is no longer booting.

Observations:

No output on UART (completely silent)

Booting from SD card also shows no UART output

In recovery mode, the module enumerates only as TI ROM DFU (0451:6165)

It never re-enumerates as Toradex USB download gadget (1b67:4000)

On a working module, the same recovery procedure proceeds further and the VID/PID changes as expected

Recovery test results:

./recovery-linux.sh only reaches the ROM DFU stage on the faulty module

No SPL / A53 / R5 stage appears

Easy Installer never starts

SD card with a known-working image also does not boot

History:

The module was previously working

At some point, an SD image was copied to eMMC

It is possible the eMMC (including boot partitions) was erased or corrupted

Question:
Is it correct to conclude that the eMMC boot0 / boot1 regions may be erased or corrupted, preventing tiboot3.bin from executing, and therefore making USB/SD recovery impossible without factory reprogramming?

Analysis of Your Boot Failure

Based on your detailed description, your analysis is correct. The symptoms you’re experiencing indicate a critical boot failure at the ROM level, likely due to corrupted or missing boot partitions on the eMMC(1).

Understanding the Boot Sequence

The AM62 boot sequence follows this pattern:

  1. ROM code loads and executes (this is working - you see TI ROM DFU enumeration)
  2. tiboot3.bin should load from eMMC boot partitions
  3. SPL/U-Boot stages should follow
  4. USB re-enumeration as Toradex USB download gadget should occur

Since you’re stuck at step 1 with only ROM DFU enumeration, the ROM code cannot find or execute tiboot3.bin from the eMMC boot partitions(1).

Root Cause Analysis

Your conclusion is accurate - the eMMC boot0/boot1 regions are likely:

  • Completely erased during the SD-to-eMMC copy operation
  • Corrupted with invalid boot signatures
  • Missing critical boot components (tiboot3.bin, certificates, etc.)

The ROM code requires properly signed and formatted boot images in the eMMC boot partitions to proceed beyond the initial DFU stage(2).

Recovery Limitations

Unfortunately, your module is in a state where:

  • Standard recovery procedures cannot work because they depend on U-Boot being accessible
  • SD card boot is disabled because the ROM code prioritizes eMMC boot partitions
  • Easy Installer cannot load as it requires the boot chain to reach U-Boot stage(1)

Recovery Options

Given the severity of this boot failure, you have limited options:

  1. Professional Recovery Service: This typically requires specialized equipment to directly program the eMMC boot partitions
  2. Factory Reprogramming: As you mentioned, this would restore the original boot partition structure
  3. Hardware-level eMMC Recovery: Using dedicated eMMC programming tools (if accessible)

Prevention for Future

To prevent this issue:

  • Always use Toradex Easy Installer for eMMC programming rather than direct dd operations(1)
  • Ensure proper backup of boot partitions before any low-level eMMC operations
  • Use recovery mode procedures as documented for safe image deployment(1)

Recommendation

Since this appears to be a case where the boot partitions were inadvertently erased during the SD-to-eMMC copy operation, and standard recovery methods are not viable, I recommend contacting Toradex technical support for guidance on:

  • Professional recovery services
  • Potential RMA if the module is under warranty
  • Hardware-level recovery procedures

Your analysis is technically sound - the module requires factory-level reprogramming to restore the critical boot partition structure.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hi @ToradexAI ,

Is there any possible way to load tiboot3.bin, SPL, or U-Boot from another boot medium (such as SD card, USB, or UART) instead of eMMC, when the eMMC boot partitions are erased or corrupted on Verdin AM62?

Or does the AM62 ROM strictly require valid boot data in the eMMC boot0/boot1 partitions before it can fall back to other boot sources?

Thank you.

I cannot find specific information about AM62 boot source fallback behavior in the available Toradex documentation. The sources I have access to primarily cover iMX6 modules and their eMMC boot configurations(1), but don’t provide detailed boot source priority information for the AM62 platform.

However, I can provide some general guidance based on the available information:

Boot Source Behavior

The available documentation shows that for other Toradex modules, boot source selection typically involves hardware configuration and fuse settings(1). For the AM62, the ROM code behavior regarding boot source fallback when eMMC boot partitions are corrupted is not explicitly documented in my sources.

What We Know from Similar Cases

From the community discussions, there have been cases where modules get stuck at the ROM DFU stage when boot partitions are corrupted(2)(3)(4), suggesting limited fallback options once the primary boot path fails.

Recommendation

Since this is a critical technical question about AM62 ROM behavior and boot source priority that could determine whether your module is recoverable, I’d recommend checking these potentially helpful sources:

Would you like me to try to provide a general answer based on my knowledge of embedded systems boot behavior instead?

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.