# Common Features

The four modes of operation build on each other, with available features in one also being available for the next level. For example, all secure bootloader functionality is still available when using the secure storage mode of operation. This is indicated in the "Bootloader Options" figure.

Figure: Bootloader Options

The bootloader divides the main flash memory into two areas: the app download area and the app execution area. This division provides a starting point for users who want to use the bootloader for firmware update purposes.

The bootloader application is the first application entry point after reset. It is located at the base address of the main flash (0x00100000).

Upon start, the bootloader checks the app download area for a valid boot image. This application can be a regular application, or a new bootloader. If there is one, the bootloader copies/overwrites this image into the app execution area, invalidates the data in the download area, and boots this new image. If no valid boot image is found in the download area, the bootloader verifies and boots from the app execution area. If no valid image is found in either area, the bootloader defaults to a mode where the UART can be used to provide updates or perform attestation queries. It prints an error message in the RTT Viewer. Sequence diagrams in Basic Bootloader, Secure Bootloader, and Attestation show detailed step-by-step procedures.

A valid boot image consists of a binary file generated from a .hex file. The .hex file is created by building the project as usual, but with certain requirements. A valid boot image for an application must have its .text section starting at the base address of the app execution area, instead of at the base address of the main flash. Therefore, making a typical sample application—for example, blinky—compatible with the bootloader requires modifications to the linker script (sections.ld) and startup code (startup.S). An example version of blinky is provided along with the secure bootloader, in a utilities subfolder. The sections.ld file must include the correct start locations and sizes for the sections of flash, and the startup.S must include the appropriate update to the IVT (ISR Vector Table) for the image descriptor.

IMPORTANT: For proper operation, the defined app excution area and the application’s IVT must be aligned to a 512-byte boundary.

Updating the firmware image, as well as basic attestation operations, can be accomplished using the RSLUpdate utility, packaged along with the RSLSec security tools. Examples of how to use RSLUpdate are included in the readme file of the secure_bootloader sample application. More information about the secure operation and updating process is described in Secure Bootloader.

When GPIO14 is tied to ground, the device enters the bootloader state, expecting updates via the UART.

When GPIO14 it is not tied to ground, and an update is pending, the device tries to process the update and reset; the bootloader tries to execute an application if one if available; and if no application is available, the device goes into the bootloader state.