SOM Verdin IMX8MP keeps resetting / SOM doesn’t boot after “Need continue download 1024”

Technical Support
1

Hello,

We made ourselves a custom carrier board. The project is focused on a in vitro diagnosis machine, with a display, camera, some LED drivers, USBs and a BMS. Other SOMs are working normally, but for any particular reasons, we have two which can’t be considered working.

The SOMs are: Verdin i.MX8MP Q 8GB WB IT, V1.1A, PN1: 15629424, PN2: 15629369

  1. PN1: 15629424

It can boot normally into the main app, or it can reset, and after 8 attempts the module shuts down the 3.3V rail and itself. The behavior is not deterministic.
"
U-Boot SPL 2022.04-6.6.0-devel+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&4802a600, size 888
Need continue download 1024

U-Boot SPL 2022.04-6.6.0-devel+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&4802a600, size 888
Need continue download 1024

U-Boot SPL 2022.04-6.6.0-devel+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&4802a600, size 888
Need continue download 1024

U-Boot SPL 2022.04-6.6.0-devel+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&4802a600, size 888
Need continue download 1024

U-Boot SPL 2022.04-6.6.0-devel+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&4802a600, size 888
Need continue download 1024

U-Boot SPL 2022.04-6.6.0-devel+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&4802a600, size 888
Need continue download 1024

U-Boot SPL 2022.04-6.6.0-devel+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&4802a600, size 888
Need continue download 1024

U-Boot SPL 2022.04-6.6.0-devel+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
"
2) PN2: 15629369

The module shuts doesn’t get past the following message and shuts down after it.
"
U-Boot SPL 2022.04-6.6.0-devel+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&4802a600, size 888
Need continue download 1024
"

Both module work by getting into EasyInstaller. We upload the desired image with an USB stick. The EasyInstaller Version “Verdin-iMX8MP_ToradexEasyInstaller_5.7.6+build.21” works with the USB stick.

I can provide the schematics for the carrier board if you need them, but keep in mind that we normally have working SOMs.

Thank you for your help!

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

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

Boot Issue Analysis for Verdin iMX8M Plus Modules

Based on your description of the boot issues with the two Verdin iMX8M Plus modules, this appears to be related to power management and boot sequence timing. Let me analyze the symptoms and provide potential solutions.

Issue Analysis

The boot logs show that both modules are getting stuck during the U-Boot SPL stage, specifically after “Find img info 0x&4802a600, size 888” and “Need continue download 1024”. This suggests an issue with loading the next boot stage.

Power Management Considerations

According to the Verdin iMX8M Plus datasheet, the power management system includes several control signals that could be affecting boot behavior (1). The power control pins are very flexible and allow different use cases for power supply on the carrier board (1).

Key power management features that may be relevant:

  • CTRL_PWR_BTN_MICO# (pin 248): Power button input signal connected directly to the ONOFF input of the i.MX 8M Plus SoC (1)
  • CTRL_FORCE_OFF_MOCI#: Open-drain output that can kill the main power supply (1)
  • CTRL_PWR_EN_MOCI: Controls peripheral power rails on the carrier board (1)

Potential Root Causes

  1. Power Supply Stability: The intermittent nature of PN1’s behavior suggests potential power supply instability during boot transitions.

  2. Timing Issues: The Verdin Development Board errata mentions timing-related issues that could affect boot reliability (2).

  3. Power Rail Sequencing: Incorrect power rail sequencing during boot could cause the observed shutdown behavior after multiple boot attempts.

Recommended Solutions

1. Power Supply Verification

  • Verify that your custom carrier board provides stable power within the specifications outlined in the datasheet (1)
  • Check the power rail sequencing matches the recommended power supply use cases (1)

2. Reset Circuit Analysis

  • Review your reset circuit implementation, particularly the CTRL_RESET_MICO# signal (pin 260) which is connected to the PWRON_B input of the PMIC (1)
  • Ensure proper pull-up resistors are implemented as specified

3. Power Button Circuit

Since the modules work with Toradex Easy Installer, verify your power button implementation follows the specifications where a short press (<5s) starts the power up sequence, and a long press (>5s) initiates the power down sequence (1).

4. Peripheral Power Control

Check if any peripheral power rails controlled by GPIO signals might be interfering with boot:

  • GPIO3.IO[25]: Wi-Fi and Bluetooth Module power
  • GPIO2.IO[20]: Ethernet PHY power
  • GPIO2.IO[19]: PCIe Reference Clock Oscillator power (1)

Next Steps

  1. Schematic Review: Please share your carrier board schematics focusing on the power management section
  2. Power Measurements: Measure the stability of all power rails during boot
  3. Signal Integrity: Check the integrity of critical boot signals, especially around the eMMC interface

The fact that both modules work with Toradex Easy Installer suggests the hardware is functional, but there may be carrier board-specific power or timing issues affecting the normal boot process.

Best regards,
Toradex AI Assistant.

3

Hi @vladurescu!

I noticed that you opened another topic regarding the same issue. To avoid creating unnecessary workload for our support team, I kindly ask you not to open multiple topics for the same matter. I will close the other message, and we’ll continue the support here.

That being said, did you try to reproduce this behavior with one of our carrier boards? In my humble opinion, the first step here is to determine whether this is a software or hardware issue. So, if it is possible, please check if it still happens with our carrier. If that’s not an option, I’ll ask you to test if this issue persists with a reference image (either Torizon or BSP).

Best regards.

4

Hi Lucas,
.
I discovered why it was powering off after reset. It was from the output of LTC2953 meant to be another input to the SOM, tied also to WAKE1 and PWR BUT, but forgotten as an output (QSPI_CS2 by default). Now both board aren’ powering off anymore, but:

  1. PN1: 15629424 keeps resetting and i think it’s normal
  2. PN2: 15629369 doesn’t do anything after the message
    So it’s still the same but it is not powering off.
    I tried also on Dahlia and they give the same messages and act the same.
5

Hi @vladurescu!

Were you able to test it with a reference image? You can install a reference image using TEZI (Toradex Easy Installer).

Best regards.

6

Hi Lucas,

I’ve tested with “Verdin-iMX8MP_Reference-Minimal-Image-Tezi_7.3.0+build.8” and uploaded it using Dahlia carrier board. It worked, the outputs are here:
lob4_def2_dahlia_15629369.log (53.6 KB)
lob4_def2_dahlia_15629424.log (47.7 KB)
Then i put the SOMs on my custom carrier board and they work just like on Dahlia. They don’t show up any message like before. I’ve reset them like 3-4 times and they seem to be fine, they boot normally.

7

Hi @vladurescu!

Since it worked with a reference image on both Dahlia and the custom board, we can assume that this is a software issue, not a hardware problem.

In this regard, which modifications did you make in your image? Probably something that was modified is causing this error during the boot initialization.

Best regards.

8

Hi Lucas,

I will come back with an answer regarding the software modifications.
We didn’t exclude here the possibility that something could be at the limit maybe? What do you think? We also have SOMs that are working without any problem, they are booting normally, but these two have issues with the same software. There may be something in the software that causes this? We have WAKE1 tied together with PWR_BUTTON, but apart from this, power is normal, 5V → 3.3V → 1.8V & 1.2V. RESET is tied to a button as well as RECOVERY.

Thank you!

Vlad

9

Hi @vladurescu!

In my humble opinion, I don’t think this issue is software-related, since there are some modules (of the same model, I suppose) that are working with the very same software installed. Maybe there is a hardware issue with these two modules.

After we analyze the software modifications made to the installed image, we’ll be in a better position to confirm. If it does turn out to be hardware-related, we can then proceed to treat these modules as RMAs.

Best regards.

10

Hello Lucas, and thank you for the assistance so far.
I have done the software on this project, so I can provide some thoughts here.

In general, the software image is based on the tdx-reference-multimedia-image. Our changes involve a couple of general areas, but nothing beneath Linux. However, as I see from the logs, the issue happens even before U-Boot. I do not have details about the boot sequence, but in the successful boot sequence, after U-Boot SPL, there is something resembling the TF-A stages, followed by the U-Boot from the image, followed by the Linux kernel.

I kind of agree with your insight that this should not be software related, since the same software is fine on other instances of the custom carrier board. Perhaps the issue is somehow related to RAM or the flash where it is stored, but the minimal image is too short to touch problematic areas. This would make sense, considering our custom software is based on the multimedia image, and the boot failure seems to happen while the image is loaded.

Perhaps you could check with the multimedia image, @vladurescu?

There is also another fact, which may not be relevant. Does the 7.3.0 from the Verdin-iMX8MP_Reference-Minimal-Image-Tezi_7.3.0+build.8 stand for the version of the Yocto manifest it has been built with? Because our custom image is based on the 6.6.0 version. Perhaps we can find another prebuilt image like the one we have already tried, but based on the older 6.6.0 manifest?

Are there any particular software changes you would need further details on, @lucas_az.tx? If so, please let me know.

11

Hi @nicadan,
I flashed the multimedia image Verdin-iMX8MP_Reference-Multimedia-Image-Tezi_6.8.3+build.17.tar and it works flawlessly on both carrier boards. I tried with the SOM: 15629369

12

Hi @nicadan and @vladurescu!

The 7.3.0 version refers to our BSP image, which is based on the kernel 6.6. We have a page on our developer website, called Release Matrix, dedicated to detailing the versions of the components used in each image.

Regarding the issue, as @vladurescu has tested, it also works on our multimedia, so it might not be a hardware issue, otherwise, the default images would also fail.

That being said, I’ll reach out to our R&D team to check if they have any insights into what could cause this error or how we could debug it.

Best regards.

13

Hi @lucas_az.tx

Are there any news regarding this subject? Can you update us, please!

Thank you,

14

Hi @vladurescu!

Sorry for the delayed answer.

I recommend applying one modification at a time and testing individually to identify which change is causing the issue. As I said before, since our reference images work perfectly, it doesn’t appear to be hardware-related.

I also talked to R&D, but it is hard to debug this error as it occurs very early during the boot process.

Just to confirm, did you build your image using Yocto?

Best regards.

15

Indeed, we build it using Yocto.

After further attempts, using clean builds and multiple versions, I get the same failure using prebuilt images on version 6.6.0, the exact version we use on our Yocto builds. As seen in previous messages, @vladurescu had success in booting prebuilt images, but he was using other versions. So there is an issue with the 6.6.0 version in particular, unrelated to our changes. I have the same failure if I do a clean Yocto build on 6.6.0, without any of the changes on our side.

Alas, I have seen the prebuilt 6.8.3 image booted just fine, so I will try to port our changes on this version. Will come with an update once I have done this.

Regards, Dan