SAMA5D2 Series Boot Process

Introduction

This training topic explains the boot process of the Microchip Technology SAMA5D2 series Arm^® Cortex^®-A5 processor-based microprocessor units (MPU) from reset to running an operating system (embedded Linux^® or RTOS) or application. The boot process begins with the MPU’s power-on reset and progresses in stages reading binary files from external Non-Volatile Memory (NVM) and loading them into volatile memory (internal Static RAM (SRAM) and external Dynamic RAM (DRAM)).

The first-stage bootloader, located in the MPU’s internal ROM (also known as Boot ROM), performs basic initialization and configuration of the device. Its main purpose is to locate a valid second-stage bootloader and read it from external NVM and store it in the MPU’s internal SRAM.

The second-stage bootloader continues the initialization and configuration of the MPU. Its main purpose is to read the third stage binary (bootloader, operating system or application), located in external NVM, and store it in external DRAM. The third stage can be one of the following:

• Third-stage bootloader (for example, Das U-Boot)
• Linux operating system directly (does not require a third-stage bootloader)
• MPLAB^® Harmony 3 Software Framework application
• Real Time Operating System (RTOS)
• Turn over control to a Debugger (JTAG) (no application is loaded)

Each stage is customizable. The second and follow-on stages are external programs (available as source code) that are configured and compiled by the developer. During development and debugging, the resulting binary files can be stored in an external NVM using a Debug Probe and the SAM-BA^® In-System Programmer utility program or copied to a detachable storage device, such as an SD memory card.

The developer must be knowledgeable of the MPU’s boot process so that each stage is configured and compiled as required by the operating system or application.

References

• SAMA5D2 series Datasheet – Section 17. Standard Boot Strategies

Back to Top

Processor Reset

The MPU begins the boot process upon reset. The Reset Controller (RSTC) handles all reset events of the device.

The RSTC responds to the sources listed in the table below and asserts internal signals:

• Processor Reset – resets the processor and embedded peripherals
• Backup Reset – resets all peripherals powered by VDDBU

The RSTC reports which reset occurred last in the RSTC Status Register.

The MPU’s Program Counter (PC) is reset to 0x0000 0000 and will begin executing the first-stage bootloader located in internal Read-Only Memory (ROM).

Back to Top

First-Stage Bootloader

MPUs contain an internal ROM (also known as Boot ROM) that contains the first-stage bootloader. It is the program that begins executing when the MPU is reset.

The purpose of the first-stage bootloader is to:

1. Initialize processor and master clocks

2. Read the Boot Configuration Word

3. If (valid code found) in external NVM, then:

   • Load second-stage bootloader at91bootstrap into internal SRAM
   • Remap internal SRAM to address 0x0
   • Reset the PC to 0x0 and jump

4. Else if (no valid code found) start the SAM-BA Monitor

Let’s look at each of these steps in more detail.

Read the Boot Configuration Word

The first-stage bootloader initially reads the Boot Configuration Word located in the Secure Fuse Controller (SFC).

The SFC contains user-configured, non-volatile, one-time programmable memory. The user area contains 544-bits of which 32-bits are reserved for the Boot Configuration Word.

The Disable Read of the Boot Sequence Controller Configuration Register (DISABLE_BSCR) bit is tested.

• If DISABLE_BSCR = 1: the Boot Configuration Word read from the SFC will be used.
• If DISABLE_BSCR = 0 (default): read the Boot Sequence Controller Configuration Register (BSC_CR)
• If BUREG_VALID = 0: the Boot Configuration Word read from SFC will be used.
• If BUREG_VALID = 1: Read the Backup Register Index (BUREG_INDEX) value and read the Boot Configuration Word from BUREG_n.

Reading the Boot Configuration Word from a Backup Register (BUREG_n) is especially helpful during prototyping. Using BUREG allows the user to test several boot configuration options, including Secure Boot mode, without burning fuses.

The BUREG is located in SRAM in the Security Module (SECUMOD). The registers will retain their value if VDDBU is powered.

Once the device is put into production, it is highly recommended that the Boot Configuration Word be programmed into the SFC with BCW:DISABLE_BSCR = 1 (must be set by the user).

The Boot Configuration Word customizes the first-stage bootloader. The following items can be configured:

• Configure the I/O Set where the external memories are connected
• Enable/disable boot on selected memories
• Configure the UART port for console serial communications
• Configure the JTAG port for debugging

Details of the Boot Configuration Word are shown in the figure above and a short description, with default bit settings, is shown below:

• SECURE_MODE: Enable Secure Boot mode (default: disabled – standard boot sequence)

The SAMA5D2 Series of Arm Cortex-A5 processor-based MPUs can load signed and encrypted programs during the boot process. This allows only authorized code to load and execute on the processor.

Enabling the ROM Boot Code for Secure Boot mode requires a Non-Disclosure Agreement (NDA) from Microchip Technology. Contact your nearest Microchip Sales office for instructions on how to attain confidential application note AN2435, SAMA5D2 series Secure Boot Strategy (Lit. No. DS00002435).

• DISABLE_MONITOR: Disable SAM-BA Monitor (default: disabled – if no boot file found, launch SAM-BA Monitor)
• DISABLE_BSCR: Disable read of Boot Sequence Controller Configuration Register (BSC_CR) (default: disabled – Read the BSC_CR to determine if Backup Register Valid (BUREG_VALID))
• QSPI_XIP_MODE: Enable XIP mode on QSPI Flash (default: disabled – Access in QSPI mode)
• EXT_MEM_BOOT_ENABLE: Enable Boot on external memories (default: disabled – external memory boot disabled)

For MRL C and later devices, the first-stage bootloader will attempt to read from SDMMC_0 and SDMMC_1 before testing the EXT_MEM_BOOT_ENABLE bit.

For more detailed information, see the SAMA5D2 series datasheet – Section 17. Standard Boot Strategies

• JTAG_IO_SET: Select pins used for JTAG access (default: use JTAG I/O Set 1)

JTAG port access is disabled during the execution of the first-stage bootloader. It is enabled when:

If valid code found in external NVM, code loaded, SRAM remap, PC to 0x0 and jump

Else if no valid code found, starts SAM-BA Monitor, locks access to internal ROM

The JTAG port can be DISABLED by the Boot Configuration Word.

• UART_CONSOLE: Select/disable UART I/O Set for console terminal (default: use UART1 I/O Set 1)
• SDMMC_1: Disable SDCard/e.MMC boot on SDMMC_1 (default: boots on SDMMC_1 using SDMMC_1 PIO Set 1)
• SDMMC_0: Disable SDCard/e.MMC boot on SDMMC_0 ((default: boots on SDMMC_0 using SDMMC_0 PIO Set 1)
• NFC: Select/disable Parallel Input/Output Controller (PIO) Set used for NFC Boot (default: use NFC PIO Set 1)
• SPI_1: Select/disable Parallel Input/Output Controller (PIO) Set used for SPI_1 Boot (default: use SPI_1 PIO Set 1)
• SPI_0: Select/disable Parallel Input/Output Controller (PIO) Set used for SPI_0 Boot (default: use SPI_0 PIO Set 1)
• QSPI_1: Select/disable Parallel Input/Output Controller (PIO) Set used for QSPI_1 Boot (default: use QSPI_1 PIO Set 1)
• QSPI_0: Select/disable Parallel Input/Output Controller (PIO) Set used for QSPI_0 Boot (default: use QSPI_0 PIO Set 1)

If (valid code found) in external NVM, then:

If valid code is found, the second-stage bootloader, at91bootstrap, is read from the external NVM and stored in internal SRAM.

There are two types of valid code detection:

1. Arm Exception Vectors check
2. boot.bin File check

The type of detection that will be used is determined by the external NVM media type.

For more information see the SAMA5D2 series datasheet – Section 17. Standard Boot Strategies

Load second-stage bootloader at91bootstrap into internal SRAM

If at91bootstrap, is found in external storage such as NAND Flash, QSPI Flash, etc., it must follow the first method of valid code detection: Arm exception vectors check.

If at91bootstrap, is found in SD memory card or e.MMC memory, it must follow the second method of valid code detection: boot.bin file check. It must be stored in the root directory of a FAT formatted file system.

The first-stage bootloader will only try to initialize and read from SDMMC if the card-detect pin is asserted low.

The card-detect pin must be active for ONLY memory devices.

For example, if an SDIO Wi-Fi module is connected to SDMMC_n and card-detect is asserted low, the first-stage bootloader will attempt to boot from the module and lock up the system.

To prevent lock-up, set DISABLE_SDMMC_n = 1 to disable the port.

 More information can be found at: at91bootstrap: A Second Stage Bootloader for Microchip Microprocessors

Remap internal SRAM to address 0x0

Once the valid code is loaded into internal SRAM, the first-stage bootloader remaps internal SRAM to address 0x0.

Reset the PC to 0x0 and jump

The MPU begins the execution of the valid code.

Else if (no valid code found), start the SAM-BA Monitor program

If the first-stage bootloader does not find valid code in any external NVM, it begins the execution of the SAM-BA Monitor.

In accordance with the Boot Configuration Word, the SAM-BA Monitor can be enabled or disabled. If there is no Boot Configuration Word stored in SFC, the SAM-BA Monitor is enabled by default.

It is highly recommended that the SAM-BA Monitor be DISABLED in production code to enhance security.

 The SAMA5D2 Series does not need an external crystal resonator or clock signal during the boot process or for UART communications with the SAM-BA Monitor. However, an external crystal resonator or a clock signal is required for USB communications with the SAM-BA Monitor.

Back to Top

Second-Stage Bootloader

The second-stage bootloader, at91bootstrap, is an external program, available in source code format. It is written and maintained by Microchip Technology and hosted on GitHub. The developer downloads, configures, and builds it according to the project’s hardware and software requirements.

at91bootstrap is stored in external NVM memory. The first-stage bootloader initializes external NVM and stores at91bootstrap into internal SRAM. Once it is loaded, the first-stage bootloader remaps internal SRAM to address 0x0, resets the PC to 0x0, and jumps.

The purpose of the second-stage bootloader, at91bootstrap, is to:

• Initialize the Main Oscillator
• Initialize external volatile and NVM interfaces, controllers, and memory
• Configure peripherals
• Load one of the following from external NVM into external volatile memory (DRAM) (main memory) and jump to:
• Third-stage bootloader (for example, Das U-Boot)
• Linux operating system directly (does not require a third-stage bootloader)
• MPLAB® Harmony 3 Software Framework application
• Real-Time Operating System (RTOS)
• Turn over control to a Debugger (JTAG) (no application is loaded)

Back to Top

Third-Stage Bootloader

A third-stage bootloader continues initializing peripherals on the MPU and facilitates the loading of the Embedded Linux operating system. The use of a third-stage bootloader is optional.

Das U-Boot

Das U-Boot (often abbreviated U-Boot) is an open-source bootloader used to configure and initialize peripherals and load and run the Linux operating system. It is written and maintained by a large open-source community and hosted on GitHub. The developer downloads, configures, and builds it according to the project’s hardware and software requirements.

U-Boot is especially helpful during development. During board bring-up, U-Boot can be a simpler software to configure compared to Linux. Also, it allows you to run scripts providing a more flexible tool for experimentation during development. It allows multiple options to load the kernel or root file system. You can interrupt the boot process and enter commands via a Command-Line Interface (CLI). Visit the U-Boot Command-line Parsing page.

However, U-Boot does add time to the boot process. To speed up the boot process, or if the application is limited on memory or minimal boot time is important, the developer may elect to boot the Linux kernel directly using at91bootstrap.

If an application is to be loaded, such as from the MPLAB® Harmony 3 Software Framework, it can be booted directly by the second-stage bootloader, at91bootstrap.

Back to Top

Embedded Linux

Embedded Linux is a popular choice for MPU development. It is much more than just an operating system. It is a large collection of software libraries, device drivers, networking stacks, software applications, and tools to choose from. There are thousands of developers contributing to its open-source model. There is a large online community providing tutorials and answering questions in forums to aid the developer.

Back to Top

MPLAB Harmony 3 Software Framework

MPLAB Harmony 3 Software Framework is a comprehensive collection of software libraries and tools for the software developer to manage, configure and generate source code for Microchip Technology branded MPUs. The developer can choose the level of development that best suits their application. The framework includes many example applications to enable the developer to get started quickly.

Back to Top

Real-Time Operating System (RTOS)

RTOS provides multitasking, real-time scheduling, multi-thread capabilities, inter-task communications, and many more features. They also greatly simplify the development of complex applications. RTOS offers much more than just an operating system, they also include software libraries, device drivers, networking stacks and a large selection of software applications.

Back to Top

Turn Over Control to a Debugger

This option is used for development. Before control can be turned over to a debugger, the MPU requires initialization and configuration of memories from the first- and second-stage (at91bootstrap) bootloaders. Once the MPU is initialized and internal and external memories are configured, the boot process ends. At this point, the debugger can load binary files and run them.

• SAMA5D29-Curiosity Development Board - Configure and Build at91bootstrap for a MPLAB Harmony v3 Project with MPLAB X IDE

Back to Top

Summary

This training topic explained the boot process of a Microchip Technology SAMA5D2 series Arm Cortex-A5 processor-based MPU from reset to running an operating system (embedded Linux or RTOS) or application.

Back to Top

What's Next?

Are you an MCU developer new to MPUs?

• Differences Between MCU and MPU Development

Learn more about the MPLAB ecosystem:

• Debug Probes
• SAMA5D29-Curiosity Development Board
• SAMA5D27-SOM1-EK1 Evaluation Kit

MPLAB Harmony 3 Software Framework

• Developing with MPLAB Harmony 3 Software Framework for Microchip Technology 32-bit MPUs

Embedded Linux

• Developing with Embedded Linux for Microchip Technology 32-bit MPUs

Back to Top