SAMA7D6 Series Boot Process
Introduction
This training topic explains the boot process of the Microchip Technology SAMA7D6 Series Microprocessor Units (MPU) from reset to running an operating system (embedded Linux® or Real Time Operating System (RTOS)), or application (MPLAB® Harmony v3 Software Framework). The boot process begins with the MPU’s power-on reset. It 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 Read-Only Memory (ROM) (also known as Boot ROM), performs basic initialization and configuration of the device. Its main purpose is to read the second-stage bootloader from an external NVM to the MPU’s internal SRAM memory, verify it and execute it.
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 v3 Software Framework application
- 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 (ISP) utility program or copied to a detachable storage device, such as a Secure Digital (SD) memory card.
The developer must know the MPU’s boot process so that each stage is configured and compiled as required by the operating system or application.
References
- SAMA7D6 Series Datasheet – Section 21. Boot Strategies
Processor Reset
The Microprocessor Unit (MPU) begins the boot process upon reset. The Reset Controller (RSTC) handles all reset events of the device.
The Reset State Manager manages the priorities of the different reset sources. The resets are listed in order of priority as follows:
The Reset Controller (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 in internal Read-only Memory (ROM).
First-Stage Bootloader
Microprocessor Units (MPUs) contain an internal ROM code (also known as Boot ROM), which is 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:
- Initialize Processor and Master Clocks
- Check if there are custom boot settings in the Boot Configuration Packet and Secure Boot Configuration Packet. If none of these packets are present in the OTP memory, the ROM code applies a standard boot configuration and boot sequence.
- If (valid code found) in external NVM, then:
- Load second-stage bootloader into internal Static RAM (SRAM0)
- Enable JTAG port
- Reset the PC to 0x00100000 and jump
- Else if (no valid code found):
- Lock ROM access
- Enable JTAG port
- Launch SAM-BA Monitor, unless it has been disabled in the Boot Configuration Packet.
Let’s look at each of these steps in more detail.
Initialize Processor and Master Clocks
Upon reset, the Main RC Oscillator (Clock Generator module) performs a fast start-up and is the source for the Main Clock (MAINCK). The first-stage bootloader performs low-level initialization of the CPUPLL and SYSPLL. When CPUPLL stabilizes, the CPU_CLK frequency is the same as the CPUPLL frequency (570 MHz) and the Main System Bus Clock (MCK0) is divided by 3 (190 MHz).
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:
- Enable/disable SAM-BA Monitor
- Configure FLEXCOMn IOSET n USART pins used for ROM code console ("RomBOOT" display) and SAM-BA Monitor UART link
- The NVM configuration (IOSet and other memory options) and the order of the NVM scan for a valid bootstrap.
If there is no Boot Configuration Packet stored in OTP memory, the first-stage bootloader uses a default configuration:
- Configure FLEXCOM6 IOSET 4 USART pins
- Initialize and attempt to boot from SDMMC1 IOSET 1 (and card detect pin = true)
If (valid code found) in external NVM, then:
Load second-stage bootloader into internal Static RAM (SRAM)
To be valid, the bootstrap must be formatted as a "bootstrap image", with a header and a tag. Detailed information on the header structure and the tag can be found in the product datasheet.
SAM-BA tool provides a "utility" command to generate a valid bootstrap image from a raw bootstrap binary.
The bootstrap image must be written at the beginning of the Flash memory to be read by the ROM code. In the case of boot on an SD Card or eMMC user partition, the bootstrap image must be stored as a "boot.bin" file in the root folder of a FAT32 partition.
In addition, a dual boot mode can be enabled on each boot memory (except for the eMMC Boot Partition mode). When this mode is enabled, a secondary bootstrap can be written at a different address than 0x0. This mode and the secondary bootstrap image address can be configured into the memory interface settings in the Boot Configuration Packet.
Reset the PC to 0x00100000 and jump
The MPU begins the execution of the bootstrap.
Else if (no valid code found):
If the first-stage bootloader does not find valid code in any external NVM, it will:
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.
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:
- 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 v3 Software Framework application
- RTOS
- Turn over control to a Debugger (JTAG)
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 basic command set 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.
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.
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 from which to choose. 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.
More information can be learned at:
MPLAB Harmony v3 Software Framework
The 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 Microprocessor Units (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.
More information can be learned at:
Real-Time Operating System
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.
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.
Summary
This training topic explained the Boot Process of a Microchip Technology SAMA7D6 Series MPU from reset to running an operating system (embedded Linux or RTOS) or application (MPLAB Harmony v3 Software Framework).