BootUp second level boot loader — Bootstrap
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.
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
JSDRAM, but the application
could also be the special-case
startup type for a RAM based RedBoot image, or some other
platform specific SDRAM or other external-memory startup type
Building a BootUp loader image is most conveniently done at the
command line. The steps needed to rebuild the
version of BootUp are:
ecosconfig new[ … ecosconfig output elided … ] $
ecosconfig import $ECOS_REPOSITORY/packages/hal/cortexm/imx/var/current/misc/bootup_SRAM.ecm$
TARGET is replaced with the
required i.MX target platform name,
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.
configured to expect to find the application stored in the
selected FlexSPI flash from the address offset
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
For convenience, prebuilt wrapped BootUp images named
qspi_bootup.bin are provided with
eCosPro releases in the
subdirectory of your eCosPro installation alongside
the unwrapped BootUp images as well as various RedBoot
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
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.
|2023-08-15||eCosPro Non-Commercial Public License|