Aquila AM69 TEZI Flashing Failed

tjohnson · May 8, 2026, 3:53pm

Hello Support Team,

I am working on bringing up a custom carrier board based on the Aquila AM69. We were troubleshooting some issues with the SD card reader, but managed to get it working. We confirmed that we were able to transfer large files (~600MB) to/from the SOM on our carrier without issue.

I tried flashing a new image using TEZI, and when doing so the transfer speed was incredibly slow (<1MBps) and ultimately failed. I repeated this multiple times without success. Now the system does not boot. It seems that the system flash was erased (as warned by the TEZI GUI).

I had a console window up while the flashing process was going on. I saw some errors related to data interrupts that I don’t understand.

I could use some help trying to understand what has happened here, and how to recover. I’ve added some screenshots of the errors I saw. Any help would be appreciated. Thanks!

Current boot output

Errors in console during flashing

TEZI error

ToradexAI · May 8, 2026, 3:54pm

Hi, I’m the Toradex AI Assistant.

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

I understand you’re experiencing issues with TEZI flashing on your Aquila AM69 custom carrier board. Based on the symptoms you’ve described - slow transfer speeds, failed flashing, and subsequent boot failures - this appears to be related to eMMC communication issues during the flashing process.

Recovery Process for Aquila AM69

Since your system is no longer booting, you’ll need to use recovery mode to restore functionality. The Aquila AM69 uses a specific recovery process that involves DFU (Device Firmware Update) utilities(1).

For the Aquila AM69 recovery process, you’ll need to:

Enter Recovery Mode: Put the module into recovery mode using the appropriate recovery pin on your custom carrier board
Use Recovery Scripts: The Aquila AM69 has dedicated recovery scripts that handle the multi-stage boot process

The recovery process for Aquila AM69 involves multiple stages with different USB VID/PID combinations:

Boot ROM: 0451:6167
R5 SPL: 1b67:4000
A72 SPL: 1b67:4000

Troubleshooting the eMMC Issues

The slow transfer speeds (<1MBps) and data interrupt errors you observed suggest potential issues with:

eMMC Signal Integrity: Check your custom carrier board’s eMMC interface design
Power Supply Stability: Ensure clean, stable power during flashing operations
Clock Configuration: Verify eMMC clock routing and signal quality

Next Steps

To recover your system and identify the root cause:

Compare with Reference Design: Review the Aquila Development Board design resources to ensure your custom carrier board follows the recommended eMMC interface design(1)
Use Recovery Mode: Follow the recovery procedure to restore a working image
Test with Known Good Image: Try flashing a reference image from the BSP 7 downloads to isolate whether this is a hardware or software issue(2)

Could you provide more details about your setup to help narrow down the issue:

Which specific Aquila AM69 variant are you using (PID8)?
What OS version were you trying to flash?
Have you verified your custom carrier board’s eMMC interface design against the reference schematics?

You can also use the tdx-info command to get detailed system information: Getting Device Information with Tdx-Info | Toradex Developer Center

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.

tjohnson · May 8, 2026, 4:02pm

@ToradexAI

We are using the Aquila AM69 Octa 32GB IT V1.1A
We are flashing a custom Yocto build, based on the 7.5 Scarthgap release
Our SD card design appears to be identical to the latest Aquila development board reference design (v1.3).

ToradexAI · May 8, 2026, 4:02pm

Based on your configuration (Aquila AM69 Octa 32GB IT V1.1A with BSP 7.5), let’s proceed with the recovery process to restore your module.

Recovery Steps for Aquila AM69

Since your module is not booting, you’ll need to use the Aquila-specific recovery procedure(1). The Aquila AM69 uses a multi-stage DFU recovery process that’s different from other Toradex modules.

1. Download Recovery Tools

First, download the appropriate Toradex Easy Installer package for your module from the BSP 7 downloads(2). Look for the Aquila AM69 recovery package that includes the necessary DFU utilities and recovery scripts.

2. Enter Recovery Mode

Put your Aquila AM69 into recovery mode using the recovery pins on your custom carrier board(1). You’ll need to connect via USB OTG to your host computer.

3. Execute Recovery Process

The Aquila AM69 recovery involves multiple stages with different USB device IDs. The recovery process will:

Load the initial bootloader via DFU to the Boot ROM (VID:PID 0451:6167)
Load the R5 SPL (VID:PID 1b67:4000)
Load the A72 SPL (VID:PID 1b67:4000)
Finally load Toradex Easy Installer via fastboot

4. Troubleshooting the eMMC Issues

Given that your SD card interface appears correct but you’re experiencing slow eMMC performance during flashing, consider these factors:

Power Supply Stability: Ensure your custom carrier provides clean, stable power during high-current eMMC operations
Signal Integrity: Even with correct schematic design, layout and routing can affect high-speed eMMC signals
eMMC Health: The slow speeds and errors suggest potential eMMC degradation or initialization issues

5. Recovery Strategy

Use the recovery mode to load a known-good reference image first(1)
Test with a standard BSP 7.5 reference image before your custom Yocto build
If the reference image flashes successfully at normal speeds, the issue may be with your custom image
If you still see slow speeds with the reference image, this points to a hardware issue

Alternative Recovery Method

If the standard USB recovery fails, you may need to use external media recovery by preparing an SD card with the Toradex Easy Installer and booting from it instead of the corrupted eMMC(3).

Can you confirm:

Do you have the recovery pins accessible on your custom carrier board?
Are you able to see the Aquila AM69 enumerate as a USB device when in recovery mode?

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.

tjohnson · May 8, 2026, 4:26pm

@ToradexAI I can try to load a reference image. However, given that the flashing process completely failed, I’m not sure that this will be successful. Is there a procedure to recover the system in a more manual way than using TEZI, for example, using the u-boot console? Currently the u-boot console is all I have access to when booting the system.

I will make some measurements on the SD card power supplies.

ToradexAI · May 8, 2026, 4:27pm

Yes, if you have access to U-Boot console, you can manually recover the system. The Aquila AM69 has specific U-Boot commands for loading and starting remote processors, which is particularly important for this SoC(4).

Manual Recovery via U-Boot

Since you have U-Boot console access, you can manually load images and configure the system. Here's the approach:

1. Load Images via TFTP or USB

You can use U-Boot's network or USB capabilities to load images directly into memory and flash them manually:

TFTP: Set up a TFTP server and load images over Ethernet
USB: Use usb start and fatload usb commands to load from USB storage
SD Card: Use mmc commands to load from SD card if available

2. Configure Remote Processors

The Aquila AM69 requires specific remote processor initialization. You can configure this in U-Boot environment(4):

> env set init_rproc 'rproc init;rproc list;'
> env set init_r5f0_0 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-main-r5f0_0-fw;rproc load 2 0x90000000 0x${filesize};rproc start 2;'
> env set init_r5f0_1 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-main-r5f0_1-fw;rproc load 3 0x90000000 0x${filesize};rproc start 3;'
> env set init_r5f1_0 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-main-r5f1_0-fw;rproc load 4 0x90000000 0x${filesize};rproc start 4;'
> env set init_r5f1_1 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-main-r5f1_1-fw;rproc load 5 0x90000000 0x${filesize};rproc start 5;'
> env set init_r5f2_0 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-main-r5f2_0-fw;rproc load 6 0x90000000 0x${filesize};rproc start 6;'
> env set init_r5f2_1 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-main-r5f2_1-fw;rproc load 7 0x90000000 0x${filesize};rproc start 7;'
> env set init_c71_0 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-c71_0-fw;rproc load 8 0x90000000 0x${filesize};rproc start 8;'
> env set init_c71_1 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-c71_1-fw;rproc load 9 0x90000000 0x${filesize};rproc start 9;'
> env set init_c71_2 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-c71_2-fw;rproc load 10 0x90000000 0x${filesize};rproc start 10;'
> env set init_c71_3 'load mmc 0:2 0x90000000 /lib/firmware/j784s4-c71_3-fw;rproc load 11 0x90000000 0x${filesize};rproc start 11;'
> env set boot_rproc 'run init_rproc;run init_r5f0_0;run init_r5f0_1;run init_r5f1_0;run init_r5f1_1;run init_r5f2_0;run init_r5f2_1;run init_c71_0;run init_c71_1;run init_c71_2;run init_c71_3;'
> env set bootcmd 'run boot_rproc; bootflow scan -b'
> env save

(4)

3. Manual Flashing Steps

Basic manual recovery process:

Load kernel and rootfs: Use U-Boot commands to load your images into memory
Erase and write eMMC: Use mmc commands to manually write to eMMC partitions
Set boot environment: Configure U-Boot environment variables for proper boot sequence

4. Example Manual Commands

Here are some basic U-Boot commands you can use:

# Check eMMC status mmc list mmc dev 0 Load image from network (example) setenv serverip 192.168.1.100 setenv ipaddr 192.168.1.10 tftp 0x90000000 your-image.wic Write to eMMC (be very careful with addresses!)

mmc write 0x90000000 0x0 0x10000

5. Power Supply Investigation

Good idea to check the power supplies. For the Aquila AM69, pay particular attention to:

Core voltages during high-current eMMC operations
IO voltage stability for the eMMC interface
Ripple and transient response during write operations

6. Debugging Tips

From U-Boot console, you can also:

Check eMMC health with mmc info
Test eMMC read/write speeds with small test operations
Verify remote processor firmware loading

To verify remote cores initialized correctly after recovery, you can check with(4):

# dmesg | grep -E "remoteproc|rpmsg|c7x|r5f|mcu"

(4)

Would you like me to provide more specific U-Boot commands for your recovery scenario, or do you need guidance on setting up TFTP/USB loading?

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.

tjohnson · May 8, 2026, 8:01pm

@ToradexAI Yes, please provide more specific u-boot commands for my recovery scenario. Please provide guidance on setting up USB loading.

ToradexAI · May 8, 2026, 8:02pm

USB Loading Setup for Aquila AM69 Recovery

Since you have U-Boot console access, here’s the step-by-step process for USB recovery:

1. Prepare USB Storage Device

Format a USB drive with FAT32 and copy your recovery files:

Your custom Yocto .wic image file
Any individual partition images (kernel, rootfs, etc.)
Device tree files if needed

2. Initialize USB in U-Boot

From your U-Boot console, initialize the USB subsystem(1):

# Reset and start USB subsystem
usb reset

# List detected USB devices
usb info

# Scan for storage devices
usb storage

(1)

3. Load Images from USB

Once USB is initialized, load your image files(1):

# Load your WIC image to memory (adjust filename as needed)
fatload usb 0:1 0x90000000 your-custom-image.wic

# Check file size (important for writing)
echo "Loaded ${filesize} bytes"

# Alternative: Load individual components
fatload usb 0:1 0x82000000 Image
fatload usb 0:1 0x88000000 your-devicetree.dtb
fatload usb 0:1 0x90000000 rootfs.ext4

(1)

4. Prepare eMMC for Writing

Check and prepare your eMMC:

# List available MMC devices
mmc list

# Select eMMC (usually device 0)
mmc dev 0

# Check eMMC info and health
mmc info

# Erase eMMC (be careful - this wipes everything!)
mmc erase 0 0x200000

5. Write Image to eMMC

For a complete WIC image:

# Calculate blocks (filesize is in hex, convert to blocks)
# Each block is 512 bytes, so divide filesize by 0x200
setexpr blocks ${filesize} / 0x200

# Write the complete image
mmc write 0x90000000 0 ${blocks}

6. Alternative: Manual Partition Writing

If you prefer to write individual partitions:

# Write bootloader (adjust addresses for your layout)
mmc write 0x90000000 0x8000 0x1000

# Write kernel to boot partition
mmc write 0x82000000 0x20000 0x8000

# Write rootfs
mmc write 0x90000000 0x100000 0x100000

7. External Media Recovery Alternative

If USB loading fails, you can use the external media approach documented for recovery(1). Prepare your SD card or USB stick with Easy Installer:

$ tree
.
├── boot.scr
├── image.json
├── imx-boot-recoverytezi
├── imx-boot-sd
├── overlays.txt
├── recovery
│ ├── uuu
│ ├── uuu.auto
│ └── uuu.exe
├── recovery-linux.README
├── recovery-linux.sh
├── recovery-windows.bat
├── recovery-windows.README
├── tezi.itb
├── tezi.png
└── wrapup.sh

(1)

Then boot from external media by setting U-Boot to skip eMMC:

# Boot from USB stick
run bootcmd_usb0

# Or boot from SD card
run bootcmd_mmc1

(1)

8. Verify Recovery

After writing, verify the recovery:

# Reset and boot
reset

# Or manually boot to test
mmc dev 0
fatload mmc 0:2 0x82000000 Image
fatload mmc 0:2 0x88000000 your-devicetree.dtb
booti 0x82000000 - 0x88000000

Important Notes:

Memory Addresses: The addresses (0x90000000, 0x82000000) are examples - verify these don’t conflict with your U-Boot memory map
Block Calculations: Always verify your block calculations before writing to eMMC
Backup: If possible, backup critical partitions before overwriting
Power: Ensure stable power during eMMC write operations

Would you like me to provide more specific addresses or commands for any particular step in this recovery 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.

tjohnson · May 8, 2026, 8:20pm

@ToradexAI Please explain how to check addresses against my u-boot memory map.

My yocto wic images are compressed with xz; do these need to be uncompressed first?

ToradexAI · May 8, 2026, 8:21pm

Checking U-Boot Memory Map

To verify safe memory addresses for loading images, you need to check your U-Boot memory layout:

1. Display Memory Information

From your U-Boot console, run these commands:

# Show memory banks and layout
bdinfo

# Display environment variables that show memory regions
printenv

# Check specific memory-related variables
printenv loadaddr
printenv fdt_addr_r
printenv kernel_addr_r
printenv ramdisk_addr_r

2. Safe Memory Regions

Look for these key variables in your environment:

loadaddr - Default load address for files
kernel_addr_r - Kernel load address
fdt_addr_r - Device tree load address
ramdisk_addr_r - RAM disk load address

3. Avoid Conflicts

Make sure your chosen addresses don’t overlap with:

U-Boot itself (usually at the beginning of RAM)
Stack and heap regions
Reserved memory regions
Other loaded components

For the Aquila AM69, typical safe regions are usually above 0x90000000, but verify with bdinfo first.

Compressed WIC Images

Yes, you must decompress XZ-compressed images first. U-Boot cannot directly write compressed WIC files to eMMC.

Decompression Options:

Option 1: Decompress on Host Before Transfer

# On your host computer
xz -d your-image.wic.xz
# This creates your-image.wic

Option 2: Check U-Boot Compression Support
Some U-Boot builds support decompression, but this varies by configuration:

# Check if unxz command exists in U-Boot
help unxz

If available, you could:

# Load compressed file
fatload usb 0:1 0x90000000 your-image.wic.xz
# Decompress in memory (if supported)
unxz 0x90000000 0xA0000000

Recommended Approach:

For reliability, decompress on your host computer first, then transfer the uncompressed .wic file to your USB drive. This ensures:

Predictable file sizes for block calculations
No dependency on U-Boot compression support
Faster recovery process

File Size Considerations:

After decompression, check your available RAM. Large WIC images might not fit entirely in memory. In that case, you may need to:

Use smaller chunk sizes and write in segments
Extract individual partitions from the WIC file instead
Use the external media recovery method with Easy Installer(1)

Would you like specific guidance on segmented writing for large images, or help with extracting individual partitions from your WIC file?

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.

tjohnson · May 8, 2026, 8:44pm

@ToradexAI I would like to try the external media recovery alternative. This would allow me to use USB (which seems to be working fine) rather than the SD card.

I have prepared my USB stick by extracting the TEZI loader into the top directory, as well as untarring a TEZI image into the USB stick. I have connected the USB stick and entered the u-boot prompt as suggested here: Loading Toradex Easy Installer | Toradex Developer Center

However, when trying to boot from the usb using run bootcmd_usb0, the command is not defined.

What are the commands that I should run to boot TEZI from the USB?

ToradexAI · May 8, 2026, 8:45pm

The bootcmd_usb0 command is not defined by default on many Toradex modules, including the Aquila AM69. This is a common issue when trying to boot from USB external media(1).

Manual USB Boot Commands

Since bootcmd_usb0 is not available, you’ll need to manually configure USB booting. Here are the specific commands to boot TEZI from USB(2):

1. Initialize USB and Load TEZI

# Initialize USB subsystem
usb start

# Load the TEZI FIT image from USB
load usb 0:1 ${ramdisk_addr_r} tezi.itb

# Start the boot process
bootm start ${ramdisk_addr_r} && bootm loados && bootm ramdisk && bootm fdt

(2)

2. Alternative Method Using Distro Boot

If your U-Boot supports distro boot, you can try:

# Check available boot targets
printenv boot_targets

# If USB is not in boot_targets, add it temporarily
setenv boot_targets 'usb0 mmc0'

# Run distro boot command
run distro_bootcmd

(3)

3. Manual Boot Script Execution

Since you have the TEZI files on USB, you can also manually execute the boot script(2):

# Load and execute the boot script
load usb 0:1 ${scriptaddr} boot.scr
source ${scriptaddr}

(2)

4. Define bootcmd_usb0 Manually

You can create the missing bootcmd_usb0 command yourself(1):

# Define the USB boot command
setenv bootcmd_usb0 'usb start; load usb 0:1 ${ramdisk_addr_r} tezi.itb; bootm ${ramdisk_addr_r}'

# Save the environment (optional)
saveenv

# Now run the command
run bootcmd_usb0

(1)

5. Check USB Detection First

Before attempting boot, verify your USB stick is detected:

# Initialize and check USB devices
usb reset
usb info
usb storage

# List files on USB to confirm TEZI files are accessible
fatls usb 0:1

6. Verify TEZI Files Structure

Make sure your USB stick has the correct structure from the TEZI package(2):

boot.scr - Boot script
tezi.itb - TEZI FIT image
image.json - Image configuration
Your TEZI image directory

Troubleshooting Tips

If the above commands don’t work:

Check memory addresses: Use printenv to verify ramdisk_addr_r and scriptaddr are defined
Verify USB partition: Ensure your USB stick is FAT32 formatted and the first partition contains the TEZI files
Try different USB ports: Some carrier boards may have multiple USB interfaces

The external media approach is not officially supported by Toradex, so you may need to adapt the boot script (boot.scr) for your specific module and BSP version(2).

Would you like me to provide guidance on modifying the boot script if the standard commands don’t work?

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.

tjohnson · May 8, 2026, 8:55pm

@ToradexAI When running usb start, u-boot reports that no working USB controllers are found. Is there a way to fix this?

ToradexAI · May 8, 2026, 8:55pm

The “no working USB controllers” error indicates that U-Boot doesn’t have the necessary USB drivers enabled or the USB controllers aren’t properly initialized on your custom carrier board.

Check USB Controller Configuration

First, verify what USB controllers are available and configured:

# Check if USB drivers are compiled into U-Boot
dm tree

# Look for USB-related devices
dm uclass

Potential Issues with Custom Carrier Board

Since you’re using a custom carrier board with the Aquila AM69, the USB configuration may differ from the reference design. The Aquila AM69 has specific USB controller requirements that need proper device tree configuration(1).

USB Controller Initialization

For the Aquila AM69, USB controllers may require specific initialization. Try these commands:

# Check available USB commands
help usb

# Try different USB initialization methods
usb reset
usb stop
usb start

# Check for specific USB controller types
dm uclass usb

Device Tree and Hardware Considerations

The issue might be related to:

Missing USB controller drivers in your U-Boot build
Incorrect pin configuration on your custom carrier board
Power supply issues to the USB controllers
Device tree configuration differences from the reference design

Alternative Recovery Approach

Since USB isn’t working in U-Boot on your custom carrier board, I’d recommend using the recovery mode approach instead(2):

Put the module in recovery mode using the recovery pins on your carrier board
Use the recovery scripts from a host PC via USB OTG connection
Load TEZI directly through the recovery interface

This bypasses the need for USB host functionality in U-Boot and uses the dedicated recovery interface instead.

Check Your Carrier Board Design

Compare your custom carrier board’s USB implementation with the Aquila Development Board reference design. Key areas to verify:

USB power supply routing
USB signal integrity and routing
Pin assignments and alternate functions
Pull-up/pull-down resistors on USB lines

Could you confirm:

Are you able to access the recovery mode pins on your custom carrier board?
Does your carrier board follow the USB design guidelines from the Aquila reference schematics?

The recovery mode approach via USB OTG is the recommended and fully supported method for this situation(2).

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.

tjohnson · May 8, 2026, 9:30pm

@ToradexAI The USB OTG interface is recognized when putting the system into recovery mode. However, after starting the TEZI interface, the OTG interface is no longer recognized, so I can’t load an image from a USB stick. Since the SD card interface is not working, is there another alternative?

ToradexAI · May 8, 2026, 9:31pm

Based on your situation - USB OTG works for recovery but not for TEZI, and SD card interface isn’t working - you have a few alternative approaches for recovery.

Network-Based Recovery

Since TEZI is running, you can use network-based image loading if your carrier board has Ethernet connectivity:

Configure network in TEZI: If your Ethernet interface is working, TEZI can download images directly from a network location
Set up a local web server: Host your image files on a local HTTP server that TEZI can access
Use TFTP: Configure TEZI to pull images via TFTP protocol

Manual Recovery via U-Boot Network Loading

Return to U-Boot and use network loading instead of USB(1):

# Configure network (adjust IPs for your setup)
setenv serverip 192.168.1.100
setenv ipaddr 192.168.1.10

# Load your WIC image via TFTP
tftp 0x90000000 your-image.wic

# Write directly to eMMC
mmc dev 0
setexpr blocks ${filesize} / 0x200
mmc write 0x90000000 0 ${blocks}

Check for Additional USB Interfaces

The Aquila AM69 has multiple USB interfaces(2). Your custom carrier board might have:

USB_1: Primary USB interface
USB_2: Secondary USB interface

Try checking if USB_2 is available and functional in TEZI, as the block diagram shows the Aquila AM69 supports multiple USB controllers(2).

Known Aquila AM69 V1.0 Issues

If you’re using Aquila AM69 V1.0, there are known USB-related errata that might affect your situation(3):

USB_2_EN signal inversion: The USB_2_EN# pin requires additional hardware or software workarounds(3)
Missing series capacitors: USB_2_SS_TX lines lack required 100nF serial capacitors(3)

These issues are fixed in V1.1, but since you mentioned V1.1A, verify your exact hardware revision.

Alternative: Ethernet Recovery

If your custom carrier board has working Ethernet:

Boot TEZI normally via recovery mode
Configure network settings in TEZI interface
Point TEZI to network location containing your images
Flash directly over network

This bypasses both USB and SD card limitations.

Verify Hardware Interfaces

Before proceeding, confirm which interfaces are actually working on your custom carrier board:

Ethernet connectivity and link status
USB interface availability (USB_1 vs USB_2)
Any other storage interfaces (SATA, additional MMC, etc.)

Could you confirm:

Does your custom carrier board have working Ethernet?
Which specific Aquila AM69 revision are you using (V1.0 vs V1.1)?
Are there any other storage or network interfaces available on your carrier board?

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.

tjohnson · May 8, 2026, 9:56pm

@ToradexAI How can I download images “directly” from a network location? I do not currently have easy access to a TFTP or local webserver.

The primary Ethernet interface on my board is working.

I am using the V1.1 revision of the AM69.

There are no other functioning storage or network interfaces on the carrier board right now, other than the primary network interface, and the USB OTG when in recovery mode.

ToradexAI · May 8, 2026, 9:57pm

Good news! Toradex Easy Installer supports downloading images over Ethernet without requiring you to set up your own server infrastructure. TEZI can fetch images directly from HTTP URLs, including from public repositories or cloud storage.

Direct Network Download Options

Option 1: Use TorizonCore Builder Image Server
If you have TorizonCore Builder installed on a machine with network access, you can use its built-in HTTP server(1):

# On your development machine with network connectivity
torizoncore-builder images serve

(1)

This command serves images from your local directory via HTTP, and any TEZI device on the same network can access them(1).

Option 2: Cloud Storage Direct Links
You can upload your image to cloud storage services and use direct HTTP links:

Upload your .tar image file to a cloud service (Google Drive, Dropbox, etc.)
Get a direct download link
Configure TEZI to use that URL

Option 3: Configure TEZI for Network Download
TEZI supports unattended flashing over Ethernet(1). You can configure it to automatically download and install images from a specified URL.

Setting Up Network Download in TEZI

Once TEZI is running with Ethernet connectivity:

Access TEZI interface via the display or VNC over network
Configure network settings if not automatically detected
Add image source pointing to your HTTP URL
Start installation directly from the network source

Manual Network Configuration

If you need to manually configure TEZI for network access, you can modify the configuration files. TEZI can be configured to search for images at specific URLs(1).

Alternative: Simple Python HTTP Server

If you have another machine on your network, you can quickly set up a simple HTTP server:

# On any machine with Python (most Linux/Mac systems)
cd /path/to/your/images
python3 -m http.server 8000

Then point TEZI to http://[machine-ip]:8000/your-image.tar

Unattended Network Flashing

For automated recovery, you can configure unattended flashing over Ethernet by setting up the image with autoinstall property and providing the network location(1).

Since you have working Ethernet and are using Aquila AM69 V1.1 (which doesn’t have the USB issues from V1.0), the network approach should work reliably for your recovery needs.

Would you like specific guidance on configuring TEZI’s network settings, or help with setting up one of these network download methods?

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.

tjohnson · May 8, 2026, 10:04pm

@ToradexAI Is there a way to use the TEZI interface to flash over ethernet without using the GUI for selecting the image? Can this be done from the command line? I do not want to auto install; I would like to be able to select and flash the image using the serial console, if it is possible.

ToradexAI · May 8, 2026, 10:05pm

I don’t have specific documentation about a command-line interface for TEZI image selection and flashing from the serial console. The available sources focus on the GUI interface and automated installation methods.

TEZI Interface Options

Based on the documentation, TEZI primarily operates through:

GUI Interface: The main TEZI interface accessed via display or VNC (1)
Automated Installation: Using the autoinstall property in image.json files (2)
Web-based Image Discovery: TEZI automatically scans for images from network sources (3)

Alternative Approaches

Since you want manual control without the GUI, consider these options:

Option 1: Manual U-Boot Network Loading

Return to U-Boot and manually download/flash via network:

# Configure network
setenv serverip [your-server-ip]
setenv ipaddr [device-ip]

# Download image directly
tftp 0x90000000 your-image.wic

# Flash to eMMC
mmc dev 0
setexpr blocks ${filesize} / 0x200
mmc write 0x90000000 0 ${blocks}

Option 2: TEZI with Remote Access

Access TEZI’s GUI remotely via VNC over Ethernet (1). You can connect to the IP address assigned to your device and control the interface remotely:

$ vncviewer [device-ip]

(1)

Option 3: Configure Image Server

Set up a simple HTTP server and let TEZI discover images automatically, then use the GUI to select which one to install (3).

Limitations

The sources indicate that TEZI is primarily designed as a GUI-based tool (3). Command-line control for image selection and manual flashing appears to be limited to the automated installation features or requires dropping back to U-Boot for manual operations.

For your specific use case of manual image selection without GUI interaction, the U-Boot approach with network loading would provide the most direct command-line control over the flashing 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.