Boot Process - SAMA5D2 Series



This topic explains the Boot Process of a SAMA5D2 Series Arm® Cortex®-A5 processor-based Microprocessor Unit (MPU) from Processor Reset to running the Linux® operating system.

The purpose of the Boot Process is to:

  • Initialize and configure the system
  • Load the operating system kernel image
  • Jump to the first instruction of the kernel image

Understanding the Boot Process is very important to your design and development of an embedded Linux product. You have several choices to make:

  • Standard Boot or Secure Boot mode
  • Setting the Boot Configuration Word
  • Choice of a third-stage bootloader
  • Initializing peripherals
  • Configuring and initializing memory
  • Finding, loading, and running the Linux kernel
  • Finding, loading, and mounting the root file system

We will discuss these choices and more below.

In the embedded Linux world, you will often hear or read several different terms referring to the same thing. It can be a little daunting, however, try not to let it fluster you. Naming consistency is not one of the strong suits of the embedded Linux world.

Here are a few additional terms used to label the Boot Process:

  • System Boot Process
  • System Boot Sequence
  • Processor Boot Sequence
  • Boot Sequence
  • Boot Loading
  • Bootstrapping
  • Booting

Boot Process – SAMA5D2 Series

Loading and running embedded Linux on a SAMA5D2 Series Arm Cortex-A5 processor-based MPU starts with a Processor Reset. From there, the processor “boots up” by successively loading binary files and executing in stages.

Sometimes instead of stages, they are also referred to as “levels” or “phases.”

Processor Reset

The Boot Process begins with the Processor Reset.


The SAMA5D2 series MPUs contain a Reset Controller (RSTC) which handles all reset events of the processor.


The RSTC responds to the sources listed in the table above and asserts internal signals: Processor Reset and Backup Reset. Processor Reset resets the processor and embedded peripherals. Backup Reset resets all peripherals powered by VDDBU.

Backup mode is one of the Low-Power modes of the MPU. In this mode, only the “backup area” is powered. This mode is entered by shutting down all the power rails except VDDBU. Refer to the "Electrical Characteristics" section of the datasheet for more information.

Stage One Bootloader: ROM Boot Code

The first-stage bootloader is located in the MPU’s internal Read-only Memory (ROM). The ROM Boot Code begins the process of initializing the processor and loading the second-stage bootloader into Internal Static RAM (SRAM).

The purpose of the internal ROM Boot Code is to:

  • Configure external memories
  • Configure the Universal Asynchronous Receiver Tranmsitter (UART) port used as a terminal console
  • Initialize master clock
  • If external memory available, read contents to SRAM
  • If external memory is not available, start SAM-BA Monitor program

To help describe the Boot Process, we will use the ATSAMA5D27-D1G System in Package (SiP) programmer’s model. The figure above shows the programmer’s model of the ATSAMA5D27-D1G device. The SiP contains a processor (ATSAMA5D27C) and memory (DDR2 SDRAM).

  • Internal Static RAM (SRAM): Begins at address 0x0020 0000. A portion of the internal memory map is shown. Beginning at address 0x0000 0000 is internal ROM which contains the ROM Boot Code.
  • Secure Digital MultiMedia Card Controller (SDMMC): Provides an interface to embedded MultiMedia Card (e.MMC) and SD/SDIO Memory Cards.
  • Static Memory Controller (HSMC): Handles several different types of external memory such as SRAM, PROM, EPROM, EEPROM, and NOR Flash. It also houses the NAND Flash Controller (NFC).
  • Serial Peripheral Interface (SPI): Provides an interface to SPI serial communication devices including memory.
  • Quad Serial Peripheral Interface (QSPI): Provides an interface to qual serial communications devices. The QPSI can execute code directly from XIP serial Flash memory.
  • Multiport DDR-SDRAM Controller (MPDDRC): Provides an interface to various DDR-SDRAM devices.

Once the processor resets, the code begins executing at address 0x0 which is the beginning of internal ROM. Internal ROM contains standard bootloader and secure bootloader.

The SAMA5D2 Series of Arm Cortex-A5 processor-based MPUs have the ability to load signed and encrypted programs during the Boot Process. This allows only authorized code to load and execute on the processor.

For the rest of this topic, Standard Boot mode will be explained.

For more information on Linux Secure Boot Process, see the application note AN2748, SAMA5D2 Linux Secure Boot (Lit. No. DS00002748).

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).



The ROM Boot Code begins by reading the Boot Configuration Word located in the Secure Fuse Controller (SFC).

The Boot Configuration Word customizes the Boot Process:

  • Configure I/O where the external memories are connected
  • Enable/disable boot on selected memories
  • Configure the UART port used as a terminal console
  • Configure the JTAG pins used for debug

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

By default, the Boot Configuration Word Disable Read of Boot Sequence Controller Configuration Register (DISABLE_BSCR) = 0b0 enabling reading the Boot Sequence Controller Configuration Register (BSC_CR) Backup Register Valid (BUREG_VALID) bit.

  • If BUREG_VALID = 0b0, the processor will read the Boot Configuration Word from the SFC.
  • If BUREG_VALID = 0b1, the processor will read the BUREG_INDEX bits and read the Boot Configuration Word from one of four Backup Register (BUREG).

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

During prototyping, it is highly recommended to use the BUREGs to load the Boot Configuration Word. This will allow the developer to test the options of Boot Configuration Word in the Boot Process.

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 = 0b1 (must be set by the user).


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

  • Enable Secure Boot Mode (default: disabled – standard boot sequence)
  • Disable SAM-BA® Monitor (default: disabled – if no boot file found, launch SAM-BA monitor)
  • Disable read of Boot Sequence Controller Configuration Register (BSC_CR) (default: disabled – Read BUREG if the BUREG index in the BSC_CR is valid)
  • Enable XIP Mode on QSPI Flash (default: disabled – Access in QSPI mode)
  • Enable Boot on External Memories (default: disabled – external memory boot disabled)
  • Select pins used for JTAG access (default: use JTAG Set 1)
  • Select/disable UART IO Set for console terminal (default: use UART1 IO Set 1)
  • Disable SDCard/e.MMC Boot on SDMMC_1 (default: boots on SDMMC_1 using SDMMC_1 PIO Set 1)
  • Disable SDCard/e.MMC Boot on SDMMC_0 ((default: boots on SDMMC_0 using SDMMC_0 PIO Set 1)
  • Select/disable Parallel Input/Output Controller (PIO) Set used for NFC Boot (default: use NFC PIO Set 1)
  • Select/disable Parallel Input/Output Controller (PIO) Set used for SPI_1 Boot (default: use SPI_1 PIO Set 1)
  • Select/disable Parallel Input/Output Controller (PIO) Set used for SPI_0 Boot (default: use SPI_0 PIO Set 1)
  • Select/disable Parallel Input/Output Controller (PIO) Set used for QSPI_1 Boot (default: use QSPI_1 PIO Set 1)
  • Select/disable Parallel Input/Output Controller (PIO) Set used for QSPI_0 Boot (default: use QSPI_0 PIO Set 1)



Once the Boot Configuration Word is read, the ROM Boot Code initializes:

  • Stack for supervisor mode
  • Phase Locked Loop (PLLA)
  • Master Clock (MCK) selection
  • Internal SRAM Variables (ROM —> SRAM)

Next, ROM Boot Code initializes and reads SDMMC 1 and then 0 checking for valid code. If found, the contents of the SD Memory Card are read into internal SRAM.

The ROM Boot Code will only try to initialize and read from SDMMC if the card-detect pin is asserted low.

If the Boot Configuration Word EXT_MEM_BOOT_ENABLE = 0b1 (by default = 0b0), then the ROM Boot Code will continue initializing and reading from external memories if they are enabled in the Boot Configuration Word. The order they are read are:

  • NFC
  • SPI
  • QSPI

Let’s take a moment to look at the ATSAMA5D27-SOM1-EK1 evaluation kit. Bootable memories are shown in the figure above. SDMMC_1 is J14, a microSD Memory Card jack. And SDMMC_0 is J12, an SD Memory Card jack.


The above figure shows the organization of an SD Memory card capable of booting Linux. There are two partitions:

  • Boot – formatted as FAT32 and contains:
    • The at91bootstrap: boot.bin
    • A ITB file containing:
      • Device Tree Binary
      • Compress Linux kernel zimage
    • U-Boot environment: uboot.env
    • U-Boot binary: uboot.bin
  • RootFS (filesystem) – formatted as ext4

If (valid code found):


If valid boot code is found in external memory, then the contents will be read into internal SRAM.


For our example, the second-stage bootloader, at91bootstrap boot.bin, is read from external memory (SD Memory Card) into internal SRAM.

The Peripheral I/O (PIO) controller will be reset.


SRAM will be remapped by the AXI Matrix (AXIMX) Remap Register (AXIMX_REMAP) to address 0x00000000, and 0 —> PC, Jump. This starts the execution of the second-stage bootloader.

If (no valid code found):


If no valid boot code is found, then the UART and USB will be enabled and the SAM-BA Monitor will start.

Stage Two Bootloader: at91bootstrap


At this stage in the Boot Process, the second-stage bootloader, at91bootstrap, resides in internal SRAM of the MPU. Execution of at91bootstrap begins when the 0 —> PC, Jump.

For more information about at91bootstrap, see Second Stage Bootloader: at91bootstrap.

at91bootstrap initializes the following peripherals and memory controllers:

  • Advanced Interrupt Controller (AIC)
  • Peripheral I/O Controller (PIO)
  • Power Management Controller (PMC)
  • Clock Generator (CKGR)
  • HSMC
  • NFC

Next, at91bootstrap downloads the third-stage bootloader, Das U-Boot (or u-boot for short) from the SD Memory Card to SDRAM.


In our example using the ATSAMA5D27-SOM1-EK1, the SDRAM is located in the ATSAMA5D27-DIG SiP device.

Finally, at91bootstrap jumps to the first location of the third-stage bootloader, u-boot.

Stage Three Bootloader: u-boot-at91


A popular choice of the third-stage bootloader is Das U-Boot, or u-boot for short, an open-source project.

The u-boot-at91 is maintained by Microchip Technology and hosted on GitHub:


U-boot loads the Device Tree and Linux kernel to external SDRAM, mount the root filesystem, and jumps to the first program, init.

Operating System: linux-at91


At the end of the Boot Process, the Linux console will prompt the user to login.

The linux-at91 is maintained by Microchip Technology and hosted on GitHub:

What’s Next?


We recommend purchasing the ATSAMA5D27-SOM1-EK1 evaluation kit and exploring the Boot Process outlined in this topic.

For more information about the ATSAMA5D27-SOM1-EK1:

SAM-BA In-System Programmer (ISP)

The SAM-BA ISP is a set of software programs that provide utility functions and in-system read, write, execute, and verification of internal and external memories of Microchip Technology’s Arm-based MPUs.

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.