# Processor-specific workflows This chapter takes you through the steps you must take to successfully boot up your device to the required security level. It describes the creation of the bootable image, connecting your device, setting up your boot preferences, and writing the image into the selected boot memory. Common steps are described first, followed by device family-specific content. It is assumed the image is executed on an NXP evaluation board. This chapter addresses image preparation for the following toolchains: - MCUXpresso IDE 11 - Keil MDK 5 μVision - IAR Embedded Workbench 8 - CodeWarrior Development Studio On the following pages you will learn how to: - Get MCUXpresso SDK with an example project for a processor - Open an example project for the processor in the toolchain - Start with the SEC - Prepare asymmetric keys - Build a plain image in the selected toolchain - Build a bootable image by SEC - Connect the NXP evaluation board - Write a bootable image into the processor and \(optionally\) secure the processor and advance the life cycle ## Common steps This section provides common steps of the process. ### Downloading MCUXpresso SDK The MCUXpresso SDK offers open source drivers, middleware, and reference example applications to speed your software development. In this section, you can find information about downloading MCUXpresso SDK as a ZIP package or as a CMSIS pack and how to open an example project from the package. It is recommended to start with **iled\_blinky** example, because it offers a simple check whether the resulting application is working - LED flashes with a 1 sec period. - **Downloading MCUXpresso SDK package for MCUXpresso IDE, VSCode or CodeWarrior Development Studio** 1. Visit [the MCUXpresso page](http://mcuxpresso.nxp.com). 2. Select your board. 3. Build an SDK package for the selected toolchain and download it. **Note:** Starting with MCUXpresso IDE v11.1.0, you can download and install the MCUXpresso SDK package directly in the tool. - **Downloading MCUXpresso SDK CMSIS pack** Alternatively, for the MDK µVision and IAR Embedded Workbench you can download CMSIS packs for the selected processor and board: - Device Family Pack \(DFP\): *NXP.\{processor\}\_DFP.\#.\#.\#.pack* - Board Support Pack \(BSP\): *NXP.EVK-\{processor\}\_BSP.\#.\#.\#.pack* - **Downloading an example project for Keil MDK or IAR Embedded Workbench** For Keil MDK or IAR Embedded Workbench, it is also possible to download a single example project only. Once you have the SDK build available on [MCUXpresso SDK Dashboard](http://mcuxpresso.nxp.com), click the download link and select **Download Standalone Example Project**. This project contains all sources and project files needed for the build. ### Opening example project - **MCUXpresso IDE** 1. Drag-and-drop the downloaded MCUXpresso SDK package into the Installed SDKs view to install the package. 2. Select **File \> New \> Import SDK examples...**. 3. Select your processor and board and on the next page select the iled\_blinky example. - **Keil MDK 5 + Example package** 1. Unpack the SDK package into the selected folder and open *boards\\evkmimxrt10\#\#\\demo\_apps\\led\_blinky\\mdk\\iled\_blinky.uvmpw*. 2. If you have downloaded a single example project only, unzip it into the selected folder and open the workspace file. 3. Go to **Project \> Options \> Output** to ensure the option **Create HEX File** is selected. - **Keil MDK 5 + CMSIS packs** 1. Select **Project \> Manage \> Pack Installer**. 2. In the **Devices** view, select **All Devices \> NXP \> MIMXRT10\#\#**. 3. In the **Packs** view, ensure that the following device-specific packs are installed: *NXP::\{processor\}\#\_DFP* and *NXP::EVK-\{processor\}\_BSP*. 4. Select the BSP pack 5. In the **Examples** view, copy the **iled\_blinky** example project into the selected folder. Go to **Project \> Options \> Output** to ensure the option **Create HEX File** is selected. - **IAR Embedded Workbench + MCUXpresso SDK package** 1. Unpack the SDK package into the selected folder and open *boards\\evkmimxrt10\#\#\\demo\_apps\\led\_blinky\\iar\\iled\_blinky.eww*. 2. If you have downloaded a single example project only, unzip it into the selected folder and open the workspace file. - **CodeWarrior Development Studio** 1. Unpack the SDK package into the selected folder and **import project** in the **Commander** pane. 2. If the MCUXpresso Config Tools was used to create a project template, import this project template as described in point 1. - **MCUXpresso for Visual Studio Code** 1. Unpack the SDK package into the selected folder. 2. Use command `> MCUXpresso for VSCode: Import Local/Remote repository`; select local and select the path of the SDK folder. 3. Use command `> MCUXpresso for VSCode: Import Example Application from Installed Repository`; fill all the items and confirm by clicking the **Create** button. ### Building example project Detailed information about project configuration and build is in the processor-specific sections below. For a quick evaluation, there are prebuilt application images from SDK examples for NXP evaluation boards provided in the installation layout. For details, refer to the installation subfolder **sample\_data/targets/\{processor\}/source\_images**. ### Setting up Secure Provisioning Tool 1. Start MCUXpresso Secure Provisioning Tool: - Windows: Double-click the desktop shortcut, or use the Windows Start menu to locate the tool. - MacOS: Click the shortcut in the Dock, or use the Launchpad to locate the tool. - Linux: Click the shortcut in the Launcher, or use the Dash to locate the tool. 2. Create a new workspace by selecting **File \> New Workspace ...** from the **menu bar**. Select the device series and the processor and click **Create**. 3. Connect the device to the host through USB, UART, SPI, or I2C. 4. Confirm that the connection is working by selecting **Target \> Connection ...** from the **menu bar** and clicking the **Test** button. Tweak if necessary. ### Preparing secure keys This section describes the generation of keys necessary for authenticated or encrypted image creation. This operation is done only once and the keys can be used for all use-cases. 1. Select the **PKI management** view. 2. Ensure it does not already contain keys. 3. Click **Generate keys**. 4. In the **Generate keys** dialog, confirm the default settings and click **Generate**. **Note:** The generated keys are located in the **keys/** subfolder and certificates \(if any\) in the **crts/** subfolder. It is recommended to back up generated keys before they are burned into fuses in the processor. ## i.MX 9x device workflow This section describes the i.MX 93 and i.MX 95 device workflow in detail. ### Preparing images for build for i.MX 9x devices In this step, select the target memory where the image\(s\) is to be executed. i.MX 9x devices have the following cores where image\(s\) can be executed: - i.MX 93: - Cortex-M33, boot core - Cortex-A55, boot core - i.MX 95: - Cortex-M33, boot core - Cortex-M7 - Cortex-A55 The following target memories are available for i.MX 9x devices: - Image running in RAM This image can be on an SD card/eMMC, will be copied into RAM and executed from there during the boot. The following RAM types are supported: - internal RAM - SDRAM \(DDR SDRAM\) There are several images required to build the resulting bootable image containing the AHAB container set. - i.MX 93 images: - Primary image container set: - ELE firmware - LPDDR4 firmware files with U-Boot SPL - \[Optional\] Cortex-M33 application - Secondary image container set: - ARM Trusted Firmware \(bl31 binary\) - U-Boot - \[Optional\] TEE binary - i.MX 95 images: - Primary image container set: - ELE firmware - DDR \(LPDDR4 or LPDDR5\) firmware files with the OEI DDR firmware - CM33 OEI TCM - CM33 System manager - U-Boot SPL - \[Optional\] Cortex-M7 application - Secondary image container set: - ARM Trusted Firmware \(bl31 binary\) - U-Boot - TEE binary For the image with Cortex-M7 and Cortex-M33 application, use the MCUXpresso SDK example. There is no need to modify the default configuration. This image is built to run in internal RAM. DDR firmware files and ELE firmware can be downloaded from the Yocto Project: - Example of ELE firmware: [https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-0.1.3-4e6938c.bin](https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-0.1.3-4e6938c.bin) - Example of DDR firmware files: [https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-0.1.3-4e6938c.bin](https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-0.1.3-4e6938c.bin) For details regarding the latest packages, see *i.MX Linux Release Notes* (document [RN00210](https://www.nxp.com/doc/IMX_LINUX_RELEASE_NOTES)). The rest of the images are built from source code. Use the following repos on [https://github.com/nxp-imx](https://github.com/nxp-imx) - OEI DDR firmware, CM33 OEI TCM: [https://github.com/nxp-imx/imx-oei](https://github.com/nxp-imx/imx-oei) - CM33 System manager: [https://github.com/nxp-imx/imx-sm](https://github.com/nxp-imx/imx-sm) - U-Boot SPL, U-Boot: [https://github.com/nxp-imx/uboot-imx](https://github.com/nxp-imx/uboot-imx), see [Build U-Boot with AHAB secure boot features](#build-u-boot-with-ahab-secure-boot-features) for details. - ARM Trusted Firmware \(bl31 binary\): [https://github.com/nxp-imx/imx-atf](https://github.com/nxp-imx/imx-atf) - TEE binary: [https://github.com/nxp-imx/imx-optee-os](https://github.com/nxp-imx/imx-optee-os) For additional Linux release materials, see [Embedded Linux for i.MX Applications Processors](https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX) For example details, see **main menu \> Help \> SPSDK Online Documentation**: - Examples - AHAB - i.MX 95 AHAB with U-Boot - Examples - AHAB - i.MX 93 signed and encrypted AHAB image. ### Connecting the board for i.MX 9x devices This section contains information about configuring the evaluation board and connecting it to the SEC tool: - IMX95LPD5EVK-19 \(IMX95LPD5BB-19 base board with IMX95LP5CPU-19 CPU board\) - MCIMX93-EVK \(MCIMX93-BB base board with MCIMX93-SOM CPU board\) - MCIMX93-QSB **Table DIP Switches: Boot mode selection for board for Cortex-M33** |Boot mode/ Device|Serial bootloader \(ISP mode\)|eMMC|SD card|FlexSPI NOR| |---------------------|----------------------------------|----|-------|-----------| |IMX95LPD5EVK-19|SW7: 1001|SW7: 1010|SW7: 1101|SW7: 1100 \(N/A\)| |MCIMX93-EVK|SW7: 1101|SW7: 0001|SW7: 0101|SW7: 1011 \(N/A\)| |MCIMX93-QSB|SW7: 1001|SW7: 1010|SW7: 1011|SW7: 1100 \(N/A\)| **Table DIP Switches: Boot mode selection for board for Cortex-A55** |Boot mode/ Device|Serial bootloader \(ISP mode\)|eMMC|SD card|FlexSPI NOR| |---------------------|----------------------------------|----|-------|-----------| |MCIMX93-EVK|SW7: 1100|SW7: 0000|SW7: 0100|SW7: 1010 \(N/A\)| |MCIMX93-QSB|SW7: 0001|SW7: 0010|SW7: 0011|SW7: 0100 \(N/A\)| 1. See **Table DIP Switches: Boot mode selection for board for Cortex-M33** or **Table DIP Switches: Boot mode selection for board for Cortex-A55** in [Connecting the board for i.MX 9x devices](#connecting-the-board-for-i-mx-9x-devices) for instructions on how to set boot mode using DIP switches. 2. Connect to the USB1/USB port with the USB cable to your PC for the download link. 3. Connect to the DBG port with the USB cable to your PC for console output. 4. Power the board to POWER JACK/USB PD and power on the POWER SWITCH. 5. Ensure that the SEC tool is already running with a workspace created for the chosen device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 6. Open the **Connection** dialog and test the board connection. **Booting from SD card** For booting from an SD card, do the following: 1. Insert a micro SDHC card into the board. 2. Select **SD card, SDHC SD-card 64 GB** in the **Boot Memory Configuration**. **Booting from eMMC** For booting from an eMMC, do the following: 1. Check that the connected board already contains eMMC 64 GB. 2. Select eMMC: **SDHC eMMC 64 GB** in the **Boot Memory Configuration**. ### Booting images for i.MX 9x devices This section describes the building and writing process of bootable images. #### i.MX 93 bootable image examples - A container set with the Cortex-M33 application. It is written to on-chip RAM by the nxpuuu tool during write and then started from there. ```{eval-rst} .. figure:: _images/images_imx93_for_container_cm33app.png :scale: 40% :align: center **Additional images for Container set with Cortex-M7 application** ``` - A container set with Cortex-A55 U-Boot \(bootloader\). It is written to the eMMC/SD card by the nxpuuu tool during write. During the boot, this bootloader is used to boot the Linux kernel image. ```{eval-rst} .. figure:: _images/images_imx93_for_container_uboot.png :scale: 40% :align: center **Additional images for Container set with Cortex-A55 U-Boot** ``` #### i.MX 95 bootable image examples - A container set with the Cortex-M7 application. It is written to on-chip RAM by the nxpuuu tool during write and then started from there. ```{eval-rst} .. figure:: _images/images_imx95_for_container_cm7app.png :scale: 40% :align: center **Additional images for Container set with Cortex-M7 application** ``` - A container set with Cortex-A55 U-Boot \(bootloader\). It is written to the eMMC/SD card by the nxpuuu tool during write. During the boot, this bootloader is used to boot the Linux kernel image. ```{eval-rst} .. figure:: _images/images_imx95_for_container_uboot.png :scale: 40% :align: center **Additional images for Container set with Cortex-A55 U-Boot** ``` #### Booting/loading unsigned image First, build a bootable image: 1. Select the **Unsigned boot type** in the **Toolbar**. 2. Select **boot device** in the **Toolbar**. 3. Switch to the **Build image** 4. Open the **Additional User/OEM Image** dialog by clicking the **Additional images** button. 5. Configure the images for the image container, see [i.MX 93 bootable image examples](#i-mx-93-bootable-image-examples) or [i.MX 95 bootable image examples](#i-mx-95-bootable-image-examples). Select the prepared images from [Preparing images for build for i.MX 9x devices](#preparing-images-for-build-for-i-mx-9x-devices). - Enable the image in the **Enabled** column. - Select the image entry using **Type** - Select the binary\(s\) in the **Image binary path**. - Select **Container set**, it should be either Primary image or Secondary image. - All other parameters are preset with default values for the selected image entry type. These parameters can be customized. 6. Close the dialog by clicking the **OK** button. 7. Click the **Build image** button to build a bootable image, `flash.bin.` When the bootable image has been successfully built: 1. Make sure that the board is in Serial bootloader \(ISP\) mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. - The nxpuuu tool is used to load the bootable image to the device. 5. If the write operation was successful: - For **eMMC** or **SD card**, switch boot mode \(see **Table DIP Switches: Boot mode selection for board for Cortex-M33** or **Table DIP Switches: Boot mode selection for board for Cortex-A55** in [Connecting the board for i.MX 9x devices](#connecting-the-board-for-i-mx-9x-devices)\) and reset the board. The applications shall run, `hello_world` in Cortex-M7 and/or U-Boot in Cortex-A55. - For **Onchip RAM**, the Cortex-M7/Cortex-M33 application runs after it is written. #### Booting signed image \(bootloader for Cortex-A55\) for i.MX 93 This section describes the building and writing of a signed image, bootloader for Cortex-A55 for i.MX 93. Keys generated in the **PKI management** view are needed in this step. For more information about generating keys, see [Generate keys](./05_user_interface.md#generate-keys). First, build a bootable image \(bootloader for Cortex-A55\): 1. In the **Toolbar** set **Boot type** to **Signed**. 2. Select **boot device** in the **Toolbar**. 3. Switch to the **Build image** 4. Open the **Additional User/OEM Image** dialog and configure the images for the bootloader. See the example configuration **Additional images for Container set with Cortex-A55 U-Boot** in [i.MX 93 bootable image examples](#i-mx-93-bootable-image-examples) and [Build U-Boot with AHAB secure boot features](#build-u-boot-with-ahab-secure-boot-features). 5. For **Authentication key** select any key, for example, *SRK1*. 6. Select the **OEM Open** or **OEM Closed** life cycle. See chapter [Get ELE events with nxpele tool](#get-ele-events-with-nxpele-tool) how to verify the application in the OEM Open life cycle. 7. Click the **Build image** button. 8. Check that the bootable image was built successfully. When the bootable image has been successfully built: 1. Make sure that the board is in Serial bootloader \(ISP\) mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. This will write the built bootloader to the selected boot device. **Note:** To write another prepared bootable image, another bootloader or a complete image with Linux kernel, unselect the checkbox and select your image. The bootloader built on **Build image** is still used during write to write fuses and to update the life cycle with the nxpele tool. 4. Click the **Write image** button. - The nxpuuu tool is used to load the bootloader, with U-Boot, to RAM. - The nxpele tool is used to write fuses and to update life cycle. - The nxpuuu tool is used to load the bootloader/your prepared bootable image to the boot device. 5. In the following window, confirm to write fuses and update the life cycle: - **OK** - Continue writing the image and burning fuses. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/burn_fuses_imx93_signed.png :scale: 80% :align: center **Burn fuses** ``` 6. If the write operation was successful, switch boot mode \(see **Table DIP Switches: Boot mode selection for board for Cortex-A55** in [Connecting the board for i.MX 9x devices](#connecting-the-board-for-i-mx-9x-devices)\) and reset the board. The applications shall run U-Boot/your prepared bootable image in Cortex-A55. #### Write fuses and update life cycle with nxpele over U-Boot The nxpele tool is used during provisioning to write fuses or to update life cycle. It is also used to read fuses in the **OTP Configuration** dialog. The nxpele tool communicates with EdgeLock Enclave over U-Boot, which must be running on the target. In these cases, the bootable image configured in the **Additional User/OEM Image** dialog is used as a bootloader with the U-Boot. The U-Boot must be built with AHAB features, see [Build U-Boot with AHAB secure boot features](#build-u-boot-with-ahab-secure-boot-features) for details. During the device provisioning, the bootloader is loaded to the target and started. #### Build U-Boot with AHAB secure boot features The U-Boot/SPL [https://github.com/nxp-imx/uboot-imx](https://github.com/nxp-imx/uboot-imx) provides extra secure boot features. The features enable the nxpele tool to communicate with EdgeLock Enclave. The support is enabled by setting `CONFIG_AHAB_BOOT=y` in the build. If the nxpele tool over fastboot is used, multiplexing of the console output to fastboot must be enabled by setting `CONFIG_CONSOLE_MUX=y`. #### Get ELE events with nxpele tool The `nxpele get-event` command can retrieve stored events in EdgeLock Enclave. The nxpele tool communicates with ELE over U-Boot, which must be running on the target. Thanks to this, we can, for example, check the container authentication status in the OEM Open life cycle: 1. See [Booting signed image \(bootloader for Cortex-A55\) for i.MX 93](#booting-signed-image-bootloader-for-cortex-a55-for-i-mx-93). In this procedure, keep the life cycle in **OEM Open**. In the OEM Open life cycle, the authentication result is ignored. 2. Connect the DBG port to your PC. 3. Switch to boot mode and reset the board. 4. Check what serial COM port is the U-Boot console output. 5. Close the serial connection session if opened in a terminal. 6. Execute `nxpele get-events` Example when authentication succeeds: ``` C:\nxp\MCUX_Provi_25.03\bin\_internal\tools\spsdk>nxpele -f mimx9352 -p COM21 get-events ELE get events ends successfully. Event count: 0 ``` Example when authentication fails: ``` C:\nxp\MCUX_Provi_25.03\bin\_internal\tools\spsdk>nxpele -f mimx9352 -p COM21 get-events ELE get events ends successfully. Event count: 2 Event[0]: 0x0287FAD6 IPC ID: Application Processor message unit Command: OEM Container authenticate Indication: The key hash verification does not match OTP Status: The request was successful Event[1]: 0x0287FAD6 IPC ID: Application Processor message unit Command: OEM Container authenticate Indication: The key hash verification does not match OTP Status: The request was successful ``` ## KW45xx/K32W1xx/MCXW71xx device workflow This chapter describes workflow for KW45xx/K32W1xx/MCXW71xx processors. ### Preparing source image for KW45xx/K32W1xx/MCXW71xx devices In this step, select the target memory where the image is executed. The following options are available for KW45xx/K32W1xx/MCXW71xx devices: - **Image running from an internal flash** It is the only supported boot memory for the KW45xx/K32W1xx/MCXW71xx device family. The image is executed directly from internal flash memory. There is no need to modify the default configuration, build the MCUXpresso SDK example as it is. ### Connecting the board for KW45xx/K32W1xx/MCXW71xx devices This section contains information about configuring the following evaluation boards and connecting them to SEC: - KW45B41Z-EVK - K32W148-EVK - MCXW71-FRDM It is assumed that the SEC tool is already running with a workspace created for an KW45xx/K32W1xx//MCXW71xx device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). For the KW45B41Z-EVK and K32W148-EVK development boards: 1. Connect the J14 port to your PC with a USB cable. 2. Set the JP25 jumper to enable the SW4 button. 3. Enable the ISP boot mode by holding the SW4 button and reset. 4. In the **Connection** dialog, test the connection to the processor. For the MCXW71-FRDM development board: 1. Connect the J10 port to your PC with a USB cable. 2. Enable the ISP boot mode by holding the SW3 button and reset. 3. In the **Connection** dialog, test the connection to the processor. ### Booting images for KW45xx/K32W1xx/MCXW71xx devices This section describes the building and writing of bootable images. For KW45xx/K32W1xx/MCXW71xx, SEC tool supports XIP images only. #### Booting plain or CRC image Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly. Dual image boot is supported only for secure boot types. First, build a bootable image: 1. Make sure you have selected the **Plain unsigned** or **Plain with CRC** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select an image built in [Preparation of OEM-specific inputs](./07_generic_workflows.md#preparation-of-oem-specific-inputs) as a **Source executable image**. 4. If there is a binary image, set the start address to 0x0. 5. Click the **Build image** button to build a bootable image. The result is a binary bootable image. When the bootable image is built, upload it to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. If the write operation was successful, reset the board. #### Booting signed image This section describes building and writing a signed image. Build a bootable image: 1. Select the **Plain signed** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select an image built in Preparation of OEM-specific inputs (see [Preparation of OEM-specific inputs](./07_generic_workflows.md#preparation-of-oem-specific-inputs)) as a **Source executable image**. 4. Ensure you have the keys on PKI management. Evaluation boards KW45B41Z-EVK, K32W148-EVK, and MCXW71-FRDM are produced with preprogrammed ROKTH and SB3KDK keys in the fuses `CUST_PROD_OEMFW_AUTH_PUK` and `CUST_PROD_OEMFW_ENC_SK`. These keys are also distributed in the SEC tool and can be imported from the tool folder `bin\data\targets\\evk_keys` or `bin\data\targets\\frdm_keys`. See [Import/Export keys](./05_user_interface.md#importexport-keys). These keys are intended for evaluation purposes only and must not be used for production. 5. For **Authentication key** select any key, for example ROT1: IMG1\_1 6. Use an imported value or create your own \(random\) one for **SB3KDK** symmetric key. 7. If needed, open **Dual image boot** and configure. Image must be linked to the **Flash Logical Window.** 8. Keep **Development** in the life cycle. 9. Click the **Build image** button to build a bootable image. The result is an SB3 capsule for installation into the processor. When the bootable image and SB3 capsule have been successfully built, you can upload to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Keep **OEM Open** in the life cycle. 5. Make sure that the IFR fields written in otp\_config\.sb are not burned already. All IFR fields are one time programmable. 6. Click the **Write image** button. **Note:** If IFR fields are written in the otp\_config\.sb, it is not possible to receive otp\_config\.sb multiple times. #### Booting PRINCE encrypted image Encrypted unsigned images, images with CRC or signed images are supported. The process of creating an encrypted image is similar to a signed image. In addition, configure encrypted regions in the **Build image** view. Use the **PRINCE regions** button to configure encrypted regions. In combination with the dual boot, set one region for image0 and one for image1. Setting a region only for image0 does not encrypt image1. Image encryption is performed when the image is written to the target memory. The regions configuration is included into the ROMCFG page. **Note:** Open OTP/IFR configuration to review the PRINCE settings in the ROMCFG block\(s\) as the block must be completely specified and can be written only once. It is an irreversible operation. #### Life cycle for KW45xx/K32W1xx/MCXW71xx devices The default life cycle, which should be used for development, is **OEM Open**. Before you deploy the application, set the **OEM Closed** or **OEM Locked** life cycle \(see documentation for the target processor for detailed description\). **Note:** Change of the life cycle is irreversible. Once the processor is in “OEM Closed” or "OEM Locked" mode, the tool does not allow initializing the ROMCFG page. The application can still be updated via the SB file. **Table Boot type and life cycle for KW45xx/K32W1xx/MCXW71xx** ||**OEM OPEN**|**OEM CLOSED/LOCKED**| |-----|--------------------------|----------------------| |**Plain unsigned or CRC** boot type|- Only user fuses burnt
- SB file not used| - life cycle fuse burnt
- SB file not used| |**Plain signed** boot type|- RKTH and SB3KDK burnt in write script
- user fuses in write script or OTP SB file
- SB file used|- RKTH and SB3KDK burnt in write script
- user fuses in OTP SB file
- SB file used| |**Encrypted** boot type|- RKTH and SB3KDK burnt in write script
- user fuses and IFR in encryption write script or OTP SB file
- SB file used|- RKTH and SB3KDK burnt in write script
- user fuses and IFR encryption in OTP SB file
- SB file used| The table below shows the security assets installed in different life cycles and trust provisioning types: ||Open life cycle, no Trust Provisioning|Closed life cycle, no Trust Provisioning|Open life cycle, EdgeLock 2GO|Closed life cycle, EdgeLock 2GO| |------------------|----------|----------|------------|------------| |**SB3KDK** |Write script|Write script|sb3kdk.asc|sb3kdk.asc| |**RKTH fuses**|Write script|Write script|rkth.bin|rkth.bin | |**Other custom fuses and IFR**|Write script or otp\_config.sb|otp\_config.sb|otp\_config.sb|otp\_config.sb| #### EdgeLock 2GO EdgeLock 2GO is described in [EdgeLock 2GO Trust Provisioning workflow](./07_generic_workflows.md#edgelock-2go-trust-provisioning-workflow). Below are KW45xx/K32W1xx/MCXW71xx specific comments: - The life cycle is set to the life cycle set to the secure objects. The RKTH and SB3KDK fuses are always burned during provisioning, even in the development life cycle. - Address for secure objects must be in internal flash, provisioning firmware erases the area before writing the secure objects. #### Update NBU firmware The NBU firmware is distributed within MCUxpresso SDK as SB3 file or as binary file (*.xip), in folder `middleware\wireless\ble_controller\bin`. There are two options to update the NBU firmware. First, use a prepared SB file with NBU firmware. It can be used for the EVK and FRDM boards with provisioned NXP keys. The other way is to prepare a custom SB file that will load the NBU firmware. **SB file with NXP keys** 1. Create or open a workspace for KW45xx/K32W1xx/MCXW71xx. 2. In the **menu bar**, select **Tools \> Manufacturing Tool**. 3. Select the **Apply SB file** operation. 4. Provide the SB file. 5. Detect a connected device by clicking the **Auto detect** button. 6. Load the SB file by clicking the **Start** button. **Custom SB file** 1. Open a workspace for KW45xx/K32W1xx/MCXW71xx with the custom keys that were provisioned to the device. 2. In the **menu bar**, select **Tools \> SB Editor**. 3. Fill the **Properties** tab or import a setting from the SB file created on the Build tab. 4. Switch to the **Commands** tab. 5. Add two low level SB commands: erase and load. 6. For erase, set the address to 0x48800000 and the size to 0x30000 7. Set the load address to 0x48800000 and provide the firmware image. 8. Configure the output paths. 9. Prepare the final SB file by clicking the **Generate** button. 10. Click the **To Manufacturing tool** button to switch to the manufacturing window with preselected **Apply SB file** operation and preselected SB file. 11. Detect a connected device by clicking the **Auto detect** button. 12. Load the SB file by clicking the **Start** button. ## KW47xx/MCXW727x device workflow This chapter describes the workflow for KW47xx/MCXW727x processors. ### Preparing source image for KW47xx/MCXW727x devices In this step, select the target memory where the image is executed. The following options are available for KW47xx/MCXW727x devices: - **Image running from an internal flash** It is the only supported boot memory for the KW47xx/MCXW727x device family. The image is executed directly from internal flash memory. There is no need to modify the default configuration, build the MCUXpresso SDK example as it is. ### Connecting the board for KW47xx/MCXW727x devices This section contains information about configuring the following evaluation boards and connecting them to SEC: - KW47-EVK It is assumed that the SEC tool is already running with a workspace created for an KW47x. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). For the KW47-EVK development board: 1. Connect the J14 port to your PC with a USB cable. 2. Enable the ISP boot mode by holding the SW4 button and reset. 3. In the **Connection** dialog, test the connection to the processor. ### Booting images for KW47xx/MCXW727x devices This section describes building and writing of bootable images. For KW47xx, the SEC tool supports XIP images only. #### Booting plain image or plain with CRC image Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly. Dual image boot is supported only for secure boot types. First, build a bootable image: 1. Make sure you have selected the **Plain unsigned** or **Plain with CRC** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select an image built in Preparation of OEM-specific inputs (see [Preparation of OEM-specific inputs](./07_generic_workflows.md#preparation-of-oem-specific-inputs)) as a **Source executable image**. 4. If there is a binary image, set the start address to 0x0. 5. Click the **Build image** button to build a bootable image. The result is a binary bootable image. When the bootable image is built, upload it to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. If the write operation was successful, reset the board. #### Life cycle for KW47xx/MCXW727x devices At this moment only the **OEM Open** is supported in the SEC tool for KW47xx/MCXW727x. ## LPC55\(S\)0x/1x/2x/6x device workflow This chapter describes workflow for LPC55\(S\)0x/1x/2x/6x, NHS52S04, and MCXW236 processors. ### Preparing source image for LPC55\(S\)0x/1x/2x/6x devices In this step, you must select the target memory where the image will be executed. The following option is available for LPC55Sxx devices: - **Image running from an internal flash** It is the only supported boot memory for the LPC55Sxx/LPC55xx device family. The image is executed directly from internal flash memory. \(XIP\) #### Image running from internal flash - **MCUXpresso IDE** 1. Build the project. 2. Open the debug folder. 3. Right-click the named .axf file. 4. Select **Binary Utilities** \> **Create binary**. - **IAR** 1. In **Project** \> **Options** \> **Output Converter**, check **Generate additional output** and select **Raw binary** output format. ```{eval-rst} .. figure:: _images/iar.png :scale: 80% :align: center **IAR options** ``` 2. Build the project. You will find the output image built as *boards\\lpc55s\#\#\\demo\_apps\\led\_blinky\\iar\\led\_blinky\\led\_blinky.bin*. - **Keil MDK 5** 1. In **Project** \> **Options** \> **User** \> **After Build/Rebuild**, check the **Run \#1** option. 2. Enter the following in the **User Command** path \(where *myprog* is the project's Name of Executable\): *C:\\Keil\\ARM\\ARMCC\\bin\\fromelf.exe --bin --output=myprog.bin myprog.axf.* 3. Build the image. You will find the output image built as *boards\\lpc55s\#\#\\demo\_apps\\led\_blinky\\mdk\\led\_blinky\\led\_blinky.bin*. ### Connecting the board for LPC55\(S\)0x/1x/2x/6x devices This section contains information about configuring the following LPC5Sxx evaluation boards and connecting them to SEC: - LPCexpresso55S69 - LPCexpresso55S66 - LPCexpresso55S28 - LPCexpresso55S26 - LPCexpresso55S16 - LPCexpresso55S14 - LPCexpresso55S06 - LPCexpresso55S04 - NHS52Sxx-EVK - FRDM-MCXW236B It is assumed that the SEC tool is already running with a workspace created for an LPC device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 1. To communicate via UART, connect USB cable to P6 connector, for USB communication use P9 connector. 2. Enable the ISP boot mode by holding the ISP button and reset. 3. Ensure you have selected the **Unsigned** boot type in the **Toolbar**. 4. In the **Connection** dialog, set the connection to **USB** or **UART** according to the selected port and test the connection to the processor. ### Booting images for LPC55\(S\)0x/1x/2x/6x devices This section describes the building and writing of images. #### Security levels The following security levels are supported in SEC: Unsigned boot types : Default processor configuration that does not provide any security. It is recommended to start with the unsigned boot type to ensure the bootable image works on the processor. Unsigned boot types are intended for development only. Signed or encrypted boot types - unsealed : Unsealed boot types are also designed to be used during development to ensure the selected boot type works well. In the KeyStore, CFPA, and CMPA pages are written into the processor. CMPA page is not sealed and can be updated or erased. Signed or encrypted boot types - sealed : A sealed CMPA page is recommended for production. Select the **Deployment** life cycle in the **Write image** view to seal the CMPA page. Once sealed, it cannot be changed or erased. #### Booting Plain/Plain with CRC image This section describes the building and writing of plain/plain with CRC image. 1. In the **Toolbar**, set **Boot Type** to **Plain unsigned** or **Plain with CRC**. 2. As a **Source executable image**, use the image from [Preparing source image for LPC55(S)0x/1x/2x/6x devices](#preparing-source-image-for-lpc55-s-0x-1x-2x-6x-devices) as a **Source executable image**. 3. In the case of a binary image, set the start address to *0x0*. 4. If needed, open **Dual image boot** and configure. 5. Click the **Build image** button. 6. Check that the bootable image was built successfully. Once the image has been successfully built, do the following: 1. Make sure that the board is in ISP mode. 2. Click the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. If the write operation was successful, reset the board. #### Booting plain signed or PRINCE encrypted image This section describes the building and writing of an authenticated or PRINCE encrypted image. Keys generated in the **PKI management** view are needed in this step. For more information about generating keys, see [Generate keys](./05_user_interface.md#generate-keys). **Note:** The keys are also used for **Encrypted \(PRINCE\) Plain and with CRC** boot type because the bootable image is updated using SB capsule, which must be signed. 1. In the **Toolbar**, set **Boot type** to **Plain signed**, **Encrypted \(PRINCE\) unsigned, Encrypted \(PRINCE\) with CRC**, or **Encrypted \(PRINCE\) signed**. 2. In the **Build image** view, use the image from [Preparing source image for LPC55(S)0x/1x/2x/6x devices](#preparing-source-image-for-lpc55-s-0x-1x-2x-6x-devices) as a source executable image. 3. For **Authentication key**, select any keychain, for example, *ROT1: IMG1\_1\_1*. 4. Open the PRINCE configuration and check the configuration. Set the size of the PRINCE region based on the size of the bootable image. 5. If needed, open **Dual image boot** and configure. For a PRINCE encrypted image, set one region for image0 and one for image1. Setting a region only for image0 does not encrypt image1. 6. Click the **Build image** button. 7. Check that the bootable image was built successfully. To write the image, do the following: 1. Select the **Write image** view. 2. Make sure that the board is connected and the ISP mode is enabled \(See [Connecting the board for LPC55\(S\)0x/1x/2x/6x devices](#connecting-the-board-for-lpc55-s-0x-1x-2x-6x-devices) \) 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. If the write operation was successful, reset the board. Once the image can be successfully executed in the processor, select the **Deployment** life cycle to permanently seal the device security with sha256 signature of the CMPA page. If the option remains unselected the security can be reconfigured. After you select the **Deployment** life cycle, click the **Build image** button in the **Build image** view. Then click the **Write image** button again and confirm the following message box: ```{eval-rst} .. figure:: _images/confirm_write.png :scale: 80% :align: center **Confirm write** ``` If the write operation was successful, reset the board. **Note:** It is necessary to completely erase the entire processor before returning from PRINCE encryption to a non-encrypted image. #### PFR and PUF KeyStore This section provides information about PFR and PUF KeyStore. **PUF KeyStore initialization** SEC initializes KeyStore on LPC55Sxx devices only once in the device life cycle. KeyStore enrollment status for the device is reported in the **Connection** dialog, using the **Test** button. ```{eval-rst} .. figure:: _images/keystore.png :scale: 80% :align: center **KeyStore connection** ``` It is possible to update the keys in the KeyStore, so it should not be needed to re-initialize KeyStore. In case of unexpected troubles, you can try to erase KeyStore, however, it is not recommended. With the KeyStore, it is recommended to also clear the CFPA page, as PRINCE IV fields in CFPA depend on the KeyStore. The device does not boot if you enroll the KeyStore and try to use it with previous IV fields. **How to erase KeyStore \(example for LPC55S69\)** ``` bin/tools/blhost/win/blhost -u 0x1FC9,0x0021 -j -- set-property 29 1 bin/tools/blhost/win/blhost -u 0x1FC9,0x0021 -j -- write-memory 0x9E600 zero_1536.bin ``` *zero\_1536.bin* is a file that contains zeros, and the file size is 3\*512 bytes. **How to update CFPA page \(example for LPC55S69\)** 1. Increment the version in cfpa.json: it is recommended to add at least 0x10 from the last known version as the version is also incremented during PRINCE IV updates. 2. Run the following commands to update the CFPA page into the processor: ``` bin/tools/spsdk/pfr generate -c cfpa.json -o cfpa.bin bin/tools/spsdk/blhost -u 0x1FC9,0x0021 -j -- write-memory 0x0009DE00 cfpa.bin ``` **DCFG\_CC\_SOCU problem on LPC55Sxx** LPC55S0x/1x/2x/6x processors do not support the`DCFG_CC_SOCU` field configured in CFPA, while `DCFG_CC_SOCU` in CMPA is zero \(not configured yet\) and the processor may stop work \(lock\) if the configuration happens. It is recommended to always configure CMPA first and erase CFPA \(+reset\) in case erasing of CMPA is needed. ## LPC55\(S\)3x device workflow ### Preparing source image for LPC55\(S\)3x devices In this step, select the target memory where the image is executed. The following options are available for LPC55\(S\)3x devices: - **Image running from internal FLASH** - XIP \(eXecution In Place\) image, which means that the image is executed directly from the memory where it is located. It is the default option for almost all SDK examples. There is no need to modify the default configuration, build the example as it is. - **Image running from external FLASH** - XIP \(eXecution In Place\) image, which means that the image is executed directly from the memory where it is located. The image must start at address 0x8001000. The other locations are not supported now. There is no need to modify the default configuration. For custom external FLASH, the configuration of external FLASH for booting can be adjusted in CMPA. ### Connecting the board for LPC55\(S\)3x devices This section contains information about configuring the evaluation board LPC55S36-EVK and connecting it to SEC. **Table Boot mode selection for EVK** |Board|In-System Programming \(ISP\) Boot|Boot from internal FLASH|Boot from external FLASH| |-----|----------------------------------|------------------------|------------------------| |**LPC55S36-EVK**|**J43:** 1-2 open 3-4 closed|**J43:** 1-2 closed 3-4 closed|**J43:** 1-2 closed 3-4 open| 1. Select ISP boot mode, see **Table Boot mode selection for EVK** in [Connecting the board for LPC55\(S\)3x devices](#connecting-the-board-for-lpc55-s-3x-devices). 2. Connect the J3 port to your PC with a USB cable. 3. Ensure SEC runs with a workspace created for the chosen device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 4. Make sure that the boot memory in the toolbar matches NOR FLASH used on EVK board \(for example, flex-spi-nor/ISxxxx\) or internal flash. 5. Set the connection to USB and test the board connection. ### Booting images for LPC55\(S\)3x devices This section describes building and writing of bootable images. For LPC55S3x, the SEC tool supports XIP images only. #### Booting plain unsigned or CRC image A plain image is typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly. First, build a bootable image: 1. Make sure you have selected the **Plain unsigned** or **Plain with CRC** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select image built in [Preparing source image for LPC55\(S\)3x devices](#preparing-source-image-for-lpc55-s-3x-devices) as a **Source executable image**. 4. If there is a binary image, set the start address to 0x0 for internal flash, or 0x8001000 for external flash. 5. If needed, open **Dual image boot** and configure. 6. Click the **Build image** button to build a bootable image. The result is a binary bootable image. When the bootable image is built, upload it to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. If the write operation is successful, switch boot mode \(see **Table Boot mode selection for EVK** in [Connecting the board for LPC55\(S\)3x devices](#connecting-the-board-for-lpc55-s-3x-devices)\) and reset the board. #### Booting plain signed image This section describes building and writing a plain signed image. Build a bootable image: 1. Select the **Plain signed** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select image built in [Preparing source image for LPC55\(S\)3x devices](#preparing-source-image-for-lpc55-s-3x-devices) as a **Source executable image**. 4. For **Authentication key** select any key, for example ROT1: IMG1\_1 5. Use random value for “CUST\_MK\_SK” and “OEM seed” symmetric keys. 6. If needed, open **Dual image boot** and configure. 7. Open the PFR configuration and on the CMPA page check, that the bit-field `SEC_BOOT_EN` in the `SECURE_BOOT_CFG` field is configured. It is necessary to select any type of image check. 8. Make sure that the board is connected and the processor is in ISP mode. During building processes, provisioning SB file for installation of `CUST_MK_SK` into processor is prepared. **Note:** The processor is reset after the SB file is built. 9. Keep **Develop** in life cycle 10. Click the **Build image** button to build a bootable image. The result is a binary bootable image and SB3 capsule for installation of the image into the processor. When the bootable image has been successfully built, you can upload to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. #### Booting encrypted image Encrypted images with CRC or signed images are supported. The process of creation an encrypted image is similar to a signed image. In addition, configure encrypted regions in the **Build image** view: - Use the **PRINCE Regions** button to configure encrypted regions for internal FLASH - Use the **IPED Regions** button to configure encrypted regions for external FLASH In both cases, the whole image is encrypted by default. For clock limitations when using encrypted images, see documentation for the target processor. With the dual boot, set one region for image0 and one for image1. Setting a region only for image0 does not encrypt image1. Image encryption is performed when the image is written to the target memory. The encrypted region is configured in the SB file. The decrypted regions are configured in the CMPA page, so make sure these two are aligned. #### Test life cycle To test processor behavior in the advanced life cycle, it is possible to temporarily change the life cycle to some higher level by setting control register PMC-\>LIFECYCLESTATE to the required level. This life-cycle state is valid until HW is reset. Required steps: 1. Prepare the image and generate keys. 2. Set access control in SOCU registers. 3. Build the image 4. Execute write operation. 5. Run the application. 6. Connect a debug probe. 7. On the write tab, click the **Test life cycle** button and in the displayed dialog set the required life cycle state. 8. Click **Apply** to move the processor into the selected life cycle. Now, it is possible to test the processor behavior. ```{eval-rst} .. figure:: _images/Figure90_new.png :scale: 80% :align: center **Lifecycle test** ``` #### Life cycle for LPC55\(S\)3x devices The default life cycle, which should be used for development, is **Develop**. Before you deploy the application, set the “In Field” or “In Field Locked” life cycle \(see documentation for the target processor for detailed description\). **Note:** Change of the life cycle is irreversible. When changing to **In Field** life cycle, CMPA and CFPA pages are installed in the `dev_hsm_provi.sb` file. It is supposed that in this mode, the pages are installed into an empty processor, so there are not any failures \(the page update may fail, so in development mode, these pages are updated in write script, where the progress and error report are much better\). Once the processor is in In Field state, the SEC tool supports only update of the application image; updates of CMPA and CFPA are not supported. ```{eval-rst} .. figure:: _images/Figure90_new.png :scale: 80% :align: center **Lifecycle test** ``` ## LPC865 workflow This section describes the LPC865 device workflow in detail. ### Preparing images for build for LPC865 The processor supports only images executed from internal flash (XIP). Use the default toolchain settings to build the application image. ### Connecting the board for LPC865 This section contains information about configuring the evaluation board LPCXpresso860-MAX and connecting it to the SEC tool. 1. To power the board, connect the J4 USB port with the USB cable to your power adapter or PC. 2. Connect pins 2(RX) and 4(TX) at the J2 connector to the UART converter and connect to your PC. 3. To switch the processor into ISP mode, hold the ISP(SW1) button and press RESET(SW3). 4. Ensure that the SEC tool is already running with a workspace created for the chosen device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 5. Open the **Connection** dialog and test the board connection. Mind the first board synchronization take a longer time. ### Booting images for LPC865 This chapter describes the building and writing of plain bootable image. #### Booting unsigned plain image **Plain unsigned** is the only boot mode supported by this processor. First, build a bootable image: 1. Switch to the **Build image** view. 2. Select an image built in [Preparing source image for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices](#preparing-source-image-for-mc56f818xx-7xx-6xx-and-mwct2xd2-12-devices) as a **Source executable image**. 3. If there is a binary image, set the start address to 0x0. 4. Click the **Build image** button to build a bootable image. During this operation, the following changes are applied to the image: life cycle (=code read protection) and CRC. When the bootable image is built, upload it to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. If the write operation is successful, reset the board. The processor will boot after several seconds. ### Life cycles The processor does not support real life cycles, so the code read protection can be configured instead of life cycle. ## MC56F818xx/7xx/6xx and MWCT2xD2/12 devices workflow This chapter describes workflow for MC56F818xx/7xx/6xx and MWCT2xD2/12 processors. ### Preparing source image for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices In this step, select the target memory where the image is executed. The following options are available for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices: - Image running from an internal flash - XIP \(eXecution In Place\) image, which means that the image is executed directly from the internal flash memory. There is no need to modify the default configuration, build the MCUXpresso SDK example as it is. ### Connecting the board for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices This section contains information about configuring the evaluation boards and connecting it to SEC: - MC56F81868-EVK - MC56F81000-EVK - WCT-QI2 1. Power the board from USB\_TYPE\_C port \(WCT-QI2\). 2. Connect the J4 1-TX, 3-RX, 5-GND port \(WCT-QI2\) via the MCU-Link to your PC. 3. In the **Connection** dialog, set the connection to **UART** 4. To get to ISP boot mode, send a blhost command to the processor within 5 seconds after the board startup, for example click the **Test connection** button in the **Connection** dialog. **Note:** The processor boots from internal flash when there is no blhost command sent within 5 seconds after the startup. ### Booting images for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices This chapter describes the building and writing of plain and signed bootable images. #### Booting plain unsigned or CRC image Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly. First, build a bootable image: 1. Make sure you have selected the **Plain unsigned** or **Plain with CRC** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select an image built in [Preparing source image for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices](#preparing-source-image-for-mc56f818xx-7xx-6xx-and-mwct2xd2-12-devices) as a **Source executable image**. 4. If there is a binary image, set the start address to 0x0. 5. Click the **Build image** button to build a bootable image. The result is a binary bootable image. For secure processors there are also separated boot headers binary \(BCA, FCB\) and binary with application. This is due to the DUKB area in the internal flash that must stay untouched during the write. When the bootable image is built, upload it to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. If the write operation is successful, reset the board. The processor will boot after 5 seconds. #### Booting plain signed image This section describes building and writing a plain signed image. Build a bootable image: 1. Select the **Plain signed** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select an image built in [Preparing source image for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices](#preparing-source-image-for-mc56f818xx-7xx-6xx-and-mwct2xd2-12-devices) as a **Source executable image**. 4. For **Authentication key**, select ROT1. 5. Make sure that the board is connected and the processor is in ISP mode. During building processes, an SBx file is prepared. The processor is used as HSM to create an encrypted SBx file. 6. Keep **OEM Open** in the life cycle. See [Life cycle and device HSM trust provisioning for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices](#life-cycle-and-device-hsm-trust-provisioning-for-mc56f818xx-7xx-6xx-and-mwct2xd2-12-devices) for **OEM Closed** life cycle. 7. Click the **Build image** button to build a bootable image. The result is a binary bootable image, boot headers binary \(BCA, FCB\), and SBx capsule for installation of the image into the processor. When the bootable image has been successfully built, you can upload to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. #### Life cycle and device HSM trust provisioning for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices The default life cycle used for development is **OEM Open**. Before you deploy the application, set the **OEM Closed** life cycle \(see documentation for the target processor for a detailed description\). When the **OEM Closed** life cycle and **Device HSM** are set in the toolbar, the trust provisioning SBx file is created during the build. The `IFR ISK_CERT_HASH` fields are written to IFR by the `dev_hsm_provi.sbx` file. It is supposed that in this mode, the IFR fields have default values in the processor. **Note:** Writing of IFR fields is irreversible. **Note:** It is possible to reset the life cycle into an OEM Open state if needed. There are two possibilities: - Keep the **Plain signed** boot type, set the **OEM Open** life cycle, disable trust provisioning and do build and write. With this, the application is updated and the life cycle is set to **OEM Open**. Fields in IFR remain unchanged. - Set **Plain unsigned** boot type, **OEM Open** life cycle, disable trust provisioning and do build and write. With this, the entire flash memory is erased and the life cycle is set to **OEM Open**. Fields in IFR remain unchanged. **Attention:** The `blhost flash-erase-all` command erases the entire memory, which also affects the life cycle state. After flash-erase-all and device reset the life cycle is in the Closed state. For details on how to reset the life cycle, see the second option. **Table Life cycle and device HSM trust provisioning** ||ISK\_CERT\_HASH|SBx file| |----------|---------------|--------| |**OEM Open lifecycle, Signed boot type**|Included in FCB|SBx used to write/update the application image| |**OEM Closed life cycle, Signed boot type**|Irreversibly written to IFR in trust provisioning SBx file|SBx used to write/update the application image| ## MCX A14x/A15x device workflow This chapter describes workflow for A14x/A15x processors. ### Preparing source image for MCX A14x/A15x devices - Image running from internal FLASH is the default option for almost all SDK examples. There is no need to modify the default configuration, build the example as it is. - Image running from internal RAM; when creating this example, select the link application to RAM. ### Connecting the board This section contains information about configuring the evaluation boards FRDM-MCXA153 and FRDM-MCXA156 and connecting them to SEC. **Table Connecting the board** |Board|In-System Programming \(ISP\) Boot|Boot from internal FLASH| |-----|--------------------------------------|------------------------| |FRDM-MCXA153|SW2/JP8|By default| |FRDM-MCXA156|SW3|By default| To connect the board, follow the steps below: 1. Select ISP boot mode, see the table above. 2. Connect the UART/USB port to your PC with a USB cable. 3. Ensure SEC runs with a workspace created for the chosen device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 4. Go to **main menu \> Target \> Connection**, select UART/USB and test the connection. ### Booting images MCX A14x/A15x devices Booting plain unsigned and plain with CRC image is the same as for the MCXN devices. For details, see [Booting plain or CRC image for MCX Nx4x/N23x devices](#booting-plain-or-crc-image-for-mcx-nx4x-n23x-devices). ### Life cycle for MCX A14x/A15x devices The default life cycle that should be used for development is **OEM Open**. Before you deploy the application, set the “In Field ROP 1”, “In Field ROP 2” or “In Field ROP 3” life cycle \(see the documentation for the target processor for a detailed description\). **Note:** Change of the life cycle is irreversible. ## MCX C041/C242/C444 device workflow This chapter describes the workflow for Cx4x processors. ### Preparing source image for MCX C041/C242/C444 devices - An image running from the internal FLASH is the default option for almost all SDK examples. There is no need to modify the default configuration, build the example as it is. - An image runs from internal RAM when this example is created. Select the link application to RAM. The option is not supported on MCXC041. ### Connecting the board for MCX C041/C242/C444 devices This section contains information about configuring the evaluation boards FRDM-MCXC041, FRDM-MCXC242, FRDM-MCXC444, and connecting them to SEC. **Table MCXC boards** |Board|In-System Programming \(ISP\) Boot|Boot from internal FLASH| |:----|:-------------------------------------|:-----------------------| |FRDM-MCXC041|SW3|By default| |FRDM-MCXC242|SW3|By default| |FRDM-MCXC444|SW3|By default| 1. Select ISP boot mode. For details, see the table above. 2. Connect the UART/USB port to your PC with a USB cable. 3. Ensure SEC runs with a workspace created for the chosen device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 4. Go to **main menu \> Target \> Connection**, select UART and test the connection. ### Booting images for MCX C041/C242/C444 devices This section describes building and writing of bootable images into the internal flash and booting. #### Booting plain unsigned image First, build a bootable image: 1. Switch to the **Build image** view. 2. Select an image built in [Preparing source image for LPC55\(S\)0x/1x/2x/6x devices](#preparing-source-image-for-lpc55-s-0x-1x-2x-6x-devices) as a **Source executable image**. 3. If there is a binary image, set the start address to 0x00000000. 4. If needed, open **BCA/FCF** configure. 5. To build a bootable image, click the **Build image** button. The result is a binary bootable image. When the bootable image is built, upload it to the processor: 1. Make sure that the processor is in the ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. If the write operation is successful, reset the board to boot the image. #### BCA and FCF pages In the development life cycle, the BCA and FCF pages are not set into the bootable image unless there is any user requirement set to the page. If any requirement is set, the whole page is written, fields that have no user value are set to the default value. In that case, make sure that any value that was set in the source image is not unintentionally overwritten with the default values. **Note**: When the life cycle is set to secured flash state, FCF is set into the bootable image even if there are no user requirements. In the BCA/FCF configuration dialog, the current field values can be read from two sources: 1. From the flash of the connected processor. 2. From the source image selected on the build tab. #### Life cycle for MCX C041/C242/C444 devices The default life cycle that should be used for development is **Flash unsecured**. Before deploying the application, set the **Flash secured** \(see documentation for the target processor for a detailed description\). When switching the life cycle, the best practice is to set BCA and FCF pages. Chip with the flash security enabled can be erased, if ISP is available and the FCF field 'mass erase' is enabled. #### Backdoor key The advanced life cycle can be temporarily disabled if the backdoor key was set and the backdoor key comparison is enabled in FCF. After the backdoor key verification, the processor behaves as if in the OEM Open life cycle until the next reset. If the verification fails, further verification is not possible until flash reset. ## MCX Nx4x/N23x device workflow This chapter describes the workflow for Nx4x/N23x processors. ### Preparing source image for MCX Nx4x/N23x devices - Image running from internal FLASH is the default option for almost all SDK examples. There is no need to modify the default configuration, build the example as is. - Image running from external FLASH must start at address 0x80001000, edit this address when creating an example in MCUXpressoIDE in advance setting. - Image running from internal RAM when creating this example select link application to RAM. ### Connecting the board for MCX Nx4x/N23x devices This section contains information about configuring the evaluation boards FRDM-MCXN947, MCX-N9XX-EVK, MCX-N5XX-EVK, and connecting it to SEC. **Table MCX boards** |Board|In-System Programming \(ISP\) Boot|Boot from external FLASH|Boot from internal FLASH| |:----|:-------------------------------------|:-----------------------|:-----------------------| |MCX-N9XX-EVK|SW3/JP49|Boot source defined in CMPA| |FRDM-MCXN947|SW3|Boot source defined in CMPA| |MCX-N5XX-EVK|SW3/JP49|Boot source defined in CMPA| |FRDM-MCXN236|SW3|N/A|By default| 1. Select ISP boot mode, see the table above. 2. Connect the UART/USB port to your PC with a USB cable. 3. Ensure SEC runs with a workspace created for the chosen device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 4. Go to **main menu \> Target \> Connection** and select UART and test the connection. ### Booting images for MCX Nx4x/N23x devices This section describes building and writing of bootable images into the internal flash and booting. Booting from the external flash is similar, but the image linked to the external flash is used. #### Booting plain or CRC image for MCX Nx4x/N23x devices Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly. First, build a bootable image: 1. Make sure you have selected the **Plain unsigned** or **Plain with CRC** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select an image built in [Preparing source image for LPC55(S)0x/1x/2x/6x devices](#preparing-source-image-for-lpc55-s-0x-1x-2x-6x-devices) as a **Source executable image**. 4. If there is a binary image, set the start address to 0x00000000 \(for external flash 0x80001000\). 5. If needed, open **Dual image boot** and configure. 6. Click the **Build image** button to build a bootable image. The result is a binary bootable image. When the bootable image is built, upload it to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. If the write operation is successful, remove the ISP jumper and reset the board to boot the image. #### Booting plain signed image This section describes building and writing a plain signed image. Build a bootable image: 1. Select the **Plain signed** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select an image built in [Preparing source image for LPC55(S)0x/1x/2x/6x devices](#preparing-source-image-for-lpc55-s-0x-1x-2x-6x-devices) as a **Source executable image**. 4. Generate keys on PKI tab. 5. Back on the **Build image** view and select any Authentication key from the drop-down menu, for example ROT1: IMG1\_1. 6. Use random value for “CUST\_MK\_SK” and “OEM seed” symmetric keys. 7. If needed, open **Dual image boot** and configure. 8. Make sure that the board is connected and the processor is in ISP mode. During building processes, a provisioning SB3 file for installation of CUST\_MK\_SK into processor is prepared. If no board is connected, the build will fail when preparing the provisioning SB3 file. But other build processes were completed. **Note:** The processor is reset after the SB file is built. 9. Click the **Build image** button to build a bootable image. The result is a binary bootable image and SB3 capsule for installation of the image into the processor. When the bootable image has been successfully built, you can upload to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. #### Booting encrypted image Encrypted images with CRC or signed images are supported. The process of creation an encrypted image is similar to a signed image. In addition, configure encrypted regions in the **Build image** view: - Use the **PRINCE Regions** button to configure encrypted regions for internal FLASH - Use the **IPED Regions** button to configure encrypted regions for external FLASH In both cases, the image is encrypted by default. For clock limitations when using encrypted images, see documentation for the target processor. In combination with the dual boot, set one region for image0 and one for image1. Setting a region only for image0 does not encrypt image1. Image encryption is performed when the image is written to the target memory. The encrypted region is configured in the SB file. The decrypted regions are configured in the CMPA page, so make sure these two are aligned. #### Life cycle for MCX Nx4x/N23x devices The default life cycle that should be used for development is **Develop**. Before you deploy the application, set the In Field or In Field Locked life cycle \(see documentation for the target processor for a detailed description\). When switching the lifecycle, the best practice is to burn the ROTKH and PRINCE or IPED region settings into fuses. ROTKH fuses are set by the tool automatically, but the PRINCE or IPED setting is up to the user to be set. **Note:** Change of the life cycle is irreversible. The life-cycle configuration also affects the way how the security assets are installed. In the development life cycle, some assets are installed in a write script so it is easier to debug the changes and problems. The table below contains detailed information on how the security assets are installed based on the selected life cycle: **Table Life cycle and trust provisioning** |Trust provisioning Life cycle|Device HSM Develop |Device HSM In Field|EdgeLock 2GO Develop |EdgeLock 2GO In Field| |------------------|----------|----------|------------|------------| |**CMPA**|Device HSM SB file|Device HSM SB file|el2go\_provi.sb3|el2go\_provi.sb3| |**CUST MK SK**|Device HSM SB file|Device HSM SB file|CUST-MK\_SK|CUST-MK\_SK| |**ROKTH in CMPA**|Device HSM SB file|Device HSM SB file|RKTH|RKTH| |**CFPA**|Write script|Device HSM SB file|Write script|el2go\_provi.sb3| |**RKTH fuses**|Not burnt unless requested by the user|Device HSM SB file|Not burnt unless requested by the user|el2go\_provi.sb3| |**NPX and IPED fuses**|Not burnt unless requested by the user|Device HSM SB file|Not burnt unless requested by the user|el2go\_provi.sb3| |**Other custom fuses**|Write script|Device HSM SB file|Write script by default; optionally el2go\_provi.sb3|el2go\_provi.sb3| In the **Develop** life cycle, the CFPA is written in the write script, so any failures can be easily detected. In the **In Field** life cycle, the provisioning is supposed to be done for an empty processor. Once the processor is in In Field state, the write script still allows updating the application image; other updates are not supported by the write script but can be done using a custom SB file. #### Test life cycle MCX Nx4x/N23x variants can set the test life cycle on the CFPA page by setting the bit-field CFPA\_LC\_STATE and INV\_CFPA\_LC\_STATE in the HEADER register. By writing this CFPA setting, MCU behaves as if the LF was moved in OTP. **Note:** Use only the expected LC values, other values can brick the chip. To move back from the advanced life cycle, set the bit-field CFPA\_LC\_STATE back to 0x0 and write it to the chip. If the LC is moved only in the CFPA, it is possible to rewrite the CFPA page after power-on reset by executing blhost -u 0x1fc9, 0x014f -- write-memory 0x01000000 cfpa.bin. Steps to advance LC and return: 1. Open or prepare a workspace that has a secure boot type \(signed or encrypted\) 2. In the **OTP/PFR configuration**, set CFPA\_LC\_STATE to 0xF and INV\_CFPA\_LC\_STATE to 0xF0 3. Build and write image 4. Power-cycle the device into ISP 5. In OTP/PFR configuration, read the CFPA page 6. Reset the device by clicking the **Reset** button or using the blhost reset command 7. Test the secure life-cycle behavior \(limited commands, debug rights based on the SOCU register\) 8. After testing is done, power-cycle the device into the ISP 9. Open the **OTP/PFR configuration** and set CFPA\_LC\_STATE to 0x0 and INV\_CFPA\_LC\_STATE to 0xFF 10. Enable advanced mode and write the CFPA page into the device 11. After reset, the device will be back in normal LC **Note:** For EVK variants for power cycle follow these steps: 1. Power off the board 2. Add jumper to JP22 3. Change the power supply to USB \(J28\) 4. Hold the ISP button \(or short the jumper for ISP\) and connect the board via J28 5. Remove jumper JP22 #### EdgeLock 2GO EdgeLock 2GO is described in [EdgeLock 2GO Trust Provisioning workflow](./07_generic_workflows.md#edgelock-2go-trust-provisioning-workflow). Below are MCXN-specific comments: - The assets installed by EdgeLock 2GO are different for the Develop and In Field life cycle, see [Life cycle for MCX Nx4x/N23x devices](#life-cycle-for-mcx-nx4x-n23x-devices) for details. - There is the `ed2go_provi.sb3` file generated in the SEC tool that contains burning of the additional fuses. For the EdgeLock 2GO firmware, this file is optional; however, the SEC tool uses the file to install the fuses in the In Field life cycle. To add the file to the EdgeLock 2GO server via web portal, use the following steps: - Create a Secure Binary Object - Select Binary File - Assign any name - Set Object Identified \(OID\) to 0x7FFF817C - Select a nonconfidential file - In the policies, select NONE - For development, use the Develop life cycle in the SEC tool and the **Open** policy in configuration with secure objects on the EdgeLock 2GO server. With these settings, the life cycle is not changed and it still erases the processor. For production, use the In Field life cycle and the **Closed** policy. This does not apply to the SB3 file above where the policy should be always NONE. - The CMPA page must be erased before provisioning firmware is started, so it can be properly provisioned. The el2go-host application clears CMPA with parameter `-clear`. In case the production is executed with new/empty processors, the parameter can be removed. - Address for secure objects must be in internal flash, provisioning firmware erases the area before writing the secure objects ## RT10xx/RT116x/RT117x device workflow This section describes the RT10xx/RT116x/RT117x device workflow in detail. ### Preparing source image for RT10xx/RT116x/RT117x devices In this step, you must select the target memory where the image will be executed. The following options are available for RT10xx/RT116x/RT117x devices: - **Image running from an external NOR flash** It is the so-called **XIP**\(e**X**ecution **I**n **P**lace\) image, which means the image is executed directly from the memory where it is located. - **Image running in internal RAM** This image can be on an SD card/eMMC or in external flash \(SPI NOR, SPI NAND, or SEMC NAND\) and will be copied into internal RAM and executed from there during the boot. - **Image running in SDRAM** This image can be located in an SD card or external flash \(SPI NOR, SPI NAND, or SEMC NAND\) and during boot will be copied into SDRAM and executed from there. #### Image running from external NOR flash - **MCUXpresso IDE** The **led\_blinky** example is linked into external flash by default. 1. Optionally go to **Project \> Properties \> C/C++ Build \> Settings \> MCU C Compiler \> Preprocessor \> Defined symbols** and set **XIP\_BOOT\_HEADER\_ENABLE** to **0**. This step is now optional, because a bootable image can be used as an input on the build tab. 2. Build the image. You will find the resulting source image as *Debug\\evkmimxrt10\#\#\_iled\_blinky.axf*. You can later use it as a **Source executable image** by SEC. - **Keil MDK 5** 1. In the toolbar, select **iled\_blinky flexspi\_nor\_debug** target. 2. Optionally, in **Project \> Options \> "\*C/C++\*"**, disable define symbol **XIP\_BOOT\_HEADER\_ENABLE=0** \(set to 0\). This step is now optional, because a bootable image can be used as an input on the build tab. 3. In **Project \> Options \> Linker**, remove all *--keep* options and the predefined symbol **XIP\_BOOT\_HEADER\_ENABLE**. As a result, **Misc. controls** contains only *--remove*. 4. Build the image. You will find the output image as *boards\\evkmimxrt10\#\#\\demo\_apps\\led\_blinky\\mdk\\flexspi\_nor\_debug\\iled\_blinky.hex*. - **IAR Embedded Workbench** 1. In **Project \> Edit Configurations ...**, select **flexspi\_nor\_debug** 2. Optionally, in Project **Options \> C/C++ Compiler \>Preprocessor\>Defined Symbols**, add, or change the existing **XIP\_BOOT\_HEADER\_ENABLE define** to **0**.This step is now optional, because a bootable image can be used as input on the build tab. 3. On multicore processors set the Processor variant in **Project \> Options... \> General Options \> Target**, for example *Cortex-M7* for *iled\_blinky\_cm7* on RT1176. 4. Build the image. You will find the output image as *boards\\evkmimxrt10\#\#\\demo\_apps\\led\_blinky\\iar\\flexspi\_nor\_debug\\iled\_blinky.out.* #### Image running in internal RAM **Note:** Memory addresses and sizes in this section are used as an example and depend on the selected processor. - **MCUXpresso IDE** 1. Select **Project \> Properties - C/C++ Build \> Settings \> Tool Settings \> MCU Linker \> Managed Linker Script** and check **Link application to RAM**. 2. In **Project \> Properties \> C/C++ Build \> MCU settings**, delete **Flash**, and modify SRAM\_ITC to start at 0x3000 with size 0x1D000. ```{eval-rst} .. figure:: _images/flash.png :scale: 80% :align: center **SRAM_ITC** ``` 3. Move **SRAM\_ITC** to the first position to make it default. 4. Build the image. You can find the resulting source image named *Debug\\evkmimxrt10\#\#\_iled\_blinky.axf*. - **Keil MDK 5** 1. In the toolbar, select **iled\_blinky** debug target. 2. Open **Project \> Options \> Linker** and click **Edit** to edit the Scatter file. 3. Close the window and make the following changes in the linker file \(changes ***highlighted***\): ``` #define m_interrupts_start 0x00003000 #define m_interrupts_size 0x00000400 ``` ``` #define m_text_start 0x00003400 #define m_text_size 0x0001DC00 ``` 4. Build the image. You can find the resulting image as *boards\\evkmimxrt10\#\#\\demo\_apps\\led\_blinky\\mdk\\debug\\iled\_blinky.hex*. - **IAR Embedded Workbench** 1. Select **Project < Edit Configurations ... \> Debug**. 2. Open file *MIMXRT10\#\#xxxxx\_ram.icf* from project root folder and make the following changes: ``` define symbol m_interrupts_start = 0x00003000; define symbol m_interrupts_end = 0x000033FF; ``` ``` define symbol m_text_start = 0x00003400; define symbol m_text_end = 0x0001FFFF; ``` 3. On multicore processors set the Processor variant in **Project \> Options... \> General Options \> Target**, for example *Cortex-M7* for *iled\_blinky\_cm7* on RT1176. 4. Save the changes and build the image. You can find the resulting image built as *boards\\evkmimxrt10\#\#\\demo\_apps\\led\_blinky\\iar\\debug\\iled\_blinky.out*. #### Image running from external SDRAM - **MCUXpresso IDE** 1. Select **Project \> Properties - C/C++ Build \> Settings \> Tool Settings \> MCU Linker \> Managed Linker Script** and check Link application to RAM. 2. Select **Project \> Properties - C/C++ Build \> Settings \> Tool Settings \> MCU C Compiler \> Preprocessor** and add defined symbol **SKIP\_SYSCLK\_INIT=1**. 3. In **Project \> Properties \> C/C++ Build \> MCU settings**, delete **Flash**, and modify BOARD\_SDRAM to start at *0x80002000* with size *0x1dfe000*. Move BOARD\_SDRAM to first position to make it default. 4. Build the image. You can find the resulting source image named *Debug\\evkmimxrt10\#\#\_iled\_blinky.axf*. - **Keil MDK 5** 1. In the toolbar, select **iled\_blinky sdram\_debug** target. 2. Open **Project \> Options \> Linker** and click **Edit** to edit the Scatter file. 3. Close the window and make the following changes in the linker file \(changes ***highlighted***\): ``` #define m_interrupts_start 0x80002000 #define m_interrupts_size 0x00000400 #define m_text_start 0x80002400 #define m_text_size 0x0001DC00 #define m_data_start 0x80020000 #define m_data_size 0x01DE0000 ``` 4. Build the image. You can find the resulting image as *boards\\evkmimxrt10\#\#\\demo\_apps\\led\_blinky\\mdk\\sdram\_debug\\iled\_blinky.hex*. - **IAR Embedded Workbench** 1. Select **Project \> Edit Configurations ... \> sdram\_debug**. 2. Open file *MIMXRT10\#\#xxxxx\_sdram.icf* from project root folder and make the following changes: ``` define symbol m_interrupts_start = 0x80002000; define symbol m_interrupts_end = 0x800023FF; define symbol m_text_start = 0x80002400; define symbol m_text_end = 0x8001FFFF; define symbol m_data_start = 0x80020000; define symbol m_data_end = 0x8002FFFF; define symbol m_data2_start = 0x80200000; define symbol m_data2_end = 0x8023FFFF; define symbol m_data3_start = 0x80300000; define symbol m_data3_end = 0x81DFFFFF; define symbol m_ncache_start = 0x81E00000; define symbol m_ncache_end = 0x81FFFFFF; ``` 3. On multicore processors set the Processor variant in **Project \> Options... \> General Options \> Target**, for example *Cortex-M7* for *iled\_blinky\_cm7* on RT1176. 4. Save the changes and build the image. You can find the resulting image built as *boards\\evkmimxrt10\#\#\\demo\_apps\\led\_blinky\\iar\\sdram\_debug\\iled\_blinky.out*. ### Connecting the board for RT10xx/RT116x/RT117x devices This section contains information about configuring the following evaluation boards and connecting them to SEC: - MIMXRT1010-EVK - MIMXRT1015-EVK - MIMXRT1020-EVK - MIMXRT1024-EVK - MIMXRT1040-EVK - MIMXRT1050-EVKB - MIMXRT1060-EVK - MIMXRT1064-EVK - MIMXRT1160-EVK - MIMXRT1170-EVKB 1. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for instructions on how to set boot mode using DIP switches. 2. Make sure you have **J1** \(J38 on RT1176, RT1166\) set to **3-4** to power the board from USB OTG. 3. Connect to the J9 \(J20 on RT1176, RT1166\) port with the USB cable to your PC. 4. Ensure that SEC is already running with a workspace created for the chosen device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 5. Make sure that the **Boot memory** in the toolbar matches the NOR flash used on the EVK board \(for example*flex-spi-nor/ISxxxx*\). 6. Set the connection to **USB** and test the board connection. **Booting from SD card** For booting from an SD card, do the following: 1. Insert a micro SDHC card into the board. 2. In the MCUXpresso Secure Provisioning Tool, select **Boot memory: sdhc\_sd\_card/SDHC SD card 8 GB** in the **Toolbar**. **Table DIP Switches: Boot mode selection for EVKs** |Boot mode/Device|Serial bootloader \(ISP mode\)|Flex-SPI NOR \(QSPI, HyperFlash\)|Flex-SPI NOR + Encrypted XIP \(BEE/OTFAD/IEE\)|SD card|eMMC|SEMC NAND|FlexSPI NAND| |----------------|------------------------------|---------------------------------|----------------------------------------------|-------|----|---------|------------| |RT1010-EVK|SW8: 0001|SW8: 0010|SW8: 0010|N/A|N/A|N/A|N/A| |RT1015-EVK|SW8: 0001|SW8: 0010|SW8: 0010|N/A|N/A|N/A|N/A| |RT1020-EVK|SW8: 0001|SW8: 0010|SW8: 0010|SW8: 0110|N/A|N/A|N/A| |RT1024-EVK|SW8: 0001|SW8: 0010|SW8: 0010|SW8: 0110|N/A|N/A|N/A| |RT1040-EVK|SW4: 0001|SW4: 0010|SW4: 0010 or 0110 SW2: 1000|SW4: 1010|N/A|N/A|N/A| |RT1050-EVKB|SW7: 0001|SW7: 0110|SW7: 0010 or 0110 SW5: 1000|SW7: 1010|N/A|N/A|N/A| |RT1060-EVK|SW7: 0001|SW7: 0010|SW7: 0010 or 0110 SW5: 1000|SW7: 1010|N/A|N/A|N/A| |RT1064-EVK|SW7: 0001|SW7: 0010|SW7: 0010 or 0110 SW5: 1000|SW7: 1010|N/A|N/A|N/A| |RT1160-EVK|SW1: 0001SW2: 0000000000|SW1: 0010SW2: 0000000000|SW1: 0010SW2: 0100000000|SW1: 0010SW2: 0000001000|SW1: 0010 SW2: 0000000100|SW1: 0010SW2: 0000010000|N/A| |RT1170-EVKB|SW1: 0001SW2: 0000000000|SW1: 0010SW2: 0000000000|SW1: 0010SW2: 0100000000|SW1: 0010SW2: 0000001000|SW1: 0010 SW2: 0000000100|SW1: 0010SW2: 0000010000|N/A| ### Booting images for RT10xx/RT116x/RT117x devices This section describes the building and writing of bootable images. You can use several combinations of used memories: **Table Booting image** |Memory where the image is executed|Memory where the image is written|DCD/XMCD needed|XIP| |----------------------------------|---------------------------------|---------------|---| |External NOR flash|External NOR flash1|No|Yes| |Internal RAM|External NOR or NAND flash1|No|No| |Internal RAM|SD card or eMMC|No|No| |SDRAM|External NOR or NAND flash1|Yes|No| |SDRAM|SD card or eMMC|Yes|No| **Note:** For RT116x/7x devices, two FlexSPI instances are supported for FlexSPI NOR and FlexSPI NAND boot devices. There is the `FLEXSPI_INSTANCE` fuse `(BOOT_CFG2\[3\])/GPIO` boot pin which determines which FlexSPI instance to use. Set a corresponding GPIO boot pin to use Instance 2 without burning the fuse. **Note:** - **Memory, where the image is executed** - Explained in [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices). - **Memory, where the image is written** - Configured as **Boot memory** in SEC. #### Booting unsigned image An unsigned image is typically used for development. It is recommended to start with this boot type before working with secured images to verify that the executable image works properly. First, build a bootable image: 1. Make sure you have selected the **Unsigned boot type** in the **Toolbar**. 2. Switch to the **Build image** view. 3. Select the image built in [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image**. 4. For images executed from SDRAM, configure SDRAM using DCD or XMCD \(RT116x/7x\). For EVK boards, the following DCD file can be used: `data\targets\MIMXRT1###/evkmimxrt1xxx_SDRAM_dcd.bin`. For RT116x/7x, the following XMCD configuration file can be used: `data\targets\MIMXRT11##/evkmimxrt11xx_xmcd_semc_sdram_simplified.yaml.` **Note:** For customization of DCD files, refer to [Creating/Customizing DCD files](#creating-customizing-dcd-files). 5. If needed, open **Dual image boot** and configure \(supported only for RT116x/7x and FlexSPI NOR\). 6. Click the **Build image** button to build a bootable image. When the bootable image has been successfully built: 1. Make sure that the board is in Serial Boot mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. If the write operation was successful, switch boot mode \(**Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices)\) and reset the board. #### Booting authenticated \(HAB\) image This section describes the building and writing of an authenticated image. If you want to use an encrypted image, you can skip this step. 1. In the **Toolbar** set the **Boot type** to **Authenticated \(HAB\)**. 2. In the **Build image** view, use the image from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image**. 3. For **Authentication key** select any key, for example, *SRK1: IMG1\_1+CSF1\_1*. 4. If needed, open **Dual image boot** and configure. \(RT116x/7x - FlexSPI NOR\) 5. Select the **HAB Closed** life cycle. 6. Click the **Build image** button. 7. Check that the bootable image was built successfully. To write the image, switch to **Write image** view. 1. Make sure that the board is set to Serial bootloader \(ISP\) mode. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) and reset the board. for more information. 2. Make sure that the **Use built image** checkbox is selected. 3. Click the **Write image** button. 4. In the following window, confirm to write fuses: - **Yes** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that the processor can only execute authenticated images. - **No** - Do not burn fuses, continue writing the image. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/fig51.png :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices)\) and reset the board. \) and reset the board. #### Booting encrypted \(HAB\) authenticated image This section describes the building and writing of an encrypted image. This image will be decrypted into RAM during booting operation, so an XIP image cannot be used. To build the image, do the following: 1. In the **Toolbar** set the **Boot type** to **Encrypted \(HAB\)** authenticated. 2. As a **Source executable image**, use the image from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image**. 3. For **Authentication key** select any key, for example, *SRK1: IMG1\_1+CSF1\_1*. 4. If needed, open **Dual image boot** and configure. \(RT116x/7x - FlexSPI NOR\) 5. Select the **HAB Closed** life cycle. 6. Click the **Build image** button. 7. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that the processor can only execute authenticated images. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/fig52.png :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) \) and reset the board. **Note:** Part of the encrypted image is a DEK key blob encrypted using a master key from the processor. This master key is specific for each processor and cannot be used for another processor. **Note:** RT101x and RT102x processors do not support running encrypted images in the NOR flash. In case no other booting device is supported for those processors, the **Encrypted \(HAB\)** authenticated boot type is not available. #### Booting XIP encrypted image \(BEE OTPMK\) authenticated \(RT10xx\) This section describes the building and writing of an XIP encrypted image using the OTP master key. An authenticated image is built and then encrypted on-the-fly during the write operation. The source image for the encrypted XIP with the BEE feature must be an XIP image. To build the image, do the following: 1. In the **Toolbar**, set the **Boot type** to **XIP encrypted \(BEE OTPMK\) authenticated**. 2. As a **Source executable image**, use the image running from external NOR flash from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image**. 3. For **Authentication key**, select any key, for example, *SRK1: IMG1\_1+CSF1\_1*. 4. Click **XIP encryption \(BEE OTPMK\)** to open the **BEE OTPMK** window. In the window, keep the default settings to encrypt the whole image or configure your own FAC Protected Region ranges within the first BEE encrypted region. 5. Select the **HAB Closed** life cycle. 6. Click the **Build image** button. 7. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information. 3. Make sure that the **Use built image** checkbox is selected. 4. Enable XIP encryption by setting a corresponding GPIO pin \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information\). 5. Click the **Write image** button. 6. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that the processor can only execute authenticated images. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/fig53.png :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) \) and reset the board. **Note:** Step 5 can be replaced by setting the EncryptedXIP fuse in the OTP configuration. #### Booting XIP encrypted image \(BEE user keys\) unsigned \(RT10xx\) This section describes the building and writing of an XIP encrypted image using user keys. The image itself is built in two steps. First, the unsigned bootable image is built and then this unsigned image is encrypted for use with enabled encrypted XIP. The source image for the encrypted XIP with the BEE feature must be an XIP image. To build the image, do the following: 1. In the **Toolbar**, set the **Boot type** to **XIP encrypted \(BEE user keys\) unsigned**. 2. As a **Source executable image**, use the image external NOR flash from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image**. 3. Click **XIP encryption \(BEE user keys\)** to open the BEE user keys window. In the window, keep the default settings to encrypt the whole image, or edit **User keys data** to provide your specific key. Furthermore, the window allows you to configure additional BEE parameters \(Both regions \(engines\), user key\(s\) for regions, FAC Protected Region ranges, random key generation\). 4. Click the **Build image** button. 5. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information. 3. Ensure that **Use built image** checkbox is selected. 4. Enable XIP encryption by setting a corresponding GPIO pin \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information\). 5. Click the **Write image** button. 6. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that it is not possible to modify them. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/fig54.png :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) \) and reset the board. **Note:** Step 5 can be replaced by setting the EncryptedXIP fuse in the OTP configuration. #### Booting XIP encrypted image \(BEE user keys\) authenticated \(RT10xx\) This section describes the building and writing of an XIP encrypted image using user keys. The image itself is built in two steps. First, the authenticated bootable image is built and then this authenticated image is encrypted for use with enabled encrypted XIP. The source image for the encrypted XIP with the BEE feature must be an XIP image. To build the image, do the following: 1. In the **Toolbar** set the **Boot type** to **XIP encrypted \(BEE user keys\) authenticated**. 2. As a **Source executable image**, use the image external NOR flash from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image**. 3. For **Authentication key**, select any key, for example, *SRK1: IMG1\_1+CSF1\_1*. 4. Click XIP encryption \(BEE user keys\) to open the BEE user keys window. In the window, keep the default settings to encrypt the whole image, or edit user keys data to provide your specific key. Additionally, the window allows you to configure additional BEE parameters \(Both regions \(engines\), user key\(s\) for regions, FAC Protected Region ranges, random key generation\). 5. Select the **HAB Closed** life cycle. 6. Click the **Build image** button. 7. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) for more information. 3. Ensure that **Use built image** checkbox is selected. 4. Enable XIP encryption by setting a corresponding GPIO pin \(see [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) for more information\). 5. Click the **Write image** button. 6. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that the processor can only execute authenticated images. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/fig55.png :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) and reset the board. **Note:** Step 5 can be replaced by setting the EncryptedXIP fuse in the OTP configuration. #### Booting XIP encrypted image \(OTFAD OTPMK\) authenticated \(RT10xx\) This section describes building and writing of an XIP encrypted image using the OTP master key. The authenticated image is built and then encrypted on-the-fly during the write operation. The source image for the encrypted XIP with the OTFAD feature must be an XIP image. To build the image, do the following: 1. In the **Toolbar**, set the **Boot type** to **XIP encrypted \(OTFAD OTPMK\)** authenticated. 2. As a **Source executable image**, use the image running from external NOR flash from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image**. 3. For **Authentication key**, select any key, for example, *SRK1: IMG1\_1+CSF1\_1*. 4. Click **XIP encryption \(OTFAD OTPMK\)** to open the **OTFAD OTPMK** window. In the window, keep the default settings to encrypt the whole image or configure your own Protected Region ranges. 5. Select the **HAB Closed** life cycle. 6. Click the **Build image** button. 7. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that the processor can only execute authenticated images. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/bf.png :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) and reset the board. #### Booting OTFAD encrypted image unsigned with user keys. This section describes the building and writing of an OTFAD encrypted image. The image itself is built in two steps. To build the image, do the following: 1. In the **Toolbar** set **Boot Type** to **Encrypted**, **\(OTFAD\) unsigned** for RT116x/7x or **XIP encrypted \(OTFAD user keys\) unsigned** for RT10xx. 2. As a **Source executable image**, use the image external NOR flash from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image**. 3. Click **OTFAD encryption**/**XIP encryption \(OTFAD user keys\)** to open the OTFAD Configuration window. In the window set random keys. The window allows you to configure the number of OTFAD regions \(contexts\), KEK source \(OTP or PUF KeyStore\), KEK, Key scramble, user keys for regions, regions ranges, random key generation. 4. Open **OTP configuration** and review the settings and fix any reported problems. 5. Click the **Build image** button. 6. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information. 3. Reset the board if the OTFAD KEK source is set to PUF KeyStore. It is necessary so that the key store is enrolled successfully. 4. Ensure that **Use built image** checkbox is selected. 5. Enable XIP encryption \(RT116x/7x\) by setting a corresponding GPIO pin \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information\). 6. Click the **Write image** button. 7. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that it is not possible to modify them. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/otfad1.png :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) \) and reset the board. **Note:** Step 6 \(RT116x/7x\) can be replaced by setting the `ENCRYPT_XIP_EN` fuse in the OTP configuration. #### Booting OTFAD encrypted image authenticated with user keys This section describes the building and writing of an OTFAD encrypted image. The image itself is built in two steps. First, the authenticated bootable image is built and then this authenticated image is encrypted for use with OTFAD. The source image for the OTFAD feature must be an XIP image. To build the image, do the following: 1. In the **Toolbar** set **Boot type** to **Encrypted \(OTFAD\) authenticated** for RT116x/7x or **XIP encrypted \(OTFAD user keys\) authenticated** for RT10xx. 2. As a **Source executable image**, use the image external NOR flash from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image**. 3. Ensure you have keys generated in the **PKI management** view. For more information, see [PKI management](./05_user_interface.md#pki-management). 4. For **Authentication key** select any key, for example, *SRK1: IMG1\_1+CSF1\_1*. 5. Click **OTFAD encryption** / **XIP encryption \(OTFAD user keys\)** to open the OTFAD configuration window. In the window set random keys. The window allows you to configure the number of OTFAD regions \(contexts\), KEK source \(OTP or KeyStore\), KEK, Key scramble, user keys for regions, regions ranges, random key generation. 6. Select the **HAB Closed** life cycle. 7. Open **OTP configuration** and review the settings and fix any reported problems. 8. Click the **Build image** button. 9. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information. 3. Reset the board if the OTFAD KEK source is set to KeyStore. It is necessary so that the KeyStore is enrolled successfully 4. Ensure that **Use built image** checkbox is selected. 5. Enable XIP encryption \(RT116x/7x\) by setting a corresponding GPIO pin \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information\). 6. Click the **Write image** button. 7. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that the processor can only execute authenticated images. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/otfad2.png :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) \) and reset the board. **Note:** Step 6 \(RT116x/7x\) can be replaced by setting the `ENCRYPT_XIP_EN` fuse in OTP configuration. #### Booting IEE encrypted image unsigned \(RT116x/7x\) This section describes how to build and write an IEE encrypted image. The image itself is built in two steps. First, the unsigned bootable image is built, and then this unsigned image is encrypted for use with the IEE. The source image for the IEE feature must be an XIP image. To build the image, do the following: 1. In the **Toolbar** set the **Boot type** to **Encrypted \(IEE\) unsigned**. 2. As a **Source executable image**, use the image external NOR flash from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image.** 3. Click **IEE encryption** to open the IEE Configuration window. In the window set random keys. The window allows you to configure the number of IEE regions \(contexts\), KEK, AES encryption mode, and user keys for regions, regions ranges, random key generation. 4. Open the **OTP configuration**, review the settings, and fix any reported problems. 5. Click the **Build image** button. 6. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to the **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information. 3. Reset the board. It is required for successful key store enrollment. 4. Ensure that the **Use built image** checkbox is selected. 5. Enable XIP encryption by setting a corresponding GPIO pin \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information\). 6. Click the **Write image** button. 7. In the following window, confirm to write fuses: **OK** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that it is not possible to modify them. **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/burn_fuses.png :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices)\) and reset the board. **Note:** Step 5 can be replaced by setting the `ENCRYPT_XIP_EN` fuse in the OTP configuration. #### Booting IEE encrypted image authenticated \(RT116x/7x\) This section describes how to build and write an IEE encrypted image. The image itself is built in two steps. First, the unsigned bootable image is built, and then this unsigned image is encrypted for use with the IEE. The source image for the IEE feature must be an XIP image. To build the image, do the following: 1. In the **Toolbar** set the **Boot type** to **Encrypted \(IEE\) authenticated**. 2. As a **Source executable image**, use the image external NOR flash from [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices) as a **Source executable image.** 3. Ensure you have keys generated in the **PKI management** view. For more information, see section PKI management in [PKI management](./05_user_interface.md#pki-management). 4. For **Authentication key** select any key, for example, SRK1: IMG1\_1+CSF1\_1. 5. Click **IEE encryption** to open the IEE Configuration window. In the window set random keys. The window allows you to configure the number of IEE regions \(contexts\), KEK, AES encryption mode, and user keys for regions, regions ranges, random key generation. 6. Select the **HAB Closed** life cycle. 7. Open the **OTP configuration**, review the settings, and fix any reported problems. 8. Click the **Build image** button. 9. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information. 3. Reset the board. It is required for successful key store enrollment. 4. Ensure that the **Use built image** checkbox is selected. 5. Enable XIP encryption by setting a corresponding GPIO pin \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices) for more information\). 6. Click the **Write image** button. 7. In the following window, confirm to write fuses: **OK** - Continue writing the image and burning fuses. **Note:** Burning fuses can only be done once, after that it is not possible to modify them. **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/Figure64_new.PNG :scale: 80% :align: center **Burn fuses** ``` If the write operation was successful, switch boot mode \(see **Table DIP Switches: Boot mode selection for EVKs** in [Connecting the board for RT10xx/RT116x/RT117x devices](#connecting-the-board-for-rt10xx-rt116x-rt117x-devices)\) and reset the board. **Note:** Step 6 can be replaced by setting the `ENCRYPT_XIP_EN` fuse in the OTP configuration. ### Creating/Customizing DCD files It is recommended to use MCUXpresso Config Tools or MCUXpresso IDE to prepare a DCD binary file. 1. In any of the tools open any project/configuration for the selected processor. 2. Import existing DCD configuration from an SDK source code by selecting **main menu \> File \> Import \> MCUXpresso Config Tools \> Import Source**. 3. Select the file from SDK package in *boards\\evkmimxrt10\#\#\\xip\\evkmimxrt10\#\#\_sdram\_ini\_dcd.c*. 4. Switch to the Device Configuration tool by selecting **main menu \> Config Tools \> Device Configuration**. 5. In the toolbar of the **DCD view**, select **Output Format** to **binary**. 6. Navigate to **Code Preview** and in the toolbar click the **Export** button and select the location where to generate a binary file. **Note:** Refer to the documentation of the Device Configuration Tool for more information. ## RT118x device workflow This section describes the RT118x device workflow in detail. ### Preparing source image for RT118x devices In this step, select the target memory where the image will be executed. The following options are available for RT118x devices: - **Image running from an external NOR flash** It is the so-called **XIP**\(e**X**ecution **I**n **P**lace\) image. It means that the image is executed directly from the memory where it is. - **Image running in RAM** This image can be on an SD card/eMMC or in external flash \(FlexSPI NOR, FlexSPI NAND\) and will be copied into RAM and executed from there during the boot. The following RAM types are supported: - internal RAM - SDRAM - HyperRAM The source image preparation is similar to RT116x/7x, see [Preparing source image for RT10xx/RT116x/RT117x devices](#preparing-source-image-for-rt10xx-rt116x-rt117x-devices). Some RT118x specifics: - Select an example for core cm33 and then set the target to Cortex-M33. ELE firmware is distributed in MCUXpresso SDK in the 'ELE crypto' component, typically the `firmware\edgelock\mxrt1180-ahab-container.img` file. ### Connecting the board for RT118x devices This section contains information about configuring the following evaluation boards and connecting them to SEC: - MIMXRT1180-EVK - MIMXRT1180A-EVK - MIMXRT1180-144 1. See Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT118x devices](#connecting-the-board-for-rt118x-devices) in for instructions on how to set boot mode using DIP switches. 2. Make sure you have J1 set to 3-4 to power the board from USB \(from UART on RT1180-144\). 3. Connect to the J33 \(J53 on RT1180-144\) port with the USB cable to your PC. 4. Ensure that SEC is already running with a workspace created for the chosen device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 5. Make sure that the **Boot device** in the **Boot Memory Configuration** matches the FlexSPI NOR flash used on the EVK board. 6. Set the connection to **USB** \(**UART** on MIMXRT1180-144\) and test the board connection. - Booting from SD card For booting from an SD card, do the following: 1. Insert a micro SDHC card into the board. 2. Select **SD card, SDHC SD-card 8GB USDHC1** in the **Boot Memory Configuration**. - Booting from eMMC: For booting from an eMMC, do the following: 1. eMMC can be installed on board, or it is possible to connect eMMC through SD slot by SD/eMMC adapter. 2. Select **eMMC, SDHC eMMC 8 GB USDHC1** in the **Boot Memory Configuration**. **Table DIP Switches: Boot mode selection for EVKs** |Boot mode/Device|Serial bootloader \(ISP mode\)|Flex-SPI NOR|SD card/ eMMC|FlexSPI NAND| |---------------------|----------------------------------|--------------|---------------|--------------| |RT1180-EVK|SW5: x001|SW5: x100|SW5: x011|SW5: x101 \(N/A\)| |RT1180A-EVK|SW5: x001|SW5: x100|SW5: x011|SW5: x101 \(N/A\)| |RT1180-144|SW5: x100|SW5: x001|SW5: x110|SW5: x101 \(N/A\)| ### Booting images for RT118x devices This section describes the building and writing of bootable images. You can use several combinations of used memories: |Memory where the image is executed|Boot memory: Memory where the image is written|XMCD needed|XIP| |------------------------------------|------------------------------------------------|-------------|-----| |External NOR flash|External NOR flash|No|Yes| |Internal RAM|External NOR or NAND flash|No|No| |Internal RAM|SD card or eMMC|No|No| |SDRAM/HyperRAM|External NOR or NAND flash|Yes|No| |SDRAM/HyperRAM|SD card or eMMC|Yes|No| **Note:** - Memory, where the image is executed is explained in [Preparing source image for LPC55(S)0x/1x/2x/6x devices](#preparing-source-image-for-lpc55-s-0x-1x-2x-6x-devices). - Memory, where the image is written is configured as Boot Memory in SEC. #### Booting unsigned image An unsigned image is typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly. First, build a bootable image: 1. Make sure you have selected the **Unsigned boot type** in the **Toolbar**. 2. Switch to the **Build image** view. 3. Select the image built in [Preparing source image for RT118x devices](#preparing-source-image-for-rt118x-devices) as a **Source executable image**. 4. For images executed from SDRAM/HyperRAM, configure SEMC SDRAM / FlexSPI HyperRAM using XMCD. For EVK boards, the following XMCD configuration files can be used: /sample\_data/targets/MIMXRT118\#/evkmimxrt118\#\_xmcd\_\*\_simplified.yaml. 5. If needed, open **Dual image boot** and configure. 6. Click the **Build image** button to build a bootable image. When the bootable image has been successfully built: 1. Make sure that the board is in Serial bootloader \(ISP\) mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. If the write operation was successful, switch boot mode \(see Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT118x devices](#connecting-the-board-for-rt118x-devices)\) and reset the board. #### Booting signed image This section describes the building and writing of a signed image. Keys generated in the **PKI management** view are needed in this step. For more information about generating keys, see [Generate keys](./05_user_interface.md#generate-keys). If you want to use an encrypted image, you can skip this step. First, build a bootable image: 1. In the **Toolbar** set **Boot type** to **Signed**. 2. In the **Build image** view, use the image from [Preparing source image for RT118x devices](#preparing-source-image-for-rt118x-devices) as a **Source executable image**. 3. For **Authentication key** select any key, for example, *SRK1*. 4. Select the **OEM Closed** life cycle. 5. Click the **Build image** button. 6. Check that the bootable image was built successfully. To write the image, switch to **Write image** view. 1. Make sure that the board is set to Serial bootloader \(ISP\) mode. See Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT118x devices](#connecting-the-board-for-rt118x-devices) for more information. 2. Make sure that the **Use built image** checkbox is selected. 3. Click the **Write image** button. 4. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/burn_fuses_RT118x.png :scale: 80% :align: center **Burn fuses** ``` 5. If the write operation was successful, switch boot mode \(see Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT118x devices](#connecting-the-board-for-rt118x-devices)\) and reset the board. #### Booting encrypted \(AHAB\) image This section describes the building and writing of an encrypted image. This image is decrypted into RAM during booting operation, so an XIP image cannot be used. The keys generated in the **PKI management** view are needed in this step. For more information about generating keys, see [Generate keys](./05_user_interface.md#generate-keys). To build the image, do the following: 1. In the **Toolbar** set the **Boot type** to **Encrypted \(AHAB\)**. 2. As a **Source executable image**, use the image from [Preparing source image for RT118x devices](#preparing-source-image-for-rt118x-devices) as a **Source executable image**. 3. For **Authentication key** select any key, for example, *SRK1*. 4. Select the **OEM Closed** life cycle. 5. Click the **Build image** button. 6. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to the **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See Table 3 for more information. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image**. button. 5. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. - **Cancel** - Abort writing the image and burning fuses. 6. If the write operation was successful, switch boot mode \(see Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT118x devices](#connecting-the-board-for-rt118x-devices)\) and reset the board. **Note:** Part of the encrypted image is a DEK key blob encrypted using a master key from the processor. This master key is specific for each processor and cannot be used for another processor. DEK key blob is generated during write and the AHAB image is then updated with this processor-specific key blob. #### Booting OTFAD encrypted image This section describes the building and writing of an OTFAD encrypted image. The image itself is built in two steps. First, the unsigned/signed AHAB image is built and then this AHAB image is encrypted for use with OTFAD. The source image for the OTFAD feature must be an XIP image. The Keys generated in the **PKI management** view are needed in this step. For more information about generating keys, see [Generate keys](./05_user_interface.md#generate-keys). To build the image, do the following: 1. In the **Toolbar** set the **Boot type** to **Encrypted \(OTFAD\) signed** or **Encrypted \(OTFAD\) unsigned**. 2. As a **Source executable image**, use the image external NOR flash from [Preparing source image for RT118x devices](#preparing-source-image-for-rt118x-devices) as a **Source executable image**. 3. For **Authentication key** select any key, for example, *SRK1*. 4. Click **OTFAD encryption** to open the OTFAD configuration window. In the window set random keys. The window allows you to configure the number of OTFAD regions \(contexts\), KEK source \(OTP or DUK\), KEK, Key scramble, user keys for regions, regions ranges, random key generation. 5. Select the **OEM Closed** life cycle. 6. Open the **OTP configuration** and review the settings and fix any reported problems. 7. Click the **Build image** button. 8. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT118x devices](#connecting-the-board-for-rt118x-devices) for more information. 3. Ensure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/burn_fuses_1.png :scale: 80% :align: center **Burn fuses** ``` 6. If the write operation was successful, switch boot mode \(see Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT118x devices](#connecting-the-board-for-rt118x-devices)\) and reset the board. #### Booting IEE encrypted This section describes the building and writing of an IEE encrypted image. The image itself is built in two steps. First, the unsigned/signed AHAB image is built and then this AHAB image is encrypted for use with IEE. The source image for the IEE feature must be an XIP image. The Keys generated in the **PKI management** view are needed in this step. For more information about generating keys, see [Generate keys](./05_user_interface.md#generate-keys). To build the image, do the following: 1. In the **Toolbar** set the **Boot type** to **Encrypted \(IEE\) signed** or **Encrypted \(IEE\) unsigned**. 2. As a **Source executable image**, use the image external NOR flash from [Preparing source image for RT118x devices](#preparing-source-image-for-rt118x-devices) as a **Source executable image**. 3. For **Authentication key** select any key, for example, *SRK1*. 4. Click **IEE encryption** to open the IEE configuration window. In the window set random keys. The window allows you to configure the number of IEE regions \(contexts\), AES encryption mode, and user keys for regions, regions ranges, random key generation. 5. Select the **OEM Closed** life cycle. 6. Open the **OTP configuration** and review the settings and fix any reported problems. 7. Click the **Build image** button. 8. Check that the bootable image was built successfully. To write the image, do the following: 1. Switch to the **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. See Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT118x devices](#connecting-the-board-for-rt118x-devices) for more information. 3. Ensure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. In the following window, confirm to write fuses: - **OK** - Continue writing the image and burning fuses. - **Cancel** - Abort writing the image and burning fuses. ```{eval-rst} .. figure:: _images/burn_fuses_1.png :scale: 80% :align: center **Burn fuses** ``` 6. If the write operation was successful, switch boot mode \(see Table DIP Switches: Boot mode selection for EVKs in [Connecting the board for RT118x devices](#connecting-the-board-for-rt118x-devices)\) and reset the board. #### Booting multicore images This section describes how to build and write an image for multiple cores \(Cortex M33 and Cortex M7\). Only Cortex M33 is a bootable core. The source image used for Cortex M33 must trigger the second core in the code \(Cortex M7\). See `demo_apps\multicore_trigger` example in the SDK package for RT118x. To build multicore images, do the following: - In this example, the Cortex M7 XIP image runs from external Flash \(start address 0x2800B000\) and the Cortex M33 image runs from internal RAM \(start address 0xFFE0000\): 1. Set the **Source executable image** \(image for Cortex M33\) in the **Build** tab. 2. Open the **Additional User/OEM Image** dialog via the **Additional images** button \(the application binary image is automatically filled up\). 3. Specify a standalone Cortex M7 executable binary image running from the flash memory and set the following values: - Image offset - 0xA000. It is calculated as: Load address \(0x2800B000\) - FlexSPI NOR base address \(0x28000000\) - AHAB image offset in FlexSPI NOR \(0x1000\) - Load address - 0x2800B000 - Entry point - 0x2800B000 - Core Id - cortex-m7 - Image type - executable 4. Close the dialog by clicking the **OK** button. 5. Click the **Build image** button. - In this example, the Cortex M7 image runs from internal ITCM RAM \(start address 0x0\) and the Cortex M33 XIP image runs from external flash \(start address 0x2810B000\). This use case requires additional fuses, so the internal RAM is properly accessible. 1. Set the **Source executable image** \(image for Cortex M33\) in the **Build** tab. 2. Open the **Additional User/OEM Image** dialog via the **Additional images** button \(the application binary image is automatically filled up\). 3. Specify a standalone Cortex M7 executable binary image running from ITCM RAM and set the following values: - Image offset - 0x10F400 - this can be any value which does not overlap with other image \(in this example the image was placed directly after the Cortex M33 image\) - Load address - 0x303C0000 \(secured alias of CM7 ITCM in the CM33 core address space\) - Entry point - 0x0 \(the start addresses of the image in the CM7 address space\) - Core Id - cortex-m7 - Image type - executable 4. Close the dialog by clicking the **OK** button. 5. Open the **OTP Configuration** dialog by clicking the **OTP configuration** button in the left-bottom corner. 6. Set POR\_PRELOAD\_MC7\_TCM\_ECC and RELEASE\_M7\_RST\_STAT fuses \(BOOT\_CFG7\) to 1 and fix any reported problems. 7. Close the dialog via the **OK** button. 8. Click the **Build image** button. **Note:** The write process of the multicore images is the same as for [Booting IEE encrypted](#booting-iee-encrypted). #### Life cycle for RT118x device workflow The default life cycle, which should be used for development, is **OEM Open**. Before you deploy the application, set the **OEM Closed** or **OEM Locked** life cycle \(see documentation for the target processor for detailed description\). **Note:** Change of the life cycle is irreversible. Once the processor is in “OEM Closed” or "OEM Locked" mode: - The tool processor does not allow burn fuses via blhost. The application can still be updated. - The processor can only execute signed images #### Firmware version The firmware version value is included in the AHAB container header, field Fuse version. This version value is fused indirectly through the ELE commit API when the AHAB container is authenticated. This commit API must be called from the application itself. The AHAB image with a lower fuse version than the version fused cannot be loaded during booting. The firmware version is supported for signed images only. ## RT5xx/6xx device workflow This section describes the RT5xx/6xx device workflow in detail. ### Preparing source image RT5xx/6xx devices In this step, you must select the target memory where the image will be executed. Supported boot memories are NOR flash, SD card, and eMMC. The following boot types are available for RT5xx/6xx processors: - Image running in external flash: The XIP image \(eXecuted In Place\) - Image running in internal RAM: The image is copied from FLASH, SD card, or eMMC to RAM before the execution It is recommended to use the **gpio\_led\_output** example for verification, the image is started properly. By default, this example triggers LED blinking only if the user button is clicked, but you can easily modify it to blink all the time. #### Image running in external flash The gpio\_led\_output example is linked into external flash by default. Disable the XIP Boot header, as it will be created by SEC. - **MCUXpresso IDE** 1. Optional step: go to Project \> Properties \> C/C++ Build \> Settings \> MCU C Compiler \> Preprocessor \> Defined symbols and set **BOOT\_HEADER\_ENABLE** to **0**. 2. Build the image. You will find the resulting source image named as *Debug\\evkmimxrt685\_gpio\_led\_output.axf*. It can be used as an input for the bootable image in SEC. - **Keil MDK** 1. In the **Toolbar**, select **gpio\_output\_flash\_debug** target. 2. Optional step: in **Project \> Options \> "\*C/C++\*"** disable define symbol **BOOT\_HEADER\_ENABLE=0 \(set to 0\)**. 3. In **Project \> Options \> Output** select the **Create HEX file** checkbox. 4. Double-check that the application is linked to 0x8001000. If not, the following fix must be applied to the linker as a workaround for the problem: ```{eval-rst} .. figure:: _images/mdk.png :width: 50% :align: center **Keil MDK workaround** ``` 5. Build the image. You will find the output image as boards\\evkmimxrt685\\driver\_examples\\gpio\\led\_output\\mdk\\flash\_debug\\gpio\_led\_output.out - **IAR Embedded Workbench** 1. In **Project \> Edit Configurations ...**, select **flash\_debug**. 2. Optional step: in **Project Options \> C/C++ Compiler \> Preprocessor \> Defined Symbols**, add or change the existing **BOOT\_HEADER\_ENABLE** define to **0**. 3. Build the image. You will find the output image as *boards\\evkmimxrt\#\#\#\\driver\_examples\\gpio\\led\_output\\iar\\flash\_debug\\gpio\_led\_output.out*. #### Image running in internal RAM - **MCUXpresso IDE** 1. Go to **Project \> Properties \> C/C++ Build \> Settings \> MCU C Compiler \> Preprocessor \> Defined symbols** and set **BOOT\_HEADER\_ENABLE** to **0**. 2. Select **Project \> Properties - C/C++ Build \> Settings \> Tool Settings \> MCU Linker \> Managed Linker Script** and check **Link application to RAM**. 3. Build the image. You will find the built image as *Debug\\evkmimxrt685\_gpio\_led\_output.axf*. You can later use it as a **Source executable image** by SEC. - **Keil MDK** Because example projects for MDK are not built into RAM, you must manually modify the linker file. Generic description of such changes is not documented yet. - **IAR Embedded Workbench** 1. In **Project \> Edit Configurations ...**, select **debug**. 2. In **Project Options \> C/C++ Compiler \> Preprocessor \> Defined Symbols**, add or change the existing **BOOT\_HEADER\_ENABLE** define to **0**. 3. Build the image. You will find the output image built as *boards\\evkmimxrt\#\#\#\\driver\_examples\\gpio\\led\_output\\iar\\debug\\gpio\_led\_output.out*. ### Connecting the board for RT5xx/6xx devices This section contains information about configuring the following evaluation boards and connecting them to SEC: - MIMXRT595-EVK - MIMXRT685-EVK **Table RT5xx/6xx EVK boot configuration** |Boot Mode/Device|ISP Mode|FlexSPI Boot|SD card|eMMC| |----------------|--------|------------|-------|----| |MIMXRT595-EVK|SW7\[1:3\]: 100 \(UART, SPI, I2C\)SW7\[1:3\]: 101 \(USB\)|SW7\[1:3\]: 001|RT595 SW7\[1:3\] 011|RT595 SW7\[1:3\] 110| |MIMXRT685-EVK|SW5\[1:3\]: 100|SW5\[1:3\]: 101|RT685 SW5\[1:3\] 011|RT685 SW5\[1:3\] 110| 1. Switch the board to ISP Mode and reset. For more information, see the above table. 2. Connect to the **J7** port with the USB cable to your PC. 3. Ensure you have started SEC with a new workspace. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 4. Set the connection to **USB** and test the board connection. **Booting from SD card:** For booting from an SD card, do the following: 1. Insert SDHC card into the board in MCUXpresso Secure Provisioning Tool 2. Select the Boot memory: sd\_card/SDHC SD card 8 GB in the **Toolbar**. 3. SDHC power cycle must be set to ENABLED for evk boards **Booting from eMMC**: For booting from an eMMC, do the following: 1. eMMC can be installed on board, or it is possible to connect eMMC through SD slot by SD/eMMC adapter. 2. Select Boot memory: eMMC/SDHC eMMC 8 GB in the **Toolbar.** ### Booting images for RT5xx/6xx devices This chapter describes the building and writing of plain and signed bootable images. #### Booting a plain/plain with CRC image A plain image is typically used for development. It is recommended to start with this boot type before working with secured images to verify that the executable image works properly. To build a bootable image, follow these steps: 1. In the **Toolbar**, select **Plain unsigned** or **Plain with CRC** in **Boot type**. 2. Switch to the **Build image** view. 3. Select image build in [Preparing source image RT5xx/6xx devices](#preparing-source-image-rt5xx-6xx-devices) as a **Source executable image**. If needed, open the **Dual image boot** and configure. If configured, open **OTP configuration** and review all reported problems. For fuse **BOOT\_CFG\[3\]** being locked after write, it is necessary to specify the whole value as it is programmed only once. 4. Click the **Build image** button to build a bootable image. When the bootable image has been successfully built: 1. Connect the board, see [Connecting the board RT5xx/6xx devices](#connecting-the-board-for-rt5xx-6xx-devices). 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. **Reset the board**. If the write script is executed twice without resetting the board, the configuration of external memory may fail unless the fuse with the QSPI reset pin is not burnt. 5. Click the **Write image** button. If the write operation was successful, switch boot mode to **FlexSPI boot** \(**Table RT5xx/6xx EVK boot configuration** in [Connecting the board RT5xx/6xx devices](#connecting-the-board-for-rt5xx-6xx-devices)\) and reset the board. #### Booting signed image using shadow registers This section describes the building and writing of an authenticated image. 1. In the **Toolbar** set **Boot type** to **Plain signed**. 2. In the **Build image** view, use the image from [Preparing source image RT5xx/6xx devices](#preparing-source-image-rt5xx-6xx-devices) as a **Source executable image**. 3. Ensure you have keys generated in the **PKI management** view. For more information, see [PKI management](./05_user_interface.md#pki-management). 4. For **Authentication key**, select any key, for example, *ROT1: IMG1\_1*. 5. As a **Key source**, select **OTP** or **KeyStore**. KeyStore represents a higher security level, as PUF is used. See [Securing the processor](#securing-the-processor) for the limitations. 6. Generate a random **User key** and **SBKEK**. 7. If needed, open **Dual image boot** and configure. 8. Select the **Development** life cycle. 9. Open **OTP configuration** and review all reported problems. For fuses **BOOT\_CFG\[0\]** and **BOOT\_CFG\[3\]** being locked after write, it is necessary to specify the whole value, as it will be programmed only once. 10. Click the **Build image** button and check that the bootable image was built successfully. To write the image, do the following: 1. To write the image, switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. For more information, see [Connecting the board RT5xx/6xx devices](#connecting-the-board-for-rt5xx-6xx-devices). 3. Make sure that the **Use built image** checkbox is selected. 4. **Reset the board**. It is necessary because: - Shadow registers cannot be updated or written twice, they can be set to a “clean” processor only. - If the fuse for the QSPI reset pin is not burnt, it is necessary to reset the flash manually before each configuration. 5. Click the **Write image** button. During the write operation, the following steps are performed: 1. Fuses are checked to ensure that the board is in an unsecured mode. 2. A simple application is written into RAM. The application initializes shadow registers. 3. Shadow registers data are written into RAM. The application is started. 4. The application resets the processor. 5. The write\_image script is started to configure external flash and write the application into flash. #### Booting OTFAD encrypted image using shadow registers This section describes the building and writing of an encrypted image \(OTFAD encryption\). 1. In the **Toolbar** set Boot Type to **Encrypted \(OTFAD\) with CRC** or **Encrypted \(OTFAD\) signed**. 2. In the **Build image** view, use the image from [Preparing source image RT5xx/6xx devices](#preparing-source-image-rt5xx-6xx-devices) as a **Source executable image**. 3. Ensure you have keys generated in the **PKI management** view. For more information, see [PKI management](./05_user_interface.md#pki-management). 4. For **Authentication key**, select any key, for example, ROT1: IMG1\_1. 5. As a **Key source**, select **OTP** or **KeyStore**. KeyStore represents a higher security level, as PUF is used. See [Securing the processor](#securing-the-processor) for the limitations. 6. Generate a random **User key** and **SBKEK**. 7. Open **OTFAD encryption** and set random keys. 8. If needed, open **Dual image boot** and configure. 9. Select **Development** life cycle. 10. Open **OTP configuration** and review all reported problems. For fuses **BOOT\_CFG\[0\]** and **BOOT\_CFG\[3\]** being locked after write, it is necessary to specify the whole value, as it will be programmed only once. 11. Click the **Build image** button and check that the bootable image was built successfully. To write the image, do the following: 1. To write the image, switch to **Write image** view. 2. Make sure that the board is set to Serial bootloader \(ISP\) mode. For more information, see [Connecting the board RT5xx/6xx devices](#connecting-the-board-for-rt5xx-6xx-devices). 3. Make sure that the **Use built image** checkbox is selected. 4. **Reset the board**. It is necessary because: - Shadow registers cannot be updated or written twice, they can be set to a “clean” processor only. - If the fuse for the QSPI reset pin is not burnt, it is necessary to reset the flash manually before each configuration. 5. Click the **Write image** button. During the write operation, the following steps are performed: 1. Fuses are checked to ensure that the board is in an unsecured mode. 2. A simple application is written into RAM. The application initializes shadow registers. 3. Shadow registers data are written into RAM. The application is started. 4. The application resets the processor. 5. The SB file is applied to the processor, and during this process, the following actions will be done: - Configure external flash - Erase flash \(KeyStore is preserved if it is used\) - Create an FCB block at the beginning of the flash - Write an encrypted application - Write OTFAD key blobs **Note:** Repetitive Write to QSPI flash might fail if the board is not Reset. #### Booting signed/encrypted image - burn fuses Burning fuses is an irreversible operation, which should be performed only after the bootable image was tested with shadow registers. It is also recommended to safely back up all keys prior to burning fuses. The booting process is identical to the process described in [Booting plain signed image using shadow registers](#booting-plain-signed-image-using-shadow-registers) with only one difference in write operation - the Deployment life cycle must be selected. During the write operation, the shadow registers will not be initialized, and the write image script will burn the fuses instead. The GUI will display confirmation with a list of fuses groups to be burnt. **Note:** Detailed info about the modification of fuses can be reviewed in [OTP/PFR/IFR configuration](./05_user_interface.md#otppfrifrbcafcf-configuration). #### Securing the processor To enable full security on RT5xx/6xx processors, *DCFG\_CC\_SOCU* and *DCFG\_CC\_SOCU\_AP* fuses must be burnt. SEC does not set up these fuses for burning by default \(even if the Deployment life cycle is selected\), but you can configure it in **OTP/PFR configuration**. Once the *DCFG\_CC\_SOCU* fuses are set, it is no longer possible to modify security configuration parameters, and no changes in the key store are allowed using blhost. If KeyStore is used, the image can be updated in SEC only if: - ISP mode is still enabled, and - *QSPI\_ISP\_AUTO\_PROBE\_EN* bin in *BOOT\_CFG\[1\]* fuse is enabled. This feature is not supported on RT6xx processors, and the image can be updated only using a custom bootloader. If the keys are stored in OTP fuses, no limitation applies. Note that OTFAD encryption on RT600 is not supported with KeyStore, because there is no support to back up and restore KeyStore during erasing the flash in the SB file. To test the DCFG\_CC\_SOCU configuration in the shadow registers, the following steps must be followed: - prepare and test the application image without DCFG\_CC\_SOCU \(for example, all DCFG\_CC\_SOCU must be zero\) - once the image is running and the FCB configuration is valid and available in FLASH, configure DCFG\_CC\_SOCU. The processor will now be set to full security, so some blhost operations are no longer available. The processor can be updated via SB file only. #### Device HSM provisioning This section describes the provisioning of the processor using key blob encrypted using device HSM, which allows to transfer keys \(fuses values\) securely and application bootable image into the factory. Device HSM is supported for all secure boot types: Plain signed and OTFAD encrypted in the **deployment** life cycle. Device HSM can be selected from the toolbar in the trust provisioning type selection dialog. In device HSM mode, several fuses are configured by trust provisioning firmware. These fuses must be configured, so the tool displays an error if the required value is not specified. The encryption of the fuses into the key blob is done using the EVK evaluation board. During the build operation, the fuses values are written into RAM, and then trust provisioning firmware creates a key blob. **To do the build, follow the steps below:** 1. On the toolbar, ensure that the **Plain signed** or **Encrypted** boot type is selected. 2. On the toolbar, ensure that the **Deployment** life cycle is selected. 3. On the toolbar, select **Device HSM** provisioning type. 4. In OTP configuration, ensure that all fuses for device HSM are specified; additional fuses can be burnt in the application SB file. 5. Connect EVK board using UART or USB connector. 6. Open the **Connection** dialog and test the connection. 7. Run the build. During the build, the bootable image and SB file are created and then the fuses values are written to processor RAM and then encrypted using provisioning firmware. The fuses of the processor are not affected in this step. 8. After the build script, the encrypted key blob is read. **Note:** Provisioning firmware is distributed in a restricted data package, see [Preferences](./05_user_interface.md#preferences) for details. **Write** Write operation is the same as secure boot type using a write script. The write script uses the same provisioning firmware to decrypt the key blob and burn selected fuses and then it resets the processor. It uses the SB file to install the application image. In case the booting device is selected by the fuse, ensure that the booting device is empty, so the processor falls into ISP mode after the reset and the application image can be uploaded. **Manufacturing package** For the manufacturing operation, it is recommended to create a manufacturing package. For more information, see [Manufacturing workflow](./07_generic_workflows.md#manufacturing-workflow). ## RT7xx device workflow This section describes the RT7xx device workflow in details. ### Preparing source image for RT7xx devices In this step, select the target memory where the image is to be executed. The supported boot memories are NOR flash \(instance 0 or 1\) or eMMC. The following boot types are available for RT7xx processors: - Image running in external flash: the XIP image \(eXecuted In Place\) - Image running in internal RAM. The ROM during the boot time copies the image from FLASH or eMMC to RAM. ### Connecting the board for RT7xx devices This section contains information about configuring the MIMXRT700-EVK evaluation board and connecting it to SEC. **Table RTxxx EVK boot configuration** |Board|ISP mode|XSPI0|XSPI1|eMMC|PSRAM| |-----|--------|-----|-----|----|-----| |MIMXRT700-EVK|SW10: 1-4 OFF, 2-3 ON|SW10: 1-4 ON, 2-3 OFF|SW10: 1-4 ON, 2-3 ON|SW10: 1-4 OFF, 2-3 OFF|JP45 to 1-2| To connect the board, follow the steps below: 1. Switch the board to ISP Mode and reset. For more information, see **Table RTxxx EVK boot configuration** in [Connecting the board for RT7xx devices](#connecting-the-board-for-rt7xx-devices). 2. Connect your PC to the **U7** port using the USB cable. 3. Ensure you have started SEC with a new workspace. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 4. Set the connection to **UART** and test the board connection. **Booting from eMMC**: Select **Boot memory eMMC** in the toolbar. **Running image in external RAM**: The image located in XSPI0 flash can be copied into XSPI1 external RAM (PSRAM) during boot and executed from there. XMCD configuration must be used to initialize the external RAM. ### Booting images for RT7xx devices This chapter describes the building and writing of plain and signed bootable images. **You can use several combinations of used memories:** |Memory where the image is executed|Memory where the image is written|XMCD needed|XIP|Supported| |----------------------------------|---------------------------------|-----------|---|---------| |External NOR flash|External NOR flash|No|Yes|Yes| |Internal RAM|External NOR or eMMC|No|No|Yes| |External RAM|External NOR|Yes|No|Yes| |External RAM|eMMC|n/a|n/a|No, ROM limitation| #### Life cycle for RT7xx devices There are two types of life cycles supported: **shadows** and **OTP**. In the **shadows**, the OTP fuses are not burnt and instead shadow registers are used. The shadow registers are initialized via a debug probe so during write the debug probe must be connected with an ISP communication cable. The shadow registers can be used only for development, not for production. #### Booting a plain unsigned/CRC image Plain images are typically used for development. It is recommended to start with this boot type before working with secured images to verify that the executable image works properly. To build a bootable image, follow these steps: 1. In the toolbar, select **Plain unsigned** or **Plain with CRC** in **Boot type**. 2. Switch to the **Build image** view. 3. Select the image build in [Preparing source image for RT7xx devices](#preparing-source-image-for-rt7xx-devices) as a **Source executable image**. If needed, open the **Dual image boot** and configure. If configured, open **OTP configuration** and review all reported problems. 4. Click the **Build image** button to build a bootable image. When the bootable image is successfully built: 1. Connect the board, see [Connecting the board for RT7xx devices](#connecting-the-board-for-rt7xx-devices). 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. If the write operation was successful, switch boot mode to **XSPI boot**\(see **Table RTxxx EVK boot configuration** in [Connecting the board for RT7xx devices](#connecting-the-board-for-rt7xx-devices).\) and reset the board. #### Booting plain signed image using shadow registers This section describes the building and writing of an authenticated image. A signed image cannot be used with the **Development, OTP** life cycle because the ROM does not contain any command to burn CUST-MK-SK without advancing the life cycle. To build a signed image, use the following steps: 1. In the toolbar, set the **Boot type** to **Plain signed**. 2. In the toolbar, set life cycle to **Development, shadows**, **InField, shadows** or **InField-Locked, shadows**. 3. In the **Build image** view, use the image from [Preparing source image for RT7xx devices](#preparing-source-image-for-rt7xx-devices) as a **Source executable image**. 4. Ensure you have keys generated in the **PKI management** view. For more information, see [PKI management](./05_user_interface.md#pki-management). 5. For **Authentication key**, select any key, for example, *ROT1: IMG1\_1*. 6. Generate a random **CUST-MK-SK** and **OEM seed**. 7. If needed, open **Dual image boot** and configure. 8. Open **OTP configuration** and review all reported problems. 9. Click the **Build image** button and check that the bootable image was built successfully. During the build, the tool communicates with the processor to create the device HSM SB file. This does not cause any changes in the processor or in the flash memory. To write the image, do the following: 1. Switch to **Write image** view. 2. Select **main menu \> Target \> Debug Probe** and select the debug probe. The debug probe is used to write the shadow registers. 3. Make sure that the board is set to Serial bootloader \(ISP\) mode. For more information, see [RT7xx device workflow](#rt7xx-device-workflow). 4. Make sure that the **Use built image** checkbox is selected. 5. Click the **Write image** button. During the write operation, the following steps are performed: 1. The shadow registers for the fuses are initialized. 2. The application is written to the processor via the SB file. Change the ISP pins and do soft reset \[button SW2\] to start the application. #### Device HSM The table below shows how the shadows/fuses are configured: **Table Shadows/fuses configuration** |Fuse|Any shadows life-cycle|InField, OTP life-cycle| |----------|---------------|------------| |CUST-MK\_SK|The device HSM SB file is used to initialize the shadow registers.|Device HSM SB file| |Other fuses|OTP shadow registers are initialized via the debug probe.|Device HSM SB file| ## RW61x device workflow This chapter describes the workflow for RW61x processors. ### Preparing source image for RW61x devices The only available boot memory for the RT61x processor is external flash. Optional step: to create the source image for the build in SEC tool, you can disable the boot header by defining the symbol **BOOT\_HEADER\_ENABLE** to 0 \(in MCUXpresso IDE, go to **Project \> Properties \> C/C++ Build \> Settings \> MCU C Compiler \> Preprocessor \> Defined symbols** and set **BOOT\_HEADER\_ENABLE** to **0**\). From SEC tool v9, this step is optional. The SEC tool can parse the bootable image and retrieve the application image from the bootable image. The image shall be at address 0x8001000 \(default in MCUXpresso SDK examples\). ### Connecting the board for RW61x devices This section contains information about configuring the evaluation boards RD-RW612-BGA or RD-RW61x-QFP or FRDM-RW612 and connecting it to SEC. **Table RD-RW boards** |**Board**|**In-System Programming** **\(ISP\) Boot**|**Boot from external FLASH**| |---------|----------------------------------------------|----------------------------| |RD-RW612-BGA|U38 switch: 0001|U38 switch: 0000| |RD-RW612-QFP|U38 switch: 0001|U38 switch: 0000| |FRDM-RW612|Hold the **SW3** button during reset.|Reset without the **ISP** button.| 1. Select ISP boot mode, see **Table RD-RW boards** in [Connecting the board for RW61x devices](#connecting-the-board-for-rw61x-devices). 2. Connect the J7 port \(on FRDM, it is J10\) to your PC with a USB cable. 3. Ensure SEC runs with a workspace created for the chosen device. For more information, see [Setting up Secure Provisioning Tool](#setting-up-secure-provisioning-tool). 4. Go to **main menu \> Target \> Connection** and select UART and test the connection. ### Shadow registers for fuses via debug probe The SEC tool uses **In-Field, shadow registers** as the default life cycle. It means that the **In-Field** life cycle will be configured using shadow registers. For development, start with shadow registers to avoid irreversible changes in fuses, but this should not be used for production. The shadow registers configuration is done via a debug probe, so the probe must be selected first: 1. Go to the **main menu \>Target \> Debug Probe** to open a dialog for debug probe selection. 2. Select a debug probe from the drop-down menu 3. Switch the board switch to boot mode from an external flash and reset the processor; click “Test connection” to check the connection with the debug probe The processor does not allow using shadow registers in the “Develop” life cycle, so by default, the shadow registers for the life cycle will configure the “In-Field” state. Also, to make image booting using shadow registers, it is necessary to configure the boot source in BOOT\_CFG0 shadow register. As the fuse is locked after the first write, the tool will ask you to specify all the other bits \(even for shadow registers\). Go to **OTP configuration** to specify them. In the shadow registers life cycle, the fuses shadow registers are configured immediately after the write image is successfully finished. The SEC tool launches the `write_shadows` script that will set the shadow registers and then resets the processor. After the reset, the processor boots the image. For the encrypted mode, the application is written via the SB file, so RKTH and CUST\_MK\_SK fuses must be programmed \(even if the **shadow registers** life cycle is selected\). ### Booting images for RW61x devices This section describes building and writing bootable images into the external flash and booting. The default SEC tool configuration is prepared for the EVK board. If you are using an FRDM board, use the FlexSPI configuration from the W25Q512 template. In case the flash is locked for write, it is possible to unlock it using the FCB provided in `sample_data`: 1. Select **main menu \> Target \> Boot Memory.** 2. Select FlexSPI NOR - complete FCB. 3. Select the FCB file from the disk. 4. Select the file `sample_data\targets\RW612\source_images\frdmrw612_wb_reset_fcb_quad_spi_v2.fcb`. This file must not be used for production. #### Booting plain or CRC image Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly. First, build a bootable image: 1. Make sure you have selected the **Plain unsigned** or **Plain with CRC** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select an image built in [Preparing source image for LPC55(S)0x/1x/2x/6x devices](#preparing-source-image-for-lpc55-s-0x-1x-2x-6x-devices) as a **Source executable image**. 4. If there is a binary image, set the start address to 0x8001000. 5. Configure BOOT\_CFG0 fuse \(see the previous paragraph\). 6. If needed, open **Dual image boot** and configure. 5. Click the **Build image** button to build a bootable image. The result is a binary bootable image. When the bootable image is built, upload it to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. 5. If the write operation was successful, reset the board. - the image boots automatically if shadow registers are selected - otherwise switch boot mode \(see **Table RD-RW boards** in [Connecting the board for RW61x devices](#connecting-the-board-for-rw61x-devices) \) and reset the board to boot the image. #### Booting plain signed image This section describes building and writing a plain signed image. Build a bootable image: 1. Select the **Plain signed** boot type in the toolbar. 2. Switch to the **Build image** view. 3. Select an image built in [Preparing source image for LPC55(S)0x/1x/2x/6x devices](#preparing-source-image-for-lpc55-s-0x-1x-2x-6x-devices) as a **Source executable image**. 4. For **Authentication key** select any key, for example ROT1: IMG1\_1 5. Use random value for “CUST\_MK\_SK” and “OEM seed” symmetric keys. 6. Ensure that there is no error in OTP configuration. For ECC p384 key length you will need to configure the BOOT\_CFG3 fuse. 7. Make sure that the board is connected and the processor is in ISP mode. During building processes, provisioning SB3 file for installation of CUST\_MK\_SK into processor is prepared. **Note:** The processor is reset after the SB file is built. 8. Keep **In-Field, shadow regs** life cycle to avoid irreversible changes in the processor 9. Click the **Build image** button to build a bootable image. The result is a binary bootable image and SB3 capsule for installation of the image into the processor. When the bootable image and SB3 capsule have been successfully built, you can upload to the processor: 1. Make sure that the processor is in ISP mode. 2. Switch to the **Write image** view. 3. Make sure that the **Use built image** checkbox is selected. 4. Click the **Write image** button. In the shadow register life cycle, no fuses are burnt. The signed application is written into the flash and then shadow registers are applied and the processor is reset to start the application. Once you advance to the life cycle without shadow registers, the fuses will be burnt irreversibly and the SB3 capsule will be used to write the application into the flash. #### Booting encrypted image Encrypted images with plain, CRC, or signed images are supported. The process of creation an encrypted image is similar to a signed image. In addition, it is necessary to configure encrypted regions via the **IPED Regions** button on the **Build image** view \(by default, the whole application is encrypted\). IPED region alignment is based on the page size of the target FLASH, which is retrieved from FCB flash configuration. See [Boot memory configuration](./05_user_interface.md#boot-memory-configuration) for details on how to convert Flex-SPI NOR simplified configuration to full FCB configuration. Due to ROM limitations, the image must be always located inside the IPED region, it is not allowed to erase or write range that exceeds the encrypted region. In combination with the dual boot, configure encryption for image0 only, and the same settings are applied for image1. Image encryption is performed when the image is written to the target memory. The application is written via SB file, so RKTH and CUST\_MK\_SK fuses must be burnt, so the processor can decrypt and authenticate SB file content. Mind these fuses will be burnt even if the shadow registers are selected. The encrypted region is configured in the SB file. The decrypted regions are configured in fuses, so make sure these two are aligned. #### Device HSM and provisioning The CUST\_MK\_SK is a customer key for SB file encryption/decryption and this key can be installed into the processor only using device HSM SB file. The key is stored in the fuses, so the installation is irreversible and once the fuse is written it is locked for write \(the lock is also used to detect if the key is already installed or not\). In the write script, there is an argument to decide whether the key shall be burnt or not. To apply device HSM into the processor, it is necessary to use a device HSM loader FW distributed in restricted data \(for details, see [Preferences](./05_user_interface.md#preferences). The content of device HSM depends on the life cycle, see [Life cycle for RW61x devices](#life-cycle-for-rw61x-devices) for details. #### Life cycle for RW61x devices The following table provides an overview of fuses burnt by the write script for different configurations of life cycle and boot type and contains information on whether the SB3 capsule can be used to update the application image. **Table Boot type and life cycle for RW61x** ||**Shadow regs life cycle**|**Develop life cycle**|**In-Field life cycle**| |-----|--------------------------|----------------------|-----------------------| |**Plain unsigned or CRC** boot type|- No fuses burnt
- SB file not used|- Fuses burnt, see OTP Configuration dialog
- SB file not used| - Same as develop + life cycle fuse burnt
- SB file not used| |**Plain signed** boot type|- No fuses burnt
- SB file not used, however it is generated during build| - Fuses burnt, see OTP Configuration dialog
- RKTH and CUST\_MK\_SK burnt
- SB file used| - Same as develop + life cycle fuse burnt
- SB file used| |**Encrypted** boot type|- RKTH and CUST\_MK\_SK burnt
- SB file used
- No other fuses burnt|- Fuses burnt, see OTP Configuration dialog
- IPED, RKTH, and CUST\_MK\_SK burnt
- SB file used|- Same as develop + life cycle fuse burnt
- SB file used| The table below shows the security assets installed in different life cycles and trust provisioning types: **Table Life cycle and trust provisioning** ||Device HSM Develop |Device HSM In Field|EdgeLock 2GO Develop |EdgeLock 2GO In Field| |------------------|----------|----------|------------|------------| |**CUST MK SK** |Device HSM SB file|Device HSM SB file|CUST-MK\_SK|CUST-MK\_SK| |**RKTH fuses**|Write script|Device HSM SB file|el2go\_provi\_otp.bin|el2go\_provi\_otp.bin | |**Other custom fuses**|Write script|Device HSM SB file|el2go\_provi\_otp.bin|el2go\_provi\_otp.bin| DRY RUN - the EdgeLock 2GO is started in **dry run** mode, there are no irreversible changes in the processor. The secure objects are downloaded and written to flash, the trust provisioning firmware is started and checks the content of the secure objects. #### EdgeLock 2GO EdgeLock 2GO is described in [EdgeLock 2GO Trust Provisioning workflow](./07_generic_workflows.md#edgelock-2go-trust-provisioning-workflow). Below are RW61x-specific comments: - The provisioning firmware does not work if the processor boots into ISP mode. The processor must be in RUN mode and the external flash must be erased. After resetting the processor, as there is no application in the flash, the processor will fall back into ISP mode and EdgeLock 2GO provisioning can be started. - The address for secure objects must be in external flash. After the provisioning is finished, all secure objects \(even secure objects that are already installed\) remain in the memory. - In case of the Develop life cycle, the provisioning works only in **DRY RUN** mode, allowing you to test the process affecting the processor. In this mode, the processor UUID is retrieved and sent to the EdgeLock 2GO server. Then, secure objects are downloaded, applied to the processor \(external flash\) and the provisioning firmware is executed. The firmware verifies the secure objects but does not burn fuses and does not change the life cycle. The application image is **not provisioned**, as the SB file cannot be loaded yet. - To upload the SB3 file into the EdgeLock 2GO server as a secure object, use the following parameters: - Create New Secure Object - Binary File - Assign any name - Set the Object Identified \(OID\) to 0x7FFF817C - Non confidential file - Add Policy/Select Device Life Cycle: Closed - Select permitted algorithm: NONE - Policies for this profile: NONE For uploading secure objects to the EdgeLock 2GO server, use the **Closed/Locked** policy. The **Open** policy is not a preferable option, as **DRY RUN** mode supports the **Closed** policies too.