OMAP-L138 Bootloader

From Texas Instruments Wiki
Jump to: navigation, search

This document describes the boot process of the OMAP-L138 ARM+DSP SOC. The content also applies to AM1808 and C6748 devices unless otherwise specified.

During Reset

There are two types of reset:

  • Power-On Reset (POR) - POR occurs when both RESET and TRST are low. Internal memory is cleared during this state. The boot pins will be latched when RESET goes high
  • Warm Reset - Warm Reset occurs when RESET is low and TRST is high. Internal memory is retained during this state. The boot pins will be not be latched when RESET goes high, but instead retain the same values from the last POR.

It is important for the device to experience a POR when initially powered up. This will clear the emulation and PLL logic, as well as latch the boot pins correctly. Therefore make sure TRST is externally pulled down on your board. Not doing so can be the cause of many boot related problems.

When the device is held in reset, all device IOs are internally pulled down.

For the boot and configuration pins, if they are both routed out and 3-stated (not driven), it is strongly recommended that an external pullup/pulldown resistor be implemented. Although, internal pullup/pulldown resistors exist on these pins and they may match the desired configuration value, providing external connectivity can help ensure that valid logic levels are latched on these device boot and configuration pins. In addition, applying external pullup/pulldown resistors on the boot and configuration pins adds convenience to the user in debugging and flexibility in switching operating modes.

See section 3.3 of the datasheet, "Pullup/Pulldown Resistors" for details on how to choose values to oppose the internal pullup/pulldown resistors.

After Reset

On the rising edge of RESETn, the following steps will occur:

  1. The boot pins will be latched. Note: This only occurs when coming out of a POR, as the boot pins will not be relatched after a warm reset.
  2. The DSP will come out of reset and begin execution of the DSP ROM bootloader *
    1. The DSP ROM bootloader will indirectly write the ARM reset vectors. Since the DSP does not have write access to the ARM local RAM, the PRU is used to perform this task
    2. The DSP takes the ARM out of reset and powers down
  3. The ARM begins execution of the ARM ROM bootloader
    1. The ARM ROM bootloader will read from the boot medium and begin sequentially executing the AIS commands in the boot image **.
    2. The last AIS command will jump to the entry point of the ARM executable.
* For AM1808 devices, the DSP is replaced by a proprietary boot controller which is only used for booting the ARM core. For C6748 devices, the DSP will read the image and perform the AIS parsing.
** For non-AIS boot modes such as NOR legacy, or NOR direct, the process will be different. See the bootloader application note for details on these boot modes.

Note that after the boot process, the DSP will be powered down in reset, so it is not possible to connect to the DSP via emulation unless it is taken out of reset by the ARM.


How do I boot an ARM executable?

The ARM executable in COFF/ELF must be converted to AIS format using the AISgen tool.

See the following wiki for more details and examples on this process: [1]

How do I boot a DSP executable?

Since OMAP-L138 is an ARM-boot device, an ARM executable must be booted first and wake up the DSP. For C6748, the DSP AIS binary can be booted directly.

See the following wiki for more details and examples on this process: [2]

Are there any sample AISgen config files that work with the EVM?

The following file contains AISgen config files that set up the core/mDDR frequencies to 456/150 MHz and 300/132 MHz.

Download Sample AISgen Config Files

Note that the core voltage must be scaled appropriately when choosing an OPP.

Why does my program work in CCS but doesn't boot from Flash?

GEL file reliance

The most common problem is that some configuration is done in the GEL file that the code needs, such as external memory configuration, pinmux configuration, or PLL configuration. Most of these functions can also be performed by the bootloader using the AISgen tool. Compare the PLL, pinmux, and DDR registers after booting and verify they match what the GEL file sets them to.

Incorrect external memory configuration

If your code has sections in external memory, the bootloader must configure the controller settings before the code is copied. Verify that the DDR configuration settings used in AISgen match those used in the GEL file. You should be able to poke the DDR memory region in CCS (0xC0000000) if the DDR is configured correctly.

ARM Supervisor vs User mode

By default the TI Code Generation tools for the ARM put the ARM in user mode. This means that certain SYSCFG registers, such as those that control the pinmuxing, cannot be modified by the code. To keep the ARM in supervisor mode, a modified boot.asm file should be included in your ARM project. This file can be found in the following LED blink example project: [3]. In CCS3.3, the "Resolve Symbols to First Library (-priority)" box should be checked in the project linker options to avoid linking errors.

KICK Register unlocking

On previous revision devices (1.0 and 1.1), the KICK registers must be unlocked before accessing certain protected registers. While your GEL file in CCS may do this automatically, it should be done once at the beginning of your code to make it portable. See the Technical Reference Manual for more information on this process.

Incorrect boot mode

Double check that the boot pins are at proper voltages by the rising edge of RESET. Use the Debug GEL File to determine what boot mode the device latched and see any other ROM error messages. Also verify that TRST is externally pulled down.

Using the bootloader shared memory

The ROM bootloader itself uses 16 KB of Shared RAM starting from 0x80000000 for multiple purposes. This memory should not be used by any initialized section of the user application.

RAM vs ROM autoinitialization model

When booting code through the ROM, make sure you are using the ROM autoinitialization model (-c) in your linker options. If the RAM autoinitialization model is used (-cr) some memory locations will never get loaded, even though they did under CCS. You can find the build option here:

CCS3.3: Build Options -> Linker -> Autoinit Model

CCS4+: Build Options -> Runtime Environment

When should I use Emulation Boot Mode?

Emulation boot mode will wake up both the ARM and DSP and put them both in while(1) spin loops. This allows you to connect to both the ARM and DSP immediately after booting.

You can still connect with your emulator in other boot modes. However the DSP may still be asleep unless the ARM or a GEL file wakes up the DSP core.

In general, this boot mode does not need to be used and is provided to put the device in a known state without loading a boot image.

Do I need a secondary bootloader (UBL)?

A secondary bootloader, AKA User Bootloader (UBL), was required on older devices, where the bootloader could not parse AIS files. By using the AISgen tool with the OMAP-L138 bootloader, most of the functions previously performed by the UBL can be done instead by the bootloader.

For a typical Linux application, the old flow looked something like this:

  • UBL (sets up DDR, PSC, and copies U-Boot to memory)
  • U-Boot (loads Linux and file system)
  • Linux

The flow for the OMAP-L138 would look like this:

  • AIS-signed U-boot (sets up DDR, PSC, and loads Linux and file system)
  • Linux

So in general, there is not a need for a separate UBL, as the AIS functions can perform most of the same tasks.

How do I prepare an image for NOR direct or NOR legacy boot modes?

See the following wiki for instructions on creating the boot image: [4]

How should an SD/MMC card be formatted in order to boot?

See the following page for details on preparing the SD/MMC card: [5]