Questions about flashing a custom image and using UART on the Verdin i.MX8MP

Hello Toradex community,

I have a few questions regarding flashing a custom Yocto image on the Verdin i.MX8MP board and using UART.

  1. Flashing via Toradex Easy Installer: If I flash my custom image using Toradex Easy Installer, created with the meta-toradex-tezi layer, via the SD card, will this remove the Toradex Easy Installer already present on the board, or will it remain intact?

  2. Booting from the SD card: If the Toradex Easy Installer is removed, is it possible to boot directly from the SD card to avoid writing to the onboard flash and thus preserve it during development?

  3. Using UART: To access the Linux terminal on the Verdin board, I am using a USB-to-UART converter connected to GND, TX, and RX. Are these pins correct if I connect them to the UART1 header (UART_1_RX, UART_1_TX) to see the terminal? Do I need to enable UART in my Yocto project?

My concern is that if I flash my Yocto-built image, I might not see anything on the serial screen, and I wouldn’t know if the issue comes from the UART setup or the custom image failing to boot.

Here is the content of the uncompressed image Verdin-iMX8MP_Reference-Minimal-Image-Tezi_7.5.0-devel-20251106093402+build.0.tar that I plan to flash onto my SD card:

ī˜‹  image.json
ļ…›  Reference-Minimal-Image-imx8mp-verdin.bootfs.tar.xz
ļ…›  u-boot-initial-env-sd
ļ…›  imx-boot
ļ…›  Reference-Minimal-Image-imx8mp-verdin.tar.xz

If you notice anything that might cause a problem, I would appreciate a warning.

I’m a beginner in this field, so apologies if some of my questions seem trivial.

Thank you very much for your help!

Hi, I’m the Toradex AI Assistant.

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


Flashing Custom Yocto Image and UART Setup on Verdin i.MX8MP

Let me address each of your questions based on the Toradex documentation:

1. Toradex Easy Installer Behavior After Flashing

When you flash your custom image using Toradex Easy Installer, the installer itself will be overwritten and removed from the internal flash (1). The Toradex Easy Installer runs completely in memory so that the complete internal flash can be erased, (re-)partitioned, formatted, or written to (2). After installation is complete, your custom image will be the only thing on the internal flash.

2. Booting from SD Card

Unfortunately, the Verdin i.MX8MP cannot boot directly from an SD card with a full OS image. The boot process requires specific bootloader components to be present in the internal flash. If you need to reinstall Toradex Easy Installer after flashing your custom image, you would need to:

  1. Download a new Toradex Easy Installer image (2)
  2. Enter Recovery Mode (2)
  3. Load the Toradex Easy Installer to the internal flash (2)

3. UART Configuration for Terminal Access

For accessing the Linux terminal on the Verdin board, you need to connect to UART_3, not UART_1 (3). According to the documentation:

  • UART_3 (/dev/verdin-uart3) is the debug console for the main OS (Cortex-A) (3)
  • UART_1 (/dev/verdin-uart1) is a general-purpose UART (3)

The UART interfaces are enabled by default in the Toradex BSP, so you shouldn’t need additional configuration in your Yocto project for basic terminal access (3).

4. Your Image Contents Analysis

Your image contents look correct for a Toradex Easy Installer compatible image:

image.json                                          # Configuration file
Reference-Minimal-Image-imx8mp-verdin.bootfs.tar.xz # Boot partition
u-boot-initial-env-sd                              # U-Boot environment
imx-boot                                           # Boot container
Reference-Minimal-Image-imx8mp-verdin.tar.xz      # Root filesystem

This matches the expected structure described in the documentation (1).

Recommendations

  1. Connect to UART_3 instead of UART_1 for terminal access
  2. Test with a pre-built image first to verify your UART setup works before flashing your custom image
  3. Keep a backup plan - know how to reload Toradex Easy Installer if needed

Your approach is sound for development. The main correction needed is using UART_3 for the debug console connection.

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,

Thanks for the detailed answer! It’s really helpful and clears up most of my doubts.

I just want to clarify one point: does this mean that if I rebuild a new custom image and want to flash it again on the board, I would need to first restore the Toradex Easy Installer on the board and then use it from the SD card to install my new custom image?

Also, for development purposes, isn’t there a faster way to update the board without going through the full reinstall process each time?

Thanks again for your help!

Flashing Updates and Development Workflow

Great follow-up questions! Let me clarify the development workflow for you.

Re-flashing Custom Images

Yes, you’re correct - if you want to flash a new custom image after already having one installed, you would need to restore Toradex Easy Installer first (1). The process would be:

  1. Load Toradex Easy Installer into RAM via Recovery Mode (1)
  2. Flash your new custom image using the Easy Installer from SD card (1)

This is because once your custom image is installed, the Easy Installer is no longer present on the internal flash (1).

Faster Development Approaches

For development purposes, there are indeed faster alternatives to avoid the full reinstall process each time:

1. Network-Based Updates

You can set up an HTTP server to serve your images over Ethernet (2). This allows you to:

  • Host your Tezi-compatible images on a local server
  • Flash directly over the network without SD card swapping
  • Note: The server must be running before powering on the board with Easy Installer (2)

2. Incremental Development with Yocto

For active development, consider:

  • Building only specific components instead of full images (3)
  • Using the Yocto build system to create incremental updates (4)
  • Leveraging the modular nature of Yocto layers for faster rebuilds (4)

3. Development vs Production Workflow

The documentation suggests that for development, you might want to:

  • Keep Easy Installer readily available for quick reflashing (1)
  • Use the comprehensive build guides to optimize your build process (3)
  • Consider the Reference Images as starting points for customization (5)

Recommendation for Development

For your development workflow, I’d suggest:

  1. Keep a Toradex Easy Installer image handy for quick recovery
  2. Set up a local HTTP server for network-based flashing to speed up iterations (2)
  3. Use incremental Yocto builds when possible to reduce build times (4)

This approach will significantly reduce the time between iterations during your development process.

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 tried flashing one of the minimal images provided in the Toradex Easy Installer. When booting, I saw garbled or unreadable characters on UART3, with only a few readable parts like this:

��	�
�[@0 @��        v �|�@F������@ko��@XAX �`4     0� a�Y
                                          
                                          X`r��� @�X0�
                                                      X B�	=�@	�␦@ �(X�
                                                                                G�x������ $0^@�
                                                                                              =�����	X
p                                                                                                        ���

However, I could see through the HDMI output that the image was working fine.

Then I tested flashing my own custom Yocto image using the Toradex Easy Installer. On UART3, I got the same kind of unreadable output (again with a few readable parts), but this time there was no HDMI output at all.

I’m not sure if HDMI output needs to be explicitly enabled in Yocto, but since I can’t see anything on either UART or HDMI, I currently have no way to confirm whether my custom image actually booted or not.

How can I verify if my image is working properly or if it’s failing to boot?

Thank you for your help!

UART Configuration and Boot Diagnostics

The issues you’re experiencing suggest both UART configuration problems and potential boot failures. Let me help you diagnose both.

1. UART Serial Configuration Issues

The garbled characters indicate a baud rate mismatch between your terminal and the board. The standard console serial parameters for Toradex boards are (1):

  • Baud Rate: 115200
  • Parity: none
  • Bits: 8
  • Stop bits: 1
  • Flow control: none

Double-check that your terminal software (PuTTY, minicom, etc.) is configured with these exact parameters (1).

2. Verifying UART Connection

For the Verdin Development Board, you should connect a USB-C to USB Type-A cable to connector X66 (1). The board has an integrated Serial-to-USB converter that lists 4 serial ports on your computer. The highest index is the Linux serial console (1). For example, if you see /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2 and /dev/ttyUSB3 listed, then /dev/ttyUSB3 is the serial console (1).

Warning: If you connect to the first or second port (for example /dev/ttyUSB0 or /dev/ttyUSB1), you will not be able to use the board. This happens because those ports are dedicated to power/reset control and FTDI JTAG (1).

3. Diagnosing Boot Issues

Since your custom image shows no HDMI output while the pre-built image works, this suggests your custom Yocto build may have boot problems. Here’s how to diagnose:

Check Build Configuration

Ensure your local.conf file has the correct machine setting (2):

MACHINE ?= "verdin-imx8mp"

(2)

For NXP-based SoMs, you must also accept the EULA (2):

ACCEPT_FSL_EULA = "1"

(2)

Verify Image Contents

Your Tezi image structure looks correct, but ensure all components built successfully. The build process should generate (2):

  • Boot partition (Reference-Minimal-Image-imx8mp-verdin.bootfs.tar.xz)
  • Root filesystem (Reference-Minimal-Image-imx8mp-verdin.tar.xz)
  • Boot container (imx-boot)
  • Configuration (image.json)

4. Troubleshooting Steps

  1. Fix UART First: Ensure you’re using the correct serial port (highest index) with 115200 baud rate
  2. Check Build Logs: Review bitbake build logs for any errors during compilation (2)
  3. Test with Known Good Image: Verify your UART setup works with a pre-built Toradex image
  4. Incremental Testing: Start with the minimal reference image recipe and add customizations gradually

5. Alternative Verification Methods

If UART remains problematic, you can:

  • Check if the device appears on your network (if Ethernet is connected)
  • Use the Toradex Easy Installer’s web interface for diagnostics
  • Monitor power consumption patterns to detect if the system is actually booting

The fact that you can see some readable characters suggests the connection is partially working but with wrong baud rate settings. Fix the UART configuration first, then you’ll have proper visibility into whether your custom image boots successfully.

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.

Thanks again for your previous help @ToradexAI !

I managed to get serial output working by connecting through the USB Type-C port — it now shows proper logs from the boot process.

However, when booting my custom Yocto image, I’m getting the following output:

U-Boot SPL 2024.07-7.5.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)
DDR configured as dual rank
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x4802f000, size 1068
Need continue download 1024
NOTICE:  Do not release JR0 to NS as it can be used by HAB
NOTICE:  BL31: v2.10.0	(release):lf-6.6.52-2.2.1-dirty
NOTICE:  BL31: Built : 06:40:36, Jul  7 2025

U-Boot 2024.07-7.5.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)

CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 57C
Reset cause: POR
DRAM:  8 GiB
Core:  177 devices, 31 uclasses, devicetree: separate
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... Reading from MMC(2)... OK
In:    serial@30880000
Out:   serial@30880000
Err:   serial@30880000
Model: Toradex 0070 Verdin iMX8M Plus Quad 8GB WB IT V1.1A
Serial#: 08626446
Carrier: Toradex Verdin Development Board V1.1F, Serial# 11490742
SEC0:  RNG instantiated
Setting variant to wifi
Net:   eth1: ethernet@30be0000, eth0: ethernet@30bf0000 [PRIME]
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
No EFI system partition
Failed to persist EFI variables
bad MBR sector signature 0x8052
Loading Boot0000 'mmc 2' failed
Loading Boot0001 'mmc 1' failed
EFI boot manager: Cannot load any image
switch to partitions #0, OK
mmc2(part 0) is current device
Scanning mmc 2:1...
Found U-Boot script /boot.scr
1841 bytes read in 2 ms (898.4 KiB/s)
## Executing script at 50280000
118 bytes read in 2 ms (57.6 KiB/s)
Failed to load '/tezi.itb'
Bootargs: quiet video=HDMI-A-1:1280x720-16@60D video=HDMI-A-2:1280x720-16@60D initcall_blacklist=vpu_driver_init rootfstype=cpio.gz root=/dev/ram autoinstall
Wrong Image Type for bootm command
ERROR -91: can't get kernel image!
SCRIPT FAILED: continuing...
...
Verdin iMX8MP #

It seems like the system can’t find or load the kernel image properly (Wrong Image Type for bootm command).

Do you know what might be causing this issue, or how I can fix it?
Could it be something missing or misconfigured in my Yocto build (for example, the boot script or kernel image format)?

Thank you very much for your help!

Boot Script and Kernel Image Loading Issues

Great progress on getting the UART working! The boot log reveals specific issues with your custom Yocto image’s boot configuration.

1. Boot Script Execution Problem

Your U-Boot is finding and executing the boot script (/boot.scr), but it’s failing to load the kernel image. The error Failed to load '/tezi.itb' indicates that U-Boot is looking for a Toradex Easy Installer FIT image instead of your custom kernel (1).

This suggests your boot script is configured for Easy Installer mode rather than normal boot. The bootargs show autoinstall parameter, which is specific to Toradex Easy Installer (1):

Bootargs: quiet video=HDMI-A-1:1280x720-16@60D video=HDMI-A-2:1280x720-16@60D initcall_blacklist=vpu_driver_init rootfstype=cpio.gz root=/dev/ram autoinstall

2. Image Type Mismatch

The Wrong Image Type for bootm command error indicates that U-Boot found an image file but it’s not in the expected format for the bootm command (2).

3. Troubleshooting Steps

Check Your Boot Configuration

Your Yocto build should generate proper boot files, not Easy Installer boot scripts. Verify that your image.json and boot partition contents are correctly configured for a standard Linux boot, not for Easy Installer (3).

Verify Kernel Image Format

Ensure your Yocto build is generating the correct kernel image format. For i.MX8MP, this should typically be a FIT image containing:

  • Kernel image (Image)
  • Device tree blobs (.dtb files)
  • Any required overlays (2)

Check Boot Script Content

The boot script (boot.scr) in your image should be configured for normal Linux boot, not for Easy Installer. The script should load your kernel and device tree, not look for tezi.itb (1).

4. U-Boot Environment Variables

You can check the current boot configuration by examining U-Boot environment variables. At the U-Boot prompt, try (2):

printenv boot_targets
printenv bootcmd

The boot_targets variable defines the order in which U-Boot probes boot sources, and bootcmd shows the actual boot command being executed (2).

5. Recommended Fix

Since you’re getting the Easy Installer boot behavior, it appears your custom image may still contain Easy Installer components. For a proper custom Yocto image:

  1. Rebuild without Easy Installer components - ensure your Yocto configuration builds a standard Linux image, not a Tezi image (3)
  2. Check your meta-layer configuration - verify you’re not including Easy Installer-specific recipes (3)
  3. Verify boot partition contents - the boot partition should contain your kernel (Image), device trees, and a proper boot script for Linux, not Easy Installer (1)

The root cause appears to be that your custom image is still configured for Easy Installer mode rather than normal Linux boot. You’ll need to rebuild your Yocto image with the correct boot configuration.

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 @stan!

Which carrier board are you using? If you’re working with one of our development boards, there’s a USB-C connector available for serial communication.

Did you follow our Build a Reference Image with Yocto Project/OpenEmbedded article? There you’ll find useful information to guide you through the process.

About flashing an image using Toradex Easy Installer, the following resources may be helpful:

Please feel free to reach out if you have any questions.

Best regards.

Hi Lucas,

Yes, everything is working fine now! I’m indeed using the Verdin Development Board, and the serial communication works perfectly through the USB Type-C connector (X66). I was able to access the console using the following command:

sudo picocom -b 115200 -r -l --flow n /dev/ttyUSBx

Thank you for the helpful resources !

Best regards,
Stanley

1 Like

Was reading through the topic, and was a little confused by some of the AI responses. As far as I am aware booting from an sd card should be possible (In fact, I have used this to run tezi from an sd card, before flashing a new image, but had definitely considered booting from a sd card. Recovery mode is not required.)

There is an article detailing how the boot from external media works.

This seems to go directly against the AI’s claim that you can only boot from flash memory. I am not sure if its refering to something like a secure boot function (I know very little about those) or something else, but the article above matches my experience with the tezi image and other boards I have worked with.

(Small note, there are definite downsides to running from an sd card, but for development and testing different images it can be really nice)

If booting into torizon from an sd card is completely impossible now, it would be nice if the documents were updated.

1 Like

Hi @dTanks!

I’ve tested this feature in the past, and it was working.
I’m not sure what the current status is, but I’ll check and update the documentation if needed.

Best regards.