BootUp second level boot loader — Bootstrap


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.


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

On-chip ROM Bootloader executes

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

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

SRAM loaded second-level boot code is executed

Figure 312.4. Final application is located in NVM

Final application is located in NVM

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

Second-level boot copies application from NVM to SDRAM

Figure 312.6. Application is started

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.

Building BootUp

Building a BootUp loader image is most conveniently done at the command line. The steps needed to rebuild the SRAM version of BootUp are:

$ 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

Where TARGET is replaced with the required i.MX target platform name, e.g. mimxrt1064_evk, mimxrt1050_evk, etc.

The resulting install/bin/bootup.bin binary can then be packaged into a bootable image (see platform specific documentation), with that bootable image subsequently programmed into a suitable non-volatile memory as supported by the i.MX RT on-chip ROM Bootloader. To be clear, the BootUp binary itself needs to be wrapped with the descriptors required by the i.MX RT ROM Bootloader but the binary started by BootUp is just the unmodified final application binary.

The example bootup_SRAM.ecm is configured to expect to find the application stored in the selected FlexSPI flash from the address offset CYGNUM_BOOTUP_IMX_SOURCE_OFFSET.

The option CYGIMP_BOOTUP_IMX_SOURCE selects the NVM location used by BootUp. Currently this is limited to the FlexSPI flash interface(s), and will default to the controller instance used by the ROM Bootloader to match the device where the second-level boot loader is stored.

For convenience, prebuilt wrapped BootUp images named qspi_bootup.bin are provided with eCosPro releases in the loaders/target subdirectory of your eCosPro installation alongside the unwrapped BootUp images as well as various RedBoot images.

Application Signature

The BootUp loader will only copy and start execution of binaries with a suitable “signature” block. For the i.MX targets the location of the descriptor block is fixed at the offset of 8-bytes within the binary image (CYGNUM_BOOTUP_SIGNATURE_OFFSET).

The binary image descriptor provides “magic” identifier values used to detect a complete signature block, and the descriptor holds the necessary information required by BootUp. e.g. a length field specifying the number of bytes in the binary image.

If the binary image at offset CYGNUM_BOOTUP_IMX_SOURCE_OFFSET is not valid then BootUp will enter the hal_imx_badapp() function. The VAR HAL provides a default implementation which is a simple infinite loop, but the weak VAR HAL definition can be overridden by a PLF specific implementation if required.