11
Bootloader for KeyStone I and KeyStone II

11.1 Introduction

A bootloader is a program that transfers a code (program and/or data) from one memory location to another. The code which is transferred is called boot code. The bootloader and the boot code are indispensable in any microprocessor‐based system. When a microprocessor, which is connected to some peripherals, is powered up, it will not function properly since these peripherals need to be configured and the application, which may reside in non‐volatile memory, should be transferred in the internal memory where it is run. For instance, if the KeyStone II is connected to double data rate (DDR) memory and flash memory, the DDR needs to be configured and the clock signals need to be set up before the bootloader transfers the code from the flash memory to DDR. The boot code can be another bootloader or an image (an application, for instance), depending on the application.

In this chapter, the bootloaders for both the KeyStone I and the KeyStone II will be discussed.

11.2 How to start the boot process

The boot process only happens after a reset. There are, however, different types of resets (see Table 11.1 and Table 11.2 for the KeyStone I and the KeyStone II, respectively):

  • Power‐on reset (POR) (higher priority)
  • Hard reset
  • Soft reset (lower priority)
  • Local reset (only affects the local core that has been reset).

For the local reset, the boot process is not triggered and, therefore, no boot process will take place.

After power‐up, the POR puts the complete system to a reset state until the initialisation (to the default values) of internal registers is completed, after the power supply voltage and the internal clock of the device reach a stable state. However, the RESETFULL (see Table 11.1 and Table 11.2) which can be asserted by the host is also asserted during POR, and it will have the same effect as the POR and therefore reset the whole device. More information on the reset can be found in Refs. [1, 2], and some useful information is shown in Table 11.1 and Table 11.2 and summarized in Table 11.3.

Table 11.1 Reset types for the KeyStone I [3]

Source: Courtesy of Texas Instruments.

Reset type Initiator Effect on device when reset occurs RESETSTAT pin status
Power‐on reset (POR)
  • POR pin active low
  • RESETFULL pin active low
  • Total reset of the chip
  • Everything on the device is reset to its default state in response to this.
  • Activates the POR signal on the chip, which is used to reset test/emu logic
  • Boot configurations are latched.
  • ROM boot process is initiated.
 Toggles RESETSTAT pin
Hard reset
  • RESET pin active low
  • Emulation
  • PLL Control Register (PLLCTL) (or Reset Control Register (RSCTRL))
  • Watchdog timers
  • Resets everything except for test/emu logic and reset isolation modules
  • Emulator and reset isolation modules stay alive during this reset.
  • This reset is also different from POR in that the PLLCTL assumes power and clocks are stable when device rest is asserted.
  • Boot configurations are not latched.
  • The ROM boot process is initiated.
 Toggles RESETSTAT pin
Soft reset
  • RESET pin active low
  • PLLCTL register (RSCTRL)
  • Watchdog timers
  • Software can program these initiators to be hard or soft.
  • Hard reset is the default, but it can be programmed to be soft reset.
  • Soft reset will behave like hard reset except that external memory contents, EMIF16 memory map registers (MMRs), DDR3 EMIF MMRs and the sticky bits in PCIe MMRs are retained.
  • Boot configurations are not latched.
  • ROM boot process is initiated.
 Toggles RESETSTAT pin
C66x CorePac local reset
  • Software (through LPSC MMR)
  • Watchdog timers
  • LRESET pin
  • MMR bit in LPSC controls the C66x CorePac local reset.
  • Used by watchdog timers (in the event of a timeout) to reset the C66x CorePac
  • Can also be initiated by LRESET device pin. The C66x CorePac memory system and slave DMA port are still alive when the C66x CorePac is in local reset.
  • Provides a local reset of the C66x CorePac, without destroying clock alignment or memory contents
  • Does not initiate ROM boot process
 Does not toggle RESETSTAT pin

Table 11.2 Reset types for the KeyStone II [1]

Source: Courtesy of Texas Instruments.

Type Initiator Effect(s)
Power‐on reset (POR)
  • POR pin
  • RESETFULL pin
  • Resets the entire chip, including the test and emulation logic
  • The device configurations are latched only during POR.
Hard reset
  • RESET pin
  • PLL Control* Register (RSCTRL)
  • Watchdog timers
  • Emulation
  • Hard reset resets everything except for test, emulation logic and reset isolation modules.
  • This reset is different from POR in that the PLL Controller assumes power and clocks are stable when a hard reset is asserted.
  • The device configuration pins are not re‐latched.
  • Emulation‐initiated reset is always a hard reset.
  • By default, these initiators are configured as hard reset, but they can be configured (except emulation) as soft reset in the RSCFG Register of the PLL Controller.
  • Contents of the DDR3 SDRAM memory can be retained during a hard reset if the SDRAM is placed in self‐refresh mode.
Soft reset RESET pin
PLL Control Register (RSCTRL)
Watchdog timers
  • Soft reset behaves like hard reset except that the PCIe MMRs (memory‐mapped registers) and DDR3 EMIF MMRs contents are retained.
  • By default, these initiators are configured as hard reset, but can be configured as soft reset in the RSCFG Register of the PLL Controller.
  • Contents of the DDR3 synchronous dynamic random‐access memory (SDRAM) can be retained during a soft reset if the SDRAM is placed in self‐refresh mode.
Local reset LRESET pin
Watchdog timer timeout
LPSC MMRs
  • Resets the C66x CorePac without disturbing clock alignment or memory contents
  • The device configuration pins are not re‐latched.

* All masters in the device have access to the PLL Control Registers.

Table 11.3 Reset types summary for both KeyStone I and II

Reset types Initiator What is not reset Boot pins Boot process
Power‐on reset (POR)
  • POR active low pin
  • RESETFULL active low
 None (reset everything on the system) Latched and updated Yes
Hard reset
  • RESET active low pin
  • Emulation
  • PLLCTL register
  • Watchdog timers
  • Test/emu logic
  • Reset isolation modules.
  • Clocking is unaffected within the device.
 No Yes
Soft reset
  • RESET active low
  • PLL Control Register (RSCTRL)
  • Watchdog timers
  • Test/emu logic
  • Reset isolation modules.
  • EMIF16 MMRs, DDR3 EMIF MMRs and the sticky bits in PCIe MMRs
 No Yes
C66x CorePac
local reset
  • Software (through LPSC MMR)
  • Watchdog timers
  • LRESET pin
  • Only CorePac reset that does not destroy memory.
 No No

11.3 The boot process

Both KeyStone I and II support various boot processes. These processes start executing the bootloader (after a reset, as shown) located at the beginning of the BOOT ROM address (see Section 11.4). There are two BOOT ROM addresses depending on whether the DSP boot mode or ARM boot mode is selected.

Since the KeyStone II has both DSPs and ARMs, it has four hardware modes supported on top of the various software‐driven boot processes [1]:

  1. Public ROM boot for non‐secure devices
    1. When the DSP CorePac0 is the boot master (DSP boot mode):
      • Both the DSP CorePac0 and the ARM CorePac0 are released at the same time.
      • Both the ARM and the DSP start executing.
      • The bootloader reads the value of these pins as latched into the bootCFG register at device POR reset.
      • Both the ARM and the DSP read the boot mode inside the bootCFG register in order to determine which the boot master is.
      • If the ARM reads that the DSP is the master, then all ARM cores will enter a low‐power standby state by executing the WFI (wait for interrupt) instruction and waiting for a DSP interrupt.
      • If the DSP is the boot master, then CorePac0 will execute the bootloader (after being downloaded) and the other DSP cores stay idling by executing the IDLE instruction.
      • The downloaded code inside the bootloader may contain code for either the other DSP cores or the ARM cores that need to be run. If this is the case, then the downloaded code should contain control code that specifies the execution addresses for each core. These addresses are written to each core’s boot address register. The CorePac0 then issues interrupts to the relevant cores through the Interrupt Control Generation Registers (IPCGRx) to execution code.
    2. When the ARM CorePac0 is the boot master (ARM boot mode):
      • This mode is similar to the previous mode except that the DSP CorePac0 and the ARM CorePac0 roles are swapped.
      • This is the preferred boot mode when using Linux.
  2. Secure ROM boot for secure devices. Secure boot allows the user bootloader to be authenticated before use, ensuring that the customer software is not modified from the original customer signed image. Secure devices always boot from the DSP internal secure ROM, and the bootloader is authenticated before use.
    1. When the TMS320C66x CorePac0 is the boot master. This mode operates in the same way as public ROM boot, when the DSP CorePac0 is the boot master.
    2. When the ARM CorePac0 is the boot master. This mode operates in the same way as public ROM boot, when the ARM CorePac0 is the boot master.

Bit 8 in Figure 11.9 determines whether the boot is a C66x CorePac boot or ARM CorePac boot (0 = ARM is boot master; 1 = C66x is boot master).

11.4 ROM Bootloader (RBL)

The KeyStone I and II devices contain RBL software that is designed to transfer code to initialize the platform and branch to the start of a user application or to a second bootloader such as U‐Boot, as shown in Section 11.5.2. The RBL, which is burned onto the on‐chip ROM at production time, cannot be modified, and it is the first piece of code to run and start the device.

The RBL is located in the ROM at the following addresses:

  • 0x20B00000 (128 K for the KeyStone I)
  • 0x00000000 (256 K for the KeyStone II).

The task of the RBL is twofold: one is to configure the device resources (which are determined by the boot mode) at the beginning of the boot process (initialisation stage), and the second is to load the image into the device and execute this image (boot process stage); see Figure 11.3 and Figure 11.4 for the KeyStone I and II, respectively.

The DSP CorePacN will boot from the address specified in the DSP_BOOT_ADDRn register (n: CorePac number) which has a default value of 0x20B00000; see Figure 11.1 and Figure 11.2.

No alt text required.

Figure 11.1 Boot address of a CorePac, DSP_BOOT_ADDR, for the KeyStone I.

No alt text required.

Figure 11.2 Boot address of a CorePac, DSP_BOOT_ADDR, for the KeyStone II.

Flowchart of high-level overview of the boot process for the KeyStone I from boot start to boot mode specific process.

Figure 11.3 High‐level overview of the boot process for the KeyStone I [4].

Source: Courtesy of Texas Instruments.

Flowchart of high-level overview of the boot process for the KeyStone II from global reset to branching to execute downloaded image.

Figure 11.4 High‐level overview of the boot process for the KeyStone II [2].

Source: Courtesy of Texas Instruments.

It is important not to confuse the DSP_BOOT_ADDR with the boot magic address. The DSP_BOOT_ADDR is used by the RBL to branch to the boot code, and the boot magic address is used by the DSP core to get the execution address of the image and start executing.

During the POST or RESETFULL assertion, the general‐purpose pins (see Figure 11.5 and Figure 11.6) that are used for selecting a boot mode are sampled, and their corresponding boot configuration values are latched into the Device Status Register (DEVSTAT) located at address 0x2620020 (for all devices) (see Figure 11.7 for the C6678 and Figure 11.8 for the 66AK2H14/12/06).

Photo displaying the boot mode configuration switches for the TMS320C6678 EVM with labels boot mode/configuration setting and shunts.

Figure 11.5 Boot mode configuration switches for the TMS320C6678 EVM.

Photo displaying the boot mode configuration switches for the KeyStone II EVM.

Figure 11.6 Boot mode configuration switches for the KeyStone II EVM.

No alt text required.

Figure 11.7 Boot mode pin for the TMS320C6678 (DEVSTAT) [3].

Source: Courtesy of Texas Instruments.

No alt text required.

Figure 11.8 Device status register for the TMS320C66AK2H14/12/06 [1].

Source: Courtesy of Texas Instruments.

The corresponding boot configuration values (stored in the Boot Parameter Table) are then copied by the RBL to a reserved L2 section of the CorePac0 and also modified according to the bootstrap pins (see Figure 11.12 and Figure 11.13).

The Boot Parameter Table used by the RBL to determine the boot flow (see Figure 11.12) is composed of some parameters that are common to all boot modes and are referred to as the Boot Parameter Table Common Parameters. It is also composed of other boot parameter tables, each one corresponding to a specific boot mode. Table 11.4 shows the C6678’s Boot Parameter Table Common Parameters, Table 11.5 is its EMIF16 Boot Parameter Table and Table 11.6 and Table 11.7 are its SPI (Serial Peripheral Interconnect) Boot Parameter Tables. For the other boot tables, please refer to the user guide [3]. Table 11.8, Table 11.9 and Table 11.10 show the 66AK2H14/12/06’s Boot Parameter Table Common Parameters, the EMIF16 Boot Parameter Table and the SPI Boot Parameter Table, respectively. Figure 11.9 shows the boot mode pins for the TMS320C66AK2H14/12/06. For the other boot tables, please refer to the user guide [1].

Tabular chart of DEVSTAT boot mode pins ROM mapping with boots for 0 and 1.

Figure 11.9 Boot mode pins for the TMS320C66AK2H14/12/06 (DEVSTAT) [1].

No alt text required.

Figure 11.10 DEVSTAT boot mode pins ROM mapping.

No alt text required.

Figure 11.11 SPI device configuration field descriptions.

Schematic illustration of the RBL boot process illustrating 3 arrows pointing from parameter common to all boot modes; EMIF 16 param table; and RBL to boxes for L2 CorePack0.

Figure 11.12 The RBL boot process.

Schematic illustration of detailed RBL boot process for the TMS320C6678 illustrating two arrows from RBL Boot ROM to 0x80 bytes.

Figure 11.13 Detailed RBL boot process for the TMS320C6678.

The RBL is very flexible, and it operates differently depending on the boot mode selected. The RBL initialisation, the loading process and the handover process when the RBL has completed are different. Please refer to Chapter 3 in Ref. [4] for the description of each boot mode and the action taken by the RBL.

Figure 11.10 and Figure 11.11 show SPI device configuration fields and descriptions, respectively. Please refer to the data sheet [1] for the other modes.

Table 11.4 Boot Parameter Table Common Parameters (TMS320C6678) [3]

Source: Courtesy of Texas Instruments.

Byte offset Name Description
0 Length The length of the table, including the length field, in bytes
2 Checksum The 16‐bit ones complement of the ones complement of the entire table. A value of 0 will disable checksum verification of the table by the boot ROM.
4 Boot Mode Internal values used by RBL for different boot modes
6 Port Num Identifies the device port number to boot from, if applicable
8 SW PLL, MSW PLL configuration, MSW
10 SW PLL, LSW PLL configuration, LSW

Table 11.5 EMIF16 boot mode parameter table (TMS320C6678) [3]

Source: Courtesy of Texas Instruments.

Byte offset Name Description Configured through boot configuration pins
12 Options Option for EMIF16 boot (currently none) –
14 Type Boot only from NOR flash is supported for TMS320C6678. –
16 Branch Address MSW Most significant bit for branch address (depends on chip select) –
18 Branch Address LSW Least significant bit for branch address (depends on chip select) –
20 Chip Select Chip select for the NOR flash –
22 Memory Width Memory width of the EMIF16 bus (16 bits) –
24 Wait Enable Extended wait mode enabled:
0 = Wait enable is disabled.
1 = Wait enable is enabled.		 Yes

Table 11.6 SPI device configuration bit fields

12 11 10 9 8 7 6 5 4 3
Mode 4, 5 Pin Addr Width Chip Select Parameter Table Index

Table 11.7 SPI device configuration field descriptions (TMS320CC6678) [3]

Source: Courtesy of Texas Instruments.

Bit Field Description
12–11 Mode Clk Pol/Phase
0 = Data are output on the rising edge of SPICLK. Input data are latched on the falling edge.
1 = Data are output one half‐cycle before the first rising edge of SPICLK and on subsequent falling edges. Input data are latched on the rising edge of SPICLK.
2 = Data are output on the falling edge of SPICLK. Input data are latched on the rising edge.
3 = Data are output one half‐cycle before the first falling edge of SPICLK and on subsequent rising edges. Input data are latched on the falling edge of SPICLK.
10 4, 5 Pin SPI operation mode configuration:
0 = 4‐pin mode is used.
1 = 5‐pin mode is used.
9 Addr Width SPI address width configuration:
0 = 16‐bit address values are used.
1 = 24‐bit address values are used.
8–7 Chip Select The chip select field value:
00b = CS0 and CS1 are both active (not used).
01b = CS1 is active.
10b = CS0 is active.
11b = None is active.
6–3 Parameter Table Index Specifies which parameter table is loaded from SPI. The boot ROM reads the parameter table (each table is 0x80 bytes) from the SPI starting at SPI address (0x80*parameter index).
The value can range from 0 to 15.

Table 11.8 EMIF16 boot parameter table common parameters (66AK2H14/12/06)

Byte offset Name Description
0 Length The length of the table, including the length field, in bytes
2 Checksum The 16‐bit ones complement of the ones complement of the entire table. A value of 0 will disable Checksum verification of the table by the boot ROM.
4 Boot Mode Internal values used by RBL for different boot modes
6 Port Num Identifies the device port number to boot from, if applicable
8 SW PLL, MSW PLL configuration, MSW
10 SW PLL, LSW PLL configuration, LSW
12 Sec PLL Config, MSW ARM PLL configuration, MSW
14 Sec PLL Config, LSW ARM PLL configuration, LSW
16 System Freq The frequency of the system clock in MHz
18 Core Freq The frequency of the core clock in MHz
20 Boot Master Set to TRUE if C66x is the master core

Table 11.9 EMIF16 boot parameter table (TMS320C66AK2H14/12/06)

Byte offset Name Description Configuration through boot configuration pins
22 Options Async Config Parameters are used.
0 = Values in the sync config parameters are not used to program async config registers.
1 = Values in the async config parameters are used to program async config registers.		 NO
24 Type Set to 0 for EMIF16 (NOR) boot NO
26 Branch Address MSW Most significant bit for branch address (depends on chip select) YES
28 Branch Address LSW Least significant bit for branch address (depends on chip select) YES
30 Chip Select Chip Select for the NOR flash YES
32 Memory Width Memory width of the EMIF16 bus (16 bits) YES
34 Wait Enable Extended wait mode enabled:
0 = Wait enable is disabled.
1 = Wait enable is enabled.		 YES
36 Async Config MSW Async Config Register MSW NO
38 Async Config LSW Async Config Register LSW NO

Table 11.10 SPI boot parameter table (TMS32066AK2H14/12/06) [1]

Source: Courtesy of Texas Instruments.

Byte offset Name Description Configuration through boot configuration pins
22 Options Bits 01 & 00 modes:
00 = Load a boot parameter from the SPI (default mode).
01 = Load boot records from the SPI (boot tables).
10 = Load boot config records from the SPI (boot config tables).
11 = Load GP header blob.
Bits 15‐02 = Reserved.		 NO
24 Address Width The number of bytes in the SPI device address. Can be 16 or 24 bit. YES
26 NPin The operational mode, 4 or 5 pin YES
28 Chipsel The chip select used (valid in 4‐pin mode only). Can be 0–3. YES
30 Mode Standard SPI mode (0–3) YES
32 C2Delay Setup time between chip assert and transaction NO
34 Bus Freq, 100 kHz The SPI bus frequency in kilohertz NO
36 Read Addr MSW The first address to read from, MSW (valid for 24‐bit address width only) YES
38 Read Addr LSW The first address to read from, LSW YES
40 Next Chip Select Next Chip Select to be used (used only in boot config mode) No
42 Next Read Addr MSW The next read address (used in boot config only) NO
44 Next Read Addr LSW The next read address (used in boot config only) NO

11.4.1 The boot configuration format

In addition to the boot parameter tables shown in Section 11.4, there are also two other tables that RBL uses. Therefore, three files referred to as tables have to be defined:

  1. Boot parameter tables seen in Section 11.4 (determine the boot flow)
  2. Boot table (the image itself)
  3. Boot configuration table (needed for peripherals configuration).

11.4.1.1 Creating the boot parameter table

See Section 11.4.

11.4.1.2 Creating the boot table

Before booting an application, this application has to be converted to an image. The hexadecimal conversion utility takes the application and information about the linker command file (*.RMD file; see example below).

The image is in a format called a boot table; see Figure 11.14, where:

  1. The first address contains the address to where the RBL should branch when all sections are copied.
  2. The second address contains the destination address of each section.
  3. The third address contains the count of each section.
  4. 2 and 3 are repeated N times; see Figure 11.14.
  5. The last memory locations of the boot table will contain 0x00000000, indicating that there are no more sections to transfer.
Schematic illustration of the boot table with 3 arrows labeled Next address after all sections are copied, Application, and Hex conversion utility pointing to Boot table column.

Figure 11.14 The boot table.

11.4.1.3 The boot configuration table

The boot configuration table is used when some default value needs to be changed; in other words, the boot configuration table is where the user specifies the parameters of the peripheral used. It is worth noting that all peripherals are configured by setting or clearing bits for each specific register. For instance, if the image needs to be loaded in the DDR memory, this DDR needs to be configured properly.

To configure a peripheral, therefore, the address of the register and the set and clear marks will be required; see Figure 11.15. When the address and the set and clear registers are set to zero, this indicates to the RBL that all registers are set.

Schematic illustration of modifying the boot configuration table with six arrows of solid and dotted pointing from boot configuration table to DDR registers.

Figure 11.15 Modifying the boot configuration table.

11.5 Boot process

11.5.1 Initialisation stage for the KeyStone I

During the initialisation phase, the RBL, knowing the content of the Device Status Register (DEVSTAT), will perform the following tasks:

  • The RBL enables the reset isolation in all peripherals that support it. The power state of these peripherals is not changed. Only the SRIO and SmartReflex support reset isolation [3].
  • The RBL also ensures that the power and clock domains are enabled for any peripherals that are required for boot.
  • The RBL configures the system PLL to set the device speed. See user guides for more details: DSP [4] and ARM [2].
  • The RBL reserves a portion of the L2 in all the cores in the device to perform the boot process; see Table 11.11.
  • For the EMIF16 boot, no memory is reserved by the RBL; memory usage depends entirely on the image stored in, and executed from, the NOR flash.
  • All the interrupts are disabled, except inter‐processor communication (IPC) interrupts and the host interrupts that are needed for the PCIe, SRIO (DirectIO) and HyperLink boot modes.
  • During the boot process, the RBL executes an IDLE command on the secondary CorePacs and keeps the secondary CorePacs waiting for an interrupt. After the application code to be loaded in these secondary CorePacs is loaded and the BOOT_MAGIC_ADDRESS values in individual CorePacs are populated, the application code in the CorePac0 can trigger the IPC interrupt to wake up the secondary cores and branch up to the address specified in the BOOT_MAGIC_ADDRESS.
  • All L1D and L1P memory is configured by the boot code as cache memory. L2 memory, however, is configured as addressable memory.
  • The RBL also provides the ability for the user to configure the DDR EMIF before loading the image into the external memory during the boot process using a DDR structure that is reserved in the L2. For every section that the RBL reads, it verifies if the DDR enable magic word is set. If the magic word is set, then the DDR structure is used to initialize the DDR. For the KeyStone I, the DDR structure is located at address 0x00873500.
  • The RBL uses the pin‐strapped boot mode pins (available through the DEVSTAT register) to set up the initial configuration structure, which is called the boot parameter table. This table is stored in the reserved section of L2 in CorePac0. Even though the boot parameter table format varies based on the boot mode selected, there are a few offsets that are common across all boot modes for a specific device. As an example, see Table 11.4 and Table 11.5 for the common ones, and EMIF16 configurations in Refs. [1] and [3] for complete lists.
  • The RBL uses the BOOTCOMPLETE register (see Figure 11.16), which controls the BOOTCOMPLETE pin status, to indicate the completion of the RBL boot process. The BOOTCOMPLETE pin goes high when the boot complete bits in the BOOTCOMPLETE register for all the cores are set. The RBL sets the bits for each CorePac once it completes the boot process in the CorePac and just before it exits the process.

Table 11.11 Bootloader Section in L2 SRAM

Start address (hex) Size (hex bytes) Description
0x00872DC0 0x40 ROM boot version string (unreserved)
0x00872E00 0x400 Boot code stack
0x00873200 0xE0 Boot log
0x008732E0 0x20 Boot progress register stack (copies of boot program on mode change)
0x00873300 0x100 Boot internal stats
0x00873400 0x20 Boot table arguments
0x00873420 0xE0 ROM boot FAR data
0x00873500 0x100 DDR configuration table
0x00873600 0x80 RAM table
0x00873680 0x80 Boot parameter table
0x00873700 0x4900 Clear text packet scratch
0x00878000 0x7F80 Ethernet/SRIO packet/message/descriptor memory
0x0087FF80 0x40 Small stack
0x0087FFC0 0x3C Not used
0x0087FFFC 0x4 Boot magic address
No alt text required.

Figure 11.16 Boot complete register, BCx. Note: BCx CorePacx boot status: 0 = CorePacx boot NOT complete, 1 = CorePacx boot complete.

11.5.2 Second‐level bootloader

In order to support other boot modes, customize an available boot mode or extend the capability of a bootloader, a second‐level boot mode can be used. In this chapter, two second‐level bootloaders are used. On the TMS320C6678 this bootloader is called the intermediate bootloader (IBL), and on the KeyStone II it is called U‐Boot.

The RBL is flexible and allows the downloaded code to modify the boot parameter table in order, for instance, to select a new boot mode and/or new parameter table. This can be very useful, for instance when one would like to have a fast booting mode. In this case, use the RBL to download a small piece of code that will modify the device clock (from the default and slow clock to a faster clock), and re‐enter the boot process to resume using a faster clock.

11.5.2.1 Intermediate bootloader

For the C6678, the IBL is used as the second‐level bootloader to allow:

  • Boot from the NAND/NOR flash on TMS320C667x.
  • Boot from an FTP server.
  • Boot from images with different formats (ELF [5] or BBLOB).
  • Boot from multiple images.
  • Extended functions before boot.

The IBL is flashed into the EEPROM that is connected to the DSP via the I2C bus at address 0x51, as shown in Figure 11.17.

Schematic illustration of IBL location displaying boxes with labels header, post, IBL, KeyStone I, 16 MB NOR flash BIOSMCSDK, and 64 MB NAND flash connected by double-headed arrows.

Figure 11.17 IBL location. Note: In Rev 1.0 of the C6670 EVM, the FPGA is programmed to invoke the IBL in order to execute the PLL fix, and then jump right back to RBL which continues the process. See the reference for the IBL update [6].

  • Boot mode dip switch settings. The EVM supports an IBL booting an image from the NAND, NOR or Ethernet; see Figure 11.18. Table 11.12 shows the boot mode dip settings for the different boot modes that the EVM supports.
Schematic illustration of IBL boot modes displaying boxes with labels NAND, NOR, TFTP, RBL, IBL, and application connected by arrows.

Figure 11.18 IBL boot modes.

Table 11.12 Boot mode for the C6678 EVM [7]

Boot mode DIP SW3
(Pin1, 2, 3, 4)		 DIP SW4
(Pin1, 2, 3, 4)		 DIP SW5
(Pin1, 2, 3, 4)		 DIP SW6
(Pin1, 2, 3, 4)
IBL NOR boot on image 0 (default) (off, off, on, off) (on, on, on, on) (on, on, on, off) (on, on, on, on)
IBL NOR boot on image 1 (off, off, on, off) (off, on, on, on) (on, on, on, off) (on, on, on, on)
IBL NAND boot on image 0 (off, off, on, off) (on, off, on on) (on, on, on, off) (on, on, on, on)
IBL NAND boot on image 1 (off, off, on, off) (off, off, on, on) (on, on, on, off) (on, on, on, on)
IBL TFTP boot (off, off, on, off) (on, on, off, on) (on, on, on, off) (on, on, on, on)
I2C POST boot (off, off, on, off) (on, on, on, on) (on, on, on, on) (on, on, on, on)
ROM SPI boot (off, on, off, off) (on, on, on, on) (on, on, off, on) (on, on, on, on)
ROM SRIO boot (off, off, on, on) (on, on, on, off) (on, off, on, off) (off, on, on, on)
ROM Ethernet boot (off, on, off, on) (on, on, on, off) (on, on, off, off) (off, on, on, on)
ROM PCIe boot (off, on, on, off) (on, on, on, on) (on, on, on, off) (off, on, on, on)
No boot (off, on, on, on) (on, on, on, on) (on, on, on, on) (on, on, on, on)

11.5.2.2 How to use the IBL

The following steps show how to use the IBL to boot from the NAND/NOR or upload to an FTP server.

  • Step 1. Compile the IBL source code, which is available in the MCSDK directory:
    • C:TImcsdk_2_01_02_06 oolsoot_loaderibl
  • Step 2. Burn the IBL and parameter set to I2C EEPROM (using eepromwriter_evm6678.out within the Code Composer Studio (CCS)).
  • Step 3. Set the IBL parameter to I2C EEPROM.
  • Step 4. Get the user application and generate a user image.
  • Step 5. Burn the user image to NAND/NOR or upload to an FTP server.
  • Step 6. Set the boot mode pins, see refs [7,8] and Table 11.12.
  • Step 7. Power on the DSP.

For more details on the IBL configuration, see Figure 11.19 and Ref. [9].

  • Examples. A few examples can be found in: C:TImcsdk_2_01_02_06 oolsoot_loaderexamples. Please read the README.txt file for each boot mode. A NAND boot over I2C example is shown here:
IBL configuration window illustrating the highlighted modules tab displaying the modules screen.

Figure 11.19 IBL configuration.

11.6 Laboratory experiment 1

Booting with the KeyStone I. In this laboratory experiment, the booting is from an SPI (TMS320C6678 EVM). The TMS320C6678 EVM layout is shown in Figure 11.20.

TMS320C6678 EVM memory layout displaying boxes with labels header, post, IBL, keystone I, 16 MB NOR flash BIOSMCSDK, and 64 MB NAND flash connected by double-headed arrows.

Figure 11.20 TMS320C6678 EVM memory layout.

In this laboratory experiment, the user will create an application that blinks one of the EVM LEDs using the CCS and flashes it to an NOR flash. The user will also do the appropriate setting for booting from the SPI NOR flash. The procedure is as follows:

  1. Create a project for the image you would like to boot.
    1. Open the project: BlinkLED

      Project location:

      • Chapter_11_CodeNOR_BootingNORbootWSBlinkLED
    2. Explore the project.
  2. Build the project and rename the BlinkLED.out program ‘app.out’. The name is changed in order to make use of an existing batch file.
  3. Place app.out in the same directory as build.bat as shown in Figure 11.21.
  4. Run the build.bat file (select build.bat, right click and run). The file generated, app.dat, will be burned into the flash. Explore the built.bat file. The built.bat file contains four executable files:
    1. hex6x.exe app.rmd: Converts the application code into a boot table format.
    2. b2i2c.exe app.btbl app.btbl.i2c: Converts the boot table into an SPI format table, as the image is to be transferred using the SPI.
    3. b2ccs.exe app.btbl.i2c app.i2c.ccs: Converts the previous file to a format that CCS recognizes since the CCS will be used to burn the flash.
    4. romparse.exe nysh.spi.map: Appends the boot parameter to the boot table.

    Note: The address 0x01F40051 needs to be changed to 0x01F40000 in order to use bank0; see Figure 11.20. This can be achieved by changing the spirom.ccs file as follows:

    The output should be as shown in Figure 11.22.

  5. Set the EVM to NO boot mode as shown in Figure 11.23.
  6. Load the nor_writer project in CCS. In this step, a CCS project entitled nor_writer is used to burn the flash. There is no need to rebuild the project; one can use norwriter_evm6678l.out.
  7. Copy the app.dat file to the location nor_writer/bin in CCS.
  8. Launch the TMS320C6678 target configuration.
  9. Run‐ > Load the file, and leave suspended at main():
    • Chapter_11_CodeNOR_BootingNORbootWS orwriter_evmc6678lin orwriter_evm6678l.out.
  10. Load gel evmc6678l.gel in CCS, and execute Scripts‐ > EVMC6678L Init Functions‐ > Global_Default_Setup as shown in Figure 11.24.
  11. Open the Memory Browser, go to address 0x80000000, right click and pick Load Memory as shown in Figure 11.25.
  12. Pick the app.dat file, choose TI Data from File type, tick the Use file header information checkbox and press Next, as shown in Figure 11.26.
  13. Fill out 0x80000000 in the Start Address field, and leave Length as it is; see Figure 11.27.
  14. Press Finish.
  15. Unsuspend the nor_writer process by pressing the Run button, and wait for completion. If all the steps are followed correctly, the NOR will be flashed; see Figure 11.28.
  16. Turn the power of the EVM off, change the bootmode switches to the SPI boot mode as shown in Figure 11.29 and power on the EVM. The LED should now blink.
Four folders labeled bin, gel, nor_writer, and util and six files labeled app.dat, app.out, app.rmd, build.bat, nor_writer.7, and nysh.spi.map.

Figure 11.21 File locations.

Window displaying the output after running the build.bat file.

Figure 11.22 Output after running the build.bat file.

Photo displaying the no boot mode switches.

Figure 11.23 No boot mode switches.

Code composer studio window with selected scripts tab displaying Global_Default_Setup (encircled) under EVMC6678L Init functions.

Figure 11.24 Loading the GEL file.

Memory browser tab displaying highlighted 0x80000000 and context menu with options for configure, CPU memory view, physical memory view, etc.

Figure 11.25 Loading the image.

Load memory window displaying data entry fields for file and file type with buttons for Browse, Back, Next, Finish, and Cancel.

Figure 11.26 Loading the memory.

Load memory window displaying data entry fields for start address and length with buttons for Back, Next, Finish, and Cancel.

Figure 11.27 Entering the information for the memory block to be loaded.

CCS Debug – Code composer studio window displaying tabs for Debug (top), Memory browser (middle), and Console (bottom).

Figure 11.28 Output when the NOR is flashed properly.

Photo displaying the ROM SPI boot mode.

Figure 11.29 ROM SPI boot mode.

11.6.1 Initialisation stage for the KeyStone II

The initialisation of the KeyStone II differs slightly from that of the KeyStone I. There are three initialisation types:

  1. Bootloader initialisation after power‐on reset (see Table 11.3)
  2. Bootloader initialisation after hard or soft reset (see Table 11.3)
  3. Bootloader initialisation after hibernation. (This is beyond the scope of this book and therefore will not be covered.)

11.6.1.1 Bootloader initialisation after power‐on reset

For the KeyStone II, all initialisation and boot processing are performed by ARM core 0. During this initialisation phase, the RBL, knowing the content of the Device Status Register (DEVSTAT), will perform the following tasks:

  • The RBL enables reset isolation in the SmartReflex and SRIO peripherals (if the power isolation is enabled, the Local Power/Sleep Controller will block global device resets and will not pause the clocks during reset transitions).
  • All interrupts are disabled except for IPC interrupts and the host interrupts that are used for external host boot modes (PCIe, SRIO and HyperLink).
  • All secondary ARM cores are held in reset during the boot process. All DSP cores execute an IDLE command.
  • All cache is disabled.
  • The RBL uses the boot configuration information in DEVSTAT to set up and initialize a boot parameter table that is used to control the boot process.

This table is stored in MSMC SRAM. Some information in the table is initialized based on the configuration parameters in DEVSTAT, while the remaining information is default values based only on the boot mode. The format of the table varies depending on the boot mode. All start with a few entries that are common to all boot modes. Information about the boot parameter table can be found in the device‐specific data manual.

11.6.1.2 Bootloader initialisation process after hard or soft reset

This initialisation process is similar to the initialisation of the power‐on reset except the test/emu logic, the reset isolation modules, the EMIF16 MMRs, the DDR3 EMIF MMRs and the sticky bits in PCIe MMRs are not reset (see Table 11.1 and Figure 11.4).

11.6.2 Second bootloader for the KeyStone II

The ARM subsystem runs the following software components:

  • U‐Boot: Bootloader
  • Boot monitor: Monitor and other secure functions
  • SMP Linux: ARM A15 port of SMP Linux.

Please refer to Ref. [10] for guidelines on how to build the Linux kernel and how to use the naming convention for Linux, U‐Boot and the boot monitor.

Figure 11.30 shows the memory layout of the KeyStone II EVM. The NOR contains the U‐Boot code, and the NAND contains the Linux kernel, the FDT1 (flat device tree) and the file system (UBIFS: Asynchronous Filesystem). The ROM contains the RBL as described in this chapter.

Schematic flow of the boot sequence for the KeyStone II EVM displaying numerical labels on arrows with boxes labeled RBL (ROM), U-Boot (NOR), U-Boot (L2), etc.

Figure 11.30 The boot sequence for the KeyStone II EVM.

The SPI boot process is as follows:

  1. The RBL loads U‐Boot from the NOR to the L2 Memory. Note the RBL cannot boot the Linux kernel as the RBL is small and has limited functionality.
  2. The U‐Boot boots the Linux kernel and the FDT to the DDR.

11.6.2.1 U‐Boot

U‐Boot is an open‐source, cross‐platform bootloader that provides out‐of‐box support for a large number of embedded platforms including the KeyStone II. The main advantage is that U‐Boot is easy to customize, has a rich feature set, is very well documented and has a small binary foot print which is very critical for embedded systems. It is worth looking at the following definition if the user is not familiar with U‐Boot:

  1. U‐Boot environment. The U‐Boot environment is a block of memory that is kept on persistent storage and copied to RAM when U‐Boot starts.
  2. Variables. U‐Boot uses environment variables that can be used to configure the boot process.
  3. Terminal. The user can access these variables via a terminal during the boot process.
  4. Ethenet and USB. U‐Boot can download a kernel image via either an Ethernet or a USB port.
Secondary program loader (SPL)

The RBL will only load the U‐Boot SPL, which will first initialize hardware and then look for u‐boot.img. An SPL is added to U‐Boot in version 2012‐10. The SPL is supported in U‐Boot for KeyStone II devices. This feature is configured using the config option CONFIG_SPL. It allows the creation of a small first‐stage bootloader (SPL) that can be loaded by ROM Bootloader (RBL) which would then load and run the second‐stage bootloader (a full version of U‐Boot) from NOR or NAND. The required config options are added to tci6638_evm.h. The user may refer to the README text file in the U‐Boot root source directory for more details.

For the KeyStone II, the RBL loads the SPL image from offset 0 of the SPI NOR flash in the SPI boot mode. The first 64 K of the SPI NOR flash is flashed with SPL followed by u‐boot.img. The initial 64 K is padded with zeros.

11.7 Laboratory experiment 2

  1. Connect the EVM as shown in Figure 11.31. Figure 11.32 shows the EVM hardware.
  2. Set the Boot Mode Switches to 0010 [11]. Set the boot mode to SPI mode. Various modes are shown in Table 11.13.
  3. Determine the port address. The port addresses on the PC will change every time a serial device is connected. Open the Device Manager and find out the port addresses. In Figure 11.33, the port addresses found for the serial ports are COM12 and COM13.
  4. Open two terminals. In Figure 11.34, PuTTY has been used as a terminal emulator. Open two terminals with COM12 and COM13 (that will depend on your settings, as it is very likely that you will have different ports); see Figure 11.34.
  5. Set the IP addresses. Set addresses as shown in Figure 11.35.
    1. VMware. Start VMware and configure VMware to Bridged as shown in Figure 11.36 and Figure 11.37, then set the IP address of VMware as shown in Figure 11.38.
    2. Setting the host PC. See Figure 11.39.
  6. Power cycle the EVM, and set up the IP address of the EVM.
Schematic of EVM connection to the PC displaying COM13 – PuTTY and COM12 – PuTTY windows pointed by arrows from box labeled PC and photo pointed by an arrow from box labeled KeyStone II EVM.

Figure 11.31 EVM connection to the PC.

Photo displaying EVMK2H hardware.

Figure 11.32 EVMK2H hardware.

Device manager window displaying items under IT060224 button with COM ports, namely, communications port (COM1), USB serial port (COM12), and USB serial port (COM13).

Figure 11.33 Device manager for identifying the COM ports.

Putty configuration window displaying data entry fields for serial line and speed with entries COM12 and 115200, respectively.

Figure 11.34 Setting up the COM ports.

Diagram of IP addresses used in this experiment, displaying shaded boxes with labels PC host, VMware, Ubuntu, and EVM connected by double-headed arrows.

Figure 11.35 IP addresses used in this experiment.

Ubuntu 64-bit-VMware Player (non-commercial use only) window displaying the items under player and items under removable devices such as CD/DVD (SATA), network adapter 2, and printer.

Figure 11.36 Accessing the network settings.

Virtual machine settings window displaying selected Hardware tab and highlighted Network Adapt…Bridged (Automatic) option.

Figure 11.37 Setting the network connection to Bridged.

Editing ethernet connection 1 window displaying selected IPv4 settings tab with data entry fields for DNS servers, search domains, and DHCP client ID.

Figure 11.38 Setting the IP address of VMware.

Internet protocol version 4 (TCP/IPv4) properties window displaying general tab with 2 selected buttons for Use the following IP address and Use the following DNS server addresses.

Figure 11.39 Setting the host PC IP address.

Table 11.13 Boot mode switches

Boot mode SW1
(pin1, pin2, pin3, pin4)
No boot off, off, off, on
UART off, on, off, off
NAND off, off, off, off
SPI off, off, on, off
I2C off, off, on, on
Ethernet off, on, off, on

Open the COM ports, power cycle the EVM and follow instructions 1 to 7 as shown in Table 11.14.

Table 11.14 Steps required for booting the EVM

KS2 EVM side PC side
  1. Power the EVM to boot, and wait for a few seconds.
  2. Type root as shown in Figure 11.40.
  3. Type ifconfig to check the EVM IP address.
  4. You can change the IP address by typing ifconfig eth0 192.168.2.5; see Figure 11.41. Please note that your IP address that you selected will be erased every time you reboot your EVM.
  1. Log in to the EVM from your virtual machine via ssh. Type:
  2. Now that you are connected to the EVM, you can perform tasks on the ARM or DSP.
  3. Explore the files.
COM12-PuTTY window displaying the console output after booting Linux.

Figure 11.40 Console output after booting Linux.

COM21 – PuTTY window displaying the setting of etho’s IP address to 192.168.2.5.

Figure 11.41 Setting eth0’s IP address to 192.168.2.5.

Naim@ubuntu:∼ window displaying codes in accessing the EVM from VMware.

Figure 11.42 Accessing the EVM from VMware.

If the EVM cannot be booted, check the EVM boot mode using the BMC as shown in Figure 11.43. Type bootmode #N as shown by the arrows pointing to the left, and observe the outputs as shown by the arrows pointing to the right as shown in Figure 11.43. Select bootmode 0 and type reboot. Further details on the EVM hardware setup can be found in Ref. [12].

Image described by caption and surrounding text.

Figure 11.43 Using the BMC to verify the EVM boot mode selected.

When the boot ends, log in as root as shown in Figure 11.40, then type ifconfig to check the EVM IP addresses as shown in Figure 11.44.

COM12-PuTTY window displaying encircled codes in using ipconfig to check the IP addresses.

Figure 11.44 Using ipconfig to check the IP addresses.

You can change the IP address of eth0 or eth1 by typing ifconfig eth0 192.168.2.105, for example, as shown in Figure 11.45.

COM12-PuTTY window displaying codes in setting the eth0 to IP address 192.168.2.105.

Figure 11.45 Setting the eth0 to IP address 192.168.2.105.

Now that Linux has completed booting, explore the file system as shown in Figure 11.46.

Image described by caption.

Figure 11.46 Monitor showing the file system.

11.7.1 Printing the U‐Boot environment

The U‐Boot environment stores some important configuration parameters. You can read and write these values when you are connected to the U‐Boot console via the serial port. Type printenv to display the U‐Boot envirionment variables as shown here:

11.7.2 Using the help for U‐Boot

To access the commands available, type help as shown here:

11.8 TFTP boot with a host‐mounted Network File System (NFS) server – NFS booting

In order to boot the root file system over NFS, the following four steps have to be performed:

  1. Install the TFTP server. A TFTP server needs to be installed as it is required to host the kernel image.
  2. NFS server. To boot a system over NFS, an NFS server must be available on the local network. This is often the same machine that is being used for software development.

An NFS file server can provide a variety of services to Linux machines on a network:

  1. It can provide a place to store files for a machine to use or write to.
  2. It can be used to allow machines to boot a root file system image stored on the NFS server.
  3. It can provide a place to store file system images when they are captured from a flash like a NAND.
  4. It can be connected to a desktop system to provide a common file store.

It is possible to boot using NFS as the root file system. This method can have two advantages:

  1. Save time during development where the root file system is modified frequently.
  2. Reduce the wear on the on‐board flash device as the flash devices have only a finite number of reprograming cycles.

Figure 11.47 shows the Linux kernel running on a target. Linux is able to mount the root file system from the host.

Schematic illustration of host-mounted NFS server, displaying 2 shaded boxes for host:PC and target:EVM connected by 2 double-headed arrow labeled Ethernet link and Serial link.

Figure 11.47 Host‐mounted NFS server.

For the KeyStone II, there are various examples, as shown in Table 11.15 [11] where the content is shown, and a complete workshop (KeyStone II Multicore Workshop) is included in Ref. [13].

To build and run U‐Boot and the Linux kernel, please refer to Ref. [14].

11.8.1 Laboratory experiment 3

This laboratory experiment shows how to bring up Linux on the EVMK2H using the NFS file system.

  1. Connect the EVM as shown in Figure 11.48.
  2. Set the boot mode to 0010.
    Photo displaying some parts of EVMK2H.
  3. Copy the Linux kernel.
    1. Create a director to hold the TI SDK Linux root file system (e.g. mynfs2) as shown in Figure 11.49. To do so, type:
    2. Locate the file + tisdk‐rootfs.tar.gz, and extract it in the created directory:
      • cd/home/naim/ti/mcsdk_linux_3_00_04_18/images
      • sudo tar xvf tisdk‐rootfs.tar.gz ‐C/mynfs2 (x: extract, v: verbose, f: File, C: change to directory DIR).
  4. Set the environment variables.

    Follow the steps shown in Figure 11.50 to Figure 11.52.

    Power up the board, press any key to hold the board (see Figure 11.52) and set the environment variables as shown here:

    Note: Do not type the comments between the brackets.

  5. Edit the exports file, and specify the file system to use:
    • naim@ubuntu:/$ sudo gedit/etc/exports
      Ubuntu 64-bit- VMware (non-commercial use only) window displaying File, Edit, View, Search, Tools, Documents, and Help menu buttons, with an ellipse highlighting a portion a code on the exports field.
  6. Set the Ethernet to shared as shown in Figure 11.53.
  7. Restart the server by typing (see Figure 11.54):
    • naim@ubuntu:~$ sudo service nfs‐kernel‐server restart
    • naim@ubuntu:~$ sudo service nfs‐kernel‐server status
  8. Booting the board. Type boot as shown in Figure 11.55. After boot, type ‘ls/’ to explore the ‘main’ root directory as shown in Figure 11.56. Type ifconfig in both windows as shown in Figure 11.57 and Figure 11.58 to find the EVM IP address and the IP address for Ubuntu.
Schematic illustrating COM13-PuTTY and COM12-PuTTY windows pointed by arrows from box labeled PC and photo pointed by an arrow from box labeled KeyStone II EVM. USB–Ethernet adaptor and serial cable encircled.

Figure 11.48 EVM setup.

Window displaying highlighted codes home, tftpboot, and tmp used in creating directory.

Figure 11.49 Creating directory to hold the TI SDK Linux root file system.

Device manager window displaying USB Serial Port (COM10) and USB Serial Port (COM11) under Ports (COM & LPT).

Figure 11.50 Check the COM ports.

PuTTY configuration window displaying the category box (left) and the basic options for your PuTTY session box (right) with COM10 and 115200 entries on serial line and speed data fields, with com010 highlighted.

Figure 11.51 Configure the COM ports.

COM10-PuTTY window displaying the codes used in EVM power up and aborting the boot.

Figure 11.52 Power up the EVM and abort the boot.

Editing Ethernet connection 2 window displaying data entry field for connection name and selected IPv4 settings tab with method drop-down bar.

Figure 11.53 Setting the Ubuntu Ethernet connection.

Window displaying the codes used in restarting the server.

Figure 11.54 Restarting the server.

COM10-PuTTY window displaying the codes used in booting the EVM.

Figure 11.55 Booting the EVM.

COM17 – PuTTY window displaying codes for EVM booted.

Figure 11.56 EVM booted.

COM17-PuTTY window displaying the codes in finding the EVM IP address (encircled).

Figure 11.57 Finding the EVM IP address.

Window displaying the codes used in finding the IP address for Ubuntu.

Figure 11.58 Finding the IP address for Ubuntu.

Open FileZilla and type the address. In this case, it is 10.42.0.23 as shown in Figure 11.59, and the username is root.

Sftp://root@10.42.0.23 – FileZilla window displaying highlighted data entry fields for host and username with entries sftp://10.42.0.2 and root, respectively.

Figure 11.59 Connect to the EVM and Ubuntu using FileZilla.

Test if the file system is really on Ubuntu. To do so, navigate to mynfs and create a directory test0 for example, as shown in Figure 11.60.

Window displaying codes for creating a directory.

Figure 11.60 Creating a directory.

Now open the terminal for the EVM and check if the file is available; see Figure 11.61.

COM17 – PuTTY window displaying created directory test0 terminal.

Figure 11.61 Terminal showing the created directory test0.

More examples can be found in Ref. [11], and the content is shown in Table 11.15.

Table 11.15 KeyStone II boot examples [11]

Source: Courtesy of Texas Instruments.

  1. 1 KeyStone II boot examples
    1. 1.1 Boot examples package download
    2. 1.2 Software dependencies
    3. 1.3 Supported hardware
    4. 1.4 Software features
    5. 1.5 Directory structure
    6. 1.6 Building the examples
    7. 1.7 Description of the examples
      1. 1.7.1 Single‐stage boot examples
      2. 1.7.2 Multistage boot example
      3. 1.7.3 Boot media specific details
        1. 1.7.3.1 SPI boot example
        2. 1.7.3.2 I2C boot examples
        3. 1.7.3.3 NAND examples
        4. 1.7.3.4 UART boot examples
        5. 1.7.3.5 Ethernet boot examples
          1. 1.7.3.5.1 K2E Ethernet boot errata work‐around
    8. 1.8 Flashing and running boot examples
      1. 1.8.1 Dip switch settings
      2. 1.8.2 Running I2C EEPROM example
      3. 1.8.3 Running SPI NOR example
      4. 1.8.4 Running NAND example
      5. 1.8.5 Running UART example
      6. 1.8.6 Running Ethernet examples
    9. 1.9 Boot utilities
    10. 1.10 FAQ
    11. 1.11 Related articles and collateral

11.9 Conclusion

In this chapter, the bootloader for the KeyStone I and II devices has been introduced. It has been shown the boot is driven only on the device reset, and the boot configuration is determined by the boot pins that can be read by the device from the DEVSTAT register.

Before booting, the ROM code has no information about the peripheral(s) connected and therefore uses the default parameter table that can be modified by the DEVSTAT. Then the PLLs are initialized if need be and the boot mode specified is performed. Once the download is complete, the specific processor starts executing the downloaded image.

Two practical examples, one for the TMS320C6678 EVM and one for the KeyStone II, have been given.

References

  1. 1 Texas Instruments, Multicore DSP + ARM KeyStone II System‐on‐Chip (SoC), November 2013. [Online]. Available: http://www.ti.com/lit/ds/symlink/66ak2h12.pdf.
  2. 2 Texas Instruments, KeyStone II Architecture ARM Bootloader user guide, July 2013. [Online]. Available: http://www.ti.com/lit/ug/spruhj3/spruhj3.pdf.
  3. 3 Texas Instruments, Multicore fixed and floating‐point digital signal processor, March 2014. [Online]. Available: http://www.ti.com/lit/ds/symlink/tms320c6678.pdf.
  4. 4 Texas Instruments, KeyStone Architecture DSP Bootloader user guide, July 2013. [Online]. Available: http://www.ti.com/lit/ug/sprugy5c/sprugy5c.pdf.
  5. 5 The Santa Cruz Operation, Inc, System V Application Binary Interface edition 4.1, March 18 1997. [Online]. Available: http://www.sco.com/developers/devspecs/gabi41.pdf.
  6. 6 Texas Instruments, Bios MCSDK 2.0.2 IBL update, 14 September 2011. [Online]. Available: http://processors.wiki.ti.com/index.php/Bios_MCSDK_2.0.2_IBL_Update.
  7. 7 Texas Instruments, TMDXEVM6678L EVM hardware setup, 12 January 2016. [Online]. Available: http://processors.wiki.ti.com/index.php/TMDXEVM6678L_EVM_Hardware_Setup.
  8. 8 Processor SDK RTOS BOOT C66x: http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_C66x. [Online].
  9. 9 Texas Instruments, IBL Configuration: C:timcsdk_2_01_02_06 oolsoot_loaderibldoc, [installation of the mcsdk is required].
  10. 10 Texas Instruments, MCSDK user guide: exploring the MCSDK, 11 March 2016. [Online]. Available: http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Running_ U‐Boot.2C_Boot_Monitor_and_Linux_Kernel_on_EVM.
  11. 11 Texas Instruments, KeyStone II boot examples, [Online]. Available: http://processors.wiki.ti.com/index.php/KeystoneII_Boot_Examples?keyMatch=KeyStoneII%20Boot%20Examples&tisearch= Search‐EN. [Accessed January 2017].
  12. 12 Texas Instruments, EVMK2H hardware setup, 1 December 2016. [Online]. Available: http://processors.wiki.ti.com/index.php/EVMK2H_Hardware_Setup#DIP_Switch_and_Bootmode_ Configurations.
  13. 13 T. Instruments, Keystone multicore workshop: lab manual‐SPRP820, April 2014. [Online]. Available: http://www.ti.com/lit/ml/sprp820/sprp820.pdf. [Accessed December 2016].
  14. 14 Build and run U‐boot and Linux kernel on TCI6638 EVM, [Online]. Available: http://www.deyisupport.com/cfs‐file.ashx/__key/telligent‐evolution‐components‐attachments/00‐53‐00‐00‐00‐02‐38‐12/Build‐and‐Run‐U_2D00_boot‐and‐Linux‐Kernel‐on‐TCI6638‐EVM.pdf.

Note

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.221.165.246