[RT-117x] Going through the MX-RT1170 hard/soft platform
Going through the MX-RT1170 hard/soft platform
最后更新于
Going through the MX-RT1170 hard/soft platform
最后更新于
The reference board quick guide is shown in the link: https://www.nxp.com.cn/docs/en/quick-reference-guide/MIMXRT1170-EVK-QSG.pdf and https://www.nxp.com/document/guide/getting-started-with-the-i-mx-rt1170-evaluation-kit:GS-MIMXRT1170-EVK#title3_1
Plug the power adapter wire into the MIMXRT1170-EVK board 5V DC IN header (J43) and switch on 5V DC IN (SW5).
As an embedded developer, you may pay more attention to the following:
Serial port: the Debug USB port will map the onboard linker service and serial port /dev/ttyACM0.
Debug port:
Onboard linker service (DAP-Link)
External J-Link.
The OpenSDA circuit (CMSIS–DAP) is an open-standard serial and debug adapter. It bridges serial and debug communications between a USB host and an embedded target processor
CMSIS-DAP features a Mass Storage Device (MSD) bootloader, which provides a quick and easy mechanism for loading different CMSIS-DAP Applications such as flash programmers, run-control debug interfaces, serial-to-USB converters, etc. Two or more CMSIS-DAP applications can run simultaneously. For example, run-control debug application and serial-to-USB converter run in parallel to provide a virtual COM communication interface while allowing code debugging via CMSIS-DAP with just a single USB connection.
For the IMXRT1170 EVK board, J11 is the connector between the USB host and the target processor. Jumper to serial downloader mode uses the stable DAP-Link debugger function. If developer wants to make OpenSDA going to the bootloader mode, jumper J27 to 1-2 and press SW3 when power on. Meanwhile, the OpenSDA supports drag/drop feature for U-Disk.
i.MX RT1170 crossover MCUs are part of the EdgeVerse™ edge computing platform and are setting speed records at 1 GHz. The dual core i.MX RT1170 MCU runs on the Arm® Cortex®-M7 core at 1 GHz and Arm Cortex-M4 at 400 MHz. For more information, please refer to https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-mcus/i-mx-rt1170-first-ghz-crossover-mcu-with-arm-cortex-m7-and-cortex-m4-cores:i.MX-RT1170.
The boot process begins at the Power-On Reset (POR) where the hardware reset logic forces the ARM core to begin the execution starting from the on-chip boot ROM. The boot ROM uses the state of the BOOT_MODE register and eFUSEs to determine the boot device. The boot ROM code also allows to download the programs to be run on the device. The example is a provisioning program that can make further use of the serial connection to provide a boot device with a new image.
Device Configuration Data (DCD). DCD feature allows the boot ROM code to obtain the SOC configuration data from an external program image residing on the boot device. As an example, the DCD can be used to program the SDRAM controller (SEMC) for optimal settings, improving the boot performance. The DCD is restricted to the memory areas and peripheral addresses that are considered essential for the boot purposes.
The imx-rt1160 bootflow is shown in the following figure:
Boot ROM stage
The figure found here show the high-level boot ROM code flow:
The mainly features of the Boot Rom include:
Support for booting from various boot device
Serial downloader support (USB OTG and UART)
Device Configuration Data (DCD) and plugin
Digital signature and encryption based High-Assurance Boot (HAB)
Wake-up from the low-power modes
Encrypted eXecute In Place (XIP) on Serial NOR via FlexSPI interface powered by Bus Encryption Engine (BEE)
Encrypted boot on devices except the Serial NOR by Data Co-Processor (DCP) controller The Boot Rom supports these boot devices:
Serial NOR Flash via FlexSPI
Serial NAND Flash via FlexSPI
Parallel NOR Flash via Smart External Memory Controller (SEMC)
RAWNAND Flash via SEMC
SD/MMC
SPI NOR/EEPROM
Secondary bootable Image stage
Overview
There are two types of i.MX MCU bootable image:
Normal boot image: This type of image can boot directly by boot ROM.
Plugin boot image: This type of image can be used to load a boot image from devices that are not natively supported by boot ROM.
Both types of image can be unsigned, signed, and encrypted for different production phases and different security level requirements:
Unsigned Image: The image does not contain authentication-related data and is used during development phase.
Signed Image: The image contains authentication-related data (CSF section) and is used during production phase. For more information, please refer to
Encrypted Image: The image contains encrypted application data and authentication-related data and is used during the production phase with higher security requirement. For more information, please refer to https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/13/rt1170_documents/rt-117x-i.mx-rt1170s-secure-boot
Boot Options
The imx RT family supports a number of different boot sources and includes the option for memory to be copied to on-chip or external destination memory, as well as Execute in Place (XIP) for some interfaces. For more information, please refer to https://www.nxp.com/docs/en/application-note/AN12107.pdf.
The FlexSPI NOR Boot flow is shown in the following diagram:
The on-chip RAM = FlexRAM (512KB + 256KB) + OCRAM(1.25MB)
RAM boot
The RAM boot mode is an option for external NVM to be copied to an on-chip or external RAM, then executes the boot image from the on-chip or external RAM.
boot source
The boot sources of the RAM boot as follows:
FlexSPI NOR/NAND Flash or EEPROM
SD/eMMC
Serial (USB/UART)
boot destination
The boot destination of the RAM boot as follows:
System RAM (ITCM/OCRAM)
External SDRAM.
With BootROM, the i.MX RT can boot from various external flash devices in the XIP (NOR-only) or non-XIP modes. Based on the IVT and BD information in the Bootable image, the bootROM either starts up the application binary directly (XIP) or copies the bootable image to the RAM and starts up the application binary (non-XIP).
The figure shows the process of the non-XIP boot:
Stage 1: Bootable image is in the external flash.
Stage 2: BootROM loads the starting 4 KB of data from the bootable image to the internal SRAM (OCRAM). It includes the IVT and BD information and will be used for the application image loading.
Stage 3: BootROM transfers the starting 4 KB of data from the internal SRAM (OCRAM) to the destination address space of the bootable image.
Stage 4: BootROM continues loading the rest of the bootable image from the external flash to the destination address space and starts up the application binary.
XIP boot
Execute in place (XIP) is a method of executing programs directly from long-term storage rather than copying it into RAM. It is an extension of using shared memory to reduce the total amount of memory required.
The XIP mode is boot directly from:
FlexSPI NOR Flash
SEMC Parallel NOR Flash
Serial(1-bit SPI) NOR via Flexcomm SPI (Design for Recovery boot)
There are many types NOR Flash can be selected:
Boot related address
This is following the the ARMv7-M Architecture Reference Manual - Address Mapping.
Boot settings
The BOOT_MODE is initialized by sampling the BOOT_MODE0 and BOOT_MODE1 inputs on the rising edge of the POR_B and stored in the internal BOOT_MODE register (can be read from SRC_SBMR2[BMOD[1:0]]).
Typically, the internal boot is selected for normal boot, which is configured by external BOOT_CFG GPIOs. The Table 4shows the typical Boot Mode and Boot Device settings.
Boot Image consists
The Boot Image consists of:
Image Vector Table (IVT): A list of pointers located at a fixed address that the ROM examines to determine where the other components of the program image are located.
Boot Data: A table that indicates the program image location, program image size in bytes, and the plugin flag.
Device Configuration Data (DCD): IC configuration data (ex: SDRAM register config).
User code and data.
CSF (optional): signature block for Secure Boot, generated by CST. For more information, please refer to https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/13/rt1170_documents/rt-117x-i.mx-rt1170s-secure-boot
KeyBlob (optional) – a data structure consists of wrapped DEK for encrypt boot. For more information, please refer to https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/13/rt1170_documents/rt-117x-i.mx-rt1170s-secure-boot
Each bootable image starts with appropriate IVT. In general, for the external memory devices that support the XIP feature, the IVT offset is 0x1000, otherwise, it is 0x400. For example, for FlexSPI NOR on RT1052, the IVT must start at address 0x60001000 (start address is 0x6000_0000, IVT offset is 0x1000).
The IVT data structure is shown in the following table:
The Boot data structure is shown in the following table:
How to generate a secondary bootable image?
The Elftosb utility is a command-line host program used to generate the i.MX bootable image for the i.MX MCU boot ROM. Elftosb tool supports SREC input program images.
Please refer to the pdf file at https://drive.google.com/file/d/1Y16oT1R-JJcHb-pvpN51YiI8rOnjDpv5/view?usp=drive_link.
It also can generate wrapped binary file with command sequences and bootable image together called SB file, using corresponding options and proper command file called BD file. (MFGTool using this .sb file)
How to burn a secondary bootable image?
DAP-Link (OpenSDA MSD drag/drop)
MFG tool
The chip supports recovery devices. If the primary boot device fails, the boot ROM tries to boot from the recovery device using one of the LPSPI ports. To enable the recovery device, the recovery boot fuse must be set. Additionally, the serial EEPROM fuses must be set as described in Serial NOR/EEPROM through LPSPI. The boot ROM code determines the type of device using the following parameters, provided by the eFUSE settings during boot.
The following figure shows the relationship of tools and IDE:
There is many binary formats that are related to the NXP bare-mental platform, please refer to the link https://mcuoneclipse.com/2017/03/29/mcuxpresso-ide-s-record-intel-hex-and-binary-files/.
Arm GNU Toolchain is a community supported pre-built GNU compiler toolchain for Arm based CPUs. https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads:
On Linux host: AArch32 bare-metal target (arm-none-eabi)
On Windows host: AArch32 bare-metal target (arm-none-eabi)
The MCUXpresso software development kit (SDK) is complimentary and includes full source code under a permissive open-source license for all hardware abstraction and peripheral driver software. https://mcuxpresso.nxp.com/en/builder?hw=MIMXRT1170-EVK.
new MCUXpresso SDK projects, and also provides pin and clock tools to generate initialization C code for custom board support. It is fully integrated into MCUXpresso or you can download it as a separate tool. You can get it from the link.
How to import hello world project, please refer to view the video from NXP https://www.nxp.com/document/guide/getting-started-with-the-i-mx-rt1170-evaluation-kit:GS-MIMXRT1170-EVK#title3_1. You can also get the user guide from https://drive.google.com/file/d/139VHbo-dKn2ovUIOdJZzyQaRVg4JUjUq/view?usp=drive_link.
DAP-Link (OpenSDA MSD drag/drop)
QSPI Flash on EVK only.
Binary file supports only.
The default firmware of DAP-Link on EVK supports Hyper Flash only. The firmware of DAP-Link should be replaced if the QSPI flash drag/drop is used. The firmware can be downloaded from https://drive.google.com/file/d/1BqRt33RNvixfIt6PPuf7axTCj7_IFY9L/view?usp=drive_link
MFG tool
Window OS only. Don’t use it.) The MfgTool supports I.MXRT BootROM and KBOOT based Flashloader, it can be used in factory production environment. The Mfgtool can detect the presence of BootROM devices connected to PC and invokes “blhost” to program the image on target memory devices connected to i.MX MCU device. The blhost is a command-line host program used to interface with devices running KBOOT based Bootloader, part of MfgTool release .sb file support only. Download address: https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/lpcxpresso-boards/mcu-bootloader-for-nxp-microcontrollers:MCUBOOT
mcu-boot-utility
This section will introduce the three boot modes:
Using non-XIP.
Using XIP mode.
Using serial mode. (For provisioning and image flash-loader)
Serial NOR can be said to be the most familiar startup device. Although this device can support two types of apps (XIP and non-XIP) to start, it is undoubtedly XIP App that you use most. Because the length of the app code under XIP can be as large as the capacity of Flash, which is very important for applications with complex functions. However, there are some points to pay attention to when writing XIP App code, For example, there are some restrictions when configuring the system clock (which cannot affect the FlexSPI module) or when writing Flash (if RWW is not supported, it needs to be copied to RAM for execution).
As for non-XIP, compared with XIP, there will be one more app copy process, and the startup time will inevitably become longer. There are many types of copy target devices, which can be internal RAM (including TCM and OCRAM) or external RAM (SDRAM or HyperRAM). In order to improve the efficiency of code execution, it is usually moved to the internal TCM for execution. Of course, it can also be moved to external SDRAM for execution. However, in this case, the DCD function needs to be used additionally to complete the initialization of the SEMC module before moving.
The RAM boot mode is an option for external NVM to be copied to an on-chip or external RAM, then executes the boot image from the on-chip or external RAM.
Note, the Nor FLASH is QSPI NorFlash, the QSPI Flash chip is shown in the following figure:
Hardware Design
In the demo’s design, the QSPI chip is IS25WP128-JBLE. The rt1170’s flexSPI interface supports the two type of the connection methods (single flash and multi flashes). It is shown in the following figure:
It is the most common case to use a flash in system design. The flash is responsible for storing the application code (so-called Code Flash). i.MXRT can be executed in the original place of Flash, and can also copy the application program to internal RAM for execution.
In the non-XIP mode, the image will load to the RAM from the Nor FLASH when the board powers on. So the BootROM must basically know what is the image start address and size. Therefore, a bootable image containing the boot header is storing information of the image start address, size and configurations.
For the non-XIP mode, the RAM mapping is shown in the following figure:
The 0x2020_0000 - 0x2020_7FFF, is reserved by the BootROM.
The 0x2020_8000 - 0x2020_8FFF, is reserved by the initial non-XIP image.
The XIP .ro/.bss/stack sections should be linked to the over the 0x2020_9000.
Generating Application
Disable the XIP_BOOT_HEADER_ENABLE
For the detail reason, please refer to the https://community.nxp.com/t5/i-MX-RT/XIP-BOOT-HEADER-ENABLE-Symbol-Effect/m-p/1391290. Meanwhile, disable the XIP_EXTERNAL_FLASH
Changing the RAM mapping
According to the above figure non-XIP mode RAM mapping, we should load the application to the RAM memory that can be the on-chip RAM (OCRAM or TCM) or the external RAM (SDRAM).
According to the above the stage 3 of non-XIP processes, we should reserved the at least 2KB RAM space for the boot header of the BootROM copied from the OCRAM. As a result, the RAM address to be linked are showing in the following:
Note, The order of RAM items is meaningful. The first item is the application’s vector linking.
The next is set the Link application to RAM, it will ignore the FLASH type on the above RAM list figure.
When you compiled the application, you would confirm the isr_vector is matching your SRAM_ITC item.
You also can select the external RAM, such as the SDRAM. The SDRAM is mapped to 0x8000_0000 address. However, there are many types of external SDRAM, the BootROM cannot know what is the SDRAM used in your board. Therefore, the BootROM loads the named DCD data file to initialize the external SDRAM.
MCUXpreeo IDE has integrated DCD config tool that is shown in the following figure:
Note, it will change your source code.
Then uses the boot utility:
This part referenced:
The boot method cannot be implemented, because hardware does not support it. No eMMC on the board, and when use the SD, the hardware should be modified.
You can refer to the link (3.4. MFG boot from Hyper Flash) to burn the OCTAL FLASH using the MFG tool, or (3.3. OpenSDA Drag/Drop and boot from Hyper Flash) using DAP-Link (OpenSDA MSD drag/drop).https://drive.google.com/file/d/1mCbtAAQ0Z34a8Iq3ay8qJbCjOP8vg5_A/view?usp=drive_link
The boot method cannot be implemented, because hardware does not support it. No NAND FLASH on the board.
If boots device from the XIP mode, the source memory is serial NOR Flash (1-bit SPI or QSPI) or parallel NOR Flash.
The HyperFlash or Nor FLASH XIP Boot Image layout is shown in the following figure:
The following table shows three macros that are added in flexspi_nor targets to support XIP:
If you want to use the QSPI Flash, the onboard Hyper Flash should be removed, otherwise it will impact the QSPI Flash read and write timing. As the result, only one type FLASH can be enabled on one board.
On the IMXRT1170 EVK board, there is one 512 Mbit Hyper Flash device. If the developer wants to boot from the Hyper Flash. By default, the Hyper Flash is not used. To enable the onboard Hyper FLASH, the settings must be changed.
Remove resistors: R380/R399/R386/R390/R392/R385.
Weld 0 Ω resistors: R381/R378/R382/R389/R402/R377/R388/R391.
The boot method cannot be implemented, because hardware does not support it.
For programming the QSPI FLASH, you can make use of the DAP-Link(OpenSDA MSD drag/drop) or MFG tool(uuu). For the DAP-Link, the QSPI Flash on EVK only and Binary file supports only.
Hardware
For the hardware design, please refer to the link #3.3.2-booting-from-the-serial-nor-flash-up-to-504mb
Memmap
For the XIP mode, the RAM mapping is shown in the following figure:
The 0x2020_0000 - 0x2020_7FFF, is reserved by the BootROM.
The XIP .ro/.bss/stack sections should be linked to the over the 0x2020_8000.
Application
When we use the mode of the XIP, the instructions (program) are loaded by the CPU’s i-cache directly. In contrast to non-XIP mode, the BootROM does not need to be aware of the application start address. As a result, XIP_BOOT_HEADER_ENABLE=0 is set for the project.
Using the IDE
The MCU config is shown in the following figure:
using the ARMCC
In the `flags.cmake` file:
download
Please refer to https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/13/rt1170_documents/rt-117x-imx-rt1170-provisioning-guideline
The boot method cannot be implemented, because hardware does not support it. No parallel NOR FLASH on the board.
The Flexible RAM Controller (FLEXRAM) provides access control, as well as Single-bit Error Correction and Dual-bit Error Detection (SEC-DED) ECC, from TCM/OCRAM to 512KB of on-chip RAM. Another 128KB of on-chip RAM is allocated to store ECC cipher or used by OCRAM to store normal data. You can refer to the pdf https://drive.google.com/file/d/1QXkQ0qL3eg0b3rxxH3PCgK5PeKgzS-lK/view?usp=drive_link.
The memory system includes support for the connection of local Tightly Coupled Memory called ITCM and DTCM. The ITCM has one 64-bit memory interface and the DTCM has two 32-bit memory interfaces, D0TCM and D1TCM, selected on bit[2] of the request address. Each TCM interface is a physical connection on the processor that is suitable for connection to SRAM with minimal glue logic. These ports are optimized for low-latency memory.
The TCM interfaces are designed to be connected to RAM, or RAM-like memory, that is, Normal-type memory in the Arm architecture. The processor can issue speculative read accesses on these interfaces. Therefore, read accesses through the TCM interfaces can be repeated, and can access uninitialized or nonexistent memory locations. This means that the TCM interfaces are generally not suitable for read-sensitive devices such as FIFOs. If an access is speculative, the processor ignores any error or retry signaled for the access, see TCM interface protocol.
The flexRAM cannot be accessed before the releasing the M7, when use the M4 as primary boot.
Offset
Field
Description
0x00-0x03
start
Absolute address of the bootable image
0x04-0x07
length
Size of the bootable image
0x08-0x0b
plugin
Plugin flag, set to 0 if it is a normal boot image
Code Section
Data Section
I-TCM
D-TCM
MACRO IN SDK
Description
XIP_EXTERNAL_FLASH
1: Exclude the code which will change the clock of flexspi. 0: make no changes.
XIP_BOOT_HEADER_ENABLE
1: Add flexspi configuration block, image vector table, boot data and device configuration data(optional) to the image by default. 0: Add nothing to the image by default.
XIP_BOOT_HEADER_DCD_ENABLE
1: Add device configuration data to the image. 0: Do NOT add device configuration data to the image.
Code Section
Data Section
Code XIP in Hyper Flash
Data in D-TCM
Code XIP in Hyper Flash
Data in SDRAM
Offset
Field
Description
0x00 - 0x03
header
0x04 - 0x07
entry
Absolute address of the first instruction to execute from the image, or thevector address of the image
0x08 - 0x0b
reserved1
Reserved for future use, set to 0
0x0c - 0x0f
dcd
Absolute address of the image DCD. It is optional, so this field can be set to NULL if no DCD is required.
0x10 - 0x13
boot_data
Absolute address of the boot data
0x14 - 0x17
self
Absolute address of the IVT.
0x18 - 0x1b
csf
Absolute address of the Command Sequence File (CSF) used by the HAB library.
0x1c - 0x1f
reserved2
Reserved, set to 0
