BootUp Integration
Prev Chapter 278. Atmel SAMA5D3x-MB (MotherBoard) Platform HAL Next

Name

BootUp Integration — Detail

BootUp

BootUp is a lightweight BootROM package that can support features such as in-field upgrades and in the case of the SAMA5 in particular, a secure boot capability.

The BootUp support for the SAMA5D3 targets is primarily implemented in the sama5d3_mb_misc.c file. The functions are 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. Its only purpose is to allow the startup of the main ROMRAM application.

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 can be installed on any SAMA5D3x bootable media, and is not restricted to being placed into SPI Dataflash.

[Note]Note

The NOR flash mapped to EBI_CS#0 is NOT an acceptable boot source for the on-chip first-level RomBOOT code.

On execution BootUp will copy the ROMRAM configured final application from its Non-Volatile-Memory (NVM) location, which currently can either be the SPI Dataflash (default) or the memory-mapped NOR flash. The configuration option CYGIMP_BOOTUP_SAMA5D3_SOURCE selects whether the second-level BootUp code will look for the final application image in SPI or NOR.

[Warning]Warning

When selecting SPI then the relevant CPU Module hardware configuration to allow the on-chip RomBOOT to boot from SPI should be used. This requires that jumper JP1 on the Embest/Flextronics “SAMA5D3x-CM_rev.E” be fitted, and for the Ronetix “SAMA5D3x-CM v2.0” daughterboard jumper J2 should be fitted.

The following diagrams give an overview of the first-level (on-chip RomBOOT) and second-level (SRAM) boot sequence:

Figure 278.1. On-chip RomBOOT executes

On-chip RomBOOT executes

Figure 278.2. On-chip RomBOOT copies second-level boot code from NVM to on-chip SRAM

On-chip RomBOOT copies second-level boot code from NVM to on-chip SRAM

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

SRAM loaded second-level boot code is executed

Figure 278.4. Final application ROMRAM is located in SPI or NOR NVM

Final application ROMRAM is located in SPI or NOR NVM

Figure 278.5. Second-level boot copies ROMRAM from NVM to DDR2-SDRAM

Second-level boot copies ROMRAM from NVM to DDR2-SDRAM

Figure 278.6. Application is started

Application is started

Encrypted Application

The BootUp SRAM application can be configured with a built-in AES-256 key which can be used to decrypt the final ROMRAM application image (as stored on the NVM) prior to execution from its final RAM location. For ease of use during development, the BootUp binary can load both encrypted and plaintext (unencrypted) application images. This allows testing of the boot sequence prior to finalising the application key, or the final application build encryption process.

[Note]Note

This feature is really only relevant (and useful) as part of a secure boot process. When secure boot is NOT being used then by itself encrypting the final ROMRAM application provides no security since the SRAM second-level boot loader can be examined to extract the AES-256 key used to decrypt the application. Using the BootUp decryption support only makes sense when it is part of a complete reset->application security implementation.

As with the normal SRAM based second-level bootstrap world, the on-chip RomBOOT code loads and executes the second-level boot code from any suitable boot source. When BootUp is used as the second-level bootstrap it is configured to look at either the SPI or NOR memories for the encrypted final ROMRAM application image.

Figure 278.7. Second-level boot code built with AES-256 key

Second-level boot code built with AES-256 key

Figure 278.8. Stored key is used to decrypt NVM application into RAM

Stored key is used to decrypt NVM application into RAM

Figure 278.9. Decrypted application is started

Decrypted application is started

Encrypting The “Final” Application

An example host tool to encrypt the final ROMRAM application using a AES-256 key is provided. A pre-built executable is provided, and available from the installed tools path as for the other build related tools. The source for the tool is available in the $ECOS_REPOSITORY/packages/hal/arm/cortexa/sama5d3/sama5d3x_mb/current/host/claes.c file. If required, a Makefile (for GNU make) is provided in the host directory to allow the command to be built locally.

The AES-256 key used to encrypt the application binary MUST be the same key that is built-into the second-level boot loader used to copy the application from its NVM location into RAM for execution.

An example key file is provided in $ECOS_REPOSITORY/packages/hal/arm/cortexa/sama5d3/sama5d3x_mb/current/misc/example256.key, but as always for a production environment the developer is responsible for managing the actual key values used, and for ensuring that embedded keys are not distributed publicly.

Assuming that the application binary is available in the file finalapp.bin, the following example shows how the claes tool can be used to create the encrypted image. 

$ claes -k example256.key finalapp.bin -o encrypted.bin

The encrypted image encrypted.bin would then be stored at the relevant NVM offset using whatever production methodology is in use. If required, for example, the default SAMA5D3 RedBoot application provides the necessary network and flash operations to allow it to be used to initialise the NVM contents from supplied binary images.

The claes command provides a brief description of its options, which can be viewed by requesting --help (or the shorthand -h) on the command-line: 

$ claes --help

Atmel Secure Boot

Details of the Atmel Secure Boot process are beyond the scope of this document, since a customer specific Non-Disclosure-Agreement (NDA) with Atmel needs to be in place. The reader is referred to the Atmel website www.atmel.com with regards to the “Secure Boot on SAMAD3 Series” (Atmel literature number 11165A) documentation.

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 sama5d31_ek minimal
[ … ecosconfig output elided … ]
$ ecosconfig import $ECOS_REPOSITORY/packages/hal/arm/cortexa/sama5d3/sama5d3_mb/current/misc/bootup_SRAM.ecm
$ ecosconfig resolve
$ ecosconfig tree
$ make

The resulting install/bin/bootup.bin binary can then be programmed into a suitable non-volatile memory as supported by the SAMA5D3 on-chip RomBOOT.

The example bootup_SRAM.ecm is configured to expect to find the ROMRAM application stored in the SPI Dataflash at offset CYGNUM_BOOTUP_SAMA5D3_SOURCE_OFFSET. It also is configured with application encryption support (CYGFUN_BOOTUP_SAMA5D3_SOURCE_SECURE option) to allow decryption of the SPI Dataflash stored application to its final RAM destination.

[Note]Note

The application image to be loaded does not need to be encrypted. The BootUp code checks the embedded application binary identity markers to check for a plaintext (unencrypted) image to be started, prior to attempting to decrypt the data and check for a valid encrypted image at offset CYGNUM_BOOTUP_SAMA5D3_SOURCE_OFFSET in the source NVM.

Prev Up Next
The HAL Port Home Chapter 279. Atmel SAMA5D3x-CM (CPU Module) Platform HAL