Chainloading a Custom U-Boot from the Toradex Preinstalled U-Boot (without replacing it)

Hi, I’m the Toradex AI Assistant.

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


U-Boot Chainloading on Verdin iMX8M Plus

I understand your goal to chainload a custom Mender-enabled U-Boot while preserving the factory Toradex U-Boot for recovery purposes. Let me address your questions based on the available documentation.

Binary Format and Build Process

For the Verdin iMX8M Plus, U-Boot uses upstream sources and builds to the imx-boot binary format (1). The specific configuration for your module is verdin-imx8mp_defconfig (1). Since these modules use upstream U-Boot, you can follow the instructions in the U-Boot documentation for building (2).

Boot Script and DistroBoot Integration

The Toradex U-Boot uses DistroBoot (Generic Distro Configuration Concept) which scans for boot configuration files including boot.scr (3). The boot process follows this sequence based on the boot_targets variable (3):

  • U-Boot scans predefined boot targets looking for standard boot configuration files or U-Boot boot scripts (boot.scr)
  • The boot_targets variable defines the order (e.g., mmc1 mmc2 dhcp for Verdin iMX8M Plus) (3)

Storage Location Recommendations

Based on the DistroBoot behavior, you should place your boot.scr script on the boot partition that U-Boot scans. The system uses variables like:

  • devtype and devnum set automatically while scanning each entry in boot_targets (3)
  • distro_bootpart for the partition number of the boot device (3)

File Loading Commands

The documentation confirms that ext4load works properly in Torizon OS 7 U-Boot on Verdin iMX8M Plus (4). You can use commands like:

ext4load mmc 2:2 ${loadaddr} /path/to/your/binary

(4)

Important Considerations

Hardware Initialization: The iMX8M Plus has complex initialization requirements. The standard boot process involves ATF (ARM Trusted Firmware) before U-Boot (5). Chainloading a complete U-Boot binary may face challenges because:

  1. The hardware is already initialized by the first-stage bootloader
  2. Memory controllers, clocks, and other subsystems are configured
  3. The second U-Boot may attempt to re-initialize already configured hardware

Alternative Approach: Instead of chainloading a complete U-Boot binary, consider customizing the existing Toradex U-Boot through:

  • Device tree modifications for Mender support
  • Environment variable customization for A/B partition logic
  • Custom boot scripts that implement the Mender boot logic

Recommended Approach

Rather than chainloading a complete U-Boot binary, I recommend:

  1. Customize the existing Toradex U-Boot by adding Mender-specific environment variables and boot logic
  2. Use boot scripts to implement A/B partition switching and rollback functionality
  3. Preserve the factory bootloader while extending its functionality through scripts and environment variables

This approach maintains compatibility with TEZI while providing the Mender functionality you need.

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.