OMAP35x and AM/DM37x Initialization

This page provides tips on debugging initialization and bring-up issues with the AM37x devices.

Power sequencing

• ensure that correct power sequencing is occurring on your board. Power sequencing specifications can be found in the data manual. In general there are no timing related specs, only that each voltage rail in the sequence must ramp individually and reach 90% of its voltage before the following rail can start ramping up. For TPS6595xx devices, this is typically done automatically. For discrete solutions, the TPS65023 design-in wiki or the the TPS65073 design-in wiki can guide you on properly designing for the correct power sequencing.

Boot sequence

• Check your SYS_BOOT signals to ensure that you have the correct boot sequence. Boot sequence tables can be found in the initialization chapter of the TRM. These define which sources the device will potentially boot from, and in what order. If you have access to memory (via JTAG, for example), you can see what the processor read from the SYS_BOOT signals by reading the CONTROL_STATUS register (0x480022F0), bits 0-5.
• The ROM will attempt to boot from each boot source in the defined boot sequence. If the first boot source fails to boot, the ROM will move on to the next one in the sequence. Keep in mind that some boot sources take some time to timeout if that boot source isn't avaiable (for example, USB or Ethernet). Thus, your bootup make take several seconds longer if your typical boot source is further down in the boot sequence. This is particularly evident on the AM35x EVM. If you boot from MMC on that EVM, it is 4th in a sequence behind NAND, USB, and Ethernet.

Tracing vectors

• Tracing vectors give you some indication what the ROM code executed in its attempt to boot. This can help you determine how far the ROM got before failing to boot, and can give you some idea as to why it failed. Information on the tracing vector can be found in the Initialization chapter of the TRM. Here are some tips:

• These are the pertinent registes for tracing data. The first 2 (0xB0 and 0xB4) contain the tracing data from the last boot sequence. The tracing vector is generally around 50 bits of information, spread across 2 32-bit words.

• • 0x4020FFB0 Current tracing vector, word 1
  • 0x4020FFB4 Current tracing vector, word 2

• This register contains a copy of the reset status register, which will give you an indication of why the processor got reset (for example, VDD1/VDD2 voltage manager reset, External warm reset, MPU watchdog reset, Global software reset, DPLL3 software reset, Global cold reset

• • 0x4020FFB8 Current copy of the PRM_RSTST register (reset reasons)

• These registers contain the tracing vectors from the first time after a cold reset.
• 0x4020FFBC Cold reset run tracing vector, word 1
• 0x4020FFC0 Cold reset run tracing vector, word 2
• 0x4020FFC4 Reserved

Here are some examples on how to interpret the tracing vectors:

Tracing Example 1

SYSBOOT = 001111 (boot from NAND,USB,UART3,MMC1) After failed boot, cold reset tracing vector reads:

• 0x4020FFBC = 0x0007307F
• 0x4020FFC0 = 0x001E0044

Comparing this to the tracing vector table in the Initialization Chapter of the TRM, we see that the following bits are set:

Bit	Meaning	Comment
0	Reset	Reset occurred
1	ROM code C main	ROM code hit the main() function in the C code
2	ROM code runs after the cold reset
3	Booting started
4	Memory booting started	Indicates that the ROM attempted to boot from a memory source
5	No more booting device to check	Indicates that the ROM exhaused all boot sources
6	Peripheral booting started	Indicates that the ROM attempted to boot from a peripheral source
7	Booting message "change device"	Indicates ROM moved to the next booting source in the sequence
12	Device initialized	Indicates that the peripheral device was initialized
13	ASIC-ID sent	ID was sent as part of the UART boot process
16	Peripheral booting failed	Indicates boot failed (in this case, UART boot, since it was the only peripheral boot source)
17	UART	Indicates UART booting was attempted
18	USB	Indicates booting from USB was attempted
34	NAND	Indicates booting from NAND was attempted
38	MMC/SD1	Indicates booting from MMCSD1 was attempted
49-51	NAND boot	Indicates NAND booting was attempted from the first 4 blocks of the NAND.

Tracing Example 2

SYSBOOT = 110001 (boot from USB,UART,MMC1,MMC2) After failed boot, cold reset tracing vector reads:

• 0x4020FFBC = 0x0007307F
• 0x4020FFC0 = 0x00000060

Comparing this to the tracing vector table in the Initialization Chapter of the TRM, we see that the following bits are set:

Bit	Meaning	Comment
0	Reset	Reset occurred
1	ROM code C main	ROM code hit the main() function in the C code
2	ROM code runs after the cold reset
3	Booting started
4	Memory booting started	Indicates that the ROM attempted to boot from a memory source
5	No more booting device to check	Indicates that the ROM exhaused all boot sources
6	Peripheral booting started	Indicates that the ROM attempted to boot from a peripheral source
7	Booting message "change device"	Indicates that ROM code moved on to another booting source
12	Device initialized	Indicates that the peripheral device was initialized
13	ASIC-ID sent	ID was sent as part of the UART boot process
16	Peripheral booting failed	Indicates one of the peripheral booting sources faied (either USB or UART in this case)
17	UART	Indicates UART booting was attempted
18	Peripheral boot	Indicates USB booting was attempted
37	MMC/SD2	Indicates booting from MMCSD2 was attempted
38	MMC/SD1	Indicates booting from MMCSD1 was attempted

NAND Booting

For those needed help in performing NAND booting on their custom boards, please refer to the OMAP Flashing wiki

UART/USB Booting

Here is some additional information on the ASIC ID Structure used during UART3 and USB booting. Only the information for Public general purpose (GP) devices is shown here. The ASIC ID is 58 bytes on UART and 69 Bytes on USB. Note that the Checksum subblock is not transmitted over the UART, only over USB.

ASIC ID Item	Size (bytes)	Description
Items	1	Number of sub blocks
ID Subblock	7	Device identification information
Reserved for non-GP devices	4	see Reserved1
2nd ID Subblock	23	ROM Identification data
Reserved for non-GP devices	23	see Reserved2
Checksum subblock	11	CRC

Items

Offset	Size (bytes)	Value
00h	1	05h - number of sub blocks USB 04h - number of sub blocks UART

ID Subblock

Offset	Size (bytes)	Value
01h	1	01h - sub block ID
02h	1	05h - sub block size
03h	1	01h - fixed value
04h	2	34h, 30h - OMAP chip version for OMAP35x 36h, 30h - OMAP chip version for AM/DM37x
06h	1	07h - ASCII bell
07h	1	XXh - ROM revision

Reserved1

Offset	Size (bytes)	Value
08h	1	13h - sub block ID
09h	1	02h - sub block size
0Ah	1	01h - fixed value
0Bh	1	00h - GP device

2nd ID Sub block

Offset	Size (bytes)	Value
0Ch	1	12h - sub block ID
0Dh	1	15h - sub block size
0Eh	1	01h - fixed value
0Fh	20h	00h - GP device

Reserved2

Offset	Size (bytes)	Value
23h	1	14h - sub block ID
24h	1	15h - sub block size
25h	1	01h - fixed value
26h	20	00h ... - GP device

Checksum Subblock

Offset	Size (bytes)	Value
3Ah	1	15h - sub block ID
3Bh	1	09h - sub block size
3Ch	1	01h - fixed value
3Dh	4	XXXXXXXXh - ROM CRC
41h	4	00000000h

ASIC ID output examples

MMC booting

• Please see the following wiki: SD-MMC Usage Notes on OMAP35x and AM/DM37x for details on MMC/SD operation (including managed NAND like eMMC and moviNANDs) during booting.