How To Load and Run Firmware on Alternative Cores (NXP)
Introduction
This article describes how to load and run firmware compiled for alternative cores using the MCUXpresso SDK.
This article complies with the Typographic Conventions for Toradex Documentation.
Prerequisites
-
Hardware prerequisites:
- A module with Torizon OS or a Linux BSP image installed
- Access to the U-Boot console
-
Software prerequisites:
- A firmware binary compiled for the alternative core, as described in How To Compile Firmware for Alternative Cores (NXP) article
- This article uses the
hello_worldfirmware binary as an example
- This article uses the
- A firmware binary compiled for the alternative core, as described in How To Compile Firmware for Alternative Cores (NXP) article
Load Firmware From U-Boot
The following procedure describes how to load the compiled firmware on the alternative cores using the ext4load command from the U-Boot terminal.
To be able to connect to U-Boot console and to the alternative core serial console, refer to the tabs below for the pinout and connection details for each module:
After connecting to the USB Debug port, the U-Boot console can be accessed through the ttyUSB3 port and the alternative core serial console can be accessed through the ttyUSB2 port.
After connecting to the USB Debug port, the U-Boot console can be accessed through the ttyUSB3 port and the alternative core serial console can be accessed through the ttyUSB2 port.
After connecting to the USB Debug port, the U-Boot console can be accessed through the ttyUSB3 port and the alternative core serial console can be accessed through the ttyUSB2 port.
After connecting to the USB Debug port, the U-Boot console can be accessed through the ttyUSB0 port. Note that access to the alternative core serial console requires a USB-to-TTL converter for the target module.
The table below shows the pinout for the connection with the Colibri Evaluation Board:
| USB/TTL Signal | Colibri Evaluation Board |
|---|---|
| RX | A40 (SODIMM_144) |
| TX | A41 (SODIMM_146) |
| GND | GND |
For more information, refer to the Colibri Evaluation Board Datasheet.
After connecting to the USB Debug port, the U-Boot console can be accessed through the ttyUSB0 port. Note that access to the alternative core serial console requires a USB-to-TTL converter for the target module.
The table below shows the pinout for the connection with the Apalis Evaluation Board:
| USB/TTL Signal | Apalis Evaluation Board (M4_0) | Apalis Evaluation Board (M4_1) |
|---|---|---|
| RX | A40 (UART1_DTR) | B13 (PWM3) |
| TX | A35 (UART1_DSR) | B12 (PWM4) |
| GND | GND | GND |
For more information, refer to the Apalis Evaluation Board Datasheet.
For Torizon OS, Toradex recommends placing the firmware binary in a directory not managed by OSTree. Refer to OSTree documentation for more information.
-
Copy the firmware binary to the target module using an SD card, USB drive, SCP, or another suitable method.
-
Identify the firmware path from the U-Boot point of view using the
ext4lscommand:> ext4ls mmc 0:1> ext4ls mmc 0:2 -
Set the
load_cmdvariable according to the installed image:> setenv load_cmd "ext4load mmc 0:1"> setenv load_cmd "ext4load mmc 0:2"warningSelect the correct device and partition according to the installed image.
-
Set the firmware binary path.
For example, if the firmware binary is placed under
/varin a Torizon OS image, use:> setenv cm_image "/ostree/deploy/torizon/var/hello_world_cm7.bin" -
Set the Cortex-M4 instruction Tightly-Coupled Memory (TCM) size:
> setenv cm_isize 20000The
cm_isizevalue corresponds to 128 KiB. -
Create the commands used to load the firmware binary into RAM and copy it to the Cortex-M4 TCM address:
> setenv load_cm_image "${load_cmd} ${loadaddr} ${cm_image}"
> setenv cm_boot "run load_cm_image; cp.b ${loadaddr} 0x203c0000 ${cm_isize}; dcache flush; bootaux 0x20000000" -
Save the U-Boot environment:
> saveenv
-
Copy the firmware binary to the target module using an SD card, USB drive, SCP, or another suitable method.
-
Identify the firmware path from the U-Boot point of view using the
ext4lscommand:> ext4ls mmc 2:1> ext4ls mmc 2:2 -
Set the
load_cmdvariable according to the installed image:> setenv load_cmd "ext4load mmc 2:1"> setenv load_cmd "ext4load mmc 2:2"warningSelect the correct device and partition according to the installed image.
-
Set the firmware binary path.
For example, if the firmware binary is placed under
/varin a Torizon OS image, use:> setenv cm_image "/ostree/deploy/torizon/var/hello_world_cm7.bin" -
Set the Cortex-M7 instruction Tightly-Coupled Memory (TCM) size:
> setenv cm_isize 20000The
cm_isizevalue corresponds to 128 KiB. -
Create the commands used to load the firmware binary into RAM and copy it to the Cortex-M7 TCM address:
> setenv load_cm_image "${load_cmd} ${loadaddr} ${cm_image}"
> setenv cm_boot "run load_cm_image; cp.b ${loadaddr} 0x7e0000 ${cm_isize}; dcache flush; mw.w 0x550ff000 0 64; bootaux 0x7e0000" -
Save the U-Boot environment:
> saveenv
-
Copy the firmware binary to the target module using an SD card, USB drive, SCP, or another suitable method.
-
Identify the firmware path from the U-Boot point of view using the
ext4lscommand:> ext4ls mmc 0:1> ext4ls mmc 0:2 -
Set the
load_cmdvariable according to the installed image:> setenv load_cmd "ext4load mmc 0:1"> setenv load_cmd "ext4load mmc 0:2"warningSelect the correct device and partition according to the installed image.
-
Set the firmware binary path.
For example, if the firmware binary is placed under
/varin a Torizon OS image, use:> setenv cm_image "/ostree/deploy/torizon/var/hello_world_cm4.bin" -
Set the Cortex-M4 instruction Tightly-Coupled Memory (TCM) size:
> setenv cm_isize 20000The
cm_isizevalue corresponds to 128 KiB. -
Create the commands used to load the firmware binary into RAM and copy it to the Cortex-M4 TCM address:
> setenv load_cm_image "${load_cmd} ${loadaddr} ${cm_image}"
> setenv cm_boot "run load_cm_image; cp.b ${loadaddr} 0x7e0000 ${cm_isize}; dcache flush; bootaux 0x7e0000" -
Save the U-Boot environment:
> saveenv
-
Copy the firmware binary to the target module using an SD card, USB drive, SCP, or another suitable method.
-
Identify the firmware path from the U-Boot point of view using the
ext4lscommand:> ext4ls mmc 0:1> ext4ls mmc 0:2 -
Set the
load_cmdvariable according to the installed image:> setenv load_cmd "ext4load mmc 0:1"> setenv load_cmd "ext4load mmc 0:2"warningSelect the correct device and partition according to the installed image.
-
Set the firmware binary path.
For example, if the firmware binary is placed under
/varin a Torizon OS image, use:> setenv m4_0_image "/ostree/deploy/torizon/var/hello_world.bin" -
Update the
loadm4image_0alias to load the firmware binary into RAM:> setenv loadm4image_0 "${load_cmd} ${loadaddr} ${m4_0_image}" -
Save the U-Boot environment:
> saveenv
-
Copy the firmware binary to the target module using an SD card, USB drive, SCP, or another suitable method.
-
Identify the firmware path from the U-Boot point of view using the
ext4lscommand:> ext4ls mmc 0:1> ext4ls mmc 0:2 -
Set the
load_cmdvariable according to the installed image:> setenv load_cmd "ext4load mmc 0:1"> setenv load_cmd "ext4load mmc 0:2"warningSelect the correct device and partition according to the installed image.
-
Set the firmware binary path.
For example, if the firmware binary is placed under
/varin a Torizon OS image, use:> setenv m4_0_image "/ostree/deploy/torizon/var/hello_world_m40.bin" -
Update the
loadm4image_0alias to load the firmware binary into RAM:> setenv loadm4image_0 "${load_cmd} ${loadaddr} ${m4_0_image}" -
Save the U-Boot environment:
> saveenv
The steps for loading firmware on the second Cortex-M4 core on Apalis iMX8 module are the same as above, using m4_1_image and loadm4image_1 instead of m4_0_image and loadm4image_0.
Start the Application
Before starting the firmware, connect to the alternative core serial console using another terminal.
To start the application, run the U-Boot command below:
> run cm_boot
> run cm_boot
> run cm_boot
> run m4boot_0
> run m4boot_0
To start the firmware on the second Cortex-M4 core on the Apalis iMX8 module, start the m4boot_1 alias instead of m4boot_0.
After running the preceding command, the firmware is loaded and executed on the alternative core. The output can be seen on the alternative core serial console, as shown below:
hello world.
Run the Firmware Automatically at Boot
Changing bootcmd modifies the boot flow. Validate the commands manually before saving the U-Boot environment.
To run the firmware automatically at boot, add the firmware loading and start commands to the bootcmd U-Boot environment variable. After saving the environment, U-Boot loads and starts the firmware during each boot.
> setenv bootcmd "run cm_boot; ${bootcmd}"
> saveenv
> reset
> setenv bootcmd "run cm_boot; ${bootcmd}"
> saveenv
> reset
> setenv bootcmd "run cm_boot; ${bootcmd}"
> saveenv
> reset
> setenv bootcmd "run m4boot_0; ${bootcmd}"
> saveenv
> reset
> setenv bootcmd "run m4boot_0; ${bootcmd}"
> saveenv
> reset
To run the firmware on the second Cortex-M4 core on Apalis iMX8 module, update the bootcmd variable with the m4boot_1 alias instead of m4boot_0.
Next Steps
Follow the How To Run a Custom Application on the Alternative Core (NXP) article to understand how to create a custom firmware application for the alternative cores.