BootUp

BootUp (CYGPKG_BOOTUP) is a lightweight second-level boot loader package, which can be extended with VAR and PLF specific features as required (e.g. firmware updates, secure boot, etc.).

The BootUp support for the i.MX RT targets is primarily implemented in the imx_support.c file. The functions are normally only included when the CYGPKG_BOOTUP package is being used to construct the actual BootUp loader binary.

The BootUp code is designed to be very simple, and it is envisaged that once an implementation has been defined the binary will only need to be installed onto a device once.

Alternative

An alternative to using BootUp to start applications is to use a SRAM (OCRAM) based RedBoot to manage the flash space, and to use the RedBoot features to load and start the main application.

The benefit of RedBoot is the ability for command-line interaction with the management of the stored application. The downside of RedBoot is the code+data space overhead and potential for run-time performance costs when using (via the virtual vector interface) RedBoot features or debugging an application via RedBoot. The BootUp package offers a light weight solution without impacting the memory space or performance of the final application, and is better suited to a H/W debugger development environment.

Boot details

Currently, its only purpose is to allow the startup of the main application when linked for external memory (e.g. SDRAM) since the i.MX RT ROM Bootloader will only load and execute applications to SRAM (OCRAM). If an SRAM based application is to be booted then the BootUp intermediate (second-level) code is not needed since the CPU can directly load and start the SRAM application from the bootable NVM.

This platform specific documentation should be read in conjunction with the generic BootUp package documentation.

The BootUp package provides a basic but fully functional implementation for the platform. It is envisaged that the developer will customize and further extend the platform side support to meet their specific application identification and update requirements.

The BootUp binary iself can be installed on any i.MX RT bootable media, and is not restricted to being placed into FlexSPI flash.

On execution BootUp will copy the configured final application from its Non-Volatile-Memory (NVM) location to its destination address and start the application. The configuration option CYGIMP_BOOTUP_IMX_SOURCE selects where the second-level BootUp code will look for the final application image. The available options depend on the configured target CPU, and whether the variant/platform specific BootUp has support for the specific storage medium.

The following diagrams give an overview of the first-level (on-chip) ROM Bootloader and second-level (SRAM) boot sequence. Blocks shown in green indicate running code. The blue arrows indicate a memory copy operation. The red arrows indicate a switch in execution. The BootUp application image stored in the bootable NVM is expected to be a valid image prefixed with FCFB, BootData, DCD and IVT information as required for the on-chip ROM Bootloader. This example is for the final application binary to be executed from SDRAM.

Figure 312.1. On-chip ROM Bootloader executes

Figure 312.2. On-chip ROM Bootloader copies second-level boot code from NVM to on-chip SRAM

Figure 312.3. SRAM loaded second-level boot code is executed

Figure 312.4. Final application is located in NVM

Figure 312.5. Second-level boot copies application from NVM to SDRAM

Figure 312.6. Application is started

The example above shows an application with the platform startup type JSDRAM, but the application could also be the special-case RBRAM startup type for a RAM based RedBoot image, or some other platform specific SDRAM or other external-memory startup type as required.

$ mkdir bootup_SRAM
$ cd bootup_SRAM
$ ecosconfig new TARGET minimal
[ … ecosconfig output elided … ]
$ ecosconfig import $ECOS_REPOSITORY/packages/hal/cortexm/imx/var/current/misc/bootup_SRAM.ecm
$ ecosconfig resolve
$ ecosconfig tree
$ make