This application report describes various boot mechanisms supported by the AM18xx bootloader read-only memory (ROM) image. Topics covered include the Application Image Script (AIS) boot process, an AISgen tool used to generate boot scripts, protocol for booting the device from an external master device, a UART Boot Host GUI for booting the device from a host PC, and any limitations, default settings, and assumptions made by the bootloader.
Project collateral discussed in this application report can be downloaded from the following URL: http://www.ti.com/lit/zip/spraba5.
Code Composer Studio is a trademark of Texas Instruments.
Windows, Microsoft are registered trademarks of Microsoft Corporation in the United States and.
All other trademarks are the property of their respective owners.
The AM18xx bootloader resides in the ROM of the device. This document describes the boot protocol used by the bootloader, discusses tools required to generate boot script, and talks about limitations/assumptions for the bootloader.
The AM18xx bootloader has undergone multiple revisions. To check the version of your device, perform the following steps.
The text d800k008 should appear in the memory window at offset 0x08. For earlier ROM revisions, the text could also appear as d800k002, d800k004, or d800k006. It’s important to know your ROM revision when generating boot images. If you don’t see any of these values in the memory window, this document is not applicable to your device. An abbreviated summary of the ROM boot loader revision history can be found in Section E.
The bootloader supports booting from various memory devices (master mode) as well as from an external master (slave mode). A complete list of the supported boot modes and the configuration of the boot pins to select each one of them can be found in Section A.
All boot modes, except the host port interface (HPI) and two out of the three NOR-boot modes, make use of the AIS for boot purpose. AIS is a Texas Instruments, Inc. proprietary boot script format widely used in TI devices. All boot modes supporting AIS present a unified interface to you. AIS and AISgen, the tool used to generate AIS, will be discussed in detail later in this document.
There are few boot modes that do not make use of AIS and have a special boot interface. For instance,
Each of these will be discussed later in the document.
NOR (or parallel Flash) boot happens from a NOR Flash device connected to the external memory interface (EMIFA) peripheral on EMA_CS[2]. For this boot mode, the bootloader configures EMIFA for 8-bit access and reads the first word from the NOR Flash. This first word indicates if the NOR Flash should be accessed in 16-bit or 8-bit mode, as well as which boot method to be used. This word is interpreted as shown in Figure 1
The NOR boot configuration word register is shown in Figure 1 and described in Table 1.
31 | 12 | 11 | 8 |
Reserved | COPY |
7 | 6 | 5 | 4 | 3 | 1 | 0 |
Reserved | METHOD | Reserved | ACCESS |
Bit | Field | Value | Description |
---|---|---|---|
31-12 | Reserved | 0 | Reserved |
11-8 | COPY | Length of data to copy from the base of the NOR Flash to the base of the On-chip RAM. This value is used only for the Legacy NOR boot method. | |
0x00 | 1 KB | ||
0x01 | 2 KB | ||
... | |||
0x0E | 15 KB | ||
0x0F | 16 KB | ||
7-6 | Reserved | 0 | Reserved |
5-4 | METHOD | Boot method | |
0x0 | Legacy NOR boot | ||
0x1 | Direct NOR boot | ||
0x2 | AIS NOR boot | ||
3-1 | Reserved | 0 | Reserved |
0 | ACCESS | EMIFA access mode | |
0x0 | 8-bit access | ||
0x1 | 16-bit access |
If ACCESS == 0x1, bootloader reconfigures EMIFA for 16-bit access before using specified boot METHOD to boot from NOR. The default configuration of the bootloader is for an 8-bit access.
When METHOD==0x0, the Legacy NOR boot option will be executed. For Legacy NOR boot, the bootloader copies a block of data, whose size is indicated by the COPY field, from the start of NOR Flash (address 0x60000000) to the start of On-chip RAM (0x80000000). This block of data should hold a secondary bootloader, as shown in Figure 2.
After copying the required data to On-chip RAM, the bootloader transfers control to the secondary bootloader by branching to address 0x80000004.
When METHOD==0x1, the Direct NOR boot option will be executed. For Direct NOR boot, the bootloader transfers control directly to the secondary bootloader present in NOR Flash by branching to address 0x60000004. The secondary bootloader is directly executed from there.
When METHOD==0x2, the AIS NOR boot option will be executed. When booting with this method, the bootloader expects the AIS image to start from address 0x60000004, which is mapped to NOR Flash.
The AIS boot method is described in detail later in this document.
HPI boot happens from the HPI0 peripheral in 16-bit mode. The sequence to boot from HPI is listed below:
The emulation debug boot powers on the device, but does not load or execute any application code. Instead, the ARM falls into an idle loop immediately after the device powers on. An emulation connection (JTAG) must then be established to load program data or perform any other operations.
AIS is a format of storing the boot image. Apart from the HPI and two NOR-boot modes described above, all boot modes supported by the AM18xx bootloader use AIS for boot purposes.
AIS is a binary language, accessed in terms of 32-bit (4-byte) words in little endian format. AIS starts with a magic word (0x41504954) and contains a series of AIS commands, which are executed by the bootloader in sequential manner. The Jump & Close (J&C) command marks the end of AIS.
Each AIS command consists of an opcode, optionally followed by one or more arguments, followed by optional data.
The opcode and its arguments are each one word (4 bytes) wide. If the length of data is not a multiple of 4 bytes, it is padded with zeros to make it so.
Knowledge of AIS commands is not required to use the bootloader, but will be discussed in the following sub-sections for completeness. You can skip to the next section if knowledge of AIS commands is not desired.
The user application consists of a number of initialized sections and an application entry point. The Section Load command is used to load each initialized section of the application to device memory.
This command takes two arguments: address and size of the section to be loaded, followed by contents of the section (data). If the length of the section content is not a multiple of 4 bytes, appropriate zero padding is added to make it so; zero padding is not reflected in the SIZE argument.
When CRC checking is enabled, the address and size arguments are fed into the CRC update function in that order. After the section is fully loaded to memory, the section data is fed into the CRC update function beginning at the specified address.
The Section Fill command is an optimized version of the Section Load command, which is used when a section is completely filled with a pattern (for example, 0x00 or 0xFF).
This command takes four arguments: address and size of the section to be filled, the type of memory access, and the pattern that will fill the memory.
Value | Length of Data Pattern |
---|---|
0 | 8-bit |
1 | 16-bit |
2 | 32-bit |
When CRC checking is enabled, the address, size, type, and pattern arguments are fed into the CRC update function in that order. After the section is completely filled with the specified pattern, the section data is fed into the CRC update function beginning at the specified address.
This command enables calculation of the cyclic redundancy check (CRC) over the user-application data loaded using the Section Load/Section Fill commands.
This command does not take any arguments or data.