Public Version
www.ti.com
Device Initialization by ROM Code
NOTE:
After reset release, the ROM code tries to boot from several interfaces, one after the other
until it finds a bootable one. These interfaces (GPMC, MMC1, MMC2, USB, and UART) are
selected in a specific order defined by the sys_boot settings.
As a consequence, if the first bootable interface found by the ROM code is not the first one
in the list, some activity occurs on the interfaces tested before the bootable interface. This
should be considered in case these intermediary interfaces are connected to other
peripherals for some other purposes (an LED connected to a GPMC pad muxed internally to
a GPIO for instance).
lists the pin multiplexing according to boot peripheral.
Table 26-6. Pin Multiplexing According to Boot Peripheral
Boot Device
Pins
NAND/OneNAND
General-purpose memory controller (GPMC) pins in mode 0
XIP memory
GPMC pins in mode 0
DiskOnChip
GPMC pins in mode 0
MMC/SD1
MMC1 pins in mode 0
MMC/SD2
MMC2 pins in mode 0
UART3
UART3 pins in mode 0
HS USB
HSUSB0 pins in mode 0
CAUTION
•
UART boot: UART3 is the only possible UART from which boot can be
performed. Additionally, only UART3 pins that provide UART3 functionality
in their MUXMODE 0 can be used. No other UART configuration allows
booting from the UART.
•
HS USB boot: If the internal USB transceiver of a supported
power-management IC is used, the IC's configuration interface must be
connected to the device through I2C1. No other I
2
C interface is supported
for this purpose. If other USB transceiver is used, the ROM code assumes it
is powered, clocked, and out of reset.
26.4.1.2 Main Features
The ROM code architecture is shown in
. The ROM code is made up of several modules:
•
The start-up module takes care of basic system configuration and dispatches control to the booting
module.
•
The clock detection module supports startup by detecting the system clock frequency.
•
The booting module uses several device drivers to boot from an external device.
•
The device drivers implement device protocols and perform logical operation on a device. They are
abstracted from interface hardware by several interface drivers, which are responsible for interacting
with hardware interface facilities.
•
The interrupt handler module provides services used by all modules. It allows registering interrupt
service routines (ISRs) and calls them when an interrupt occurs.
shows each module.
3521
SWPU177N – December 2009 – Revised November 2010
Initialization
Copyright © 2009–2010, Texas Instruments Incorporated
