OMAP-L137 Bootloader

This document describes the boot process of the OMAP-L137 ARM+DSP SOC. The content also applies to AM1707 and C6747/5/3 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, with the exception of some emulator related pins.

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 the section of the datasheet titled "Pullup/Pulldown Resistors" for details on how to choose values to oppose the internal pullup/pulldown resistors.

After Reset

On the rising edge of RESET, 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 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 DSP executable.

* For AM1707 devices, a proprietary boot controller will initialize the ARM, which will then read and parse the AIS commands.
** 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 ARM will be powered down in reset, so it is not possible to connect to the ARM via emulation unless it is taken out of reset by the DSP.

FAQ

How do I boot a DSP executable?

The DSP 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 an ARM executable?

Since this is a DSP-boot device, a DSP executable must be booted first and wake up the ARM.

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

Why does my program work in CCS but doesn't work when booting?

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, 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 System Reference Guide 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.

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.

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 ARM may still be asleep unless the DSP or a GEL file wakes up the ARM 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-L137 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:

• DSP UBL (sets the ARM reset vector and takes it out of reset)
• ARM UBL (sets up DDR, PSC, and copies U-Boot to memory)
• U-Boot (loads Linux and file system)
• Linux

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

• AIS-signed DSP UBL (sets ARM reset vector, sets up DDR and PSCs, copies U-Boot to memory, and takes ARM out of reset)
• U-boot (loads Linux and file system)
• Linux

So in general, there is not a need for an ARM UBL, as the AIS functions in the DSP UBL 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]