SAM9X60 Boot Process

Last modified by Microchip on 2024/01/03 17:10

Introduction

This training topic explains the boot process of the Microchip Technology SAM9X60 Microprocessor Unit (MPU) from reset to running an operating system (embedded Linux® or Real Time Operating System (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)).

SAM9X60 Programmers model

The First-Stage Bootloader, located in the MPU’s internal Read-Only Memory (ROM) (also known as boot ROM), performs basic initialization and configuration of the device. Its main purpose is to locate and read the second-stage bootloader from the external NVM and store it in the MPU’s internal SRAM memory.

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:

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

Back to top

References

Back to top

Processor Reset

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

SAM9X60 processor Reset diagram

The Reset State Manager manages the priorities of the different reset sources. The resets are listed in order of priority as follows:

SAM9X60 processor reset state manager table

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

SAM9X60 processor reset MPUs program counter

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 Packet
  3. Enable/disable UART or DBGU port for console serial communications
  4. Enable/disable JTAG port for debugging
  5. Initialize external NVM
  6. 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
  7. Else if (no valid code found) start the SAM-BA Monitor

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

Caution:

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

Back to top

Initialize Processor and Master Clocks

Upon reset, the first-stage bootloader performs an initialization of the Processor Clock (CPU_CLK) and Master Clock (MCK).

The Main RC Oscillator (Clock Generator module) performs a fast start-up to start the system and is the source for the Main Clock (MAINCK). The Power Management Controller (PMC) Processor Clock Controller selects the MAINCK as the source for the Processor Clock (CPU_CLK) and MCK).

SAM9X60 general clock distribution block diagram Main RC Oscillator

Next, the first-stage bootloader initializes the PLLA phase-locked loop to a frequency of 396 MHz. When the PLLA is stabilized, the PMC Processor Clock Controller selects the PLLA clock (PLLACK) signal as the source.

SAM9X60 general clock distribution block diagram first-stage bootloader

The result is the Processor Clock (CPU_CLK) is the same frequency as the PLLA (396 MHz) and the MCK is one-fourth of the PLLA (99 MHz).

Note:
The SAM9X60 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


Read the Boot Configuration Packet

The first-stage bootloader can be customized by the Boot Configuration Packet. It is stored in the device’s internal One-Time Programmable (OTP) memory. The following items can be configured:

If there is no Boot Configuration Packet stored in OTP memory, the first-stage bootloader uses a default configuration:

  • Configure DBGU for console serial communications
  • Enable JTAG port for debugging
  • Initialize and attempt to boot from one of the following NVM memories:
  • SDMMC0 (IOSET0)
  • SDMMC1 (IOSET0)
  • QSPI0 (IOSET0)
  • SPI0 (IOSET0)
  • NAND0 (IOSET0)
  • Enable SAM-BA Monitor

Back to top


Configure UART or DBGU Port for Console Serial Communications

In accordance with the Boot Configuration Packet, configure UART or DBGU port for console serial communications.

If there is no Boot Configuration Packet stored in OTP fuse memory, the first-stage bootloader will configure the DBGU serial port for console serial communications.

Back to top


Enable/disable JTAG Port for Debugging

In accordance with the Boot Configuration Packet, enable or disable the JTAG port for debugging.

If there is no Boot Configuration Packet stored in OTP fuse memory, the first-stage bootloader will enable the JTAG port for debugging.

Caution:

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

Back to top


Initialize External NVM

In accordance with the Boot Configuration Packet, the external NVM interface I/O pin configuration (IOSET) is configured, the memory controller is configured and the interface is enabled. Or the specific memory controller can be disabled. If there is no Boot Configuration Packet stored in OTP fuse memory, the first-stage bootloader uses a default configuration and will initialize and attempt to boot from one of the following NVM memories:

  • SDMMC0 (IOSET0)
  • SDMMC1 (IOSET0)
  • QSPI0 (IOSET0)
  • SPI0 (IOSET0)
  • NAND0 (IOSET0)

If the initialization fails, the first-stage bootloader restores the reset values for the PIO and controller and attempts to boot from the next NVM memory.

If the initialization is successful, the first-stage bootloader reads NVM memory and determines if it contains valid code.

Back to top


If (valid code found) in External NVM

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

Load Second-Stage Bootloader at91bootstrap Into 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.

Note:

For more information see the SAM9X60 Datasheet – Section 12. Boot Strategies for detailed information.

If at91bootstrap is found in other than SD memory card or eMMC memory (e.g., NAND Flash,  Quad Serial Peripheral Interface (QSPI) Flash, etc.), it must follow the first method of valid code detection: ARM exception vectors check.

If at91bootstrap is found in the SD memory card or eMMC 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.

SAM9X60 first stage bootloader diagram

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.

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.

Back to top


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 Packet, the SAM-BA Monitor can be enabled or disabled. If there is no Boot Configuration Packet stored in OTP fuse memory, the SAM-BA Monitor is enabled by default.

Caution:

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

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

Note:

The SAM9X60 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, reset the PC to 0x0 and jumps.

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

Memory card file system diagram

Back to top

Third-Stage Bootloader

A third-stage bootloader continues initializing peripherals on the MPU and facilitates loading 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 Documentation" page.

However, U-Boot does add time to the boot process. 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. See "SAM9X60-EK Evaluation Kit - Fast Boot Demonstration" for an example.

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

Memory card file system diagram

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.

Memory card file system diagram

Back to top

MPLAB Harmony v3 Software Framework

MPLAB Harmony v3 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

An 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. RTOSs offer 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.

Back to top

Summary

This training explained the boot process of a Microchip Technology SAM9X60 MPU from reset to running an operating system (embedded Linux or RTOS) or application.

Back to top

Learn More

Back to top