MCUBOOT-based Flashloader

The MCUBOOT-based Flashloader is a specific implementation of the MCU Bootloader. It is used as a one-time programming aid for manufacturing. Most of the MCUBOOT commands are supported in the Flashloader to enable external Flash programming.
See MCU Flashloader Reference Manual for details.

Related Documents:
AN12238 i.MX RT Flashloader Use Case

Elprotronic Host utilities for NXP

...

The SB file is the NXP binary file format for bootable images. The file consists of sections, a sequence of bootloader commands, and data that assists MCU Bootloader in programming the image to target memory. The image data can also be encrypted in the SB file. The file can be downloaded to the target using the MCU Bootloader receive-sb-file command.

...

i.MX RT bootable image

There are two types of supported boot image:

...

XIP (Execute-In-Place) boot image: This type of boot image is only applicable to Serial NOR devices connected to QuadSPI or FlexSPI interfaces and Parallel NOR devices connected to WEIM or SEMC interface. The boot device memory is identical to the destination memory. ROM can boot this boot image directly.

...

To make the manufacturing process easier, all the commands supported by Flashloader and bootable images can be wrapped into a single SB file. Even if there are any changes in the application, Gangflasher-NXP still uses this SB file to manufacture. The SB file can be updated separately without updating Gangflasher-NXP settings.

i.MX RT bootable image

There are two types of supported boot images:

XIP (Execute-In-Place) boot image: This type of boot image is only applicable to Serial NOR devices connected to QuadSPI or FlexSPI interfaces and Parallel NOR devices connected to WEIM or SEMC interface. The boot device memory is different from identical to the destination memory. ROM loads the boot image from the can boot this boot image directly.
Non-XIP boot image: This type of boot image is usually for the NAND, SD, and eMMC devices that does not support the XIP feature. The boot device memory is different from the destination memory. ROM loads the boot image from the Boot device memory to Destination memory and then boots from the Destination memory

...

Some data structures must be included in the bootable image. The bootable image consists of i.MX RT bootable image:

Image Vector Table (IVT): a list of pointers located at a fixed address that ROM examines to determine where the other components of the bootable image are located.
Boot Data: a table that indicates the bootable image location, image size in bytes, and the plugin flag
Device configuration data (DCD) (optional): IC configuration data, usually is used to configure DDR/SDRAM memory. This is optional
User application and data
CSF (optional): signature block for Secure Boot, generated by CST
KeyBlob (optional) – a data structure consists of wrapped DEK for encrypt boot

...

The Flashloader generates the encrypted XIP image using the AES CTR algorithm when programming the image on the device. On execution, the hardware engine does on-the-fly decryption.

...

The above types of bootable images can be generated by using the elftosb utility. The detailed usage of the elftosb utility is available in elftosb User's Guide.

https://www.nxp.com/docs/en/user-guide/MBOOTELFTOSBUG.pdf MBOOTELFTOSBUG elftosb User's Guide

Expand

title	Generate unsigned normal i.MX RT bootable image

Typically, the unsigned bootable image is generated and programmed to the destination memory during the development phase.
The elftosb utility supports unsigned bootable image generation using options, BD file, and ELF/SREC file generated by toolchain.
Taking the Flashloader project as an example, here are the steps to create a bootable image for Flashloader.

Step 1: Create a BD file. For unsigned image creation, the “constants” block is optional, as shown below.

Code Block
options { flags = 0x00; startAddress = 0x200000000x60000000; ivtOffset = 0x400; initialLoadSize = 0x2000; entryPointAddress = 0x60002411; } sources { elfFile = extern(0); } section (0) { }

After the BD file is created, place it into the same folder that holds elftosb utility executable.

Step 2: Copy Flashloader.srec provided in the release package into the same folder that holds elftosb utility executable.

Step 3: Generate the Bootable image using elftosb utility.

Code Block
elftosb.exe -f imx -V -c imx-unsigned.bd -o ivt_flashloader_unsigned.bin flashloader.srec

Then, there are two bootable images generated by elftosb utility. The first one is ivt_flashloader_unsigned.bin. The memory regions from 0 to ivt_offset are filled with padding bytes (all 0x00s).
The second one is ivt_flashloader_nopadding.bin, which starts from ivtdata directly without any padding before ivt.

Expand

title	Generate signed normal i.MX RT bootable image

To generate a signed bootable image using elftosb utility, perform the following steps:

Step 1: Create a BD file. The BD file can be as follows

Code Block

options {
    flags = 0x08;
    startAddress = 0x60000000;
    ivtOffset = 0x1000;
    initialLoadSize = 0x2000;
}
sources {
    elfFile = extern(0);
}
constants {
    SEC_CSF_HEADER              = 20;
    SEC_CSF_INSTALL_SRK         = 21;
    SEC_CSF_INSTALL_CSFK        = 22;
    SEC_CSF_INSTALL_NOCAK       = 23;
    SEC_CSF_AUTHENTICATE_CSF    = 24;
    SEC_CSF_INSTALL_KEY         = 25;
    SEC_CSF_AUTHENTICATE_DATA   = 26;
    SEC_CSF_INSTALL_SECRET_KEY  = 27;
    SEC_CSF_DECRYPT_DATA        = 28;
    SEC_NOP                     = 29;
    SEC_SET_MID                 = 30;
    SEC_SET_ENGINE              = 31;
    SEC_INIT                    = 32;
    SEC_UNLOCK                  = 33;
}
section (SEC_CSF_HEADER; 
    Header_Version="4.2", 
    Header_HashAlgorithm="sha256", 
    Header_Engine="DCP", 
    Header_EngineConfiguration=0, 
    Header_CertificateFormat="x509",
    Header_SignatureFormat="CMS"
    )
{
}
section (SEC_CSF_INSTALL_SRK; 
    InstallSRK_Table="keys/SRK_1_2_3_4_table.bin", // "valid file path"
    InstallSRK_SourceIndex=0 
    )
{
}
section (SEC_CSF_INSTALL_CSFK; 
    InstallCSFK_File="crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem", // "valid file path"
    InstallCSFK_CertificateFormat="x509" // "x509"
     )
{
}
section (SEC_CSF_AUTHENTICATE_CSF)
{
}
section (SEC_CSF_INSTALL_KEY; 
    InstallKey_File="crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem", 
    InstallKey_VerificationIndex=0, // Accepts integer or string 
    InstallKey_TargetIndex=2) // Accepts integer or string 
{
}
section (SEC_CSF_AUTHENTICATE_DATA;
    AuthenticateData_VerificationIndex=2, 
    AuthenticateData_Engine="DCP",
    AuthenticateData_EngineConfiguration=0) 
{
}
section (SEC_SET_ENGINE;
    SetEngine_HashAlgorithm = "sha256", // "sha1", "Sha256", "sha512" 
    SetEngine_Engine = "DCP", // "ANY", "SAHARA", "RTIC", "DCP", "CAAM" and "SW" 
    SetEngine_EngineConfiguration = "0") // "valid engine configuration values"
{
}
section (SEC_UNLOCK;
    Unlock_Engine = "SNVS",
    Unlock_features = "ZMK WRITE" 
    )
{
}

After the blank BD file is created, place it into the same folder that holds elftosb utility executable.

Step 2: Copy Flashloader.srec provided in the release package into the same folder that holds elftosb utility executable.

Step 3: Copy the “cst” executable, “crts” folder, and “keys” folder from “<cst_installation_dir>” to the same folder that holds elftosb utility executable.

Step 4: Generate a bootable image using elftosb utility.

Code Block
elftosb.exe -f imx -V -c imx-signed.bd -o ivt_flashloader_signed.bin flashloader.srec

Then, there are two bootable images generated by elftosb utility. The first one is ivt_flashloader_signed.bin. The memory regions from 0 to ivt_offset is filled with padding bytes (all 0x00s). The second one is ivt_flashloader_signed_nopadding.bin, which starts from ivt_offset directly. The CSF section is generated and appended to the unsigned bootable image successfully.

Generate SB file for bootable image programming

Expand

title	Generate SB file for plaintext FlexSPI NOR image programming

Usually, a BD file for FlexSPI NOR boot consists of 7 parts.

The bootable image file path is provided in the sources block
Code Block
sources { myBinFile = extern(0) }
The FlexSPI NOR Configuration Option block is provided in section block
The example presents setup for Hyperflash 1v8 Query pads: 8, Frequency: 133MHz
Code Block
section(0) { ... load 0xC0233007 > 0x2000; ... }
To enable FlexSPI NOR access, the “enable” command must be provided following the above option block.
Code Block
section(0) { ... enable flexspinor 0x2000; ... }
In case the Flash device is not erased, an “erase” command is required before programming data to the Flash device. The erase operation is time-consuming and is not required for a blank Flash device (factory setting) during Manufacturing.
Code Block
section(0) { ... erase 0x60000000..0x6001000; ... }
The FlexSPI NOR Configuration Block (FNORCB) is required for FlexSPI NOR boot. To program the FNORCB generated by FlexSPI NOR Configuration Option block, a special magic number ‘0xF000000F” must load into RAM first.
ROM configures FlexSPI interface with the parameters provided in configuration block read from Serial NOR flash and starts the boot procedure. Refer to Table 9-18 in Reference Manual for details regarding FlexSPI configuration parameters and to the FlexSPI NOR boot flow chart for a detailed boot flow chart of FlexSPI NOR.
Code Block
section(0) { ... load 0xf000000f > 0x3000; ... }
To notify the Flashloader to program the FNORCB, an “enable” command must be used following the magic number loading.
Code Block
section(0) { ... enable flexspinor 0x3000; ... }
After above operation, Flashloader can program the bootable image binary into Serial NOR Flash through FlexSPI module using load command
Code Block
section(0) { ... load myBinFile > 0x60001000; ... }

Command for secure binary generation:

Code Block
elftosb -f imx -V -c imx-flexspinor-unsigned.bd -o ivt_flexspinor_xip.bin led_demo_evk_flexspi_nor_0x60002000.srec

Expand

title	Generate SB file for FlexSPI NOR Image encryption and programming

Usually, a BD file for FlexSPI NOR image encryption and programming consists of 7 parts.

The bootable image file path is provided in the sources block
Enable FlexSPI NOR access using FlexSPI NOR Configuration Option block
Erase the Flash device if it is not blank. The erase operation is time-consuming and is not required for a blank Flash device (factory setting) during Manufacturing.
Enable image encryption using PRDB option block.
Program FNORCB using a magic number.
Program boot image binary into Serial NOR via FlexSPI module
Enable Encrypted XIP fuse bits.

Version	Old Version 3	New Version Current
Changes made by	Kamil Możdżyński	Kamil Możdżyński
Saved on	Oct 20, 2021	Nov 10, 2021

Content Comparison

Versions Compared

Key

MCUBOOT-based Flashloader

Elprotronic Host utilities for NXP

i.MX RT bootable image

i.MX RT bootable image

Generate SB file for bootable image programming